Issues with ldap integration

Hi,
I am facing issues with Issues with ldap integration
We have a 3 node Open Search Cluster.
We have configured ldap authentication and ran the security plugin script. Its successfull, but we are unable to login using the ldap users.

Below is the config.yml file and the error in the cluster logs


_meta:
type: “config”
config_version: 2

config:
dynamic:
http:
anonymous_auth_enabled: false
xff:
enabled: false
internalProxies: ‘192.168.0.10|192.168.0.11’ # regex pattern
authc:
basic_internal_auth_domain:
description: “Authenticate via HTTP Basic against internal users database”
http_enabled: true
transport_enabled: true
order: 4
http_authenticator:
type: basic
challenge: true
authentication_backend:
type: intern
ldap:
http_enabled: true
transport_enabled: true
order: 1
http_authenticator:
type: basic
challenge: true
authentication_backend:
type: ldap
config:
enable_ssl: false
enable_start_tls: false
enable_ssl_client_auth: false
verify_hostnames: true
hosts:
- ADNode1.abcdomain.lan:389
- ADNode2.abcdomain.lan:389
bind_dn: cn=srv.gt.procSRE.elk,ou=service,ou=Users,ou=Datacenter,dc=abcdomain,dc=lan
password: XXXXXXXXXX
userbase: ‘cn=GL_Getnet-Proc-CDE-ElkAdmin,ou=Opensearch,ou=GROUPS APPLICATION,ou=CHENNAI,ou=INDIA,ou=ASIA,dc=abcdomain,dc=lan’
usersearch: ‘(uid={0})’
username_attribute: uid
authz:
ldap:
http_enabled: true
transport_enabled: true
authorization_backend:
type: ldap
config:
enable_ssl: false
enable_start_tls: false
enable_ssl_client_auth: false
verify_hostnames: true
hosts:
- ADNode1.abcdomain.lan:389
- ADNode2.abcdomain.lan:389
bind_dn: cn=srv.gt.procSRE.elk,ou=service,ou=Users,ou=Datacenter,dc=abcdomain,dc=lan
password: oT9aMsfsh8HA
userbase: ‘cn=GL_Getnet-Proc-CDE-ElkAdmin,ou=Opensearch,ou=GROUPS APPLICATION,ou=CHENNAI,ou=INDIA,ou=ASIA,dc=abcdomain,dc=lan’
usersearch: ‘(uid={0})’
username_attribute: uid
rolebase: ‘cn=GL_Getnet-Proc-CDE-ElkAdmin,ou=Opensearch,ou=GROUPS APPLICATION,ou=CHENNAI,ou=INDIA,ou=ASIA,dc=abcdomain,dc=lan’
rolesearch: ‘(member={0})’
userroleattribute: null
userrolename: none
rolename: cn
resolve_nested_roles: true

Error in Cluster log

Caused by: org.ldaptive.LdapException: Unable to connect to any of those ldap servers [ADNode1.abcdomain.lan:389, ADNode2.abcdomain.lan:389] due to [org.ldaptive.LdapException@277590303::resultCode=INVALID_CREDENTIALS, matchedDn=null, responseControls=null, referralURLs=null, messageId=-1, message=javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090447, comment: AcceptSecurityContext error, data 52e, v3839], providerException=javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090447, comment: AcceptSecurityContext error, data 52e, v3839]]
at com.amazon.dlic.auth.ldap.backend.LDAPAuthorizationBackend.getConnection0(LDAPAuthorizationBackend.java:360) ~[opensearch-security-2.1.0.0.jar:2.1.0.0]
at com.amazon.dlic.auth.ldap.backend.LDAPAuthorizationBackend$2.run(LDAPAuthorizationBackend.java:166) ~[opensearch-security-2.1.0.0.jar:2.1.0.0]
at com.amazon.dlic.auth.ldap.backend.LDAPAuthorizationBackend$2.run(LDAPAuthorizationBackend.java:156) ~[opensearch-security-2.1.0.0.jar:2.1.0.0]
at java.security.AccessController.doPrivileged(AccessController.java:569) ~[?:?]
at com.amazon.dlic.auth.ldap.backend.LDAPAuthorizationBackend.getConnection(LDAPAuthorizationBackend.java:156) ~[opensearch-security-2.1.0.0.jar:2.1.0.0]
at com.amazon.dlic.auth.ldap.backend.LDAPAuthorizationBackend.fillRoles(LDAPAuthorizationBackend.java:715) ~[opensearch-security-2.1.0.0.jar:2.1.0.0]
… 72 more
Caused by: org.ldaptive.LdapException: javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090447, comment: AcceptSecurityContext error, data 52e, v3839]
at org.ldaptive.provider.ProviderUtils.throwOperationException(ProviderUtils.java:55) ~[ldaptive-1.2.3.jar:?]
at org.ldaptive.provider.jndi.JndiConnection.processNamingException(JndiConnection.java:619) ~[ldaptive-1.2.3.jar:?]
at org.ldaptive.provider.jndi.JndiConnection.simpleBind(JndiConnection.java:261) ~[ldaptive-1.2.3.jar:?]
at org.ldaptive.provider.jndi.JndiConnection.bind(JndiConnection.java:203) ~[ldaptive-1.2.3.jar:?]
at org.ldaptive.BindOperation.invoke(BindOperation.java:28) ~[ldaptive-1.2.3.jar:?]
at org.ldaptive.BindOperation.invoke(BindOperation.java:9) ~[ldaptive-1.2.3.jar:?]
at org.ldaptive.AbstractOperation.execute(AbstractOperation.java:126) ~[ldaptive-1.2.3.jar:?]
at org.ldaptive.BindConnectionInitializer.initialize(BindConnectionInitializer.java:156) ~[ldaptive-1.2.3.jar:?]
at org.ldaptive.DefaultConnectionFactory$DefaultConnection.open(DefaultConnectionFactory.java:269) ~[ldaptive-1.2.3.jar:?]
at com.amazon.dlic.auth.ldap.backend.LDAPAuthorizationBackend.getConnection0(LDAPAuthorizationBackend.java:328) ~[opensearch-security-2.1.0.0.jar:2.1.0.0]
at com.amazon.dlic.auth.ldap.backend.LDAPAuthorizationBackend$2.run(LDAPAuthorizationBackend.java:166) ~[opensearch-security-2.1.0.0.jar:2.1.0.0]
at com.amazon.dlic.auth.ldap.backend.LDAPAuthorizationBackend$2.run(LDAPAuthorizationBackend.java:156) ~[opensearch-security-2.1.0.0.jar:2.1.0.0]
at java.security.AccessController.doPrivileged(AccessController.java:569) ~[?:?]
at com.amazon.dlic.auth.ldap.backend.LDAPAuthorizationBackend.getConnection(LDAPAuthorizationBackend.java:156) ~[opensearch-security-2.1.0.0.jar:2.1.0.0]
at com.amazon.dlic.auth.ldap.backend.LDAPAuthorizationBackend.fillRoles(LDAPAuthorizationBackend.java:715) ~[opensearch-security-2.1.0.0.jar:2.1.0.0]
… 72 more
Caused by: javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090447, comment: AcceptSecurityContext error, data 52e, v3839]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3260) ~[?:?]
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3206) ~

@harikrishnapachava As per your error output.

Caused by: org.ldaptive.LdapException: Unable to connect to any of those ldap servers [ADNode1.abcdomain.lan:389, ADNode2.abcdomain.lan:389] due to [org.ldaptive.LdapException@277590303::resultCode=INVALID_CREDENTIALS,

Have you tested your binding with the ldapsearch tool? Try using port 3268 instead of 389.

@harikrishnapachava Just to be clear, that error regards invalid credentials of your binding account and not the LDAP user.

Thanks @pablo . I have tried with ldapsearch and with the same credentials and the ldapsearch is returning results. But in openSearch the issue is still the same

[root@OS_Server1 ~]# ldapsearch -x -LLL -h ADNode1.abcdomain.lan -D srv.gt.procSRE.elk@abcdomain.lan -w xxxxxxxxxxx -b"ou=service,ou=Users,ou=Datacenter,dc=abcdomain,dc=lan" -s sub “(objectClass=user)” srv.gt.procSRE.elk
dn: CN=srv.backup.exch,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC=lan

dn: CN=CWAService,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC=lan

dn: CN=monitoring, wd,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC=lan

dn: CN=Conferencepad, abcdomain,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,
DC=lan

dn: CN=Admin Vshare,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC=lan

@harikrishnapachava Could you try the below command instead?

ldapsearch -x -LLL -h ADNode1.abcdomain.lan -D "cn=srv.gt.procSRE.elk,ou=service,ou=Users,ou=Datacenter,dc=abcdomain,dc=lan" -w xxxxxxxxxxx -b"ou=service,ou=Users,ou=Datacenter,dc=abcdomain,dc=lan" -s sub “(objectClass=user)” srv.gt.procSRE.elk

Hi @pablo

I have executed the command, it is showing as invalid credentials if i specify the complete CN and if i specify the CN as name@domain.lan, its showing the results

[root@muccbes00050 ~]# ldapsearch -x -LLL -h ADNode1.abcdomain.lan -D “cn=srv.gt.procSRE.elk,ou=service,ou=Users,ou=Datacenter,dc=abcdomain,dc=lan” -w xxxxxxxxxxxxxxxxx -b"ou=service,ou=Users,ou=Datacenter,dc=abcdomain,dc=lan" -s sub “(objectClass=user)” srv.gt.procSRE.elk
ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C090447, comment: AcceptSecurityContext error, data 52e, v3839

[root@muccbes00050 ~]# ldapsearch -x -LLL -h ADNode1.abcdomain.lan -D “srv.gt.procSRE.elk@abcdomain.lan” -w xxxxxxxxxxxxxxxxx -b"ou=service,ou=Users,ou=Datacenter,dc=abcdomain,dc=lan" -s sub “(objectClass=user)” srv.gt.procSRE.elk
dn: CN=srv.backup.exch,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC=lan

dn: CN=CWAService,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC=lan

dn: CN=monitoring, wd,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC=lan

dn: CN=Conferencepad, abcdomain,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,
DC=lan

dn: CN=Admin Vshare,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC=lan

dn: CN=Service Hadoop,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC=lan

dn: CN=Coda, U4BA,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC=lan

dn: CN=Service, Vmwaremon,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC=la
n

dn: CN=Coda, Basis,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC=lan

dn: CN=abcdomain, VMware vRealize,OU=service,OU=Users,OU=Datacenter,DC=wirecar
d,DC=lan

dn: CN=Service, ITSMGL Linux,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC
=lan
and many more

@harikrishnapachava That proves incorrect bind_dn in your config.yml and as a result, you get a connection error in the logs.

As long as you can’t authenticate with ldapsearch and bind_dn, the security plugin won’t work.

Hi @pablo Thanks for pointing it out. Now i have corrected the bind dn(and ldap search is working fine now) and updated the config files and ran the security plugin script. But its still showing the below

[2022-10-25T17:53:15,212][INFO ][o.o.j.s.JobSweeper ] [OS_Server1.abcdomain.lan] Running full sweep
[2022-10-25T17:53:33,633][WARN ][o.o.s.a.BackendRegistry ] [OS_Server1.abcdomain.lan] Authentication finally failed for a.hpacha from 10.210.175.250:40738
[2022-10-25T17:53:39,912][WARN ][o.o.s.a.BackendRegistry ] [OS_Server1.abcdomain.lan] Authentication finally failed for a.hpacha from 10.210.175.250:40738
[2022-10-25T17:53:45,920][WARN ][o.o.s.a.BackendRegistry ] [OS_Server1.abcdomain.lan] Authentication finally failed for a.hpacha@abcdomain.lan from 10.210.175.250:40738
[2022-10-25T17:53:49,760][WARN ][o.o.s.a.BackendRegistry ] [OS_Server1.abcdomain.lan] Authentication finally failed for a.hpacha@abcdomain.lan from 10.210.175.250:40738

[2022-10-25T16:39:24,561][WARN ][o.o.s.a.BackendRegistry ] [OS_Server2.abcdomain.lan] Authentication finally failed for harikrishna.pachava from 10.210.175.250:44836
[2022-10-25T16:39:31,551][WARN ][o.o.s.a.BackendRegistry ] [OS_Server2.abcdomain.lan] Authentication finally failed for harikrishna.pachava@abcdomain.lan from 10.210.175.250:44836
[2022-10-25T16:39:33,820][WARN ][o.o.s.a.BackendRegistry ] [OS_Server2.abcdomain.lan] Authentication finally failed for harikrishna.pachava@abcdomain.lan from 10.210.175.250:44836
[2022-10-25T16:39:41,044][WARN ][o.o.s.a.BackendRegistry ] [OS_Server2.abcdomain.lan] Authentication finally failed for a.hpacha@abcdomain.lan from 10.210.175.250:44836
[2022-10-25T16:40:37,341][WARN ][o.o.s.a.BackendRegistry ] [OS_Server2.abcdomain.lan] Authentication finally failed for a.hpacha from 10.210.175.250:44836

Config.yml File


_meta:
type: “config”
config_version: 2

config:
dynamic:
kibana:

Kibana multitenancy

  multitenancy_enabled: true
  server_username: kibanaserver
  index: '.kibana'
do_not_fail_on_forbidden: false
http:
  anonymous_auth_enabled: false
  xff:
    enabled: false
    internalProxies: '192\.168\.0\.10|192\.168\.0\.11' # regex pattern
authc:
  kerberos_auth_domain:
    http_enabled: false
    transport_enabled: false
    order: 6
    http_authenticator:
      type: kerberos
      challenge: true
      config:
        # If true a lot of kerberos/security related debugging output will be logged to standard out
        krb_debug: false
        # If true then the realm will be stripped from the user name
        strip_realm_from_principal: true
    authentication_backend:
      type: noop
  basic_internal_auth_domain:
    description: "Authenticate via HTTP Basic against internal users database"
    http_enabled: true
    transport_enabled: true
    order: 4
    http_authenticator:
      type: basic
      challenge: true
    authentication_backend:
      type: intern
  proxy_auth_domain:
    description: "Authenticate via proxy"
    http_enabled: false
    transport_enabled: false
    order: 3
    http_authenticator:
      type: proxy
      challenge: false
      config:
        user_header: "x-proxy-user"
        roles_header: "x-proxy-roles"
    authentication_backend:
      type: noop
  jwt_auth_domain:
    description: "Authenticate via Json Web Token"
    http_enabled: false
    transport_enabled: false
    order: 0
    http_authenticator:
      type: jwt
      challenge: false
      config:
        signing_key: "base64 encoded HMAC key or public RSA/ECDSA pem key"
        jwt_header: "Authorization"
        jwt_url_parameter: null
        roles_key: null
        subject_key: null
    authentication_backend:
      type: noop
  clientcert_auth_domain:
    description: "Authenticate via SSL client certificates"
    http_enabled: false
    transport_enabled: false
    order: 2
    http_authenticator:
      type: clientcert
      config:
        username_attribute: cn #optional, if omitted DN becomes username
      challenge: false
    authentication_backend:
      type: noop
  
  ldap:
    description: "Authenticate via LDAP or Active Directory"
    http_enabled: true
    transport_enabled: true
    order: 0
    http_authenticator:
      type: basic
      challenge: true
    authentication_backend:
      # LDAP authentication backend (authenticate users against a LDAP or Active Directory)
      type: ldap
      config:
        custom_attr_whitelist:
          - sAMAccountName
          - department
          - company
        # 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: false
        hosts:
          - ADNode1.abcdomain.lan:389
          - ADNode2.abcdomain.lan:389
        bind_dn: 'CN=Service\, gt.procSRE.elk,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC=lan'
        password: 'XXXXXXXXXXXXX'
        userbase: 'cn=GL_Getnet-Proc-CDE-ElkAdmin,ou=Opensearch,ou=GROUPS APPLICATION,ou=CHENNAI,ou=INDIA,ou=ASIA,dc=abcdomain,dc=lan'
        usersearch: '(sAMAccountName={0})'
        # Use this attribute from the user as username (if not set then DN is used)
        username_attribute: sAMAccountName
authz:
  roles_from_myldap:
    description: "Authorize via LDAP or Active Directory"
    http_enabled: true
    transport_enabled: true
    authorization_backend:
      # LDAP authorization backend (gather roles from a LDAP or Active Directory, you have to configure the above LDAP authentication backend settings too)
      type: ldap
      config:
        custom_attr_whitelist:
          - sAMAccountName
          - department
          - company
        # 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: false
        hosts:
          - ADNode1.abcdomain.lan:389
          - ADNode2.abcdomain.lan:389
        bind_dn: 'CN=Service\, gt.procSRE.elk,OU=service,OU=Users,OU=Datacenter,DC=abcdomain,DC=lan'
        password: 'XXXXXXXXXXXXX'
        rolebase: 'cn=GL_Getnet-Proc-CDE-ElkAdmin,ou=Opensearch,ou=GROUPS APPLICATION,ou=CHENNAI,ou=INDIA,ou=ASIA,dc=abcdomain,dc=lan'
        rolesearch: '(sAMAccountName={2})'
        userroleattribute: sAMAccountName
        # Roles as an attribute of the user entry
        userrolename: department, company
        resolve_nested_roles: false
        userbase: 'cn=GL_Getnet-Proc-CDE-ElkAdmin,ou=Opensearch,ou=GROUPS APPLICATION,ou=CHENNAI,ou=INDIA,ou=ASIA,dc=abcdomain,dc=lan'
        usersearch: '(sAMAccountName={0})'
        rolesearch_enabled: false
        skip_users:
          - "admin"
          - "kibanaserver"
          - "metricbeat"
          - "logstash"
          
  roles_from_another_ldap:
    description: "Authorize via another Active Directory"
    http_enabled: false
    transport_enabled: false
    authorization_backend:
      type: ldap

@harikrishnapachava These are just warning and are caused by basicauth. When you have multiple authentication domains enabled, user authentication will be executed against all of them.

In your case, it’s ldap and basicauth.

You will see similar errors when you authenticate with an internal user.

Can you test the below?
curl --insecure -u -XGET https://localhost:9200/_plugins/_security/authinfo?pretty

Hi @pablo The Issue was with the base DN, i have modified the base dn to DC=abcdomain,DC=lan and now i am able to login with my AD account.

Thanks for your time and efforts in helping to resolve the issue