On Wed, Apr 29, 2015 at 06:33:01PM +0000, Galen Johnson wrote:
I want to be sure I understand this as well...
So, when you have ldap_group_search_base defined, using simple will look for any group name that is defined where the groupname would be (essentially) cn=groupname within the entire ldap_group_search_base definition? For example, if you had the following:
ldap_group_search_base = ou=Groups,ou= Test,dc=example,dc=com?subtree?ou=Groups,ou=Default,dc=example,dc=com?subtree?
the group cn was
cn=groupname,ou=Groups,ou=Default,dc=example,dc=com
then using:
access_provider = simple simple_allow_groups = groupname
would trigger the allow without needing to know the fully defined attribute? I think the answer is "yes". If so, definitely seems "simpler".
The principal difference is that the filter-based options are applied on the /user entry on the server side/. With ldap_access_filter in effect, we run an LDAP search along the following lines: (&(objectclass=user)(name=$login_name)($ldap_access_filter))
If the user entry matches, we allow access. The upside is that this filter can be used for any custom filters. For instance, you could only allow uses who use bash and work for the IT department: ldap_access_filter = (&(loginShell=/bin/bash)(department=IT)) The downside is that many server implementations, notably AD, don't allow an easy way for parent groups to be referenced from the user entry.
The simple access provider on the other hand is applied on the entries in the SSSD cache. The upside is that SSSD resolves the complete[*] nested group hierarchy for you prior to running the check The downside is that only access based on groupname or username can be allowed. But then again, that's what most deployments do anyway.
Btw when talking about AD, I should bring up that since 1.12, SSSD supports using GPOs for access control. There might still be some rough edges here and there, so feel free to report bugs!
[*] there is a configurable nesting limit that defaults to 2 nesting levels with the LDAP provider. The AD provider uses tokenGroups by default which unrolls the memberships, so the nesting doesn't really apply for the AD provider.