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
> > > locally-scoped default groups (which can be set on ACLs on the local
> > > computer only, which are managed using the "Local Users and
> > > 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
> > etc..
> > > More specifically, I am referring to domain-scoped default groups in
> > > the "cn=Builtin" container (as opposed to the
> > 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
> > 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),
> > > 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
> > 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 :-)
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
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
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
But I think the BUILTIN\Account_Operators example is valid and sssd
currently prevents its membership from being stored in the sysdb
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
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
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
Simo Sorce * Red Hat, Inc * New York