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