How is the BindDN used for LDAP authentication (or: does BindDN need to be in each identified group?)

[hisrocketsignit]

Hi there

I've asked this question in two ways to hedge my bets as I'm trying to understand the mechanism for using LDAP groups in Splunk access a little better, and have a specific issue I'm trying to resolve.

I am trying to set up LDAP group access for Splunk, and have two groups created (including users) for read-only and admin privileges respectively. I have a non-human BindDN name to pull the group data. This BindDN user is not a member of either group. My own ID is, however - in summary, the issue is that when using my non-human BindDN, I cannot pull any groups, but when using my own ID I can see all the groups I am a member of and use those for the LDAP strategy.

So it seems that only a member of the groups can view the details & members of those groups - and I am assuming that at some level this is down to our LDAP implementation. So to resolve, I can add our non-human account to the groups and use that as the BindDN as planned, which is okay if necessary, but does mean we'd need to set up some controls around it.

The first part of my question comes about, however, because via ldapsearch, I CAN pull all group and membership data for all groups everywhere using my same non-human ID, which leads me to think that Splunk is making the query in a way that our LDAP limits the results for - so it would be nice to understand a little more about how that mechanism works to see if there is another way or if I am simply missing something.

Thanks in advance for any help!

[grijhwani]

You set up one LDAP "strategy" per LDAP tree you want to search (which might be one per LDAP server, or might be multiple per LDAP server to encompass separate sub-trees). But to simplify let's assume one server and one search tree.

One of the big gotchas of LDAP is that by default most LDAP servers will not return more than 1000 records, and will truncate at that point, so you have to create your filters to ensure the required record set is within the data returned.

For each strategy you have to provide a BindDN (and if necessary a password) because the BindDN is the authentication/authorisation for your search. If that BindDN does not have query access to the segments of the tree that you need to search, you won't see any results, and that's down to authentication/autorisations set up by the LDAP admin. Ideally you will have a BindDN specifically for your Splunk authentication, and nothing else, which has query access only to the data it needs (i.e. password hashes and group memberships relevant to Splunk role definition). In practice it will probably have access to a broader range of data than it needs, because granular access control across LDAP is a hairy subject.