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"
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"
> More specifically, I am referring to domain-scoped default groups in
> the "cn=Builtin" container (as opposed to the "cn=Users"
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
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 :-)
Simo Sorce * Red Hat, Inc * New York