LDAP Integration Not Getting backend-roles

[John Doecisco]

I am able to authc into the dashboard GUI. I receive own_index and all_access but no backend roles.  Followed this excellent documentation, https://documentation.wazuh.com/current/user-manual/user-administration/ldap.html but no success.

 

My LDAP user is not getting the backend role or any permissions. I'm not 100% sure my group attribute configuration is correct.  LDAP is not my primary job unfortunately.

User name is It6 that is located in ou IT Accounts

It6 is a member of the inosec group under ou Security Team

My authz looks like this:

 authz:
      roles_from_myldap:
        description: "Authorize via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: false
        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:
            enable_ssl: true
            pemtrustedcas_filepath: /etc/wazuh-indexer/opensearch-security/ldapcacert.pem
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: true
            hosts:
            - s1.xxxx.xxxx:636
            - s2.xxxx.xxxx:636
            bind_dn: xx...@xxxx.xxxx
            password: "xxxx
            userbase: ou=IT Accounts, dc=xxxx, dc=xxxx
            usersearch: (sAMAccountName={0})
            username_attribute: cn
  #         userroleattribute: null
            rolesearch: (member={0})
            rolename: cn
            userrolename: memberOf
            resolve_nested_roles: true
  #         rolesearch_enabled: true
            rolebase: ou="Security Team, dc=xxxx, dc=xxxx
  #          userrolename: none

And my mapping is this

all_access:
  reserved: false
  hidden: false
  backend_roles:
  - "admin"
  - "InfoSec"
  - "IT Accounts"
  hosts: []
  users:
   - "*"

My dashboard mapping 

administrator

Any are true

backend_roles find IT Accounts

backend_roles find Security Team

Thanks for help

[fabio.c...@wazuh.com]

Hi John,

To narrow it down, could you share:

1. What backend roles the indexer actually returns for It6. Log in as It6 and call:

curl -k -u It6:'<password>' https://<wazuh-indexer>:9200/_plugins/_security/api/account?pretty

The backend_roles field is the source of truth. (OpenSearch Security API – Get account details)

2. Indexer log during a failing login: /var/log/wazuh-indexer/wazuh-cluster.log (any line mentioning LDAP).

3. Did you re-run securityadmin.sh after editing config.yml? Per the Wazuh LDAP guide, changes only take effect after that script pushes them to the security index.

4. The exact cn of the AD group It6 belongs to (you wrote both inosec and InfoSec). With rolename: cn in your authz config, the backend role is the group's cn, not the OU name. The Wazuh LDAP guide states this in the Required parameters section: "rolename: The attribute of the role entry that should be used as the role name." So your role mapping must list the group cn (inosec/InfoSec), not IT Accounts or Security Team.

You can confirm the exact group cn on the DC with:

Get-ADPrincipalGroupMembership -Identity It6 | Select-Object name, distinguishedName

The name column is what the indexer will return as backend_role.

5. The exact authz block from your config.yml pasted as a code block. The rolebase line in your post reads:

rolebase: ou="Security Team, dc=xxxx, dc=xxxx

That looks like an unbalanced quote; the doc example uses an unquoted DN (rolebase: ou=groups,dc=example,dc=org) or a fully quoted value. Could you confirm what is in the file?

Once I have items 1 and 2, I can tell whether the chain is breaking at bind, role search, or only at role mapping in roles_mapping.yml / the dashboard.

Best regards,

[John Doecisco]

Thanks for the quick response.  The attribute inconsistencies were from me anonymizing my data. 

 
1. What backend roles the indexer actually returns for It6. Log in as It6 and call:

John - 

  "user_name" : "IT 6",
  "is_reserved" : false,
  "is_hidden" : false,
  "is_internal_user" : false,
  "user_requested_tenant" : null,
  "backend_roles" : [ ],
0

2. Indexer log during a failing login: /var/log/wazuh-indexer/wazuh-cluster.log

John - no log entries or errors

3. Did you re-run securityadmin.sh after editing config.yml? Per the Wazuh LDAP guide, changes only take effect after that script pushes them to the security index.

John - Yes.  It's in my history buffer so I just up arrow and execute it

4. The exact cn of the AD group It6 belongs to (you wrote both inosec and InfoSec). With rolename: cn in your authz config, the backend role is the group's cn, not the OU name. The Wazuh LDAP guide states this in the Required parameters section: "rolename: The attribute of the role entry that should be used as the role name." So your role mapping must list the group cn (inosec/InfoSec), not IT Accounts or Security Team.

John - should be InfoSec. It6 (It 6) is a memberOf InfoSec. I've reconfigured.  

PS C:\Windows\system32> Get-ADPrincipalGroupMembership -Identity It6 | Select-Object name, distinguishedName

name                        distinguishedName
----                        -----------------
Domain Users                CN=Domain 
InfoSec                            CN=InfoSec,OU=Security Team,DC=xxxx,DC=xxxx
Sec-Pass                         CN=Sec-Pass,OU=Security Team, DC=xxxx,DC=xxxx
IT Accounts                    CN=GLPC IT Accounts,OU=IT Accounts,DC=xxxx,DC=xxxx

So my group name is InfoSec.

Indexer mapping

all_access:
  reserved: false
  hidden: false
  backend_roles:
  - "admin"
  - "InfoSec"

  hosts: []
  users:
  - "*"

Dashboard mapping

Name - InfoSec

Roles - administrator

Mapping rules

  Customer Rule

      backend_roles find InfoSec

5)  The exact authz block from your config.yml pasted as a code block. The rolebase line in your post reads:

John - My translation typo. No quotes.  

[fabio.c...@wazuh.com]

Hi John,

Thanks for the detail. The backend_roles: [ ] from /api/account confirms the indexer is not pulling any group for It6 at all. Couple of things to try:

• userrolename: memberOf + rolesearch together.

userrolename is documented as: "If the roles/groups of a user are not stored in the groups subtree, but as an attribute of the user's directory entry, define this attribute name here." 

In AD, memberOf on the user entry returns group DNs, so it's an alternative path to rolesearch. With both set, both run. You could try to drop userrolename: memberOf and rely on rolesearch because that is the cleaner AD pattern and matches the official AD example, which sets userrolename: none.

• Enable LDAP debug and reproduce one login.

wazuh-cluster.log may not show LDAP details at default level. You can flip the level at runtime via the cluster settings API:

curl -k -u admin:'<pw>' -X PUT https://127.0.0.1:9200/_cluster/settings \
    -H 'Content-Type: application/json' -d '{
      "transient": {
        "logger.com.amazon.dlic.auth.ldap": "DEBUG"
      }
    }'

Verify it took effect:

curl -k -u admin:'<pw>' 'https://127.0.0.1:9200/_cluster/settings?flat_settings=true'

You should see the logger entry echoed back under transient. Then trigger one auth round trip as It6, either log in to the dashboard once or hit the security plugin directly:

curl -k -u 'It6:<pw>' https://127.0.0.1:9200/_plugins/_security/authinfo?pretty

And tail the log:

tail -f /var/log/wazuh-indexer/wazuh-cluster.log | grep -iE 'ldap|dlic'

The debug output prints the exact usersearch and rolesearch filters with variables substituted, the bind result, and how many entries each search returned. That single log will tell you whether:

• the user DN found by usersearch is what you expect (it should be CN=IT 6,OU=IT Accounts,DC=xxxx,DC=xxxx),
• the rolesearch against ou=Security Team,dc=xxxx,dc=xxxx returns the InfoSec entry,
• or the bind user can't read the member attribute on InfoSec (AD ACL issue, the service account may need explicit read on the group's member).

To revert the logger when you're done (INFO is the default):

curl -k -u admin:'<pw>' -X PUT https://127.0.0.1:9200/_cluster/settings \
    -H 'Content-Type: application/json' -d '{ "transient": { "logger.com.amazon.dlic.auth.ldap": "INFO" } }'

If sending the relevant debug lines is fine, paste them and I can point at the exact stage.

One thing worth double checking now without waiting for logs: that rolebase value as it sits in the file. The doc example uses an unquoted DN (rolebase: ou=groups,dc=example,dc=org, unquoted, or a fully quoted value). An unbalanced double quote, or a stray space inside the DN, parses as YAML but produces a base DN AD won't match. Worth a cat of the file rather than retyping.

Best regards,