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(a)lists.fedorahosted.org
>https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
>
--
/ Alexander Bokovoy