Hi all,
I'm running into problems on a RHEL6 machine with configuring sssd. I keep getting errors like this:
Sep 30 14:11:26 tst0030 sshd[7512]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=somehost.domain.com user=XXX Sep 30 14:11:27 tst0030 sshd[7512]: Failed password for XXX21358 from 12.34.56.78 port 32950 ssh2 Sep 30 14:11:33 tst0030 sshd[7512]: Failed password for XXX21358 from 12.34.56.78 port 32950 ssh2
However, I can perform a ldapsearch succesfully. So LDAP is available.
I've copied the configuration from a working RHEL5 machine(which runs just fine, I can login with the same credentials I try on the RHEL6 box), but it appears to be a no-go for now. sssd.conf looks like this:
[sssd] config_file_version = 2
# Number of times services should attempt to reconnect in the # event of a crash or restart before they give up reconnection_retries = 3
# If a back end is particularly slow you can raise this timeout here sbus_timeout = 30 services = nss, pam
# SSSD will not start if you do not configure any domains. # Add new domain configurations as [domain/<NAME>] sections, and # then add the list of domains (in the order you want them to be # queried) to the "domains" attribute below and uncomment it. domains = default
[nss] # The following prevents SSSD from searching for the root user/group in # all domains (you can add here a comma-separated list of system accounts that # are always going to be /etc/passwd users, or that you want to filter out). filter_groups = root filter_users = root reconnection_retries = 3
# The entry_cache_timeout indicates the number of seconds to retain an # entry in cache before it is considered stale and must block to refresh. # The entry_cache_nowait_timeout indicates the number of seconds to # wait before updating the cache out-of-band. (NSS requests will still # be returned from cache until the full entry_cache_timeout). Setting this # value to 0 turns this feature off (default). ; entry_cache_timeout = 600 ; entry_cache_nowait_timeout = 300
[pam] reconnection_retries = 3 #offline_credentials_expiration = 0 #offline_failed_login_attempts = 5 #offline_failed_login_delays = 15
[domain/default] ldap_id_use_start_tls = False cache_credentials = True ldap_search_base = ou=TST_EMEA_NL-TST01,ou=Locations,ou=NXDI,o=NXP ldap_user_search_base = ou=People,ou=NXDI,o=NXP ldap_user_object_class = NxpUserAuxClass ldap_user_principal = krbForeignPrincipalName ldap_force_upper_case_realm = True ldap_user_fullname = fullName ldap_user_member_of = groupMembership ldap_group_search_base = ou=Group,ou=NXDI,o=NXP ldap_group_object_class = NxpGroupAuxClass ldap_group_gid_number = gidNumber ldap_schema = rfc2307bis enumerate = True krb5_realm = WBI.NXP.COM chpass_provider = krb5 krb5_kdcserver = wbi.nxp.com id_provider = ldap auth_provider = krb5 debug_level = 0 ldap_uri = ldap://dtc0001.dtq.nl-htc01.nxp.com,ldap:// dtc0002.dtq.nl-htc01.nxp.com krb5_kpasswd = wbi.nxp.com ldap_tls_cacertdir = /etc/openldap/cacerts
I've modified nsswitch.conf to use sss, and also the system-auth to use the sssd-pam library. These look like:
auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so #account required pam_access.so accessfile=/etc/security/access.netgroup.conf
password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so nullok use_authtok md5 shadow password sufficient pam_sss.so use_authtok password required pam_deny.so
#session required pam_limits.so session required pam_unix.so session required pam_keyinit.so revoke session optional pam_sss.so
Anyone who can help me out with this ? I'm kinda stuck. Google didn't show up any useful results.
cheers, Andy
On Fri, Sep 30, 2011 at 02:26:46PM +0200, Andy Kannberg wrote:
I've modified nsswitch.conf to use sss, and also the system-auth to use the sssd-pam library. These look like:
auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so #account required pam_access.so accessfile=/etc/security/access.netgroup.conf password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so nullok use_authtok md5 shadow password sufficient pam_sss.so use_authtok password required pam_deny.so #session required pam_limits.so session required pam_unix.so session required pam_keyinit.so revoke session optional pam_sss.so
Anyone who can help me out with this ? I'm kinda stuck. Google didn't show up any useful results.
On my EL6 systems, /etc/pam.d/sshd (which is what sshd uses) is referencing /etc/pam.d/password-auth rather than /etc/pam.d/system-auth, which is a change since EL5. Did you update /etc/pam.d/password-auth as well?
HTH,
Nalin
On Fri, 2011-09-30 at 14:26 +0200, Andy Kannberg wrote:
Hi all,
I'm running into problems on a RHEL6 machine with configuring sssd. I keep getting errors like this:
Sep 30 14:11:26 tst0030 sshd[7512]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=somehost.domain.com user=XXX Sep 30 14:11:27 tst0030 sshd[7512]: Failed password for XXX21358 from 12.34.56.78 port 32950 ssh2 Sep 30 14:11:33 tst0030 sshd[7512]: Failed password for XXX21358 from 12.34.56.78 port 32950 ssh2
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.
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
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.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
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
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.
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
On Mon, Oct 03, 2011 at 01:09:34PM +0200, Andy Kannberg wrote:
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:
sssd_default.log and sssd_pam.log would be the most interesting for us in this case.
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
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
On Mon, 2011-10-03 at 22:47 +0200, Andy Kannberg wrote:
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)
This should be irrelevant. You shouldn't need a keytab file to talk to kerberos for user authentication (though without one you won't gain GSSAPI single-sign-on for SSH).
So I'd really like to know more about your setup. If you could send us a complete (sanitized) sssd_default.log at debug_level=7, we could better identify the issue.
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.
SSSD will not perform an LDAP authentication over an insecure connection. It will always requires either TLS or LDAPS for this function. This is because the LDAP protocol sends simple bind requests with the password in the clear, so in order to protect users' passwords, SSSD will not permit an authentication attempt to be sent over an unencrypted channel. So if you're using an ldap:// URI, we will always attempt START_TLS, and if that fails we will deny the auth attempt.
So I suspect what was happening is that your CA directory was pointing at the wrong location, and by commenting it out, SSSD switched back to the default, which worked.
If you were to look at your SSSD debug logs or LDAP server logs, you'd see a START_TLS request go across before the LDAP bind for authentication.
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.
See above. You shouldn't need this for simple authentication.
On Mon, 2011-10-03 at 16:57 -0400, Stephen Gallagher wrote:
On Mon, 2011-10-03 at 22:47 +0200, Andy Kannberg wrote:
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)
This should be irrelevant. You shouldn't need a keytab file to talk to kerberos for user authentication (though without one you won't gain GSSAPI single-sign-on for SSH).
We do validation by default, so a keytab is needed.
Simo.
On Mon, 2011-10-03 at 17:27 -0400, Simo Sorce wrote:
On Mon, 2011-10-03 at 16:57 -0400, Stephen Gallagher wrote:
On Mon, 2011-10-03 at 22:47 +0200, Andy Kannberg wrote:
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)
This should be irrelevant. You shouldn't need a keytab file to talk to kerberos for user authentication (though without one you won't gain GSSAPI single-sign-on for SSH).
We do validation by default, so a keytab is needed.
Simo.
We only validate by default in the IPA provider. Validation is disabled by default when using only the krb5 provider (because there is no guarantee of a keytab).
sssd-devel@lists.fedorahosted.org
-
Andy Kannberg -
Jakub Hrozek -
Jan Zelený -
Nalin Dahyabhai -
Simo Sorce -
Stephen Gallagher