skip_users config option for authc section

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. user1@foo.com and user2@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

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 <briansrch@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. user1@foo.com and user2@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+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@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.

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.

···

On Friday, December 7, 2018 at 12:59:47 AM UTC+1, Search Guard wrote:

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 briansrch@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. user1@foo.com and user2@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+unsubscribe@googlegroups.com.

To post to this group, send email to search-guard@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.

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. :wink:

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.