Hello,
We've got a RHEL 6.9 system in testing for AD integration. We have to use 6.x due to compatibility issues with software that will eventually be deployed to the system so moving to RHEL 7.3 isn't an option. Currently we're working on getting SSSD integrated with AD on this box. So far everything except GPO restrictions are working. Users can login via their AD credentials, their groups are enumerated, home directories are made automatically, etc. The only piece left is GPO based access restrictions. We'd really like to use AD GPOs to set who can and can't login via SSH. To this end we've made a new OU for the Linux server, placed it's AD object in the OU, and attached a GPO to the OU with a test user account in the "Deny log on through Remote Desktop Services" policy setting. So far this hasn't been working and the test account can always login through SSH. The SSSD system can see the GPOs attached to the OU all the way up to the domain root, but does not think any of the GPOs apply to it. We've got "ad_gpo_access_control = enforcing" set in sssd.conf but it doesn't seem to be doing anything. According to the logs SSSD is parsing all the GPO LDAP attributes then deciding none of the GPOs apply, without parsing the GPO INI files themselves. I have confirmed manually that the server's Kerberos credentials will return results via LDAP queries and can mount the domain SYSVOL share as well as read the GPO files in the share. So I'm not sure why SSSD won't apply the GPO settings. I've attached a sanitized sssd.conf file and selected parts of the sssd_ad.domain.com.log file to this post. Here's the relevant version info: RHEL 6.9 - Linux ad-lnx-test.ad.domain.com 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux yum info sssd: Name : sssd Arch : x86_64 Version : 1.13.3 Release : 56.el6 Size : 34 k Repo : installed From repo : rhel-6-server-rpms Any thoughts on why this isn't working are much appreciated.
On 05/04/2017 06:37 PM, Ledford, Donald wrote:
Hello,
We've got a RHEL 6.9 system in testing for AD integration. We have to use 6.x due to compatibility issues with software that will eventually be deployed to the system so moving to RHEL 7.3 isn't an option.
Currently we're working on getting SSSD integrated with AD on this box. So far everything except GPO restrictions are working. Users can login via their AD credentials, their groups are enumerated, home directories are made automatically, etc. The only piece left is GPO based access restrictions. We'd really like to use AD GPOs to set who can and can't login via SSH. To this end we've made a new OU for the Linux server, placed it's AD object in the OU, and attached a GPO to the OU with a test user account in the "Deny log on through Remote Desktop Services" policy setting. So far this hasn't been working and the test account can always login through SSH.
The SSSD system can see the GPOs attached to the OU all the way up to the domain root, but does not think any of the GPOs apply to it. We've got "ad_gpo_access_control = enforcing" set in sssd.conf but it doesn't seem to be doing anything. According to the logs SSSD is parsing all the GPO LDAP attributes then deciding none of the GPOs apply, without parsing the GPO INI files themselves. I have confirmed manually that the server's Kerberos credentials will return results via LDAP queries and can mount the domain SYSVOL share as well as read the GPO files in the share. So I'm not sure why SSSD won't apply the GPO settings. I've attached a sanitized sssd.conf file and selected parts of the sssd_ad.domain.com.log file to this post. Here's the relevant version info:
RHEL 6.9 - Linux ad-lnx-test.ad.domain.com 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
yum info sssd: Name : sssd Arch : x86_64 Version : 1.13.3 Release : 56.el6 Size : 34 k Repo : installed From repo : rhel-6-server-rpms
Any thoughts on why this isn't working are much appreciated.
Hi,
Check the Security filtering[1] and GPO status[2]. are readable [3].
[1] Go to the Group Policy Management window and select the GPO you want to check in the tree list on the left. Under the 'Scope' you can see section called 'Security filtering'. Check if it is not too restrictive.
[2] Also in the Group Policy Management window select the GPO you want to check in the tree list on the left as before. Under the 'Details' you can see 'GPO Status'. It must be Enabled (or at least the COmputer configuration can not be disabled, because the access control rules are in the computer configuration part of the GPO).
Also, what credentials did you use for the test LDAP queries?
Michal
On 05/05/2017 02:10 PM, Michal Židek wrote:
On 05/04/2017 06:37 PM, Ledford, Donald wrote:
Hello,
We've got a RHEL 6.9 system in testing for AD integration. We have to use 6.x due to compatibility issues with software that will eventually be deployed to the system so moving to RHEL 7.3 isn't an option.
Currently we're working on getting SSSD integrated with AD on this box. So far everything except GPO restrictions are working. Users can login via their AD credentials, their groups are enumerated, home directories are made automatically, etc. The only piece left is GPO based access restrictions. We'd really like to use AD GPOs to set who can and can't login via SSH. To this end we've made a new OU for the Linux server, placed it's AD object in the OU, and attached a GPO to the OU with a test user account in the "Deny log on through Remote Desktop Services" policy setting. So far this hasn't been working and the test account can always login through SSH.
The SSSD system can see the GPOs attached to the OU all the way up to the domain root, but does not think any of the GPOs apply to it. We've got "ad_gpo_access_control = enforcing" set in sssd.conf but it doesn't seem to be doing anything. According to the logs SSSD is parsing all the GPO LDAP attributes then deciding none of the GPOs apply, without parsing the GPO INI files themselves. I have confirmed manually that the server's Kerberos credentials will return results via LDAP queries and can mount the domain SYSVOL share as well as read the GPO files in the share. So I'm not sure why SSSD won't apply the GPO settings. I've attached a sanitized sssd.conf file and selected parts of the sssd_ad.domain.com.log file to this post. Here's the relevant version info:
RHEL 6.9 - Linux ad-lnx-test.ad.domain.com 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
yum info sssd: Name : sssd Arch : x86_64 Version : 1.13.3 Release : 56.el6 Size : 34 k Repo : installed From repo : rhel-6-server-rpms
Any thoughts on why this isn't working are much appreciated.
Hi,
Check the Security filtering[1] and GPO status[2]. are readable [3].
Ignore the 'are readable [3]', it is leftover from half deleted sentence.
[1] Go to the Group Policy Management window and select the GPO you want to check in the tree list on the left. Under the 'Scope' you can see section called 'Security filtering'. Check if it is not too restrictive.
[2] Also in the Group Policy Management window select the GPO you want to check in the tree list on the left as before. Under the 'Details' you can see 'GPO Status'. It must be Enabled (or at least the COmputer configuration can not be disabled, because the access control rules are in the computer configuration part of the GPO).
Also, what credentials did you use for the test LDAP queries?
Michal _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
-----Original Message-----
Date: Fri, 05 May 2017 14:14:01 +0200 Subject: [SSSD-users] Re: [SSSD][AD][GPO] GPOs Found but Not Applied To: End-user discussions about the System Security Services Daemon <sss d-users@lists.fedorahosted.org> Reply-to: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org From: Michal Židek mzidek@redhat.com
On 05/05/2017 02:10 PM, Michal Židek wrote:
On 05/04/2017 06:37 PM, Ledford, Donald wrote:
Hello,
We've got a RHEL 6.9 system in testing for AD integration. We have to use 6.x due to compatibility issues with software that will eventually be deployed to the system so moving to RHEL 7.3 isn't an option.
Currently we're working on getting SSSD integrated with AD on this box. So far everything except GPO restrictions are working. Users can login via their AD credentials, their groups are enumerated, home directories are made automatically, etc. The only piece left is GPO based access restrictions. We'd really like to use AD GPOs to set who can and can't login via SSH. To this end we've made a new OU for the Linux server, placed it's AD object in the OU, and attached a GPO to the OU with a test user account in the "Deny log on through Remote Desktop Services" policy setting. So far this hasn't been working and the test account can always login through SSH.
The SSSD system can see the GPOs attached to the OU all the way up to the domain root, but does not think any of the GPOs apply to it. We've got "ad_gpo_access_control = enforcing" set in sssd.conf but it doesn't seem to be doing anything. According to the logs SSSD is parsing all the GPO LDAP attributes then deciding none of the GPOs apply, without parsing the GPO INI files themselves. I have confirmed manually that the server's Kerberos credentials will return results via LDAP queries and can mount the domain SYSVOL share as well as read the GPO files in the share. So I'm not sure why SSSD won't apply the GPO settings. I've attached a sanitized sssd.conf file and selected parts of the sssd_ad.domain.com.log file to this post. Here's the relevant version info:
RHEL 6.9 - Linux ad-lnx-test.ad.domain.com 2.6.32- 696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
yum info sssd: Name : sssd Arch : x86_64 Version : 1.13.3 Release : 56.el6 Size : 34 k Repo : installed From repo : rhel-6-server-rpms
Any thoughts on why this isn't working are much appreciated.
Hi,
Check the Security filtering[1] and GPO status[2]. are readable [3].
Ignore the 'are readable [3]', it is leftover from half deleted sentence.
[1] Go to the Group Policy Management window and select the GPO you want to check in the tree list on the left. Under the 'Scope' you can see section called 'Security filtering'. Check if it is not too restrictive.
[2] Also in the Group Policy Management window select the GPO you want to check in the tree list on the left as before. Under the 'Details' you can see 'GPO Status'. It must be Enabled (or at least the COmputer configuration can not be disabled, because the access control rules are in the computer configuration part of the GPO).
Also, what credentials did you use for the test LDAP queries?
Michal _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.o rg
Hello Michal,
[1] I have fiddled with both the GPO Security Filtering and Delegation permissions, just to be thorough. I've tried giving the computer UPN in the domain explicit Read to the GPO and I've given "Everyone" explicit Read as well. Our default is "Authenticated Users - Read" in Security Filtering. I've even looked at the GPO LDAP object permissions in ADSI Edit and I didn't see anything that leaped out at me.
[2] The GPO is Enabled under "Details". It's also "Link Enabled" but not "Enforced" in GPMC. I've done a lot of work in AD with Windows, but this is my first foray into Linux/SSSD AD integration, so it's like I'm learning all of this over again from scratch. :O
When doing LDAP/CIFS testing I kinit'ed from the local keytab as root. Klist showed I had a TGT for the local machine UPN, i.e. AD-LNX-TEST$. When using ldapsearch I used -Y GSSAPI to search the DCs using our AD DNS entry, i.e. "ldapsearch -Y GSSAPI -H ldap://ad.domain.com -b 'dc=ad,dc=domain,dc=com' -s subtree" and got attribute results for the GPO CN queries I ran.
Similarly, I used Kerberos with the machine UPN TGT when testing mapping the SYSVOL share, i.e. mount -t cifs -o sec=krb5i,vers=3.0 //ad.domain.com/SYSVOL /mnt/sysvol. I was able to read the GPO INI files in SYSVOL with this mount setup. I would assume the local machine could also read the SYSVOL.
After performing LDAP queries and mounting SYSVOL with the machine UPN TGT, klist showed LDAP and CIFS service tickets for the DCs, so I assume Kerberos is setup correctly as far as that goes.
I guess I should have also mentioned the domain is at the Windows 2012 functional level and we have trusts with other domains at levels ranging from 2008 R2 to 2012 R2. However, everything I'm doing is limited to our local domain, so I don't think trusts should be an issue.
What should I be looking for in the logs if SSSD is reading the GPO LDAP attributes correctly? It's getting the INI path in SYSVOL from AD but the gpo_cache dir and gpo_child.log are empty so it's not even pulling down the files to read AFAICT.
Thanks, ---- -Donald
_______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On 05/05/2017 05:27 PM, Ledford, Donald wrote:
-----Original Message-----
Date: Fri, 05 May 2017 14:14:01 +0200 Subject: [SSSD-users] Re: [SSSD][AD][GPO] GPOs Found but Not Applied To: End-user discussions about the System Security Services Daemon <sss d-users@lists.fedorahosted.org> Reply-to: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org From: Michal Židek mzidek@redhat.com
On 05/05/2017 02:10 PM, Michal Židek wrote:
On 05/04/2017 06:37 PM, Ledford, Donald wrote:
Hello,
We've got a RHEL 6.9 system in testing for AD integration. We have to use 6.x due to compatibility issues with software that will eventually be deployed to the system so moving to RHEL 7.3 isn't an option.
Currently we're working on getting SSSD integrated with AD on this box. So far everything except GPO restrictions are working. Users can login via their AD credentials, their groups are enumerated, home directories are made automatically, etc. The only piece left is GPO based access restrictions. We'd really like to use AD GPOs to set who can and can't login via SSH. To this end we've made a new OU for the Linux server, placed it's AD object in the OU, and attached a GPO to the OU with a test user account in the "Deny log on through Remote Desktop Services" policy setting. So far this hasn't been working and the test account can always login through SSH.
The SSSD system can see the GPOs attached to the OU all the way up to the domain root, but does not think any of the GPOs apply to it. We've got "ad_gpo_access_control = enforcing" set in sssd.conf but it doesn't seem to be doing anything. According to the logs SSSD is parsing all the GPO LDAP attributes then deciding none of the GPOs apply, without parsing the GPO INI files themselves. I have confirmed manually that the server's Kerberos credentials will return results via LDAP queries and can mount the domain SYSVOL share as well as read the GPO files in the share. So I'm not sure why SSSD won't apply the GPO settings. I've attached a sanitized sssd.conf file and selected parts of the sssd_ad.domain.com.log file to this post. Here's the relevant version info:
RHEL 6.9 - Linux ad-lnx-test.ad.domain.com 2.6.32- 696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
yum info sssd: Name : sssd Arch : x86_64 Version : 1.13.3 Release : 56.el6 Size : 34 k Repo : installed From repo : rhel-6-server-rpms
Any thoughts on why this isn't working are much appreciated.
Hi,
Check the Security filtering[1] and GPO status[2]. are readable [3].
Ignore the 'are readable [3]', it is leftover from half deleted sentence.
[1] Go to the Group Policy Management window and select the GPO you want to check in the tree list on the left. Under the 'Scope' you can see section called 'Security filtering'. Check if it is not too restrictive.
[2] Also in the Group Policy Management window select the GPO you want to check in the tree list on the left as before. Under the 'Details' you can see 'GPO Status'. It must be Enabled (or at least the COmputer configuration can not be disabled, because the access control rules are in the computer configuration part of the GPO).
Also, what credentials did you use for the test LDAP queries?
Michal _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.o rg
Hello Michal,
[1] I have fiddled with both the GPO Security Filtering and Delegation permissions, just to be thorough. I've tried giving the computer UPN in the domain explicit Read to the GPO and I've given "Everyone" explicit Read as well. Our default is "Authenticated Users - Read" in Security Filtering. I've even looked at the GPO LDAP object permissions in ADSI Edit and I didn't see anything that leaped out at me.
[2] The GPO is Enabled under "Details". It's also "Link Enabled" but not "Enforced" in GPMC. I've done a lot of work in AD with Windows, but this is my first foray into Linux/SSSD AD integration, so it's like I'm learning all of this over again from scratch. :O
When doing LDAP/CIFS testing I kinit'ed from the local keytab as root. Klist showed I had a TGT for the local machine UPN, i.e. AD-LNX-TEST$. When using ldapsearch I used -Y GSSAPI to search the DCs using our AD DNS entry, i.e. "ldapsearch -Y GSSAPI -H ldap://ad.domain.com -b 'dc=ad,dc=domain,dc=com' -s subtree" and got attribute results for the GPO CN queries I ran.
Similarly, I used Kerberos with the machine UPN TGT when testing mapping the SYSVOL share, i.e. mount -t cifs -o sec=krb5i,vers=3.0 //ad.domain.com/SYSVOL /mnt/sysvol. I was able to read the GPO INI files in SYSVOL with this mount setup. I would assume the local machine could also read the SYSVOL.
After performing LDAP queries and mounting SYSVOL with the machine UPN TGT, klist showed LDAP and CIFS service tickets for the DCs, so I assume Kerberos is setup correctly as far as that goes.
I guess I should have also mentioned the domain is at the Windows 2012 functional level and we have trusts with other domains at levels ranging from 2008 R2 to 2012 R2. However, everything I'm doing is limited to our local domain, so I don't think trusts should be an issue.
What should I be looking for in the logs if SSSD is reading the GPO LDAP attributes correctly? It's getting the INI path in SYSVOL from AD but the gpo_cache dir and gpo_child.log are empty so it's not even pulling down the files to read AFAICT.
Thanks,
-Donald
Can you take a look at the AD object with GUID 17A3A1EB-16F3-4B2A-9B01-0043A58239A8 ? It looks like SSSD has trouble reading it's attributes. Is it the container for GPO that has the deny rules?
Maybe there are wrong permissions on just this one container.
Michal
On 05/05/2017 05:59 PM, Michal Židek wrote:
On 05/05/2017 05:27 PM, Ledford, Donald wrote:
-----Original Message-----
Date: Fri, 05 May 2017 14:14:01 +0200 Subject: [SSSD-users] Re: [SSSD][AD][GPO] GPOs Found but Not Applied To: End-user discussions about the System Security Services Daemon <sss d-users@lists.fedorahosted.org> Reply-to: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org From: Michal Židek mzidek@redhat.com
On 05/05/2017 02:10 PM, Michal Židek wrote:
On 05/04/2017 06:37 PM, Ledford, Donald wrote:
Hello,
We've got a RHEL 6.9 system in testing for AD integration. We have to use 6.x due to compatibility issues with software that will eventually be deployed to the system so moving to RHEL 7.3 isn't an option.
Currently we're working on getting SSSD integrated with AD on this box. So far everything except GPO restrictions are working. Users can login via their AD credentials, their groups are enumerated, home directories are made automatically, etc. The only piece left is GPO based access restrictions. We'd really like to use AD GPOs to set who can and can't login via SSH. To this end we've made a new OU for the Linux server, placed it's AD object in the OU, and attached a GPO to the OU with a test user account in the "Deny log on through Remote Desktop Services" policy setting. So far this hasn't been working and the test account can always login through SSH.
The SSSD system can see the GPOs attached to the OU all the way up to the domain root, but does not think any of the GPOs apply to it. We've got "ad_gpo_access_control = enforcing" set in sssd.conf but it doesn't seem to be doing anything. According to the logs SSSD is parsing all the GPO LDAP attributes then deciding none of the GPOs apply, without parsing the GPO INI files themselves. I have confirmed manually that the server's Kerberos credentials will return results via LDAP queries and can mount the domain SYSVOL share as well as read the GPO files in the share. So I'm not sure why SSSD won't apply the GPO settings. I've attached a sanitized sssd.conf file and selected parts of the sssd_ad.domain.com.log file to this post. Here's the relevant version info:
RHEL 6.9 - Linux ad-lnx-test.ad.domain.com 2.6.32- 696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
yum info sssd: Name : sssd Arch : x86_64 Version : 1.13.3 Release : 56.el6 Size : 34 k Repo : installed From repo : rhel-6-server-rpms
Any thoughts on why this isn't working are much appreciated.
Hi,
Check the Security filtering[1] and GPO status[2]. are readable [3].
Ignore the 'are readable [3]', it is leftover from half deleted sentence.
[1] Go to the Group Policy Management window and select the GPO you want to check in the tree list on the left. Under the 'Scope' you can see section called 'Security filtering'. Check if it is not too restrictive.
[2] Also in the Group Policy Management window select the GPO you want to check in the tree list on the left as before. Under the 'Details' you can see 'GPO Status'. It must be Enabled (or at least the COmputer configuration can not be disabled, because the access control rules are in the computer configuration part of the GPO).
Also, what credentials did you use for the test LDAP queries?
Michal _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.o rg
Hello Michal,
[1] I have fiddled with both the GPO Security Filtering and Delegation permissions, just to be thorough. I've tried giving the computer UPN in the domain explicit Read to the GPO and I've given "Everyone" explicit Read as well. Our default is "Authenticated Users - Read" in Security Filtering. I've even looked at the GPO LDAP object permissions in ADSI Edit and I didn't see anything that leaped out at me.
[2] The GPO is Enabled under "Details". It's also "Link Enabled" but not "Enforced" in GPMC. I've done a lot of work in AD with Windows, but this is my first foray into Linux/SSSD AD integration, so it's like I'm learning all of this over again from scratch. :O
When doing LDAP/CIFS testing I kinit'ed from the local keytab as root. Klist showed I had a TGT for the local machine UPN, i.e. AD-LNX-TEST$. When using ldapsearch I used -Y GSSAPI to search the DCs using our AD DNS entry, i.e. "ldapsearch -Y GSSAPI -H ldap://ad.domain.com -b 'dc=ad,dc=domain,dc=com' -s subtree" and got attribute results for the GPO CN queries I ran.
Similarly, I used Kerberos with the machine UPN TGT when testing mapping the SYSVOL share, i.e. mount -t cifs -o sec=krb5i,vers=3.0 //ad.domain.com/SYSVOL /mnt/sysvol. I was able to read the GPO INI files in SYSVOL with this mount setup. I would assume the local machine could also read the SYSVOL.
After performing LDAP queries and mounting SYSVOL with the machine UPN TGT, klist showed LDAP and CIFS service tickets for the DCs, so I assume Kerberos is setup correctly as far as that goes.
I guess I should have also mentioned the domain is at the Windows 2012 functional level and we have trusts with other domains at levels ranging from 2008 R2 to 2012 R2. However, everything I'm doing is limited to our local domain, so I don't think trusts should be an issue.
What should I be looking for in the logs if SSSD is reading the GPO LDAP attributes correctly? It's getting the INI path in SYSVOL from AD but the gpo_cache dir and gpo_child.log are empty so it's not even pulling down the files to read AFAICT.
Thanks,
-Donald
Can you take a look at the AD object with GUID 17A3A1EB-16F3-4B2A-9B01-0043A58239A8 ? It looks like SSSD has trouble reading it's attributes. Is it the container for GPO that has the deny rules?
Maybe there are wrong permissions on just this one container.
Michal
Maybe I should have mentioned that the DN of the object is cn={17A3A1EB-16F3-4B2A-9B01-0043A58239A8},cn=policies,cn=system,dc=ad,dc=domain,dc=com
So that you can find it easier in ADSI Edit tool.
Michal
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
On 05/05/2017 06:21 PM, ledfordd@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
On 05/05/2017 06:38 PM, Michal Židek wrote:
On 05/05/2017 06:21 PM, ledfordd@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
-----Original Message----- From: Michal Židek [mailto:mzidek@redhat.com] Sent: Friday, May 5, 2017 11:57 AM To: End-user discussions about the System Security Services Daemon <sss d-users@lists.fedorahosted.org> 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, ledfordd@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
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
On 05/05/2017 10:51 PM, Ledford, Donald wrote:
-----Original Message----- From: Michal Židek [mailto:mzidek@redhat.com] Sent: Friday, May 5, 2017 11:57 AM To: End-user discussions about the System Security Services Daemon <sss d-users@lists.fedorahosted.org> 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, ledfordd@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
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
Hi Donald,
I have the same issue.
(Mon May 22 16:35:35 2017) [sssd[be[unix.example.com]]] [ad_gpo_populate_candidate_gpos] (0x0400): candidate_gpos[171]->gpo_dn: cn={E94CC8A3-7FAA-44B5-BEF9-4BFADF72C41A},cn=policies,cn=system,DC=unix,DC=example,DC=com (Mon May 22 16:35:35 2017) [sssd[be[unix.example.com]]] [ad_gpo_populate_candidate_gpos] (0x0400): candidate_gpos[172]->gpo_dn: cn={7B18B4F3-4388-4981-8830-45D3BD78C38F},cn=policies,cn=system,DC=unix,DC=example,DC=com (Mon May 22 16:35:35 2017) [sssd[be[unix.example.com]]] [ad_gpo_populate_candidate_gpos] (0x0400): candidate_gpos[173]->gpo_dn: cn={D56308B7-2ACA-4677-900E-745477B7FAF6},cn=policies,cn=system,DC=unix,DC=example,DC=com (Mon May 22 16:35:35 2017) [sssd[be[unix.example.com]]] [ad_gpo_process_gpo_done] (0x0400): No GPOs found that apply to this system. (Mon May 22 16:35:35 2017) [sssd[be[unix.example.com]]] [ad_gpo_access_done] (0x0400): GPO-based access control successful.
I wanted to check how you granted permissions to other candidate gpo's. We have a OU with bunch of servers and multiple gpo's. Each GPO is applied to a group of servers using security filtering section in scope of GPO.
Is every Linux server needs read access to all GPO's? In this case do I need to add all Linux servers to all GPO's in security filtering section so they can get read access to all GPO's? If it is like that how can we apply particular GPO to only a set of servers, I need to Limit each application group of users to their respective server.
Thanks in Advance. Krishna.
sssd-users@lists.fedorahosted.org
-
chaithanya77＠hotmail.com -
Ledford, Donald -
ledfordd＠umkc.edu
-
Michal Židek