On Fri, Mar 18, 2016 at 11:06:53AM -0400, Cyril Scetbon wrote: > Hi Jakub, > > Here are the pam logs : > - when the authentication is working http://pastebin.com/aDw3tfnL > - when it's not http://pastebin.com/B7azEfn9
(I'm stepping in here for Jakub because he might no be available during the next days). The SSSD logs are looking good. The first show a successful online-authentication while the second shows a successful offline-authentication against cached credentials. > > I'm trying to test it on another machine where pam_ldap is not used. Cause it > could come from the fact that both are used and that the user I test exists > on the system too (it is used by pam_ldap + pam_sssd). > > > On Mar 17, 2016, at 17:35, Jakub Hrozek <[email protected]> wrote: > > > > On Thu, Mar 17, 2016 at 02:29:33PM -0400, Cyril Scetbon wrote: > >> Hey Jakub, > >> > >> So I think I've provided you all the log files I could. The last version > >> (first a connection with the reachable ldap, and then without) can be > >> found at : http://pastebin.com/B3JnMr65 <http://pastebin.com/B3JnMr65> > >> > >> The other logs are empty : > > > > Because you didn't enable debugging in those respective sections, only > > in [domain]. We don't log anything except fatal failures by default.. > > > >> > >> # ls -lrt /var/log/sssd/ > >> total 304 > >> -rw------- 1 root root 0 Mar 17 19:16 sssd_pam.log > >> -rw------- 1 root root 0 Mar 17 19:16 sssd_nss.log > >> -rw------- 1 root root 0 Mar 17 19:16 sssd_autofs.log > >> -rw------- 1 root root 0 Mar 17 19:16 sssd.log > >> -rw------- 1 root root 0 Mar 17 19:16 ldap_child.log > >> -rw------- 1 root root 306912 Mar 17 19:17 sssd_default.log > >> > >> However I found other logs : > >> > >> Mar 17 19:22:26 cscetbon-vdi mysqld: pam_sss(serverdb:auth): > >> authentication success; logname= uid=64259 euid=64259 tty= ruser= rhost= > >> user=myuser <==== ldap accessible > >> > >> Mar 17 19:22:49 cscetbon-vdi mysqld: pam_sss(serverdb:auth): > >> authentication success; logname= uid=64259 euid=64259 tty= ruser= rhost= > >> user= myuser <== no ldap This is in agreement to the logs from above, both authentications are successful. > >> Mar 17 19:22:54 cscetbon-vdi mysqld: nss_ldap: could not search LDAP > >> server - Server is unavailable > >> Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: could not connect to > >> any LDAP server as uid=pamldap,ou=Auth,dc=fti,dc=net - Can't contact LDAP > >> server > >> Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: failed to bind to LDAP > >> server ldaps://ldap.multis/: Can't contact LDAP server > >> Mar 17 19:22:55 cscetbon-vdi unix_chkpwd: nss_ldap: could not search LDAP > >> server - Server is unavailable > >> Mar 17 19:22:55 cscetbon-vdi unix_chkpwd[3173]: could not obtain user info > >> (myuser) It looks like mysqld tries to lookup the user with all available NSS modules. Maybe it would help if you remove the 'ldap' entry in /etc/nsswitch.conf from passwd and group lines? bye, Sumit > >> Mar 17 19:25:01 cscetbon-vdi CRON[3652]: pam_unix(cron:session): session > >> opened for user root by (uid=0) > >> Mar 17 19:25:01 cscetbon-vdi CRON[3652]: pam_unix(cron:session): session > >> closed for user root > >> > >> I'm wondering if another pam file is not included even if I thought it's > >> not because of this unix_chkpwd issue > > > > Yes, I would have also expected pam_sss to show up here because the > > domain log files you showed earlier included a PAM_* action, which must > > have been triggered by something.. > > _______________________________________________ > > sssd-users mailing list > > [email protected] <mailto:[email protected]> > > https://lists.fedorahosted.org/admin/lists/[email protected] > > > > <https://lists.fedorahosted.org/admin/lists/[email protected]> > _______________________________________________ > sssd-users mailing list > [email protected] > https://lists.fedorahosted.org/admin/lists/[email protected] _______________________________________________ sssd-users mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
