-----Original Message----- From: Michal Židek [mailto:[email protected]] Sent: Friday, May 5, 2017 11:57 AM To: End-user discussions about the System Security Services Daemon <sss [email protected]> 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, [email protected] 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 _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
