[SSSD] GPO ACLs and AGP

Yassir Elley yelley at redhat.com
Fri Feb 21 14:19:22 UTC 2014



----- Original Message -----
> On Fri, 2014-02-21 at 01:24 -0500, Yassir Elley wrote:
> > 
> > ----- 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".
> 
> The confusion stems from the fact that the 'predefined' groups are
> "builtin local", but if you create new groups in the cn=Builtin
> container they are "domain local".
> Builtin groups are always special and you cannot create new "builtin
> groups" ever, as the BUILTIN domain cannot be modified by the Admin.
> 
> > 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).
> 
> Ok, but the fact it is possible doesn't necessarily mean it is a good
> idea. In fact there are several warnings to not use  builtin groups
> unless you know what you are doing.
> 
> > 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).
> 
> This is fine, but unless SSSD is ever made to run on a domain
> controller, then BUILTIN\Account_Operators will never apply, *unless* we
> decide to define a 'local to sssd' group with that name/sid.
> 
> Ie, you can fully ignore this kind of DACL for "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.
> 
> We may want to implicitly consider "Domain Users" as part of BUILTIN
> \Users and "Domain Administrators" as part of BUILTIN\Administrator as
> that's the default on Windows machines that are joined to a Windows
> Domain (the join procedure adds thos domain groups to the local builtin
> groups).
> So perhaps we will have, at some point, to introduce these additional
> mappings. Winbindd also allows you to manage Builtin groups this way for
> the same reasons.
> 
> However we still *have to* filter BUILTIN groups (ie groups of SID
> S-1-5-32-*) from any tokengroup response, because those groups are
> strictly local and in the Windows architecture are not controlled by the
> DCs for normal clients.
> 
> > 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.
> 
> It should care, but those memberships are local, so whatever is the
> content of the "builtin local" groups on the DC is meaningless for the
> clients.
> 

Upon further investigation (and IRC), I agree with you that "builtin local" groups on the DC are not relevant to clients. As such, I withdraw my second proposal and agree that we should keep filtering any builtin groups returned by an LDAP request for tokenGroups. With regard to adding implicit mappings, I think we should hold off on that until we implement more comprehensive semantics for local accounts. Thanks for the clarifications! Much appreciated!

Regards,
Yassir.



More information about the sssd-devel mailing list