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
[email protected]>
Reply-to: End-user discussions about the System Security Services
Daemon <[email protected]>
From: Michal Židek <[email protected]>
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 -- [email protected]
To unsubscribe send an email to [email protected]
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
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
