Community:Authenticating against an LDAP server which returns referrals

From Splunk Wiki

Jump to: navigation, search

< Back to Best Practices

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.

Server-side referrals

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.

Sample Configuration:

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
Personal tools
Hot Wiki Topics

About Splunk >
  • Search and navigate IT data from applications, servers and network devices in real-time.
  • Download Splunk