----- Original Message -----
On Thu, 2014-02-20 at 15:46 -0500, 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
> 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.
Make sense for now, however going forward we will have to add this SID
to a security token of sorts if SSSD is to be used wit the Samba File
Server, so in future we may want to have an explicit "Windows Security
Context" that lists all SIDs, including this one.
> 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.
Something's not right here.
Built-in groups are an inherently "local" concept in Windows, they are
not associated with domain users (you will not find built-in SIDs in the
MS-PAC or in tokenGroups replies) and are meant to have meaning only on
the local system where they are defined.
Can you give me a reference for the use of built-in groups with GPOs ?
The word "built-in" is ambiguous here. I think you are referring to
locally-scoped default groups (which can be set on ACLs on the local computer only, which
are managed using the "Local Users and Groups" GUI), while I am referring to
domain-scoped default groups (which can be set on ACLs in the entire domain, which are
managed by ADUC). More specifically, I am referring to domain-scoped default groups in the
"cn=Builtin" container (as opposed to the "cn=Users" container).
Indeed, when SSSD performs an LDAP call to retrieve tokenGroups, LDAP returns the
domain-scoped built-in "Users" group (S-1-5-32-545), but SSSD specifically
filters out all builtin group SIDs (of the form S-1-5-32-*), and therefore SSSD does not
save this SID to the sysdb cache. Does that make sense?
PS: For a good description of default groups vs default local groups, see