On Tue, Jun 27, 2017 at 01:35:18PM -0400, Abhijit Tikekar wrote:
>
> Hi,
>
> We are running into some SSSD authentication issues and would really appreciate any
advice. Here’s some background:
>
> Until now, all CentOS machines which use SSSD were joined to the same domain that
also holds all user’s along with their respective groups. Let’s call this abc.xyz.local.
Now, due to some compliance issue, we cannot have these Linux computer accounts in “abc”
domain, and need to be moved to another domain called “def.xyz.local”. User’s / Groups who
would be accessing these servers are unchanged and continue to be part of abc.xyz.local.
>
> “xyz.local” is the forest whereas both “abc” & “def” are child domains with
bi-directional trust. Was able to successfully join this machine to “def” domain.
ad_access_filter and other SSSD configurations are kept the same except domains,
ad_server, krb5_realm, ldap_uri which all point to the “DEF” domain now.
>
> But when trying to authenticate, we get the following under /var/log/secure:
>
> Jun 27 12:58:48 sshd[15716]: pam_sss(sshd:auth): authentication failure; logname=
uid=0 euid=0 tty=ssh ruser= rhost= user=first.last(a)ABC.XYZ.LOCAL
> Jun 27 12:58:48 sshd[15716]: pam_sss(sshd:auth): received for user
first.last(a)ABC.XYZ.LOCAL: 6 (Permission denied)
This sounds like GPO access control prevented you from logging in.
Can you (just for a test!) please set either:
ad_gpo_access_control = permissive
or even:
access_provider = permit
and see if the issue persists?
>
> From the logs, it looks like SSSD was able to change request domain from “def” to
“abc” and was able to locate the OU where the user’s reside, but could not get any
further.
>
> Also, “id” commands returns only a default group of “domain users” instead of all
the groups this user is member of in “ABC” domain.
> [root@]# id first.last(a)ABC.XYZ.LOCAL
> Uid=xxxxxxxxx(first.last(a)abc.xyz.local) gid=yyyyyyyyy(first.last(a)abc.xyz.local)
groups=yyyyyyyyy(first.last(a)abc.xyz.local),xxxxxxxxx(domain users(a)abc.xyz.local)
>
> Tried changing the ldap_user_search_base to dc=xyz,dc=local but still same results.
>
> SSSD Configuration:
>
>
> [sssd]
> domains = DEF.XYZ.LOCAL
> services = nss, pam, sudo
> config_file_version = 2
> debug_level = 10
> [nss]
> [pam]
> [sudo]
> debug_level=10
> [domain/def.xyz.local]
> debug_level=10
> ad_server = AD-Server.def.xyz.local
> id_provider = ad
> auth_provider = ad
> access_provider = ad
> sudo_provider = ad
> ldap_use_tokengroups = False
Why exactly did you disable tokengroups?
> krb5_realm = DEF.XYZ.LOCAL
> ldap_uri = ldap://<AD-Server>.def.xyz.local
> ldap_sudo_search_base = ......................... dc=abc,dc=xyz,dc=local
> ldap_user_search_base = dc=xyz,dc=local
> ldap_group_search_base = ........................ dc=abc,dc=xyz,dc=local
> ldap_access_order = filter, expire
Same here, can you test with a more vanilla configuration, removing
anything that starts with ldap_ (unless you had a reason to set those) ?
Point being, the AD provider normally has the defaults set sensibly
enough, so there shouldn't be any point in overriding the AD config..
> ad_access_filter = ...
> cache_credentials = true
> override_homedir = /home/%d/%u
> default_shell = /bin/bash
>
>
>
> krb5.conf:
>
> [logging]
> default = FILE:/var/log/krb5libs.log
> kdc = FILE:/var/log/krb5kdc.log
> admin_server = FILE:/var/log/kadmind.log
> [libdefaults]
> default_realm = DEF.XYZ.LOCAL
> dns_lookup_realm = true
> dns_lookup_kdc = true
> ticket_lifetime = 24h
> renew_lifetime = 7d
> forwardable = yes
> [realms]
> DEF.XYZ.LOCAL = {
> kdc = AD-Server.def.xyz.local:88
> admin_server = AD-Server.def.xyz.local:749
> }
> [domain_realm]
> .def.xyz.local = DEF.XYZ.LOCAL
> def.xyz.local = DEF.XYZ.LOCAL
>
>
>
>
>
> Here is sssd_domain log set to level 10. Captured during authentication.
Thank you for the logs, but I don't think the logs are complete, is
there anything after:
> > (Tue Jun 27 10:41:00 2017) [sssd[be[def.xyz.local]]] [krb5_auth_queue_send]
(0x1000): Wait queue of user [first.last(a)abc.xyz.local] is empty, running request
[0x1136800] immediately.
> > (Tue Jun 27 10:41:00 2017) [sssd[be[def.xyz.local]]] [krb5_setup] (0x4000): No
mapping for: first.last(a)abc.xyz.local