[SSSD] GPO ACLs and AGP

Simo Sorce simo at redhat.com
Fri Feb 21 13:47:53 UTC 2014


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.

HTH,
Simo.

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




More information about the sssd-devel mailing list