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. 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 _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
