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 ?
Simo.