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.