Hi,
This email proposes two changes that would allow sssd to correctly support ACL processing on GPO objects.
In addition to various other factors, in order for a GPO to be considered applicable to a particular computer target, the GPO object's AD ACL must grant the "ApplyGroupPolicy" right (AGP) to the computer (or, more likely, to a group of which the computer is a member). By default, AD grants the AGP right to the "Authenticated Users" group, which includes both authenticated users and computers. While this group can be placed on AD ACLs (like other groups), it is special in that its membership is supposed to be maintained by the client (not by AD). Additionally, Windows admins can change this default behavior by denying the AGP right to the "Authenticated Users" group, and by granting the AGP right to some other security principal (which could be a "built-in" principal).
Since there has never been a need, SSSD neither maintains an "Authenticated Users" group membership, nor does it cache any Built-in Groups (those whose SIDS are of the form S-1-5-32-*, such as "Administrators", "Users", etc ) returned from LDAP. In order to support the ACL filtering of GPOs described above, the GPO code needs to know which Built-in Groups the computer target is a member of.
I have the following two proposals:
1. I propose that the GPO access-control code (which is executed after a successful pam authentication) should just assume that any user or computer is a member of the "Authenticated Users" group. This would be local to the GPO code, and would therefore have no effect on other SSSD components.
2. I propose that SSSD should no longer filter out built-in groups returned by LDAP, but should rather store them in the sysdb cache, in the same manner as it stores other groups. This would allow the GPO code to seamlessly include the built-in groups in its ACL processing decision. Since we would be storing these built-in groups in the cache, they would be visible to other SSSD components. An alternative would be to have the GPO code interact with AD to determine the computer's group memberships directly (without consulting the cache), but that seems too inefficient.
Comments?
Regards, Yassir.
On 02/20/2014 03:46 PM, Yassir Elley wrote:
Hi,
This email proposes two changes that would allow sssd to correctly support ACL processing on GPO objects.
In addition to various other factors, in order for a GPO to be considered applicable to a particular computer target, the GPO object's AD ACL must grant the "ApplyGroupPolicy" right (AGP) to the computer (or, more likely, to a group of which the computer is a member). By default, AD grants the AGP right to the "Authenticated Users" group, which includes both authenticated users and computers. While this group can be placed on AD ACLs (like other groups), it is special in that its membership is supposed to be maintained by the client (not by AD). Additionally, Windows admins can change this default behavior by denying the AGP right to the "Authenticated Users" group, and by granting the AGP right to some other security principal (which could be a "built-in" principal).
Since there has never been a need, SSSD neither maintains an "Authenticated Users" group membership, nor does it cache any Built-in Groups (those whose SIDS are of the form S-1-5-32-*, such as "Administrators", "Users", etc ) returned from LDAP. In order to support the ACL filtering of GPOs described above, the GPO code needs to know which Built-in Groups the computer target is a member of.
I have the following two proposals:
- I propose that the GPO access-control code (which is executed after a successful pam authentication) should just assume that any user or computer is a member of the "Authenticated Users" group. This would be local to the GPO code, and would therefore have no effect on other SSSD components.
IMO makes sense
- I propose that SSSD should no longer filter out built-in groups returned by LDAP, but should rather store them in the sysdb cache, in the same manner as it stores other groups. This would allow the GPO code to seamlessly include the built-in groups in its ACL processing decision. Since we would be storing these built-in groups in the cache, they would be visible to other SSSD components. An alternative would be to have the GPO code interact with AD to determine the computer's group memberships directly (without consulting the cache), but that seems too inefficient.
I think it was done for a reason so it might change the semantics. If we need this info cached may be we should store it in a different area of cache so that other components do not see it but GPO code would know and consult?
Comments?
Regards, Yassir. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Thu, 2014-02-20 at 15:46 -0500, Yassir Elley wrote:
Hi,
This email proposes two changes that would allow sssd to correctly support ACL processing on GPO objects.
In addition to various other factors, in order for a GPO to be considered applicable to a particular computer target, the GPO object's AD ACL must grant the "ApplyGroupPolicy" right (AGP) to the computer (or, more likely, to a group of which the computer is a member). By default, AD grants the AGP right to the "Authenticated Users" group, which includes both authenticated users and computers. While this group can be placed on AD ACLs (like other groups), it is special in that its membership is supposed to be maintained by the client (not by AD). Additionally, Windows admins can change this default behavior by denying the AGP right to the "Authenticated Users" group, and by granting the AGP right to some other security principal (which could be a "built-in" principal).
Since there has never been a need, SSSD neither maintains an "Authenticated Users" group membership, nor does it cache any Built-in Groups (those whose SIDS are of the form S-1-5-32-*, such as "Administrators", "Users", etc ) returned from LDAP. In order to support the ACL filtering of GPOs described above, the GPO code needs to know which Built-in Groups the computer target is a member of.
I have the following two proposals:
- I propose that the GPO access-control code (which is executed after
a successful pam authentication) should just assume that any user or computer is a member of the "Authenticated Users" group. This would be local to the GPO code, and would therefore have no effect on other SSSD components.
Make sense for now, however going forward we will have to add this SID to a security token of sorts if SSSD is to be used wit the Samba File Server, so in future we may want to have an explicit "Windows Security Context" that lists all SIDs, including this one.
- I propose that SSSD should no longer filter out built-in groups
returned by LDAP, but should rather store them in the sysdb cache, in the same manner as it stores other groups. This would allow the GPO code to seamlessly include the built-in groups in its ACL processing decision. Since we would be storing these built-in groups in the cache, they would be visible to other SSSD components. An alternative would be to have the GPO code interact with AD to determine the computer's group memberships directly (without consulting the cache), but that seems too inefficient.
Something's not right here. Built-in groups are an inherently "local" concept in Windows, they are not associated with domain users (you will not find built-in SIDs in the MS-PAC or in tokenGroups replies) and are meant to have meaning only on the local system where they are defined.
Can you give me a reference for the use of built-in groups with GPOs ?
Simo.
----- Original Message -----
On Thu, 2014-02-20 at 15:46 -0500, Yassir Elley wrote:
Hi,
This email proposes two changes that would allow sssd to correctly support ACL processing on GPO objects.
In addition to various other factors, in order for a GPO to be considered applicable to a particular computer target, the GPO object's AD ACL must grant the "ApplyGroupPolicy" right (AGP) to the computer (or, more likely, to a group of which the computer is a member). By default, AD grants the AGP right to the "Authenticated Users" group, which includes both authenticated users and computers. While this group can be placed on AD ACLs (like other groups), it is special in that its membership is supposed to be maintained by the client (not by AD). Additionally, Windows admins can change this default behavior by denying the AGP right to the "Authenticated Users" group, and by granting the AGP right to some other security principal (which could be a "built-in" principal).
Since there has never been a need, SSSD neither maintains an "Authenticated Users" group membership, nor does it cache any Built-in Groups (those whose SIDS are of the form S-1-5-32-*, such as "Administrators", "Users", etc ) returned from LDAP. In order to support the ACL filtering of GPOs described above, the GPO code needs to know which Built-in Groups the computer target is a member of.
I have the following two proposals:
- I propose that the GPO access-control code (which is executed after
a successful pam authentication) should just assume that any user or computer is a member of the "Authenticated Users" group. This would be local to the GPO code, and would therefore have no effect on other SSSD components.
Make sense for now, however going forward we will have to add this SID to a security token of sorts if SSSD is to be used wit the Samba File Server, so in future we may want to have an explicit "Windows Security Context" that lists all SIDs, including this one.
OK.
- I propose that SSSD should no longer filter out built-in groups
returned by LDAP, but should rather store them in the sysdb cache, in the same manner as it stores other groups. This would allow the GPO code to seamlessly include the built-in groups in its ACL processing decision. Since we would be storing these built-in groups in the cache, they would be visible to other SSSD components. An alternative would be to have the GPO code interact with AD to determine the computer's group memberships directly (without consulting the cache), but that seems too inefficient.
Something's not right here. Built-in groups are an inherently "local" concept in Windows, they are not associated with domain users (you will not find built-in SIDs in the MS-PAC or in tokenGroups replies) and are meant to have meaning only on the local system where they are defined.
Can you give me a reference for the use of built-in groups with GPOs ?
Simo.
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), while I am referring to domain-scoped default groups (which can be set on ACLs in the entire domain, which are managed by ADUC). More specifically, I am referring to domain-scoped default groups in the "cn=Builtin" container (as opposed to the "cn=Users" container). 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?
Regards, Yassir.
PS: For a good description of default groups vs default local groups, see http://technet.microsoft.com/en-us/library/cc756898(v=ws.10).aspx
Regards, Yassir.
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.
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_encrypti...
HTH, Simo.
----- 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_encrypti...
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".
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).
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).
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.
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.
Regards, Yassir.
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_encrypti...
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.
----- 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_encrypti...
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.
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Simo Sorce -
Yassir Elley