Four blog posts and three of them relate to LDAP.  This must be a complicated topic!  It can be and that is why I break it up into chunks that should be easier to digest.

This post will be short and sweet.  I want to provide a few examples of userBaseFilters and groupBaseFilters that you can use in your configuration to make your Splunk experience, hopefully, better.

When you specify a userBaseDN or groupBaseDN without a filter, you are asking your LDAP server to return all entries residing beneath the specified baseDN.   In 99.9999999999% of cases, you don’t actually want all entries.  This is where *BaseFilter configuration comes in handy.  Now, let’s go right to the examples:

If you’re using AD, you can use the following userBaseFilter to return ALL person-type entries that are NOT disabled (We can thank our friend Gerald K. for this one):

userBaseFilter = (&(objectcategory=person)(objectclass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

A method that I have suggested is to use the memberOf attribute as a filter.  If your user entries contain this attribute, it consists of the DN for the group that the user is a “member of”.  In this following example I list out 3 memberOf values to filter on:

userBaseFilter = (|(memberOf=CN=Splunk Admins,OU=Groups,DC=splunksupport,DC=com)(memberOf=CN=Splunk Power Users,OU=Groups,DC=splunksupport,DC=com)(memberOf=CN=Splunk Users,OU=Groups,DC=splunksupport,DC=com))

Please feel free to comment with your own examples!

Now that I’ve (hopefully) convinced you that ldapsearch is your friend, let’s get down to the matter. How can you use that information to configure Splunk to authenticate against LDAP?

The file used to configure LDAP authentication: authentication.conf

If you have never attempted to configure ldap auth before then you won’t have one of these files in your $SPLUNK_HOME/etc/system/local/. You can either create it by hand or use the UI (which creates the file for you.)

Here’s a sample authentication.conf file that I will break down for you. (BTW, a lot of this explanation already exists in a file called $SPLUNK_HOME/etc/system/README/authentication.conf.spec):

[authentication]
* This does not change
authType = LDAP
*If you want LDAP, set it to LDAP. Other options are Splunk and Scripted.
authSettings = myldapstrategy
*the name of your LDAP strategy from

[myldapstrategy]
*This is the custom name you set for your LDAP configuration “strategy”. Do not use any whitespace.
SSLEnabled = 0
*disabled by default - Make sure your LDAP server supports LDAPS if enabling this.
bindDN = cn=Directory Manager
*Bind account used to make requests to LDAP server. If binding to AD, you can use a valid email address, e.g. Gina.Lee@Splunkers.com.
*If your LDAP server allows anonymous bind, you can leave this field blank.
bindDNpassword = $hashed_password
*Enter the password for the configured password. The password gets hashed when you restart Splunk. Leave blank if binding anonymously.
failsafeLogin = admin
*Select an arbitrary, failsafe userid. I like to use ‘admin’ to keep things simple.
failsafePassword = $hashed_password
*Enter your desired password for your failsafe account above. Enter in plain text and it gets hashed on restart.
groupBaseDN = ou=Groups,dc=splunksupport,dc=com;
*This is the Base of your Groups in LDAP. You can also specify multiple bases. For example: ou=Management,ou=Groups,dc=Splunkers,dc=com;ou=Consultants,ou=Groups,dc=Splunkers,dc=com;
groupBaseFilter =
*This is optional. It can be very useful for narrowing down search results if you have a large Directory tree to recurse (and/or large entries being returned.)
groupMappingAttribute = dn
*By default, set this to ‘dn’. I have very rarely seen this set to anything else.
groupMemberAttribute = uniquemember
*Typically, you have a list of members listed out within the group entry. This attribute is the one that stores the member’s dn (usually.)
groupNameAttribute = cn
*This is the “pretty name” for your group. Usually, ‘cn’ but can be set to something else.
host = SplunksupportLDAP
*This is the hostname, FQDN or IP address of your LDAP Server.
pageSize = 0
*This tells the LDAP server how many entries to return “per page” of request. I set this to 0 because I use Sun LDAP in-house for testing — Sun LDAP does not support paging so it has to be disabled this way. If you’re using AD, you can leave it to the default of 800.
port = 389
*The default non-SSL LDAP port is 389. LDAPS default port is 636. Yours could possibly something else.
realNameAttribute = name
*This is the “pretty name” for your users. Other possible attributes you can use are displayName, cn.
userBaseDN = ou=People,dc=splunksupport,dc=com;
*This is the Base of your Users in LDAP. You can specify multiple UserBaseDNs. Example: ou=Tech Support,ou=People,dc=Splunkers,dc=com;ou=ITOPs,ou=People,dc=Splunkers,dc=com;
userBaseFilter =
*Like the groupBaseFilter, this can be very useful if you have to narrow down your search results. Here’s an example that returns only those users who are a member of the SplunkAdmins group or the SplunkUsers group in LDAP: (|(memberOf=CN=SplunkAdmins)(memberOf=CN=SplunkUsers))
userNameAttribute = uid
*This will be the user’s login id.  In AD its usually sAMAccountName.
[roleMap]
*Here’s where you will map the LDAP group to Splunk Role. This must be done before users will be able to log in. The format is usually (Splunk Role) = (LDAP group CN)
admin = Splunk Admin Users;
power = Splunk Power Users;
user = My&Group;Splunk Users;

Once you’ve got LDAP auth configured, restart Splunk and, if you’re lucky, you’ll be able to login as an LDAP user. If not, you’ll have to login as the failsafe user and figure out what went wrong.

A couple more hints: Don’t forget that handy dandy tool called ldapsearch. And, It is very helpful to have DEBUG logging enabled for ‘authenticationManagerLDAP’ when troubleshooting these LDAP issues. And you can now enable DEBUG logging right in the UI, under System Logging, without having to restart Splunk.

OK, if you MUST use an LDAP Browser then check out Apache Directory Studio which is free for OSX, Linux and Windows.
Download, install and launch. Enter your LDAP hostname and go from there.

If you’re tired, frustrated, lost and given up hope after reading this, feel free to contact Splunk Support and we’ll get you moving forward.

If you’ve ever tried exporting lots of events from Splunk UI then you probably know that there’s a hardcoded max of 10,000 lines. This is to prevent users from potentially crashing splunkd or python. Taking the previous into consideration may allow you to view this restriction as a safety feature.

In most cases, users should not need to export 10,000 lines of data. If you’ve got more than 10,000 lines, you should refine your search so that your have less (a lot less) than that. There are probably a few cases where there’s a legitimate reason to export this many lines and more. If you feel the compelling need to be able to export more than 10,000 lines here are a couple of workarounds:

METHOD 1:

Run the search in question and pipe it to csv:

’sourcetype=”samplesourcetype” SenderIP=”192.168.0.12” | outputcsv myoutputfile.csv’

This will create a file named “myoutputfile.csv” in $SPLUNK_HOME/var/run/splunk that contains the results of your search in csv format. If you’ve got access to the file system to grab the file, problem solved. But what if you have a user who doesn’t have access to the file system and you don’t want to have to do this for them?

METHOD 2:

As a Splunk user, you can output your search results to a csv file on the indexer and then input the data and scan through it at your rated limit. Sounds complicated until you see the example. But this does require a bit extra user involvement.

- Just like Method1, you’ll need to run the search and pipe it to csv file:

’sourcetype=”samplesourcetype” SenderIP=”192.168.0.12” | outputcsv myoutputfile.csv’

- After your search completes, you’ll need to manually export at your rated limit (10000 results):

‘| inputcsv start=0 max=10000 myoutputfile.csv’

- Once it is finished running, select “Export results…” from the “Actions” pull down menu. Name a file to save to and be careful to include a unique number in the filename to prevent it from being overwritten on next run: e.g. - myoutputfile10000

- Repeat the previous search with a modified start value:

‘| inputscsv start=10000 max=10000 myoutputfile.csv’

- Once it is finished running, select “Export results…” from the “Actions” pull down menu. Name a file to save to and be careful to include a unique number in the filename to prevent it from being overwritten on next run: e.g. - myoutputfile20000

- Run as many additional searches as needed until you have all your results exported.

Need a friend to help you in the war against seemingly complex LDAP configuration tasks? Let me introduce you to a handy dandy tool called ldapsearch.

Next to an LDAP browser (they cheat, by the way, but I’ll talk more about this later), ldapsearch is your friend when it comes to configuring Splunk, or any other LDAP capable app for that matter, to authenticate against LDAP as it allows you to test out your configuration purely from command-line and then implement once you know its working.

The most important things you’ll need to know about your LDAP server are its hostname or IP address, the LDAP port number and base DN. If you don’t know any of the aforementioned ldapsearch can’t help you there — it does not perform magic. If you’re guessing the LDAP port number, your first guess should be 389 which is the default port for LDAP. (Second guess would be 636, the default LDAPS port. However, that would be treading into SSL waters and I’d like to keep it simple here.) Not knowing any of the required items usually means you should contact your IT/OPS department or someone who manages the LDAP or AD infrastructure at your organization.

STEP 1: Assuming you know the LDAP hostname (or IP),port and base DN, let’s find out if you have access to ldapsearch. Most *nix systems, including OSX, ship with ldapsearch so its a matter of launching the terminal and typing:

$ which ldapsearch
/usr/bin/ldapsearch


If you haven’t got ldapsearch, go online and find one and download it. Stay away from the LDAP browsers (GUI) if possible. I mentioned earlier that LDAP browsers, at least the ones I’ve seen, particularly the ones that run on Windows cheat. They do things like follow ldap referrals (which is just silly.)

STEP 2: Run ldapsearch and pray that the LDAP server you’re connecting to allows anonymous bind. If your LDAP server allows anonymous bind, you can bind to it without providing a bind account and password!

$ ldapsearch -h ldaphostname -p 389 -x -b “dc=splunkers,dc=com”

All of the above options are necessary to perform a simple, anonymous bind to the LDAP server.

-h hostname
-p port number
-x tells ldapsearch to perform a simple_authentication (yes, you need this even for anonymous bind)
-b baseDN

If your organization is relaxed about LDAP access, it should just work. You’ll get human readable output in ldif format that you can pipe to a file for review. If your organization is not so relaxed (most responsible ones are NOT), you may need to provide a bind_account and password:

-D "uid=tina,ou=People,dc=splunkers,dc=com"
-W will prompt you for your password

Example:

$ ldapsearch -h ldaphostname -p 389 -x -D “uid=tina,ou=People,dc=splunkers,dc=com” -b “dc=splunkers,dc=com” -W
Enter LDAP Password:

Here’s what sample user and group entries look like:

# tina, People, splunkers.com
dn: uid=tina,ou=People,dc=splunkers,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgPerson
uid: tina
givenName: Tiny
sn: Ina
cn: Tiny Ina
userPassword::


# TechSupport, Groups, splunkers.com
dn: cn=TechSupport,ou=Groups,dc=splunkers,dc=com
cn: Technical Support
objectClass: top
objectClass: groupOfNames
ou: Groups
member: uid=tina,ou=People,dc=splunkers,dc=com

NOTE: It is possible that LDAP returns no entries even when a proper bind_dn, password and base DN are provided. LDAP can be configured to prevent listing of entries starting at the root base, e.g. “dc=splunkers, dc=com”. In this case, you’ll have to provide a more specific base DN, for example:

-b “ou=People,dc=splunkers,dc=com”
or
-b “ou=Groups,dc=splunkers,dc=com”

Stay tuned for my blog post on how to use this information to configure Splunk to authenticate against LDAP.