Documentation: 3.0
|  Print Version Contents
This page last updated: 12/04/07 04:12pm

Set up LDAP

Splunk supports authentication via its internal authentication services or your existing LDAP v3 server. You can configure multiple LDAP servers (defined as an Authentication Strategy) but Splunk supports only using one at a time. You must specify a user for the bind, as Splunk 3.x does not support anonymous bind. You may wish to create a user with minimal privileges for this purpose.

Configure your Authentication Strategy via SplunkWeb

In the Admin section, click the Server tab . Then click the Authentication Configuration header. Select LDAP from the Set Authentication method drop-down.

http://www.splunk.com/assets/doc-images/30_admin12_authLDAP/ldap.jpg

Configure Splunk to use your LDAP server

These are the steps that you need to follow in order to successfully configure Splunk to use your existing LDAP infrastructure:

  • Define an LDAP strategy name for your configuration. The name cannot be LDAP and it must not contain spaces.
    • Once you have saved your LDAP configurations, the strategy name will be added to the Set Authentication Strategy drop-down.
  • Specify the Host name of your LDAP server. Be sure that your Splunk Server can resolve the host name.
  • Specify the Port that Splunk should use to connect to your LDAP server. By default LDAP servers listen on TCP port 389.
  • Specify the Distinguished Name (DN) to bind to the LDAP server with; typically the administrator or manager user. Should have full read access.
  • Specify the password of the user Splunk is using to bind to the LDAP server.
  • Confirm the password.
  • Specify the User base DN that Splunk should use when looking up user information.
  • Specify the User base filter for the object class you want to filter your users on.
    • IMPORTANT: The username attribute cannot contain whitespace. The username is case sensitive.
  • Specify the Group base DN that Splunk should use when looking up group information.
  • Specify the Group base filter, the attribute that defines the group name. The standard OpenLDAP/POSIX value is gid.
  • Enter the User name attribute that defines the user name. The standard OpenLDAP/POSIX value is uid. for example, sAMAccountName for an AD account
  • Specify the Real name attribute (also referred to as the common name) of the user. The standard OpenLDAP/POSIX value is cn.
  • Input the Group name attribute. Use only if users and groups are defined in the same tree. Usually cn.
  • Specify the Group member attribute. The standard OpenLDAP/POSIX value is member. Usually member or memberOf, depending on whether the memberships are listed in the group entry or the user entry.
  • Enter the Group mapping attribute. Enter this value only if your member entries don't contain dn strings. Usually dn. In most cases, you can leave this field blank.
  • Enter a value for pageSize. This determines how many records to return at one time. Enter 0 to disable and revert to LDAPv2
  • Specify a Failsafe user name. This user will allow you to authenticate into Splunk in the event that your LDAP server is unreachable.
    • IMPORTANT: This user has admin privileges on the Splunk install.
  • Specify a Failsafe user password for your failsafe user.
    • Confirm the failsafe password.

Determine your User and Group Base DN

The distinguished name is the location in the directory where authentication information is stored. If all information is contained in each user's entry, then these distinguished names must be the same. If group membership information for users is kept in a separate entry, then supply a separate distinguished name identifying the subtree in the directory where the group information is stored.

This allows flexibility in configuration and prevents Splunk from having to extend the LDAP schema.

Examples

Case 1: User entries in the directory have both password and group membership stored in them. User entry DNs are of the form userid=bjensen,ou=People,o=MyCo.

userBaseDN = ou=People,o=MyCo
groupBaseDN = ou=People, o=MyCo

Case 2: Group membership information is kept in a separate entry from the user entries. User entry DNs are of the form userid=bjensen,ou=People,o=MyCo and group information is stored at gid=Users,ou=Groups,o=MyCo

userBaseDN = ou=People,o=MyCo
groupBaseDN = ou=Groups,o=MyCo

Map existing LDAP groups to Splunk Roles

Once you have configured your Splunk Server to authenticate via your LDAP server you will need to map your existing LDAP groups to Splunk's user role levels. If you do not use groups you can map users individually, but note that you can either map users or map groups but not both. If you are using groups, all the users you wish to have access to Splunk must be members of an appropriate group.

Under the Users tab you will see all of your users and groups. Click the Edit link next to the appropriate user or group to define User Roles

Test your LDAP configuration

If you find that your Splunk install is not able to successfully connect to your LDAP server there are a few troubleshooting steps that you can perform:

  • Remove any custom values you've added for userBaseFilter and groupBaseFilter until your configuration is correct.
  • Check your $SPLUNK_HOME/var/log/splunk/splunkd.log for any authentication errors.
  • Perform an ldapsearch to test that the variables you are specifying will work:
ldapsearch -h "<host>" -p "<port>" -b "<userBaseDN>" -x -D "<bindDN>" -w "<bindDNpassword>"
ldapsearch -h "<host>" -p "<port>" -b "<groupBaseDN>" -x -D "<bindDN>" -w "<bindDNpassword>"

Sample configurations

Mapping users directly

This example has all the users in the same location, with no separate group records. Users are mapped to roles via the employeeType.

auth.conf:

[auth]
authType = LDAP
authSettings = iPlanetCongress

[iPlanetCongress]
groupNameAttribute = employeeType
host = 10.1.1.162
port = 3389
SSLEnabled = 0
failsafeLogin = admin
failsafePassword = 
bindDN = cn=Directory Manager
bindDNpassword = 
userBaseDN = ou=Congressmen,dc=splunk,dc=com;
groupBaseDN = ou=Congressmen,dc=splunk,dc=com;
userNameAttribute = sn
realNameAttribute = cn
pageSize = 0
groupBaseFilter = (objectclass=*)
groupMappingAttribute = dn
userBaseFilter = (objectclass=*)
groupMemberAttribute =
Admin = Representative
Power =
User = Senator

User's ldif:

dn: cn=Adam Putnam, ou=Congressmen,dc=splunk,dc=com
givenName: Adam
sn: Putnam
employeeType: Representative
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
postalAddress: 1213 LONGWORTH HOUSE OFFICE BUILDING $ WASHINGTON DC 20515
cn: Adam Putnam
employeeNumber: 12
businessCategory: Republican
st: FL

Users and groups in the same location

This example uses the same userBaseDN and groupBaseDN

auth.conf


[AD]
SSLEnabled = 0
bindDN = cn=Administrator,CN=Users,DC=ad,DC=splunk,DC=com
bindDNpassword =
failsafeLogin = admin
failsafePassword =
groupBaseDN = CN=Users,DC=ad,DC=splunk,DC=com;
groupBaseFilter = (objectclass=*)
groupMappingAttribute = dn
groupNameAttribute = memberOf
host = 10.1.1.27
pageSize = 800
port = 389
realNameAttribute = cn
userBaseDN = CN=Users,DC=ad,DC=splunk,DC=com;
userBaseFilter = (objectclass=user)
userNameAttribute = sAMAccountName
Admin = CN=Group Policy Creator Owners,CN=Users,DC=ad,DC=splunk,DC=com;CN=TestGroup3,CN=Users,DC=ad,DC=splunk,DC=com;
Power = CN=TestGroup2,CN=Users,DC=ad,DC=splunk,DC=com;
User = CN=TestGroup1,CN=Users,DC=ad,DC=splunk,DC=com;
groupMemberAttribute =

[auth]
authSettings = AD
authType = LDAP

User ldif

dn: CN=Administrator, CN=Users, dc=ad,DC=splunk,DC=com
sAMAccountType: 805306368
primaryGroupID: 513
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
adminCount: 1
badPasswordTime: 128323857101974560
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=splunk,DC=com
cn: Administrator
userAccountControl: 66048
codePage: 0
distinguishedName: CN=Administrator,CN=Users,DC=ad,DC=splunk,DC=com
whenChanged: 20070503190032.0Z
whenCreated: 20070406210810.0Z
pwdLastSet: 128226924328683968
logonCount: 48
isCriticalSystemObject: TRUE
description: Built-in account for administering the computer/domain
accountExpires: 9223372036854775807
lastLogoff: 0
objectGUID:
lastLogon: 128324519126218672
uSNChanged: 57357
uSNCreated: 8194
objectSid: 
countryCode: 0
sAMAccountName: Administrator
instanceType: 4
memberOf: CN=Group Policy Creator Owners,CN=Users,DC=ad,DC=splunk,DC=com
memberOf: CN=Domain Admins,CN=Users,DC=ad,DC=splunk,DC=com
memberOf: CN=Enterprise Admins,CN=Users,DC=ad,DC=splunk,DC=com
memberOf: CN=Schema Admins,CN=Users,DC=ad,DC=splunk,DC=com
memberOf: CN=Administrators,CN=Builtin,DC=ad,DC=splunk,DC=com
badPwdCount: 0
name: Administrator

Group ldif

dn: CN=Group Policy Creator Owners, CN=Users, dc=ad,DC=splunk,DC=com
member: CN=Administrator,CN=Users,DC=ad,DC=splunk,DC=com
sAMAccountType: 268435456
objectClass: top
objectClass: group
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=ad,DC=splunk,DC=com
cn: Group Policy Creator Owners
groupType: -2147483646
distinguishedName: CN=Group Policy Creator Owners,CN=Users,DC=ad,DC=splunk,DC=com
whenChanged: 20070406211429.0Z
whenCreated: 20070406211428.0Z
isCriticalSystemObject: TRUE
description: Members in this group can modify group policy for the domain
objectGUID:
uSNChanged: 12380
uSNCreated: 12350
objectSid: 
sAMAccountName: Group Policy Creator Owners
instanceType: 4
name: Group Policy Creator Owners

Previous: Set up users    |    Next: How data distribution works

Comments

  1. I get an error after entering my ldap configs:
    <module 'splunk.clilib.cli_common' from '/Applications/splunk/lib/python2.4/site-packages/splunk/clilib/cli_common.pyc'>
    Malformed XML or SOAP returned from the call getAuthConfig, with parameters .: None

    The GUI then becomes unusable with a bunch of java/xml errors on the screen.

    I had this problem with Splunk 2.x and now same problem in 3.0.

    I am going to try and work around this by hand editing /Applications/splunk/etc/bundles/local/auth.conf, but it seems like this is a bug because the GUI does not "nicely" report an error.
    Posted by jacbop on Sep 04 2007, 8:34am

Log in to comment.