Hi,
the attached patch fixes: https://fedorahosted.org/sssd/ticket/3114
We have a user that can not login with enforced GPO because of this. I do not think it is a common issue, I could not create groupPolicyContainer with gPCMachineExtensionNames containing only whitespaces, but you can create it with a script and the blank value is not an error so we should handle it properly (and maybe thre is a way in the GUI maze to create such GPOs as well, I just could not find it).
I was able to reproduce the same "sssd log path" the user has and this patch fixed the issue.
Thanks.
Michal
On Fri, Jul 29, 2016 at 05:40:44PM +0200, Michal Židek wrote:
Hi,
the attached patch fixes: https://fedorahosted.org/sssd/ticket/3114
We have a user that can not login with enforced GPO because of this. I do not think it is a common issue, I could not create groupPolicyContainer with gPCMachineExtensionNames containing only whitespaces, but you can create it with a script and the blank value is not an error so we should handle it properly (and maybe thre is a way in the GUI maze to create such GPOs as well, I just could not find it).
I was able to reproduce the same "sssd log path" the user has and this patch fixed the issue.
If the user tested the patch, then I would say we should accept it.
Did you ask someone from the Samba team if this is the right thing to do?
On (09/08/16 11:48), Jakub Hrozek wrote:
On Fri, Jul 29, 2016 at 05:40:44PM +0200, Michal Židek wrote:
Hi,
the attached patch fixes: https://fedorahosted.org/sssd/ticket/3114
We have a user that can not login with enforced GPO because of this. I do not think it is a common issue, I could not create groupPolicyContainer with gPCMachineExtensionNames containing only whitespaces, but you can create it with a script and the blank value is not an error so we should handle it properly (and maybe thre is a way in the GUI maze to create such GPOs as well, I just could not find it).
I was able to reproduce the same "sssd log path" the user has and this patch fixed the issue.
If the user tested the patch, then I would say we should accept it.
Did you ask someone from the Samba team if this is the right thing to do?
It would be good to add link to the MSDN documentation. Try to ask ab. He is quite familiar with the documentation.
LS
Summary for Alexander (in CC): - Regarding processing GPOs on the client. - If groupPolicyContainer in AD has attribute gPCMachineExtensionNames that contains only whitespaces, SSSD fails to process GPOs and denies access to users - if the gPCMachineExtensionNames is missing, it is Ok and SSSD skips such GPO (because we are only interested in Machine extensions) - We have customer that has thousands of GPOs stored in AD and some of them have just ' ' (space) in the gPCMachineExtensionNames attribute. The AD administrators say that they created the GPOs using the GUI provided by AD. - Treating the gPCMachineExtensionNames with just whitespaces the same way as if the gpcMachineExtensionNames was missing completely fixed the issue for the customer.
- Now, it would be good to support the fix with some links to documentation.
- I believe we should go with that fix, but could not find any documentation that would explicitly say something about just whitespaces in the gpcMachineExtensionNames - Gunter could also not find documentation that would say something about just whitespaces in that attribute, but believes that we should use the fix and skip such attributes.
Alexander, can you try to find something in the MSDN documentation, that would support our fix? If not, then just what is your opinion?
Thanks (the original conversation is below - does not include Gunter because that was on IRC).
On 08/09/2016 11:50 AM, Lukas Slebodnik wrote:
On (09/08/16 11:48), Jakub Hrozek wrote:
On Fri, Jul 29, 2016 at 05:40:44PM +0200, Michal Židek wrote:
Hi,
the attached patch fixes: https://fedorahosted.org/sssd/ticket/3114
We have a user that can not login with enforced GPO because of this. I do not think it is a common issue, I could not create groupPolicyContainer with gPCMachineExtensionNames containing only whitespaces, but you can create it with a script and the blank value is not an error so we should handle it properly (and maybe thre is a way in the GUI maze to create such GPOs as well, I just could not find it).
I was able to reproduce the same "sssd log path" the user has and this patch fixed the issue.
If the user tested the patch, then I would say we should accept it.
Did you ask someone from the Samba team if this is the right thing to do?
I asked Gunter and he said that we should ignore this attribute if it contains just whitespaces. Btw. I can confirm that this fixed the issue for the customer. He is now hitting this: https://fedorahosted.org/sssd/ticket/2751
which is already fixed in master.
It would be good to add link to the MSDN documentation. Try to ask ab. He is quite familiar with the documentation.
I tried to find some MSDN documentation, but nothing explicitly mentioned if the attribute can contain just whitespaces or not. Gunter could not find anything either.
However if the attribute is missing completely, it is a valid GPO (we already ignore such GPOs). So having it containing just whitespaces is not too distant from that. I can ask Alexander if he can find something in the documentation though.
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Tue, 09 Aug 2016, Michal Židek wrote:
Summary for Alexander (in CC):
- Regarding processing GPOs on the client.
- If groupPolicyContainer in AD has attribute
gPCMachineExtensionNames that contains only whitespaces, SSSD fails to process GPOs and denies access to users
- if the gPCMachineExtensionNames is missing, it is Ok and
SSSD skips such GPO (because we are only interested in Machine extensions)
- We have customer that has thousands of GPOs stored in AD and
some of them have just ' ' (space) in the gPCMachineExtensionNames attribute. The AD administrators say that they created the GPOs using the GUI provided by AD.
- Treating the gPCMachineExtensionNames with just whitespaces the
same way as if the gpcMachineExtensionNames was missing completely fixed the issue for the customer.
- Now, it would be good to support the fix with some links to
documentation.
- I believe we should go with that fix, but could not find any
documentation that would explicitly say something about just whitespaces in the gpcMachineExtensionNames
- Gunter could also not find documentation that would say something
about just whitespaces in that attribute, but believes that we should use the fix and skip such attributes.
Alexander, can you try to find something in the MSDN documentation, that would support our fix? If not, then just what is your opinion?
You should use MS-GPOL spec. 2.2.4 'GPO Search' section says that when processing gPCMachineExtensionNames, "Group Policy processing terminates at the first <CSE GUIDn> out of sequence." Since ' ' (space only) does not fall into defined syntax for gPCMachineExtensionNames, this Group Policy processing is stopped and its CSE GUIDs are set to 'empty list'.
Because of the 3.2.5.1.10 'Extension Protocol Sequences' language ------------------------------------------------------------------------ The Group Policy client MUST evaluate the subset of the abstract element Filtered GPO list separately for each Group Policy extension by including in the subset only those GPOs whose gPCUserExtensionNames (for user policy mode) or gPCMachineExtensionNames (for computer policy mode) attributes contain CSE GUID that correspond to the Group Policy extension. If the CSE GUID corresponding to the Group Policy extension is present in Extension List, it is invoked using the Implementation Identifier field. Applicability is determined as specified in section 3.2.1.5. The Group Policy Registry Extension MUST always execute first. All other applicable Group Policy extensions in the Extension List MUST be loaded and executed in Extension List order. A failure in any Group Policy extension sequence MUST NOT affect the execution of other Group Policy extensions. -------------------------------------------------------------------------
I think we can practically treat wrong content of gPCMachineExtensionNames (and gPCUserExtensionNames) as inability of the GPO to pass through the Filtered GPO list. Thus, the GPO would be ignored.
Thanks (the original conversation is below - does not include Gunter because that was on IRC).
On 08/09/2016 11:50 AM, Lukas Slebodnik wrote:
On (09/08/16 11:48), Jakub Hrozek wrote:
On Fri, Jul 29, 2016 at 05:40:44PM +0200, Michal Židek wrote:
Hi,
the attached patch fixes: https://fedorahosted.org/sssd/ticket/3114
We have a user that can not login with enforced GPO because of this. I do not think it is a common issue, I could not create groupPolicyContainer with gPCMachineExtensionNames containing only whitespaces, but you can create it with a script and the blank value is not an error so we should handle it properly (and maybe thre is a way in the GUI maze to create such GPOs as well, I just could not find it).
I was able to reproduce the same "sssd log path" the user has and this patch fixed the issue.
If the user tested the patch, then I would say we should accept it.
Did you ask someone from the Samba team if this is the right thing to do?
I asked Gunter and he said that we should ignore this attribute if it contains just whitespaces. Btw. I can confirm that this fixed the issue for the customer. He is now hitting this: https://fedorahosted.org/sssd/ticket/2751
which is already fixed in master.
It would be good to add link to the MSDN documentation. Try to ask ab. He is quite familiar with the documentation.
I tried to find some MSDN documentation, but nothing explicitly mentioned if the attribute can contain just whitespaces or not. Gunter could not find anything either.
However if the attribute is missing completely, it is a valid GPO (we already ignore such GPOs). So having it containing just whitespaces is not too distant from that. I can ask Alexander if he can find something in the documentation though.
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Wed, Aug 10, 2016 at 12:02:18PM +0300, Alexander Bokovoy wrote:
On Tue, 09 Aug 2016, Michal Židek wrote:
Summary for Alexander (in CC):
- Regarding processing GPOs on the client.
- If groupPolicyContainer in AD has attribute
gPCMachineExtensionNames that contains only whitespaces, SSSD fails to process GPOs and denies access to users
- if the gPCMachineExtensionNames is missing, it is Ok and
SSSD skips such GPO (because we are only interested in Machine extensions)
- We have customer that has thousands of GPOs stored in AD and
some of them have just ' ' (space) in the gPCMachineExtensionNames attribute. The AD administrators say that they created the GPOs using the GUI provided by AD.
- Treating the gPCMachineExtensionNames with just whitespaces the
same way as if the gpcMachineExtensionNames was missing completely fixed the issue for the customer.
- Now, it would be good to support the fix with some links to
documentation.
- I believe we should go with that fix, but could not find any
documentation that would explicitly say something about just whitespaces in the gpcMachineExtensionNames
- Gunter could also not find documentation that would say something
about just whitespaces in that attribute, but believes that we should use the fix and skip such attributes.
Alexander, can you try to find something in the MSDN documentation, that would support our fix? If not, then just what is your opinion?
You should use MS-GPOL spec. 2.2.4 'GPO Search' section says that when processing gPCMachineExtensionNames, "Group Policy processing terminates at the first <CSE GUIDn> out of sequence." Since ' ' (space only) does not fall into defined syntax for gPCMachineExtensionNames, this Group Policy processing is stopped and its CSE GUIDs are set to 'empty list'.
Because of the 3.2.5.1.10 'Extension Protocol Sequences' language
The Group Policy client MUST evaluate the subset of the abstract element Filtered GPO list separately for each Group Policy extension by including in the subset only those GPOs whose gPCUserExtensionNames (for user policy mode) or gPCMachineExtensionNames (for computer policy mode) attributes contain CSE GUID that correspond to the Group Policy extension. If the CSE GUID corresponding to the Group Policy extension is present in Extension List, it is invoked using the Implementation Identifier field. Applicability is determined as specified in section 3.2.1.5. The Group Policy Registry Extension MUST always execute first. All other applicable Group Policy extensions in the Extension List MUST be loaded and executed in Extension List order. A failure in any Group Policy extension sequence MUST NOT affect the execution of other Group Policy extensions.
I think we can practically treat wrong content of gPCMachineExtensionNames (and gPCUserExtensionNames) as inability of the GPO to pass through the Filtered GPO list. Thus, the GPO would be ignored.
Michal, if you add Alexander's response into the commit message, I will push the patch.
On 08/10/2016 11:35 AM, Jakub Hrozek wrote:
On Wed, Aug 10, 2016 at 12:02:18PM +0300, Alexander Bokovoy wrote:
On Tue, 09 Aug 2016, Michal Židek wrote:
Summary for Alexander (in CC):
Regarding processing GPOs on the client.
If groupPolicyContainer in AD has attribute gPCMachineExtensionNames that contains only whitespaces, SSSD fails to process GPOs and denies access to users
if the gPCMachineExtensionNames is missing, it is Ok and SSSD skips such GPO (because we are only interested in Machine extensions)
We have customer that has thousands of GPOs stored in AD and some of them have just ' ' (space) in the gPCMachineExtensionNames attribute. The AD administrators say that they created the GPOs using the GUI provided by AD.
Treating the gPCMachineExtensionNames with just whitespaces the same way as if the gpcMachineExtensionNames was missing completely fixed the issue for the customer.
Now, it would be good to support the fix with some links to documentation.
I believe we should go with that fix, but could not find any documentation that would explicitly say something about just whitespaces in the gpcMachineExtensionNames
Gunter could also not find documentation that would say something about just whitespaces in that attribute, but believes that we should use the fix and skip such attributes.
Alexander, can you try to find something in the MSDN documentation, that would support our fix? If not, then just what is your opinion?
You should use MS-GPOL spec. 2.2.4 'GPO Search' section says that when processing gPCMachineExtensionNames, "Group Policy processing terminates at the first <CSE GUIDn> out of sequence." Since ' ' (space only) does not fall into defined syntax for gPCMachineExtensionNames, this Group Policy processing is stopped and its CSE GUIDs are set to 'empty list'.
Because of the 3.2.5.1.10 'Extension Protocol Sequences' language
The Group Policy client MUST evaluate the subset of the abstract element Filtered GPO list separately for each Group Policy extension by including in the subset only those GPOs whose gPCUserExtensionNames (for user policy mode) or gPCMachineExtensionNames (for computer policy mode) attributes contain CSE GUID that correspond to the Group Policy extension. If the CSE GUID corresponding to the Group Policy extension is present in Extension List, it is invoked using the Implementation Identifier field. Applicability is determined as specified in section 3.2.1.5. The Group Policy Registry Extension MUST always execute first. All other applicable Group Policy extensions in the Extension List MUST be loaded and executed in Extension List order. A failure in any Group Policy extension sequence MUST NOT affect the execution of other Group Policy extensions.
I think we can practically treat wrong content of gPCMachineExtensionNames (and gPCUserExtensionNames) as inability of the GPO to pass through the Filtered GPO list. Thus, the GPO would be ignored.
Michal, if you add Alexander's response into the commit message, I will push the patch.
I copied the entire comment into the commit message.
New patch is attached.
Michal
On Wed, Aug 10, 2016 at 11:53:43AM +0200, Michal Židek wrote:
On 08/10/2016 11:35 AM, Jakub Hrozek wrote:
On Wed, Aug 10, 2016 at 12:02:18PM +0300, Alexander Bokovoy wrote:
On Tue, 09 Aug 2016, Michal Židek wrote:
Summary for Alexander (in CC):
Regarding processing GPOs on the client.
If groupPolicyContainer in AD has attribute gPCMachineExtensionNames that contains only whitespaces, SSSD fails to process GPOs and denies access to users
if the gPCMachineExtensionNames is missing, it is Ok and SSSD skips such GPO (because we are only interested in Machine extensions)
We have customer that has thousands of GPOs stored in AD and some of them have just ' ' (space) in the gPCMachineExtensionNames attribute. The AD administrators say that they created the GPOs using the GUI provided by AD.
Treating the gPCMachineExtensionNames with just whitespaces the same way as if the gpcMachineExtensionNames was missing completely fixed the issue for the customer.
Now, it would be good to support the fix with some links to documentation.
I believe we should go with that fix, but could not find any documentation that would explicitly say something about just whitespaces in the gpcMachineExtensionNames
Gunter could also not find documentation that would say something about just whitespaces in that attribute, but believes that we should use the fix and skip such attributes.
Alexander, can you try to find something in the MSDN documentation, that would support our fix? If not, then just what is your opinion?
You should use MS-GPOL spec. 2.2.4 'GPO Search' section says that when processing gPCMachineExtensionNames, "Group Policy processing terminates at the first <CSE GUIDn> out of sequence." Since ' ' (space only) does not fall into defined syntax for gPCMachineExtensionNames, this Group Policy processing is stopped and its CSE GUIDs are set to 'empty list'.
Because of the 3.2.5.1.10 'Extension Protocol Sequences' language
The Group Policy client MUST evaluate the subset of the abstract element Filtered GPO list separately for each Group Policy extension by including in the subset only those GPOs whose gPCUserExtensionNames (for user policy mode) or gPCMachineExtensionNames (for computer policy mode) attributes contain CSE GUID that correspond to the Group Policy extension. If the CSE GUID corresponding to the Group Policy extension is present in Extension List, it is invoked using the Implementation Identifier field. Applicability is determined as specified in section 3.2.1.5. The Group Policy Registry Extension MUST always execute first. All other applicable Group Policy extensions in the Extension List MUST be loaded and executed in Extension List order. A failure in any Group Policy extension sequence MUST NOT affect the execution of other Group Policy extensions.
I think we can practically treat wrong content of gPCMachineExtensionNames (and gPCUserExtensionNames) as inability of the GPO to pass through the Filtered GPO list. Thus, the GPO would be ignored.
Michal, if you add Alexander's response into the commit message, I will push the patch.
I copied the entire comment into the commit message.
New patch is attached.
Michal
ACK
On Thu, Aug 11, 2016 at 10:30:09AM +0200, Jakub Hrozek wrote:
ACK
master: b1a8b4a1291529367b46c79eb02448eced3bf8d2
I think this patch should be applied to the stable (sssd-1-13) branch as well. Anyone against?
On (11/08/16 10:34), Jakub Hrozek wrote:
On Thu, Aug 11, 2016 at 10:30:09AM +0200, Jakub Hrozek wrote:
ACK
master: b1a8b4a1291529367b46c79eb02448eced3bf8d2
I think this patch should be applied to the stable (sssd-1-13) branch as well. Anyone against?
I wanted to propose the same.
LS
On Thu, Aug 11, 2016 at 10:39:19AM +0200, Lukas Slebodnik wrote:
On (11/08/16 10:34), Jakub Hrozek wrote:
On Thu, Aug 11, 2016 at 10:30:09AM +0200, Jakub Hrozek wrote:
ACK
master: b1a8b4a1291529367b46c79eb02448eced3bf8d2
I think this patch should be applied to the stable (sssd-1-13) branch as well. Anyone against?
I wanted to propose the same.
LS
sssd-1-13: a8f3d2ae28ffbef1d30cbcdf87eed10c4e2eb5b7
sssd-devel@lists.fedorahosted.org