LDAP Authorization and many LDAP groups

[colinj]

I'm using LDAP as the authorization mechanism for Splunk and I'm running in to a problem with the number of groups that I need to be able to pull in.

Since we are mapping groups to roles and we are going to have more than a few roles based on which indexes someone is able to see I'm currently querying for a lot of groups and that's causing my group search filter to grow rather large

(|(cn=groupA)(cn=groupB)(cn=groupC). . .(cn=groupZ))

This doesn't seem manageable in the long term as more groups want to use Splunk in our organization. So I'm wondering about nested groups and whether that might solve this problem. Currently we don't have the memberof attribute in use but that might be something that I can make happen. What I'm wondering is, if I do use nested groups will all of the subgroups appear in the role mapping page? Or will it only show the top most group?

colin j.

[reed_kelly · Accepted solution]

If you have a small number of groups in your AD, then you can just use something like: (objectClass=group) and restrict which groups actually have access with the role mappings. If the number is large (>1000), then you may be able to use wildcards like: (cn=group*)(cn=foo*), etc.. In fact, you could use a convention that AD groups with access to Splunk must be of the form splunk and use (cn=splunk*).

Nested groups does seems like a good approach, but I don't think that is supported.

[colinj]

We do have a very large number of groups in our directory (not AD actually). So using all groups would be a nightmare.

I'm thinking that a prefix for the group names is the right way to go at the moment as that keeps the search filter nice and small. The only concern is that our groups are not centrally managed, anyone can create a group.

The ideal situation for me would be a group of groups that then shows all of the group names for role mapping.