[SSSD-users] Re: [SSSD][AD][GPO] GPOs Found but Not Applied

[Ledford, Donald]

-----Original Message-----
From: Michal Židek [mailto:[e-mail]] 
Sent: Friday, May 5, 2017 11:57 AM
To: End-user discussions about the System Security Services Daemon <sss
d-users(a)lists.fedorahosted.org&gt;
Subject: [SSSD-users] Re: [SSSD][AD][GPO] GPOs Found but Not Applied



On 05/05/2017 06:38 PM, Michal Židek wrote:
>  On 05/05/2017 06:21 PM, ledfordd(a)umkc.edu wrote:
>  > No, that's a GPO for some update Pre-Deployment systems. It's 
>  > inherited further up the OU tree. The Security Filtering on it
>  > would 
>  > prevent our Linux test system from reading it.
>  > 
>  > The GPO I'm specifically using for testing is 
>  > "{8C43AC42-0B5E-4703-AB0C-E25460C9ED29}". SSSD starts reading that 
>  > GPO on line 501 of the sanitized log I sent. Again, probably
>  > should 
>  > have mentioned that originally. That GPO is linked to the Linux 
>  > server's OU, and the server is the only object in the OU. It
>  > doesn't 
>  > have any WMI filtering and it's the GPO I've been changing 
>  > permissions on during testing.
>  > 
>  > Thanks,
>  > -Donald
>  
>  I see. Could you for testing purposes allow SSSD to read also the 
>  unrealted GPO with GUID 17A3A1EB-16F3-4B2A-9B01-0043A58239A8 and see 
>  if it helps?
>  
>  Also, are there other GPOs that SSSD does not have a permission to 
>  read? If so please allow SSSD to read those as well.
>  
To be more precise here. look for messages in the log that start with:

[ad_gpo_populate_candidate_gpos] (0x0400): candidate_gpos

Like this one

[ad_gpo_populate_candidate_gpos] (0x0400): candidate_gpos[0]->gpo_dn: 
cn={2D551881-E71B-40CF-8656-
846671FAFAB0},cn=policies,cn=system,dc=ad,dc=domain,dc=com

And make sure SSSD can read all the those group policy containers.

>  
>  I see that SSSD stopped the evaluation right after the unreadable
>  GPO 
>  was hit. Maybe there is an issue that SSSD stops the evaluation
>  after 
>  the first non-readable GPO is read from LDAP.
>  
>  I will be leaving the office soon, and there is holiday here until 
>  Tuesday. I am not sure if I will be able to take a look at your
>  issue 
>  sooner than after the holiday, but please let me know if the above 
>  helped.
>  
>  Michal
>  
Michal,

No worries, I appreciate the help and I'm not in a rush.  Can't
complain about free technical support! ;)

It's working! Woohoo!

So {17A3A1EB-16F3-4B2A-9B01-0043A58239A8} was not the issue but your
email got me looking and I found the next GPO in the candidate list,
and the very last one in the list at that, was NOT being processed by
SSSD. All the other candidate GPOs were at least getting an LDAP
lookup.

I took all of the candidate GPO GUIDs and ran them through some
PowerShell on the  our Windows side to find any GPOs the Linux test box
wouldn't have been able to read. GPO {D47FA940-3024-4F98-88E7-
B77CC2F7CA20}, last in the candidate chain, did not have any ACLs that
would have let the Linux box read it. I explicitly set a Security
Filter ACL to give the Linux machine read rights, let that replicate
across the DCs, cleared out SSSD's caches, and restarted the service.
After that GPOs were working as expected! My test user was denied SSH
access. Adjusting group and user SSH rights works as expected after
some more testing!

So, if I'm understanding this correctly SSSD has to be able to read ALL
candidate GPOs to apply ANY of them. The broken GPO in this case had an
explicit group Security Filter on it that the Linux box was not a part
of, so it couldn't read it. 

If a Windows box encountered this issue, it would skip the GPO it
couldn't read and keep going. Is there a specific design decision in
SSSD for this behavior?

Thanks and have a good holiday!

-Donald