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

Reply via email to