Cannot configure LDAP on Opensearch Dashboard

Security
, ,
1

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):
Opensearch Dashboard

Describe the issue:
Our company has stable Wazuh 3.12 service with Active Directory integration.
Have installed for testing standalone Wazuh 4.3. Also have migrated config.yml and updated roles_mapping.yml by adding specific user groups from AD.

As result I can send requests like:
curl -XGET ‘https://localhost:9200/_search?pretty’ -u ‘username_from_AD_group’ -k

I cannot login via username_from_AD_group in browser by URL:
https: / / X.X.X.X / app / login?nextUrl=%2F

In this case WUI shown: ‘Invalid username or password, please try again’

Configuration:
config.yml:

---
_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:
      ldap:
        description: "Authenticate via LDAP or Active Directory"
        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:
            - ad01.dc.ltd.com:389
            - ad02.dc.ltd.com:389
            bind_dn: 'CN=elastic,OU=ServiceAccounts,OU=company,DC=dc,DC=ltd,DC=com'
            password: 'password'
            userbase: 'OU=Users,OU=company,DC=dc,DC=ltd,DC=com'
            usersearch: '(sAMAccountName={0})'
            username_attribute: uid
            connect_timeout: 5000
            response_timeout: 0
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 2
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern
    authz:
      roles_from_myldap:
        description: "Authorize via LDAP or 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:
            - ad01.dc.ltd.com:389
            - ad02.dc.ltd.com:389
            bind_dn: 'CN=elastic,OU=ServiceAccounts,OU=company,DC=dc,DC=ltd,DC=com'
            password: 'password'
            rolebase: 'ou=company,dc=dc,dc=ltd,dc=com'
            rolesearch: '(member={0})'
            userroleattribute: null
            userrolename: disabled
            rolename: cn
            resolve_nested_roles: true
            userbase: 'OU=Users,OU=company,DC=dc,DC=ltd,DC=com'
            usersearch: '(uid={0})'
            skip_users:
              - kibanaserver
              - admin
            connect_timeout: 5000
            response_timeout: 0

roles_mapping.yml example:
…
all_access:
reserved: true
hidden: false
backend_roles:

  • “admin”
  • “Group-Kibana-FullAccess”
    description: “Maps admin to all_access”

…

Relevant Logs or Screenshots:

Logs when login attempt:

{“type”:“log”,“@timestamp”:“2023-01-24T19:34:18Z”,“tags”:[“error”,“plugins”,“securityDashboards”],“pid”:5519,“message”:“Failed authentication: Error: Cannot override default header authorization.”}
{“type”:“response”,“@timestamp”:“2023-01-24T19:34:18Z”,“tags”:,“pid”:5519,“method”:“post”,“statusCode”:401,“req”:{“url”:“/auth/login”,“method”:“post”,“headers”:{“host”:“X.X.X.X”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0”,“accept”:“/”,“accept-language”:“en-US,en;q=0.5”,“accept-encoding”:“gzip, deflate, br”,“referer”:“https: / / X.X.X.X / app / login?nextUrl=%2F”,“content-type”:“application/json”,“osd-version”:“1.2.0”,“content-length”:“54”,“origin”:"https: / / X.X.X.X ",“connection”:“keep-alive”,“sec-fetch-dest”:“empty”,“sec-fetch-mode”:“cors”,“sec-fetch-site”:“same-origin”},“remoteAddress”:“Y.Y.Y.Y”,“userAgent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0”,“referer”:“https: / / X.X.X.X / app/login?nextUrl=%2F”},“res”:{“statusCode”:401,“responseTime”:4,“contentLength”:9},“message”:“POST /auth/login 401 4ms - 9.0B”}

2

Hey @OleksandrMishchenko Could you please share the detailed request, including headers? It’ll be helpful to look at the structure of headers being sent in the request.

Looking at the log Cannot override default header authorization., it seems like one of the custom headers passed had the key authorization which is a restricted default header and fails a check in the callAsCurrentUser() [1] method.

[1] OpenSearch-Dashboards/scoped_cluster_client.ts at main · opensearch-project/OpenSearch-Dashboards · GitHub

1 Like
3

@OleksandrMishchenko Did you check that your bind_dn user CN=elastic can search OU=Users,OU=company,DC=dc,DC=ltd,DC=com for AD users and OU=company,DC=dc,DC=ltd,DC=com for AD groups?

Could you run the below command and share the output?

curl --insecure -u "LDAP_user" -XGET "https://<OpenSearch_node>:9200/_plugins/_security/authinfo?pretty"
4

Thanks for your time. Did not see your answers previously.

Have resolved issue.

The reason was in that:
In that day was last day of active password for this user.
Next day I’ve have received proposition to change password.
The password was changed and it starts to work correctly.)))

The issue is strange.
It works fine for curl, but does not work for dashboard. Might be some specific password lifetime limitation are set on it.

5

@OleksandrMishchenko Have you tried to flush the cache?