[SSSD] GPO ACLs and AGP

Yassir Elley yelley at redhat.com
Fri Feb 21 06:24:05 UTC 2014



----- Original Message -----
> On Thu, 2014-02-20 at 21:54 -0500, Simo Sorce wrote:
> > On Thu, 2014-02-20 at 17:53 -0500, Yassir Elley wrote:
> > > 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),
> > 
> > Yes the BUILTIN Domain is local and manged this way.
> > 
> > >  while I am referring to domain-scoped default groups (which can be
> > > set on ACLs in the entire domain, which are managed by ADUC).
> > 
> > The only Domain scoped default groups are "Domain Users, "Domain Admins"
> > etc..
> > 
> > >  More specifically, I am referring to domain-scoped default groups in
> > > the "cn=Builtin" container (as opposed to the "cn=Users" container).
> > 
> > The builtin groups in this container are are domain scoped only in the
> > sense that all domain controllers share the same SAM, however, afaik,
> > they do not influence clients. (If you check them in ADUC they are of
> > 'builtin local' type and can't be changed).
> > 
> > However if you create additional groups in this container you will get
> > "Domain local" groups. These groups have a SID that is in the domain and
> > is not filtered by SSSD afaik. (If you check in ADUC these are of
> > "Domain local" type and can be changed to a different type).
> > 
> > >  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?
> > > 
> > > cn=Builtin, is just the LDAP storage for the BUILTIN domain.
> > 
> > S-1-5-32-545 is in fact the BUILTIN\Users SID, which is the computer SID
> > for the local BUILTIN\Users group you will find in any Windows Machine.
> > That is why it is filtered, because it is not supposed to be managed by
> > the domain controller, it's local stuff on the clients.
> > 
> > Note that BUILTIN\Users, is augmented by adding as its member the
> > "Domain Users" group at domain join, so on the local machine you do have
> > the BUILTIN\Users group in your credentials as this group is added to
> > you transitively by the logon process. However different machines can
> > have different memberships for that group in theory as it is managed
> > locally.
> > 
> > I am surprised the tokenGroups call would return those SIDs, I'd
> > consider it a bug, in any case the authoritative memberships are
> > contained in the MS-PAC which usually do not list groups from the
> > BUILTIN domain in my experience.
> > 
> > Long story short BUILTIN groups memberships should be decided locally,
> > if you need them we can think of adding the concept in SSSD, but I would
> > like to understand what kind of policies would reference BUILTIN\Users
> > rather than Domain Users ? Do you have an example ?
> 
> Just wanted to add a pointer to an article that gives a decent
> explanation with pictures too :-)
> http://www.windowsecurity.com/articles-tutorials/authentication_and_encryption/Built-in-Groups-Delegation.html
> 

I find the terminology very confusing because different articles contradict each other on the topic of Built-in Groups, with some Microsoft Technet articles indicating that Built-in Groups are "domain local", and other articles stating they are "builtin local". 

In any case, the reason I thought of this scenario was that, when working on GPO DACL filtering (in order to determine whether the GPO is applicable to a specific policy target user/computer), I noticed that a Windows admin could add or remove security principals from the GPO's DACL using the "Delegation" tab, which specifically states that one can add users, groups, or "built-in" security principals (to the GPO's DACL).

For example, you may create a domain-linked GPO, which will then be applicable to all users/computers in the domain. However, you may decide that you *don't* want this GPO to be applicable to members of the Domain Controller BUILTIN\Account_Operators group, the membership of which is shared by all Domain Controllers in the domain. So you add an Access Control Entry to the GPO's DACL indicating that the "Apply Group Policy" right should not be granted to members of BUILTIN\Account_Operators. When a user logs in to the domain from a particular computer, the sssd/gpo code running on that computer needs to determine whether this GPO is applicable (i.e. needs to determine whether the user or computer is a member of BUILTIN\Account_Operators).

The example I have given makes sense to me because the BUILTIN\Account_Operators group is *only* found on DC's (not on domain members). I'm not sure how it should work in the case where the local computer and DC both have BUILTIN groups with the same name. For example, a domain member can have its own BUILTIN\Users and the DC can have its own BUILTIN\Users. Perhaps there is some distinction between "local" built-in and "DC" built-in. I don't know the answer to that. But I think the BUILTIN\Account_Operators example is valid and sssd currently prevents its membership from being stored in the sysdb cache.

Perhaps we haven't run into this problem before because the DC enforces the standard read/write/delete permissions on its own AD objects, so sssd has never cared about the membership of the DC's BUILTIN groups. However, in this case, the GPO enforcement code is running on the client (in sssd), and it does care about such membership.

Regards,
Yassir.



More information about the sssd-devel mailing list