#3697 AD_GPO_ACCESS_CONTROL failing to Read GPOs
Opened 7 months ago by scipioamericanus. Modified 7 months ago

Using Amazon Linux 1. Can easily join the machine to our domain for authentication, however, the GPO access control seems to be failing. gpo_child.log remains empty at all times. Looks like the applicable logs are from sssd_MY.DOMAIN.COM.log is below. Looks like SSSD is having trouble discovering the DN for Policy Target. Can anyone help me out here?

(Mon Apr 9 14:51:32 2018) [sssd[be[MY.DOMAIN.COM]]] [ad_gpo_connect_done] (0x4000): server_hostname from uri: DOMAINCONTROLLER.MY.DOMAIN.COM
(Mon Apr 9 14:51:32 2018) [sssd[be[MY.DOMAIN.COM]]] [ad_gpo_connect_done] (0x0400): sam_account_name is IP-10.10.10.10$
(Mon Apr 9 14:51:32 2018) [sssd[be[MY.DOMAIN.COM]]] [ad_gpo_target_dn_retrieval_done] (0x0040): No DN retrieved for policy target.
(Mon Apr 9 14:51:32 2018) [sssd[be[MY.DOMAIN.COM]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.


Wanted to add SSSD version.

sssd --version

1.15.2

CC @mzidek he might know what the error mean

SSSD was trying to find the DN of the host machine in the AD/LDAP, but could not find anything.

I have few questions:
Was the config generated using realmd?
What is the domain name in the domain section in sssd.conf? (or please paste the sssd.conf)
Is the name in the domain section the same as the actual AD domain it is connected to? (if not this could be the problem)

I wanted to suggest using the ad_domain option if the domain name part of the domain section name in sssd.conf is not the same as the AD domain, but I have found this bug when testing it:
https://pagure.io/SSSD/sssd/issue/3704

So for now, make sure your [domain/addom.test] section contains real AD domain name.

Thanks for the feedback everyone. Was able to find a few things out myself.

I think this is an issue with us having a strange AD setup.

We are trying to set ldap_user_name to authenticate users against an ldap attribute that is not their SAMAccountName (HR types forced us to change the SAMAccountName to something derived from an employeeID, leaving it non user friendly). This allows us to authenticate against the kerberos realm successfully, but leads us to the issue with the GPO options.

When I remove the ldap_user_name configuration to use the SAMAccountName as is default, everything with the GPOs work properly.

I would think setting SASL_authID could solve this, but there doesn't seem to be a place to use a variable to set this. Will be difficult at scale to write the expected service principal into the sssd.conf file.

For reference, here is the SSSD.CONF file. When I set ldap_user_name = LegacyID, I can authenticate using the LegacyID, however the GPOs are not able to be pulled down. When I remove this, I can authenticate using the SAMAccountName, and successfully pull down the GPOs.

[sssd]
config_file_version = 2
domains = MY.DOMAIN.COM
services = nss, pam, sudo

[sudo]
debug_level = 9

[domain/MY.DOMAIN.COM]
debug_level = 9
ad_domain = MY.DOMAIN.COM
krb5_realm = MY.DOMAIN.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_user_name = LegacyID

ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u
case_sensitive = false
krb5_use_enterprise_principal = False
ldap_user_principal = userPrincipalName

id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
sudo_provider = ad

ldap_user_home_directory = unixHomeDirectory
ldap_user_shell = loginShell

ad_gpo_access_control = enforcing

If ldap_user_name fixed the issue then it may have been constructing the user's DN (not the host's as I thought).

I wonder if this could be a bug in SSSD where we try to use whatever attribute people use as ldap_user_name in the construction of the user's DN when we should only use the sAMAccountName for that or if it is just configuration issue. We will have to investigate this further (I only briefly checked the code so far).

Thanks for filling the issue.

Thanks for following up. At a high level though, this sounds like exactly what is happening. However, I'm not sure there is anything in AD that forces the DN to be related to be CN=$SAMAccountName, CN=Users, DC=My, DC=Domain, DC=COM. I believe it would be better to look up the DN by searching for users where ldap_user_name = given value. Don't make any assumptions about how that DN will be built.

I agree with you about not making any assumptions. I was just braindumping into a comment :) . Thanks again for your input.

(I rarely ever saw the GPO code, this comment is entirely based on this issue..)

Should we construct the user DN? @abbra might know better if it's even possible to have a user DN with a different RDN than samAccountName, but I wonder if it was safer, in the general case to search for a user entry and read its actual DN?

Searching is preferred, of course. However, your DN in AD uses CN as RDN typically.
For example, on my test install I have:

ldapsearch -Y GSSAPI -b dc=ad,dc=ipa,dc=cool -h $DC.ad.ipa.cool '(samaccountname=ab)' dn samaccountname
...
# LDAPv3
# base <dc=ad,dc=ipa,dc=cool> with scope subtree
# filter: (samaccountname=ab)
# requesting: dn samaccountname 
#

# a b, Users, ad.ipa.cool
dn: CN=a b,CN=Users,DC=ad,DC=ipa,DC=cool
sAMAccountName: ab

Login to comment on this ticket.

Metadata