Hi again,
After a few hours of trial and error, I've figured it out and got it working. Well, partly that is. We use LDAP(Novell eDirectory) primary as identity vault and Kerberos(AD) for primary authentication source and LDAP as fallback authentication source. So, I've disabled Kerberos in SSSD, as our develop and test systems are not known by the KDC (no keytab file) Secondly, I thought I had TLS disabled, as eDirectory doesn't have TLS enabled. However, as I still had a parameter pointing to the CA directory, SSSD apparantly thought it needed TLS. Once this was commented out and SSSD was restarted, I was able to login.
To get Kerberos in the loop again I need to pull some strings in the organisation or build a new Kerberos realm for development purposes only. Anyway...For now, SSSD is working. I
cheers and thanks for all the input so far !
Andy
2011/10/3 Jan Zelený jzeleny@redhat.com
Hi,
I've put the log level to 9, which gives a LOT of logging in sssd_default.log. These are [ldb] and [sdap] entries. sssd.log itself only shows the message:
(Mon Oct 3 11:48:24 2011) [sssd] [monitor_quit] (0): Monitor received Terminated: terminating children (Mon Oct 3 12:04:49 2011) [sssd] [monitor_quit] (0): Monitor received Terminated: terminating children (Mon Oct 3 12:08:33 2011) [sssd] [monitor_quit] (0): Monitor received Terminated: terminating children (Mon Oct 3 12:28:33 2011) [sssd] [monitor_quit] (0): Monitor received Terminated: terminating children
I rebooted the system, and when I checked the log of the
sssd_default.log,
I saw this:
(Mon Oct 3 13:02:19 2011) [sssd[be[default]]] [sbus_dispatch] (9): dbus conn: 964780 (Mon Oct 3 13:02:19 2011) [sssd[be[default]]] [sbus_dispatch] (3): Connection is not open for dispatching. (Mon Oct 3 13:02:19 2011) [sssd[be[default]]] [be_client_destructor]
(4):
Removed NSS client (Mon Oct 3 13:02:19 2011) [sssd[be[default]]] [remove_krb5_info_files] (5): Could not remove [/var/lib/sss/pubconf/kdcinfo.WBI.NXP.COM], [2][No such file or directory] (Mon Oct 3 13:02:19 2011) [sssd[be[default]]] [remove_krb5_info_files] (5): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.WBI.NXP.COM], [2][No such file or directory] (Mon Oct 3 13:02:19 2011) [sssd[be[default]]] [sdap_handle_release] (8): Trace: sh[0x9695d0], connected[1], ops[(nil)], ldap[0x9698d0], destructor_lock[0], release_memory[0] (Mon Oct 3 13:02:19 2011) [sssd[be[default]]]
[remove_connection_callback]
(9): Successfully removed connection callback.
Don't know if it is related to this problem however.
I'm kinda stuck right now.
Try setting the debug level to every section in the config file, that will produce logs for both responders as well. I'm particularly interested in the nss provider. It seems like there is some sbus communication problem. Could you also paste a little more complete log (without sensitive information) somewhere?
Thanks Jan
2011/10/3 Jan Zelený jzeleny@redhat.com
Hi Stephen,
/etc/pam.d/sshd didn't include system-auth. Fixed that, but still not
able
to login. Errors in /var/log/secure:
Oct 3 12:29:14 tst0030 login: pam_sss(login:auth): authentication
failure;
logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost= user=XXX1111 Oct 3 12:29:14 tst0030 login: pam_sss(login:auth): received for user XXX1111: 4 (System error) Oct 3 12:29:15 tst0030 login: FAILED LOGIN 2 FROM (null) FOR
XXX1111,
Authentication failure
What do sssd logs say? Anything interesting? Based on the config you pasted earlier, I suggest raising the log level to at least 4 or 5 before you try logging in again.
Logging in on the local console gives the same error.
cheers, Andy
2011/9/30 Stephen Gallagher sgallagh@redhat.com
This log doesn't show any attempt to authenticate with pam_sss.so. Can you make sure that your /etc/pam.d/sshd is actually importing system-auth. Also, make sure that /etc/ssh/sshd_config has "UsePAM yes"
Also, try logging into the local console (non-graphical). If that
works,
then it's an SSH issue, not an SSSD issue.
Jan
-- Thank you Jan Zeleny
Red Hat Software Engineer Brno, Czech Republic