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