Issues Configuring LDAP Authentication

Search Guard
1

I’m attempting to configure LDAP authentication in Kibana. I’ve loaded the attached sg_config.yml into Elasticsearch. However, when I attempt to login, I get the following error after clicking “Login”:

{"statusCode":403,"error":"Forbidden","message":"no permissions for [indices:data/read/search] and User [name=CN=username,OU=users,DC=example,DC=com, backend_roles=[], requestedTenant=null]: [security_exception] no permissions for [indices:data/read/search] and User [name=CN=username,OU=users,DC=example,DC=com, backend_roles=[], requestedTenant=null]"}

This would suggest to me that authentication is working, but authorization is not. However when I look in the GUI to check the status of LDAP authentication, it states that it’s Disabled (see screenshot).

Attached are screenshots of the “LDAP Disabled” message, sg_config.yml, and kibana.yml.

I’m using Elasticsearch/Kibana 7.6.2, with the corresponding version of Search Guard.

Edit

I should also note that we are using nested AD groups for authentication (i.e., we search on group-1, but users are actually members of group-2, group-3, group-4, which are in turn members of group-1).

LDAP Auth Disabled Screenshot
LDAP Auth Disabled Screenshot797×313 29.9 KB
kibana.yml (1.6 KB) sg_config.yml (6.8 KB)

2

I see you have the LDAP module disabled. Enable it like this

sg_config.yml

authc:
  ldap:
    enabled: true

authz:
  ldap:
    enabled: true

See the docs to find out more about all available LDAP authc and authz options.

Also, don’t change ldap module name in sg_config.yml. There is a bug that prevents rendering the LDAP module information in the UI if the name was changed. The bug will be fixed in the next release.

3

Updated as shown above, now I receive the following error when loading sg_config.yml:

ERR: Seems /tmp/sgadmin/sgconfig/sg_config.yml is not in SG 7 format: com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "enabled" (class com.floragunn.searchguard.sgconf.impl.v7.ConfigV7$AuthcDomain), not marked as ignorable (6 known properties: "http_enabled", "transport_enabled", "http_authenticator", "authentication_backend", "order", "description"])

Additionally, just as a note - naming the ldap module in authz roles_from_my_ldap is how it’s shown in the sample sg_config.yml file included with Search Guard (see below) - this should probably be updated.
Additionally, when I change the authz.roles_from_myldap to authz.ldap as shown in the instructions, that’s when it fails to render for me.

LDAP Missing

Sample sg_config.yml:

roles_from_myldap:
  description: "Authorize via LDAP or Active Directory"
  http_enabled: false
  transport_enabled: false
  ...
4

…also, is this issue resolved in 41.0.0, which was announced today? I’m not seeing it in the changelogs.

5

Can you send all Elasticsearch log? Restart it and record all log.

I look at your sg_config.yml and wonder, are you really running LDAP on example.com? Maybe you did a typo. Use your real LDAP domain.

  authc
    ...
              hosts:
                - ldap.example.com:636
              bind_dn: CN=ldap_user,OU=Service Accounts,DC=example,DC=com
              password: changeme
              users:
                example:
                  base: 'OU=users,DC=example,DC=com'

  authz
    ...
              hosts:
                - ldap.example.com:636
              bind_dn: CN=ldap_user,OU=Service Accounts,DC=example,DC=com
              password: changeme
              roles:
                example:
                  base: 'OU=Elastic Stack,OU=groups,DC=example,DC=com'
              ...
              users:
                example:
                  base: 'OU=users,DC=example,DC=com'

Also, you need to configure userbase, userbase and maybe username_attribute. Read this doc LDAP Authentication | Security for Elasticsearch | Search Guard to find more.

Unrecognized field “enabled”

I was wrong. The enabled option was deprecated some time ago but the docs have not been updated. The docs will be fixed soon.

Also, don’t change ldap module name in sg_config.yml …
is this issue resolved in 41.0.0 …?

The plan is to resolve this issue in the next release. The ETA is approximately one month.

6

Also, the following blog posts can be useful:

7

Thanks - glad to know it’s not me.

Don’t worry - I’m not using example.com. I’ve sanitized all files for posting

According to the documentation, there are two different ways to configure the userbase & rolebase:

The first is:

authc:
  userbase: 'ou=people,dc=example,dc=com'
authz:
  rolebase: 'ou=groups,dc=example,dc=com'

The second is:

authc:
  users:
    primary-userbase:
      base: 'ou=people,dc=example,dc=com'
      search: '(uid={0})'
    secondary-userbase:
      base: 'ou=otherpeople,dc=example,dc=com'
      search: '(initials={0})'
    tertiary-rolebase:  # <-- this is a typo in the documentation
      ...

authz:
  roles:
    normalroles:
      base: 'ou=groups,dc=example,dc=com'
      search: '(uniqueMember={0})'
    other:
      base: 'ou=othergroups,dc=example,dc=com'
      search: '(owner={0})'

…which is what I’m using:

authc:
  users:
    example:
      base: 'OU=Users,DC=example,DC=com'
      search: '(sAMAccountName={0})'
  ...

authz:
  roles:
    example:
      base: 'ou=Groups,DC=example,DC=com'
      search: '(member={1})'
  ...

Is this correct? I’m using this format so that, once I have it working for our primary domain, I can add a secondary domain. Note that, according to this answer on another ticket, the names for userbase/rolebase don’t matter and can be arbitrarily chosen. I did this in a previous (working) configuration, but unfortunately that instance and those config files appear to be lost forever, which is why I’m starting from scratch again.

I’ve also sent you a copy of all Elasticsearch and Kibana logs by PM. Elastic logs are set to DEBUG for Search Guard, and Kibana logs are set to VERBOSE.

Finally - I’ll review the two blog posts you recommend, to see if either of them appear to apply.

Thanks!

Edit 1

An additional question: I observe that authc.basic_internal_authentication.transport_enabled: true is set, but I have authc.ldap.transport_enabled: false and authz.roles_from_myldap.transport_enabled: false set. Should these be true? Because I’m still seeing disabled for both LDAP authentication and authorization.

Edit 2

I set authc.ldap.transport_enabled: true and authz.roles_from_myldap.transport_enabled: true and the “Disabled” has disappeared from both authentication and authorization, but no change in behavior. I suspect that this setting only impacts whether LDAP accounts can be used on the transport port, is this correct? I wasn’t able to find clarification in the documentation.

9

OK…mostly resolved. The key ended up being changing authz.roles_from_myldap.userrolename: disabled to userrolename: memberOf.

At this point, I can use the AD Group Name as a backend role and successfully login. However, this appears to prevent me from setting a group name to having the equivalent permissions of the admin and kibanaserver back-end roles. I attempted to do this by duplicating the SG_ALL_ACCESS role (for admin) and renaming it, but that doesn’t appear to work. I’m opening another question with that, since this one is resolved.

1 Like
10

The option .transport_enabled enables Elasticsearch transport protocol. It is used if a client supports it. Now to have LDAP shown as enabled in the UI you need to set both transport_enabled and http_enabled to true.

11

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.