Can't bind to LDAP server

OpenSearch Dashboards
1

Versions 2.6

Describe the issue:

Can’t bind to ldap server. I am trying to login to Dashboards with another user, but I am using a service account to bind to LDAP server.

Configuration:

      ldap:
        description: "Authenticate via LDAP or Active Directory"
        http_enabled: false
        transport_enabled: false
        order: 2
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          # LDAP authentication backend (authenticate users against a LDAP or Active Directory)
          type: ldap
          config:
            # enable ldaps
            enable_ssl: false
            # enable start tls, enable_ssl should be false
            enable_start_tls: false
            # send client certificate
            enable_ssl_client_auth: false
            # verify ldap hostname
            verify_hostnames: true
            hosts:
            - tx01-ldap.example.pvt:389
            - va01-ldap.exmaple.pvt:389
            bind_dn:
            - 'OU=Service Accounts,OU=System Accounts,DC=example,DC=pvt'
            password: xxxxxxxxxxx
            userbase:
            - 'OU=Employees,OU=People,DC=corp,DC=pvt'
            - 'OU=Service Accounts,OU=System Accounts,DC=corp,DC=pvt'
            # Filter to search for users (currently in the whole subtree beneath userbase)
            # {0} is substituted with the username
            usersearch: '(CN={0})'
            # Use this attribute from the user as username (if not set then DN is used)
            username_attribute: LogstashServer

Relevant Logs or Screenshots:

Authentication finally failed for johndoe123 from

johndoe123 is part of the OU=Employees,OU=People,DC=corp,DC=pvt in AD

2

Whats the full DN of jondoe123?

I have the feeling the the issue might be with usersearch: '(CN={0})'

Also, if you are not performing a TLS verifications I think you can set verify_hostnames: true to false.

1 Like
3

@jasonrojas it’s this

CN=johndoe123,OU=Employees,OU=People,DC=corp,DC=pvt

4

Thats strange, the config looks fine, Can you see any errors on the AD side?

5

Sounds good, I will ask the guys responsible for AD to take a look

6

I just noticed bind_dn: - 'OU=Service Accounts,OU=System Accounts,DC=example,DC=pvt'

Are you missing the actual bind user perhaps?

7

I have the username_attribute: LogstashServer in the config, which supposed to append to the rest of the bind_dn if I understand it correctly?

I also tried to use this as you suggested, but no luck

bind_dn: - ‘CN=LogstashServer,OU=Service Accounts,OU=System Accounts,DC=example,DC=pvt’

Also checked with AD guy, he is not seeing anything coming to AD with that service account from OpenSearch Dashboard IP.

I can run ldapsearch using this same bind and do a query.

What I want to understand is, from the dashboard service perspective, how does the login for AD users work? It uses bind_dn to bind in the background, and query a user trying to login as a query parameter, based on the user base?

8

Ah thats the issue, thats not what the username_attribute field is for…
for instance with my setup when it auths against AD this is what I have:

            bind_dn: 'CN=svcuser,OU=Service,DC=x,DC=com'
            password: '<redacted>'
            userbase: 'dc=x,dc=com'
            # Filter to search for users (currently in the whole subtree beneath userbase)
            # {0} is substituted with the username×
            usersearch: '(sAMAccountName={0})'
            # Use this attribute from the user as username (if not set then DN is used)
            username_attribute: 'sAMAccountName'

So the issue is you need to set your bind_dn to the proper DN, and the username attribute to CN if that is where you store your username

9

Ok I will give it a try and let you know

10

@stecino Did you resolve your issue? If not, could you share your ldapsearch command?

11

@pablo thanks for following up, here is my ldapsearch command

ldapsearch -h ca01-ldap.corp.pvt -p 389 -b "dc=corp,dc=pvt" -D "corp\LogstashServer" -W "cn=johndoe123" cn uid homeDirectory sAMAccountName name distinguishedName
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=corp,dc=pvt> with scope subtree
# filter: cn=johndoe123
# requesting: cn uid homeDirectory sAMAccountName name distinguishedName
# with pagedResults control: size=100
#

# johndoe123, Employees, People, corp.pvt
dn: CN=johndoe123,OU=Employees,OU=People,DC=corp,DC=pvt
cn: johndoe123
distinguishedName: CN=johndoe123,OU=Employees,OU=People,DC=corp,DC=pvt
name: johndoe123
sAMAccountName: johndoe123

This is what I have for my bind_dn

bind_dn: ‘CN=LogstashServer,OU=Service Accounts,OU=System Accounts,DC=corp,DC=pvt’

should i add corp\ infront?

12

@stecino You should test the ldapsearch with bind_dn.

ldapsearch -h ca01-ldap.corp.pvt -p 389 -b "dc=corp,dc=pvt" -D "CN=LogstashServer,OU=Service Accounts,OU=System Accounts,DC=corp,DC=pv" -W "cn=johndoe123" cn uid homeDirectory sAMAccountName name distinguishedName
13

@pablo

It worked, but then what else could be wrong for ldap user not being able to login?

14

@pablo this is what I have, maybe single quotes need to be replaced?

ldap:
description: “Authenticate via LDAP or Active Directory”
http_enabled: false
transport_enabled: false
order: 2
http_authenticator:
type: basic
challenge: false
authentication_backend:
# LDAP authentication backend (authenticate users against a LDAP or Active Directory)
type: ldap
config:
# enable ldaps
enable_ssl: false
# enable start tls, enable_ssl should be false
enable_start_tls: false
# send client certificate
enable_ssl_client_auth: false
# verify ldap hostname
verify_hostnames: true
hosts: ‘ca01-ldap.corp.pvt:389’
bind_dn: ‘CN=LogstashServer,OU=Service Accounts,OU=System Accounts,DC=corp,DC=pvt’
password: ‘xxxxxx’
userbase:
- ‘OU=Employees,OU=people,DC=corp,DC=pvt’
- ‘OU=Service Accounts,OU=System Accounts,DC=corp,DC=pvt’
# Filter to search for users (currently in the whole subtree beneath userbase)
# {0} is substituted with the username
usersearch: ‘(CN={0})’
# Use this attribute from the user as username (if not set then DN is used)
username_attribute: ‘CN’

15

When you get this error do you have any other preceding LDAP-related errors in OpenSearch logs?

Could you share your current config.yml?

16

No other logs pertaining to that, please see my ldap config above

17

Reloading security setting via POST API call should be sufficient enough, correct? Or do I need to restart opensearch on all the nodes?

18

@stecino It should. Just check with the below API request if the config has been applied.

GET _plugins/_security/api/securityconfig
19

Looks like it’s not showing the ldap I have setup? authz per documentation I can setup in the roles.yml file

{
  "config" : {
    "dynamic" : {
      "filtered_alias_mode" : "warn",
      "disable_rest_auth" : false,
      "disable_intertransport_auth" : false,
      "respect_request_indices_options" : false,
      "kibana" : {
        "multitenancy_enabled" : true,
        "server_username" : "kibanaserver",
        "index" : ".kibana"
      },
      "http" : {
        "anonymous_auth_enabled" : false,
        "xff" : {
          "enabled" : false,
          "internalProxies" : "192\\.168\\.0\\.10|192\\.168\\.0\\.11",
          "remoteIpHeader" : "X-Forwarded-For"
        }
      },
      "authc" : {
        "jwt_auth_domain" : {
          "http_enabled" : false,
          "transport_enabled" : false,
          "order" : 0,
          "http_authenticator" : {
            "challenge" : false,
            "type" : "jwt",
            "config" : {
              "signing_key" : "base64 encoded HMAC key or public RSA/ECDSA pem key",
              "jwt_header" : "Authorization"
            }
          },
          "authentication_backend" : {
            "type" : "noop",
            "config" : { }
          },
          "description" : "Authenticate via Json Web Token"
        },
        "ldap" : {
          "http_enabled" : false,
          "transport_enabled" : false,
          "order" : 5,
          "http_authenticator" : {
            "challenge" : false,
            "type" : "basic",
            "config" : { }
          },
          "authentication_backend" : {
            "type" : "ldap",
            "config" : {
              "enable_ssl" : false,
              "enable_start_tls" : false,
              "enable_ssl_client_auth" : false,
              "verify_hostnames" : true,
              "hosts" : [
                "localhost:8389"
              ],
              "userbase" : "ou=people,dc=example,dc=com",
              "usersearch" : "(sAMAccountName={0})"
            }
          },
          "description" : "Authenticate via LDAP or Active Directory"
        },
        "basic_internal_auth_domain" : {
          "http_enabled" : true,
          "transport_enabled" : true,
          "order" : 4,
          "http_authenticator" : {
            "challenge" : true,
            "type" : "basic",
            "config" : { }
          },
          "authentication_backend" : {
            "type" : "intern",
            "config" : { }
          },
          "description" : "Authenticate via HTTP Basic against internal users database"
        },
        "proxy_auth_domain" : {
          "http_enabled" : false,
          "transport_enabled" : false,
          "order" : 3,
          "http_authenticator" : {
            "challenge" : false,
            "type" : "proxy",
            "config" : {
              "user_header" : "x-proxy-user",
              "roles_header" : "x-proxy-roles"
            }
          },
          "authentication_backend" : {
            "type" : "noop",
            "config" : { }
          },
          "description" : "Authenticate via proxy"
        },
        "clientcert_auth_domain" : {
          "http_enabled" : false,
          "transport_enabled" : false,
          "order" : 2,
          "http_authenticator" : {
            "challenge" : false,
            "type" : "clientcert",
            "config" : {
              "username_attribute" : "cn"
            }
          },
          "authentication_backend" : {
            "type" : "noop",
            "config" : { }
          },
          "description" : "Authenticate via SSL client certificates"
        },
        "kerberos_auth_domain" : {
          "http_enabled" : false,
          "transport_enabled" : false,
          "order" : 6,
          "http_authenticator" : {
            "challenge" : true,
            "type" : "kerberos",
            "config" : {
              "krb_debug" : false,
              "strip_realm_from_principal" : true
            }
          },
          "authentication_backend" : {
            "type" : "noop",
            "config" : { }
          }
        }
      },
      "authz" : {
        "roles_from_another_ldap" : {
          "http_enabled" : false,
          "transport_enabled" : false,
          "authorization_backend" : {
            "type" : "ldap",
            "config" : { }
          },
          "description" : "Authorize via another Active Directory"
        },
        "roles_from_myldap" : {
          "http_enabled" : false,
          "transport_enabled" : false,
          "authorization_backend" : {
            "type" : "ldap",
            "config" : {
              "enable_ssl" : false,
              "enable_start_tls" : false,
              "enable_ssl_client_auth" : false,
              "verify_hostnames" : true,
              "hosts" : [
                "localhost:8389"
              ],
              "rolebase" : "ou=groups,dc=example,dc=com",
              "rolesearch" : "(member={0})",
              "userrolename" : "disabled",
              "rolename" : "cn",
              "resolve_nested_roles" : true,
              "userbase" : "ou=people,dc=example,dc=com",
              "usersearch" : "(uid={0})"
            }
          },
          "description" : "Authorize via LDAP or Active Directory"
        }
      },
      "auth_failure_listeners" : { },
      "do_not_fail_on_forbidden" : false,
      "multi_rolespan_enabled" : true,
      "hosts_resolver_mode" : "ip-only",
      "do_not_fail_on_forbidden_empty" : false
    }
  }
}
20

@stecino It’s the default config.yml. How did you deploy your cluster?