On 05/05/2017 10:51 PM, Ledford, Donald wrote:
-----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
Great to hear it works for you now.
SSSD indeed needs to have read permissions for all candidate Group
Policy Container objects and their attributes in the LDAP. It is then
performing security filtering based on these attributes (so if security
filtering filters out a GPO then SSSD does not need read access to the
filtered GPO's INI files, but it still need read access to the LDAP
container). If the candidate GPO is not filtered out based on the
LDAP attributes, then SSSD downloads the INI files, for which it needs
read access also to these files (of course, because these are GPOs that
will be used).
SSSD can read the attributes for security filtering only with LDAP
searches. Maybe Windows clients have other means to get these attributes
so they do not need the LDAP read access and the security filtering
still works for them (TBH IDK, I will have to search through MS
documentation to see if it says something about this).
Have a nice day.
Michal
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
