Problem with internal authenticacion and LDAP

Security
,
1

I have the following configuration in ‘config.yml’:

_meta:
  type: "config"
  config_version: 2


config:
  dynamic:
    authc:
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: false
        transport_enabled: false
        order: 0
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern
      ldap:
        description: "Authenticate via Active Directory"
        http_enabled: true
#        transport_enabled: true
        order: 1
        http_authenticator:
          type: basic
          challenge: true
        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: false
            hosts:
            - dc.es:3268
            bind_dn: CN=opensearch,OU=people,OU=cuentasservicio,DC=dc,DC=es
            password: "******"
            userbase: 'OU=people,OU=blabla,DC=dc,DC=es'
            # Filter to search for users (currently in the whole subtree beneath userbase)
            # {0} is substituted with the username
            #usersearch: '(sAMAccountName=%s)'
            usersearch: '(sAMAccountName=%s)'
            # Use this attribute from the user as username (if not set then DN is used)
            username_attribute: sAMAccountName
            connect_timeout: 5000
            response_timeout: 0

At the moment I want to configure internal authentication and ldap authentication, authorisation is set to internal by default.

I have checked with the ldapsearch tool that there is no problem with the domain controller, as the following command is executed correctly:

ldapsearch -x -b "dc=dc,dc=es" -h dc.es:3268 -D "CN=opensearch,OU=people,OU=cuentasservicio,DC=dc,DC=es" -W

However, the following lines keep appearing in the opensearch log (kibanaserver is an internal user):

[2022-02-07T23:01:52,090][TRACE][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] Connect to dc.es:3268
[2022-02-07T23:01:52,091][TRACE][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] Connect to ldap://dc.es:3268
[2022-02-07T23:01:52,091][DEBUG][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] Connect timeout: PT5S/ResponseTimeout: PT0S
[2022-02-07T23:01:52,092][DEBUG][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] bindDn CN=opensearch,OU=people,OU=cuentasservicio,DC=dc,DC=es, password ****
[2022-02-07T23:01:52,092][DEBUG][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] Will perform simple bind with bind dn
[2022-02-07T23:01:52,151][DEBUG][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] Opened a connection, total count is now 1
[2022-02-07T23:01:52,154][DEBUG][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] Closed a connection, total count is now 0
[2022-02-07T23:01:52,156][WARN ][o.o.s.a.BackendRegistry  ] [opensearch-master-node] Authentication finally failed for kibanaserver from 127.0.0.1:37372

Is there any way to find out more about the problem, what it might be?

2

@Zeus29 Please share the current version of OpenSearch and the name of the LDAP solution.
Have you been able to authenticate before or has it never worked?

3

Hi @pablo ,

The version of Opensearch is 1.2.3 and I am trying to integrate Opensearch against the Active Directory of a Domain Controller (Windows) via LDAP.

4

Hi @pablo
Any news on this?

Thanks and regards.

5

@Zeus29 I’ve noticed that your ldapsearch command runs against dc=dc,dc=es and your userbase against OU=poeple,OU=blabla,DC=dc,DC=es.

It means that ldapsearch searches the entire domain where the security plugin only a specific OU.

Could you try the following command to match your security config settings?

ldapsearch -x -b "ou=people,ou=balbla,dc=dc,dc=es" -h dc.es:3268 -D "CN=opensearch,OU=people,OU=cuentasservicio,DC=dc,DC=es" -W
6

Hi @pablo,

With that command the request succeeds as well. Any other ideas what could be going wrong? Is there a way to increase the log level?

Thank you very much.

7

@Zeus29 I don’t find the answer to my previous question. Are you able to successfully authenticate against AD?
Is the kibanaserver user your only concern?

8

Hello again @pablo ,

With the ldapsearch command from your previous reply I’m able to authenticate succesfully on the AD.
The opensearch authentication problem happens on local users (like “kibanaserver”) and on domain users.
When I try to authenticate on opensearch dashboards with a domain user using this yaml configuration I get an “incorrect credentials” error (as well as the continuous authentication errors with the local kibanaserver user)

Thank you

9

@Zeus29 I’ve reviewed your config again. Would you mind using the below lines instead in your config.yml?

usersearch: "(sAMAccountName={0})
username_attribute: "cn"

Also try the below settings to skip admin and kibanaserver users

  skip_users:
   - "admin"
   - "kibanaserver"
10

Hi @pablo,

I have tried both configurations, but authentication still does not work.

In opensearch I keep getting the following errors:

[2022-03-03T22:08:46,328][TRACE][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] Connect to dc.es:3268
[2022-03-03T22:08:46,329][TRACE][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] Connect to ldap://dc.es:3268
[2022-03-03T22:08:46,332][DEBUG][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] Connect timeout: PT5S/ResponseTimeout: PT0S
[2022-03-03T22:08:46,332][DEBUG][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] bindDn CN=opensearch,OU=people,OU=cuentasservicio,DC=dc,DC=es, password ****
[2022-03-03T22:08:46,332][DEBUG][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] Will perform simple bind with bind dn
[2022-03-03T22:08:46,341][DEBUG][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] Opened a connection, total count is now 1
[2022-03-03T22:08:46,343][DEBUG][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] Closed a connection, total count is now 0
[2022-03-03T22:08:46,344][WARN ][o.o.s.a.BackendRegistry  ] [opensearch-master-node] Authentication finally failed for kibanaserver from 127.0.0.1:58994

Also, in opensearch-dashboard I can’t login, I get the error “OpenSearch Dashboards server is not ready yet” and in the log I continuously see the following message:

{"type":"log","@timestamp":"2022-03-03T22:19:44Z","tags":["error","opensearch","data"],"pid":2094,"message":"[ResponseError]: Response Error"}

Any other ideas on what the problem might be or how it can be narrowed down?

Thanks!.

11

@Zeus29 Have the OpenSearch nodes initiated? Do you see any errors in OpenSearch logs?
Could you try following against the OpenSearch node?

curl --insecure -u admin -XGET https://<opensearch_node>:9200

Please, share again your current config.yml file?

12

Hi @pablo,
This is a single virtual machine on which OpenSearch and OpenSearch Dashboard are installed. OpenSearch is listening on 127.0.0.1:9200 and the following message appears when making a curl request with the user “admin”:

Authentication finally failed

No error appears in OpenSearch log.

The current config.yml:

_meta:
  type: "config"
  config_version: 2


config:
  dynamic:
    authc:
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: false
        transport_enabled: false
        order: 0
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern
      ldap:
        description: "Authenticate via Active Directory"
        http_enabled: true
#        transport_enabled: true
        order: 1
        http_authenticator:
          type: basic
          challenge: true
        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: false
            hosts:
            - aede.es:3268
            bind_dn: CN=opensearch,OU=people,OU=cuentasservicio,DC=dc,DC=es
            password: "**********"
            userbase: 'OU=people,OU=blabla,DC=dc,DC=es'
            # Filter to search for users (currently in the whole subtree beneath userbase)
            # {0} is substituted with the username
            #usersearch: '(sAMAccountName=%s)'
            usersearch: '(sAMAccountName=%s)'
            # Use this attribute from the user as username (if not set then DN is used)
            #username_attribute: sAMAccountName
            username_attribute: "cn"
            connect_timeout: 5000
            response_timeout: 0
            skip_users:
            - "admin"
            - "kibanaserver"

Also, I have checked that in the logs of the active directory of the domain appear successful logins (events 4624) with the user “opensearch” from the OpenSearch machine, so I understand that the integration with the AD is correct.

Thanks.

13

@Zeus29 I’ve tested again and skip_users will work only with authorization. The kibanaserver user is the service account and the security plugin will try to authenticate against all authentication types configured in config.yml.

I see you’ve changed the usernam_attribute value to cn. However, usersearch is still intact.
Would you mind changing it exactly to the below line?

usersearch: '(sAMAccountName={0})'

Where did you find sAMAccountName=%s?

14

Hi @pablo,

I have taken into account what you say and I have been able to get the authentication against AD work, however the local authentication does not work. As a workaround, I have created a service account in the AD to configure in OpenSearch Dashboard so as not to use the local user kibanaserver.

On the other hand, now that at least the authentication against the AD is working, I have also configured the authorisation, but when a user authenticates in OpenSearch Dashboard, I get an error that he has no role assigned, even though he should.

The config.yml file has the following lines:

_meta:
  type: "config"
  config_version: 2

config:
  dynamic:
    http:
      anonymous_auth_enabled: false
      xff:
        enabled: false
    authc:
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: false
        transport_enabled: false
        order: 1
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern
      ldap:
        description: "Authenticate via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: false
        order: 0
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          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: false
            hosts:
            - dc.es:3268
            bind_dn: CN=opensearch,OU=people,OU=cuentasservicio,DC=dc,DC=es
            password: "*********"
            userbase: 'DC=dc,DC=es'
            # 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"
    authz:
      roles_from_myldap:
        description: "Authorize via Active Directory"
        http_enabled: false
        transport_enabled: false
        authorization_backend:
          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: false
            hosts:
            - dc.es:3268
            bind_dn: CN=opensearch,OU=people,OU=cuentasservicio,DC=dc,DC=es
            password: *********
            userbase: 'OU=groups,OU=blabla,DC=dc,DC=es'
            # Filter to search for roles (currently in the whole subtree beneath rolebase)
            # {0} is substituted with the DN of the user
            # {1} is substituted with the username
            # {2} is substituted with an attribute value from user's directory entry, of the authenticated user. Use userroleattribute to specify the name of the attribute
            rolesearch: '(member={0})'
            # Specify the name of the attribute which value should be substituted with {2} above
            userroleattribute: null
            # Roles as an attribute of the user entry
            userrolename: none
            #userrolename: memberOf
            # The attribute in a role entry containing the name of that role, Default is "name".
            # Can also be "dn" to use the full DN as rolename.
            #rolename: cn
            rolename: sAMAccountName
            # Resolve nested roles transitive (roles which are members of other roles and so on ...)
            resolve_nested_roles: true
            # Filter to search for users (currently in the whole subtree beneath userbase)
            # {0} is substituted with the username
            usersearch: '(uid={0})'
            # Skip users matching a user name, a wildcard or a regex pattern
            #skip_users:
            # - kibanaserver

The roles_mapping.yml file has the following lines:

_meta:
  type: "rolesmapping"
  config_version: 2

# Define your roles mapping here

## Demo roles mapping

all_access:
  reserved: false
  backend_roles:
  - "admin"
  - "cn=Opensearch-Admin,OU=groups,OU=blabla,DC=dc,DC=es"
  description: "Maps admin to all_access"
  users:
  - "opensearch_kibana"

#own_index:
#  reserved: false
#  users:
#  - "*"
#  description: "Allow full access to an index named like the username"

logstash:
  reserved: false
  backend_roles:
  - "logstash"

kibana_user:
  reserved: false
  backend_roles:
  - "kibanauser"
  description: "Maps kibanauser to kibana_user"

readall:
  reserved: false
  backend_roles:
  - "readall"

manage_snapshots:
  reserved: false
  backend_roles:
  - "snapshotrestore"

kibana_server:
  reserved: true
  users:
  - "kibanaserver"
  - "opensearch_kibana"

kibana_read_only:
  reserved: false
  backend_roles:
    - "cn=Opensearch-Operator,OU=groups,OU=blabla,DC=dc,DC=es"

alerting_ack_alerts:
  reserved: false
  backend_roles:
    - "cn=Opensearch-Operator,OU=groups,OU=blabla,DC=dc,DC=es"

anomaly_read_access:
  reserved: false
  backend_roles:
    - "cn=Opensearch-Operator,OU=groups,OU=blabla,DC=dc,DC=es"

reports_instances_read_access:
  reserved: false
  backend_roles:
    - "cn=Opensearch-Operator,OU=groups,OU=blabla,DC=dc,DC=es"

  • Any idea why local authentication might not be working but AD authentication is working?

  • Any idea why AD users members of the “Opensearch-Operator” and “Opensearch-Admin” groups are not being assigned any roles?

Thank you very much for your help and time.

15

Hi @pablo,

About my previous message, do you have any response to my previous message?

Thank you very much.

16

Hi @Zeus29 For internal authentication, try to reverse the order. Set basic authentication order with 0 and ldap with 1.

Please share the result of the following command. As ldap_username use one of the members of Opensearch-Operator or Opensearch-Admin groups

curl --insecure -u <ldap_username> -XGET https://<OpenSearch_node_IP_or_FQDN>:9200/_plugins/_security/authinfo?pretty

You can DM me the results if you don’t want to share them here.

17

Hi @pablo ,

I have managed to get the authentication and authorisation settings to work against the domain:

_meta:
  type: "config"
  config_version: 2

config:
  dynamic:
    http:
      anonymous_auth_enabled: false
      xff:
        enabled: false
    authc:
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: false
        transport_enabled: false
        order: 0
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern
      AD_users:
        description: "Authenticate via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: false
        order: 1
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: ldap
          config:
            enable_ssl: false
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: false
            hosts:
            - dc.es:389
            bind_dn: CN=opensearch,OU=people,OU=cuentasservicio,DC=dc,DC=es
            password: "*********"
            userbase: 'DC=dc,DC=es'
            usersearch: '(sAMAccountName={0})'
            username_attribute: "sAMAccountName"
    authz:
      AD_roles:
        description: "Authorize via Active Directory"
        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: false
            hosts:
            - dc.es:389
            bind_dn: CN=opensearch,OU=people,OU=cuentasservicio,DC=dc,DC=es
            password: "******"
            userbase: 'DC=dc,DC=es'
            usersearch: '(sAMAccountName={0})'
            username_attribute: "sAMAccountName"
            rolebase: 'OU=groups,OU=blabla,DC=dc,DC=es'
            rolesearch: '(member={0})'
            userroleattribute: null
            userrolename: none
            rolename: "name"
            resolve_nested_roles: true

It seems that it was a problem with the port I was using for integration. On the other hand, aet basic authentication order with 0 and ldap with 1 doesn’t seem to work.

Any idea about the local authentication failure?, I get the following error in the log when I try to authenticate to OpenSearch Dashboard via web:

[2022-04-04T21:18:33,763][WARN ][o.o.s.a.BackendRegistry ] [opensearch] Authentication finally failed for admin from 127.0.0.1:38562

Very thanks.

18

@Zeus29 I’ve tested against 3268 in my lab and had no issues, that’s why I didn’t suggest a port change.

The error is expected as you’ve disabled basic authentication in the config. Try changing the below options to true in the basic_internal_auth_domain section.

        http_enabled: true
        transport_enabled: true
19

Very thanks @pablo , it works fine!.

20

Hi everyone!
Sorry for offtopic, can u explain how you get this logs

[2022-02-07T23:01:52,090][TRACE][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] Connect to dc.es:3268
[2022-02-07T23:01:52,091][TRACE][c.a.d.a.l.b.LDAPAuthorizationBackend] [opensearch-master-node] Connect to ldap://dc.es:3268

i’m using docker opensearch:1.3.0 container. I’m set trace log level in log4j2.properties, but still nothing can see in logs.
Can’t debug LDAP connection and resolve errors