-----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(a)lists.fedorahosted.org>
Reply-to: End-user discussions about the System Security Services
Daemon <sssd-users(a)lists.fedorahosted.org>
From: Michal Židek <mzidek(a)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(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)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