LDAP users failed to login to Splunk

Applicability

Splunk Enterprise

Description

The account for the LDAP users is locked about once a day. Once locked, all LDAP users are prevented from logging into Splunk and require manual intervention to log in.

Investigation

Observe the warning below in the splunkd.log:

WARN ScopedLDAPConnection [15758 PrecacheUsersThread] - strategy="ldap_splunk_BC2" LDAP Server returned warning in search for DN="OU=ouGroups_Users,DC=NWS,DC=local". reason="Operations error"

To consider:
- Was this working before?
- Is this an Active Directory?
- Does the LDAP server allow anonymous binding?
- Is the "bindDNpassword" set correctly in the authentication.conf?

Checking the authentication.conf, check if the anonymous_referrals is enabled (enabled by default) in each of your LDAP stanzas.

[uses_ldap_<>]
anonymous_referrals = 1

anonymous_referrals = [0|1]
* Set this to 0 to turn off referral chasing
* Set this to 1 to turn on anonymous referral chasing
* NOTE: the Splunk platform only chases referrals using anonymous bind.
It does not support rebinding using credentials.
* If you do not need referral support, set this to 0.
* If you wish to make referrals work, set this to 1 and confirm your server
allows anonymous searching
* This setting is optional.
* Default: 1

 

Most of the workarounds suggest turning off this attribute. However, this might not work without confirming the above "to-consider" questions.

1. Additionally, set up debug for LDAP in the problematic Splunk by setting log-level as below from the cli(restart not required)

splunk set log-level AuthenticationProviderLDAP -level DEBUG
splunk set log-level LoadLDAPUsersThread -level DEBUG
splunk set log-level ScopedLDAPConnection -level DEBUG

2. Once the debug is set, reproduce the issue by trying to authenticate as an LDAP user.

3. Collect a diag from the problematic server and upload it to the case.

/opt/splunk/bin/splunk diag --upload --case-number=<> --upload-description="[INSTANCE NAME]"

4. Also generally reapplying the LDAP strategy would resolve the issue.

Resolution

It is not recommended to push a configuration bundle that the peer needs to update automatically.

For example, in case the authentication.conf has the "bindDNpassword" specified in the app bundle being pushed. This would not allow the peers to update the unencrypted "bindDNpassword" upon a restart, the reason being the $SPLUNK_HOME/etc/peer-apps directory on the peers is read-only. 

Likewise, as mentioned in this document such deployment would create a duplicate app in the peers.

Therefore, upon restart after bundle push, they instead write the encrypted version to $SPLUNK_HOME/etc/apps/<app>, with the same name as its name under $SPLUNK_HOME/etc/peer-apps/<app>

Supplying this authentication.conf manually in each peer with the "bindDNpassword" value allows the peers to encrypt the plain test value upon restart.

Related Links

authentication.conf.spec

Settings that you should not distribute through the configuration bundle

LDAP strategy 

Revision History

Revision	Publish Date	Comments
1.0	30-Sep-2026	Initial Release