skip_users config option for authc section

42 views
Skip to first unread message

Brian

unread,
Dec 3, 2018, 12:52:45 PM12/3/18
to search...@googlegroups.com
ELK: 6.4.2
SearchGuard 23.2
SearchGuard Kibana: 16

The use case is having multiple LDAP authentication sources that have no access (Active Directory trust relationship) to cross authenticate users from a different LDAP domain.  This means that each LDAP domain will have its own set of LDAP authc and authz sections.  To make life easier with this multiple LDAP configuration the username is specified in the userPrincipalName format.  us...@foo.com and us...@bar.com as two examples.  

For authz, having the skip_users option field is amazing since it is very easy to configure a regex for the skip user that catches the domain of the other domain.  This prevents LDAP authorization requests from being issued against LDAP domains that do not contain that user.

Does this exist as an undocumented configuration option on the authc section?  I tried and it will import without any problem and it is visible in the GUI, but it doesn't appear to do anything.  This would be similarly very useful on the authc section to prevent LDAP authentication attempts being made against LDAP domains that do not have the ability to authenticate that user.

Config snippet below shortened to only show the above concept.  The two authc skip_users options highlighted in yellow



searchguard:
  dynamic:
    authc:
      foo_ldap:
        order: 2
        authentication_backend:
          type: ldap
          config:
            userbase: 'dc=foo,dc=com'
            usersearch: '(userPrincipalName={0})'
            skip_users:
              - '*bar.com'
      bar_ldap:
        order: 2
        authentication_backend:
          type: ldap
          config:
            userbase: 'dc=bar,dc=com'
            usersearch: '(userPrincipalName={0})'
            skip_users:
              - '*foo.com'
    authz:
      foo_ldap:
        authorization_backend:
          type: ldap
          config:
            userbase: 'dc=foo,dc=com'
            skip_users:
              - '*DC=bar,DC=com*'
      bar_ldap:
        authorization_backend:
          type: ldap
          config:
            userbase: 'dc=bar,dc=com'
            skip_users:
              - '*DC=foo,DC=com*'

SG

unread,
Dec 6, 2018, 6:59:47 PM12/6/18
to search...@googlegroups.com
Fort authc this currently not implemented.
Can you file a github issue for this feature request?

And if you use regex in Search Guard config file you shoulds omit the leading ^ and and trailing $, so that it looks like: '/[^@]+@bar\.com/'

> Am 03.12.2018 um 18:52 schrieb Brian <bria...@gmail.com>:
>
> ELK: 6.4.2
> SearchGuard 23.2
> SearchGuard Kibana: 16
>
> The use case is having multiple LDAP authentication sources that have no access (Active Directory trust relationship) to cross authenticate users from a different LDAP domain. This means that each LDAP domain will have its own set of LDAP authc and authz sections. To make life easier with this multiple LDAP configuration the username is specified in the userPrincipalName format. us...@foo.com and us...@bar.com as two examples.
>
> For authz, having the skip_users option field is amazing when dealing with UPN formatted usernames since it is very easy to configure a regex for the skip user that catches the domain name portion of the UPN username. This prevents LDAP authorization requests from being issued against LDAP domains that do not contain that user.
>
> Does this exist as an undocumented configuration option on the authc section? I tried just in case but did not have any luck. This would be similarly very useful on the authc section to prevent LDAP authentication attempts being made against LDAP domains that do not have the ability to authenticate that user.
>
> Config snippet below shortened to only show the above concept. The two authc skip_users options highlighted in yellow
>
>
>
> searchguard:
> dynamic:
> authc:
> foo_ldap:
> order: 2
> authentication_backend:
> type: ldap
> config:
> userbase: 'dc=foo,dc=com'
> usersearch: '(userPrincipalName={0})'
> skip_users:
> - '/^[^@]+@bar\.com$/'
> bar_ldap:
> order: 2
> authentication_backend:
> type: ldap
> config:
> userbase: 'dc=bar,dc=com'
> usersearch: '(userPrincipalName={0})'
> skip_users:
> - '/^[^@]+@foo\.com$/'
> authz:
> foo_ldap:
> authorization_backend:
> type: ldap
> config:
> userbase: 'dc=foo,dc=com'
> skip_users:
> - '/^[^@]+@bar\.com$/'
> bar_ldap:
> authorization_backend:
> type: ldap
> config:
> userbase: 'dc=bar,dc=com'
> skip_users:
> - '/^[^@]+@foo\.com$/'
>
> --
> You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
> To post to this group, send email to search...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/e2786155-4d16-4659-8461-eddf7e0d7c7c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Jochen Kressin

unread,
Dec 16, 2018, 5:04:12 PM12/16/18
to Search Guard Community Forum
Added this feature request under ITT-1789, targeted for SG7, but let's discuss if we want to release it earlier. I opt for making this feature available for all authc and authz modules.
> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.

Brian

unread,
Dec 16, 2018, 6:39:18 PM12/16/18
to Search Guard Community Forum
Not sure if this was a question for me?

I have immediate use for it dealing with 3+ LDAP sources so my answer would be biased. ;)

RE: making available on all authc and authz modules, I can imagine several use cases if this were implemented and agree with you.  It is incredibly useful when dealing with multiple authc and authz options in the same config.  It is similar in functionality to a 'domain' dropdown box on the login screen found on many products....just done on the back end without needing the dropdown box.
Reply all
Reply to author
Forward
0 new messages