Community:Authenticating against an LDAP server which returns referrals
From Splunk Wiki
Authenticating against an LDAP server which returns referrals (such as Active Directory)
As stated in our known issues with LDAP, Splunk does not currently support LDAP referrals.
With this in mind, you might want an alternative and this page is intended to document the alternatives. If you are interested in the referral capability, be sure email Splunk Support to log a support case requesting this feature enhancement. The best way to test if we will work/support any proposed workaround is to use the
ldapsearch command when performing your tests. Splunk-to-LDAP authentication communicates similarly to the ldapsearch command.
Some LDAP servers have the capability to handle the referral on their own. This is called a server side referral and would be enabled on the LDAP server (if it supports it). This has been done by some customers although I cannot confirm which software supports the server side referral.
Use the Global Catalog Server (only applicable for Active Directory servers)
Active Directory servers have the capability to return LDAP search results that exclude referrals (will turn referrals off). This capability is defined as serving global catalog searches. These searches run on port 3268 and are only valid for AD servers which are created as Global Catalog Servers. Things to be aware of:
- Not all AD servers are Global Catalog Servers. Be sure you enable the correct AD server as the Global Catalog Server
- Run an ldapsearch (with the proper credentials) against port 3268. You will likely find that you are missing attributes/data
- To use LDAPS, set your port to 3269
- Replicate the required data on the Global Catalog Server (AD server)
- Run the ldapsearch again to verify functionality
- Setup splunk to use the proper credentials and port number
- Be sure to use realNameAttribute=name or realNameAttribute=displayName. There is a known issue when using realNameAttribute=cn.
Create a standalone instance
This is the one of the most extreme workarounds. This would require the LDAP admin to replicate only the Splunk users and store them on a separate instance. Customers have done this previously, but not without hesitation due to the work involved.
[AD] SSLEnabled = 0 bindDN = cn=Administrator,cn=Users,dc=splunksupport,dc=kom bindDNpassword = password failsafeLogin = failsafe failsafePassword = password groupBaseDN = CN=Builtin,DC=splunksupport,DC=kom; groupBaseFilter = (objectclass=*) groupMappingAttribute = dn groupMemberAttribute = member host = support06 pageSize = 800 port = 3268 realNameAttribute = displayName userBaseDN = CN=Users,DC=splunksupport,DC=kom; userBaseFilter = (objectclass=*) userNameAttribute = sAMAccountName groupNameAttribute = cn