From the Administrator account unable to see LDAP users and when logged in from the LDAP user account able to see account 80357643 under settings->users.
Check for related errors in splunkd.log we found the warn message
WARN LoadLDAPUsersThread [30682 PrecacheUsersThread] - Strategy="ADC.COM": the group="80357643" was not found on the LDAP server. Suggest to remove it from the role map to save server loading time.
For additional information which will be useful for further troubleshooting, turn on DEBUG-level logging for the AuthenticationManagerLDAP and ScopedLDAPConnection. From the "Server Settings ->Server Logging ->configuration page in Splunk Web.
category.AuthenticationManagerLDAP=DEBUG category.ScopedLDAPConnection=DEBUG
Remove any custom values that might have been added for the userBaseFilter and groupBaseFilter settings for the LDAP strategy that was configured in the authentication.conf file.
Check in authentication.conf for size limit how much user entries can be displayed maximum.
sizelimit = 3000 sizelimit = <integer> * Limits the amount of entries that Splunk software requests in LDAP search. * NOTE: The max entries returned is still subject to the maximum imposed by your LDAP server. *Example: If you set this to 5000 and the server limits it to 1000, the software only returns 1000 entries. * This setting is optional. * Default: 1000
On Linux and Unix machines, use the below ldapsearch command-line tool to confirm that the variables specified returned the expected entries.
ldapsearch -x –h <ldap_host> –p <ldap_port> –D "bind_dn" -w "bind_passwd" -b "user_basedn" "userNameAttribute=*" ldapsearch -x –h <ldap_host> –p <ldap_port> –D "bind_dn" -w "bind_passwd" –b "group_basedn" "groupNameAttribute=*"
If the above commands return matching entries, then LDAP system have properly configured in the backend.
Check the LDAP strategies settings by navigating to Access controls » Authentication method » LDAP strategies.
Check the values in LDAP strategy manually and verified user was part of the correct group.
To check the configuration on the domain controller, use the commands shown below:
dsquery user -name Administrator
Administrator denotes the user name that can bind to LDAP
dsquery user -name username_here
username_here denotes one of the usernames that you want to use in Splunk
dsquery group -name "group_name_here"
"group_name_here" denotes the group where the users are located.
Check limits.conf if there are more number of users than the limit defined in limits.conf:
[ldap] max_users_to_precache = 2000
The below search will show all the capabilities that all the users have, which makes it easy to identify which capabilities Admin (or any other) role does not have. Find missing capabilities between the admin user and the newly created/non-visible user then add them to the role.
| rest splunk_server=local /services/authorization/roles |fields title capabilities |mvexpand capabilities |eval type="C" |append [| rest splunk_server=local /services/authorization/roles |fields title imported_capabilities |mvexpand imported_capabilities |rename imported_capabilities as capabilities |eval type="I"] |rename title as role |xyseries capabilities role type
Tried setting the LDAP userbaseDN same as groupbaseDN in authentication.conf. And also, tried setting userbaseDN differently with groupbaseDN and noticed still it is not working.
Note that log in with LDAP user credentials is successful but only the users are not showing up when checking from administrator account.
Previously, the userbaseDN was the same as the groupbaseDN,
so the LDAP users were compressed into groups, and the roles assigned by some users, such as "80357643", would be kept in the authentication.conf.
Resolved by specifying in authentication.conf
groupBaseDN - a complete DN (including CN) of the LDAP group userBaseDN - a complete DN (including CN) of all the users(semicolon separated) of the group under userBaseDN
After updating the authentication.conf file, splunkd.log has no error about LDAP.
The web UI go to Settings > Access controls > Authentication method and click Reload authentication configuration. This refreshes the authentication caches, but does not disconnect current users. And restarted the instance
| Revision | Publish Date | Comments |
|---|---|---|
1.0 |
29-Sep-2026
|
Initial Release |