Issues Configuring LDAP Authentication

[Doug_Renze]

@srgbnd

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

Thanks - glad to know it’s not me.

@srgbnd

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.

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

@srgbnd

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

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

@srgbnd

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

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.