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.l...@abc.xyz.LOCAL > > Jun 27 12:58:48 sshd[15716]: pam_sss(sshd:auth): received for user > > first.l...@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.l...@abc.xyz.LOCAL > > Uid=xxxxxxxxx(first.l...@abc.xyz.local) > > gid=yyyyyyyyy(first.l...@abc.xyz.local) > > groups=yyyyyyyyy(first.l...@abc.xyz.local),xxxxxxxxx(domain > > us...@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.l...@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.l...@abc.xyz.local _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org