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
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
