We've implemented the dynlist overlay in our LDAP server, and are having trouble getting Splunk to read any dynamic groups. Testing w/ a "static" group (objectclass=GroupofNames) does work. Not sure if Splunk can't cope with the objectclass=GroupofURLs, or if there is something I'm missing in the authentication.conf for this?
thanks in advance.
I'm reasonably certain that Splunk does not support expansion of dynamic groups directly. If I'm understanding correctly, however, the overlay should be taking care of the expansion for you.
With that in mind, the first step would be to verify that the groups are being expanded correctly, using ldapsearch from the command line as described here.
If that works, then make sure that the
member attribute exists in the results, and that it contains the valid
dn for each user. If not, you'll need to either fix the dynamic group or set
Some LDAP servers also have a requirement that the objectClass that is the "trigger" for the dynamic group be explicitly included in the search filter before expansion will occur. You may want to try setting
groupBaseFilter = (objectclass=GroupofURLs) and see if anything changes.
If all else fails, try using a sniffer to watch the LDAP traffic and see the exact queries and responses. That's the most definitive way to tell whether the LDAP server is actually returning all results (indicating a Splunk issue) or whether expansion isn't working (an LDAP isue).
Correct. I honestly have never heard of an LDAP client external application that "expands" dynamic LDAP groups. The entire point of dynamic LDAP groups is that the server expands them dynamically at query time and provides the list of users to a client that knows nothing of it. At most, you may have to use a different attribute to get the list of dynamic members, but normally only tools that are for managing the LDAP server itself have to break the abstraction and find out the filters.
Sorry, I should have added that ldapsearch from the commandline works fine. I've set up a test static group and a dynamic group, and either will return the appropriate members. Looking at the openldap.log I can see when using the groupbasefilter cn=dynamic group, it's screwing up the search filter. (Still has the correct base, etc. but is doing filter="(&(cn=staticgroup)(cn=dynamicgroup))" even though I ONLY have the dynamicgroup as the filter in splunk. I can attach more results from ldapsearch, auth.conf, etc. but I'm sensing this just doesn't work.
That filter looks a little funny to me. Do you have "cn" anywhere in your userBaseFilter or groupBaseFilter? If so, you almost certainly shouldn't.
If you can edit your question above and post the relevant portions of your config (sanitized if necessary), it would probably go a long way toward understanding what's happening.
I recently got this working on my own system, so I thought I would share the configuration. The LDAP portion is defined on similar work I wrote up for securing logins to Linux servers through PAM. That is treated in detail here: http://www.hurricanelabs.com/newsletters/login-security-using-openldap-and-pam/
For now though, I will just post the quick relevant parts to this discussion.
In slapd.conf, I have the following:
overlay dynlist dynlist-attrset groupOfNames labeledURI member
Sample LDIF would look something like this:
dn: cn=splunk,ou=groups,dc=example,dc=com objectClass: top objectClass: groupOfNames objectClass: labeledURIObject cn: splunk labeledURI: ldap:///ou=users,dc=example,dc=com??one?(host=splunk) member: cn=placeholder,dc=example,dc=com
Relevant LDIF for the user would be something like this:
dn: uid=steve,ou=users,dc=example,dc=com uid: steve uidNumber: 1000 gidNumber: 100 cn: Steve User host: splunk objectClass: person objectClass: posixAccount objectClass: hostObject
The following authentication.conf file is working for me to map users in LDAP with the host=splunk attribute to the admin role. The key is the dynamicMemberAttribute value that is used to tell splunkd which attribute to pull in order to do the dynamic search. Splunk does do the dynamic expansion on its own, which is why it requires this field. I cannot get this to work without that being defined. As soon as I remove it in Manager, I immediately get kicked out when logged in as an LDAP user.
[authentication] authSettings = example.com authType = LDAP [roleMap_example.com] admin = splunk [example.com] SSLEnabled = 0 anonymous_referrals = 0 bindDNpassword = $1$0w== charset = utf8 dynamicMemberAttribute = labeleduri groupBaseDN = ou=groups,dc=example,dc=com groupBaseFilter = (cn=splunk) groupMappingAttribute = dn groupMemberAttribute = member groupNameAttribute = cn host = ldap.example.com nestedGroups = 0 network_timeout = 20 port = 389 realNameAttribute = cn sizelimit = 1000 timelimit = 15 userBaseDN = ou=users,dc=example,dc=com userBaseFilter = (host=splunk) userNameAttribute = uid