Security
Highlighted

LDAP User Base Filter

Builder

I noticed these errors in my splunkd log:

06-12-2012 16:54:49.652 +0000 ERROR UserManagerPro - Failed to get LDAP user="Yoda" from any configured servers
06-12-2012 16:54:49.680 +0000 ERROR AuthenticationManagerLDAP - Couldn't find matching groups for user="Yoda". Search filter="(uniquemember=uid=Yoda,ou=inactive,ou=people,dc=mydomain,dc=com)" strategy="LDAPAuth"

These errors are for multiple users that have since departed. I believe the issue is the following:

Our User Base DN is setup as follows for Splunk Authentication:

 ou=people,dc=mydomain,dc=com;

However in LDAP under ou=people we also have another ou called "ou=inactive". This ou contains users who have since departed.

I'd like to tell splunk to not even look in ou=inactive. I noticed there is User Base Filtering. My question is, if I put in "ou=inactive" would it filter this out? From the description of what this does, it sounds like the opposite.

Enter the User base filter for the object class you want to filter your users on.

    This is recommended to return only applicable users. For example: (department=IT).
    Default value is empty, meaning no user entry filtering. 

How can you filter out an ou that is in another ou for ldap authentication?

Tags (1)
Highlighted

Re: LDAP User Base Filter

SplunkTrust
SplunkTrust

LDAP filters don't work on OU membership, but on attributes of the entries in the directory. There's some good docs on how they work at http://www.centos.org/docs/5/html/CDS/ag/8.0/Finding_Directory_Entries-LDAP_Search_Filters.html .

If you can associate an attribute with all of your 'inactive' users, then you can filter on it. For example, you can extend your schema with a new objectclass of "inactiveAccount" and then do a search filter on:

(!(objectclass=inactiveAccount))

The suckage here is that you have to update all of those accounts and assign that objectclass to them.

Or, if this is active directory (or another directory that assigns pseudo-attributes based on group membership), then you could create an 'inactiveAccounts' group and put everyone in it, then filter by:

(!(memberOf=inactiveAccounts))

Neither of these approaches really provides a lot of winnage though, because you have to do something to every account that gets put into inactive. Perhaps move your "ou=inactive" out to be a peer of "ou=people" instead of a child of it?