On 02/20/2014 03:46 PM, Yassir Elley wrote:
This email proposes two changes that would allow sssd to correctly support ACL processing
on GPO objects.
In addition to various other factors, in order for a GPO to be considered applicable to a
particular computer target, the GPO object's AD ACL must grant the
"ApplyGroupPolicy" right (AGP) to the computer (or, more likely, to a group of
which the computer is a member). By default, AD grants the AGP right to the
"Authenticated Users" group, which includes both authenticated users and
computers. While this group can be placed on AD ACLs (like other groups), it is special in
that its membership is supposed to be maintained by the client (not by AD). Additionally,
Windows admins can change this default behavior by denying the AGP right to the
"Authenticated Users" group, and by granting the AGP right to some other
security principal (which could be a "built-in" principal).
Since there has never been a need, SSSD neither maintains an "Authenticated
Users" group membership, nor does it cache any Built-in Groups (those whose SIDS are
of the form S-1-5-32-*, such as "Administrators", "Users", etc )
returned from LDAP. In order to support the ACL filtering of GPOs described above, the GPO
code needs to know which Built-in Groups the computer target is a member of.
I have the following two proposals:
1. I propose that the GPO access-control code (which is executed after a successful pam
authentication) should just assume that any user or computer is a member of the
"Authenticated Users" group. This would be local to the GPO code, and would
therefore have no effect on other SSSD components.
IMO makes sense
2. I propose that SSSD should no longer filter out built-in groups
returned by LDAP, but should rather store them in the sysdb cache, in the same manner as
it stores other groups. This would allow the GPO code to seamlessly include the built-in
groups in its ACL processing decision. Since we would be storing these built-in groups in
the cache, they would be visible to other SSSD components. An alternative would be to have
the GPO code interact with AD to determine the computer's group memberships directly
(without consulting the cache), but that seems too inefficient.
I think it was done for a reason so it might change the semantics.
If we need this info cached may be we should store it in a different
area of cache so that other components do not see it but GPO code would
know and consult?
sssd-devel mailing list
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?