[SSSD] GPO ACLs and AGP

Simo Sorce simo at redhat.com
Fri Feb 21 03:08:31 UTC 2014


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

HTH,
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list