[SSSD] Re: [PATCH] gpo: gPCMachineExtensionNames with just whitespaces

2016-08-11 Thread Jakub Hrozek 
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
> >> 
> >> CI: http://sssd-ci.duckdns.org/logs/job/51/34/summary.html
> >
> >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 mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org

[SSSD] Re: [PATCH] gpo: gPCMachineExtensionNames with just whitespaces

2016-08-11 Thread Lukas Slebodnik 
On (11/08/16 10:34), Jakub Hrozek wrote:
>On Thu, Aug 11, 2016 at 10:30:09AM +0200, Jakub Hrozek wrote:
>> ACK
>> 
>> CI: http://sssd-ci.duckdns.org/logs/job/51/34/summary.html
>
>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-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org

[SSSD] Re: [PATCH] gpo: gPCMachineExtensionNames with just whitespaces

2016-08-11 Thread Jakub Hrozek 
On Thu, Aug 11, 2016 at 10:30:09AM +0200, Jakub Hrozek wrote:
> ACK
> 
> CI: http://sssd-ci.duckdns.org/logs/job/51/34/summary.html

master: b1a8b4a1291529367b46c79eb02448eced3bf8d2 

I think this patch should be applied to the stable (sssd-1-13) branch as
well. Anyone against?
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org

[SSSD] Re: [PATCH] gpo: gPCMachineExtensionNames with just whitespaces

2016-08-11 Thread Jakub Hrozek 
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  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

CI: http://sssd-ci.duckdns.org/logs/job/51/34/summary.html
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org

[SSSD] Re: [PATCH] gpo: gPCMachineExtensionNames with just whitespaces

2016-08-10 Thread Michal Židek 

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  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

>From fc0927d0a8dbce10505e09316878aa0e11b042fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michal=20=C5=BDidek?= 
Date: Fri, 29 Jul 2016 16:09:16 +0200
Subject: [PATCH] gpo: gPCMachineExtensionNames with just whitespaces

Resolves:
https://fedorahosted.org/sssd/ticket/3114

We failed GPO procesing if the gPCMachineExtensionNames
attribute contained just whitespaces. This coused
failures in some server settings.

Comment from Alexander Bokovoy quoting:

You should use MS-GPOL spec. 2.2.4 'GPO Search' section says that when
processing gPCMachineExtensionNames, "Group Policy processing terminates
at the first  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

[SSSD] Re: [PATCH] gpo: gPCMachineExtensionNames with just whitespaces

2016-08-10 Thread Jakub Hrozek 
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  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.
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org

[SSSD] Re: [PATCH] gpo: gPCMachineExtensionNames with just whitespaces

2016-08-10 Thread Alexander Bokovoy 

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  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





--
/ Alexander Bokovoy

[SSSD] Re: [PATCH] gpo: gPCMachineExtensionNames with just whitespaces

2016-08-09 Thread Michal Židek 

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

[SSSD] Re: [PATCH] gpo: gPCMachineExtensionNames with just whitespaces

2016-08-09 Thread Lukas Slebodnik 
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
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org

[SSSD] Re: [PATCH] gpo: gPCMachineExtensionNames with just whitespaces

2016-08-09 Thread Jakub Hrozek 
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?
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org