Red Hat Bugzilla – Bug 889206
On clock skew sssd returns system error
Last modified: 2015-03-05 05:26:53 EST
This bug is created as a clone of upstream ticket: https://fedorahosted.org/sssd/ticket/1721 I updated one of my laptops today and time got 1 hour out of sync for some reason. When I tried to login I got back system error. Checking the krb error returned it said clock skew. I think we should not return system error, we should either adjust to the skew or log in with offline credentials.
Fixed upstream (in ticket 1096): master: 83011d97d17bd00e99ccf1e0302167a6bc0db84e
Tested with: # rpm -q sssd sssd-1.12.2-39.el7.x86_64 With kdc time ahead by one hour, I see system error in /var/log/secure # ssh puser1@localhost puser1@localhost's password: Permission denied, please try again. puser1@localhost's password: # tailf /var/log/secure Jan 14 01:32:57 qe-blade-01 sshd[14926]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost user=puser1 Jan 14 01:32:57 qe-blade-01 sshd[14926]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost user=puser1 Jan 14 01:32:57 qe-blade-01 sshd[14926]: pam_sss(sshd:auth): received for user puser1: 4 (System error) Jan 14 01:33:00 qe-blade-01 sshd[14926]: Failed password for puser1 from ::1 port 50380 ssh2 # tailf /var/log/sssd/krb5_child.log | grep skew (Wed Jan 14 01:32:57 2015) [[sssd[krb5_child[14968]]]] [get_and_save_tgt] (0x0020): 996: [-1765328236][Clock skew too great in KDC reply] (Wed Jan 14 01:32:57 2015) [[sssd[krb5_child[14968]]]] [map_krb5_error] (0x0020): 1065: [-1765328236][Clock skew too great in KDC reply] # tailf /var/log/messages Jan 14 01:32:57 qe-blade-01 [sssd[krb5_child[14968]]]: Clock skew too great in KDC reply Jan 14 01:32:57 qe-blade-01 [sssd[krb5_child[14968]]]: Clock skew too great in KDC reply # tailf /var/log/sssd/sssd_LDAP-KRB5.log (Wed Jan 14 01:32:57 2015) [sssd[be[LDAP-KRB5]]] [write_pipe_handler] (0x0400): All data has been sent! (Wed Jan 14 01:32:57 2015) [sssd[be[LDAP-KRB5]]] [read_pipe_handler] (0x0400): EOF received, client finished (Wed Jan 14 01:32:57 2015) [sssd[be[LDAP-KRB5]]] [check_wait_queue] (0x1000): Wait queue for user [puser1] is empty. (Wed Jan 14 01:32:57 2015) [sssd[be[LDAP-KRB5]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success] (Wed Jan 14 01:32:57 2015) [sssd[be[LDAP-KRB5]]] [be_pam_handler_callback] (0x0100): Sending result [4][LDAP-KRB5] sssd.conf domain section: [domain/LDAP-KRB5] debug_level = 0xFFF0 id_provider = ldap ldap_uri = ldap://<ldap server> ldap_search_base = dc=example,dc=com auth_provider = krb5 krb5_server = <kdc hostname> krb5_realm = EXAMPLE.COM
I think I see the problem, we only handled one of the two possible skew error codes, not the other one. Can you try this build? http://brewweb.devel.redhat.com/brew/taskinfo?taskID=8527595
(In reply to Jakub Hrozek from comment #5) > I think I see the problem, we only handled one of the two possible skew > error codes, not the other one. > > Can you try this build? > http://brewweb.devel.redhat.com/brew/taskinfo?taskID=8527595 This build works as expected. System error no longer appears and sssd goes offline on clock skew. /var/log/secure now shows: Jan 14 05:31:21 qe-blade-01 sshd[31863]: pam_sss(sshd:auth): received for user puser1: 9 (Authentication service cannot retrieve authentication info)
Verified with sssd-1.12.2-42.el7 If kdc is ahead of time by one hour, /var/log/secure now shows: Jan 16 02:54:03 yttrium sshd[7003]: pam_sss(sshd:auth): received for user puser1: 9 (Authentication service cannot retrieve authentication info) # cat /var/log/sssd/krb5_child.log | grep -i "Clock skew too great" (Fri Jan 16 02:54:03 2015) [[sssd[krb5_child[7013]]]] [get_and_save_tgt] (0x0020): 996: [-1765328236][Clock skew too great in KDC reply] (Fri Jan 16 02:54:03 2015) [[sssd[krb5_child[7013]]]] [map_krb5_error] (0x0020): 1065: [-1765328236][Clock skew too great in KDC reply] Domain log shows: (Fri Jan 16 02:54:03 2015) [sssd[be[LDAP-KRB5]]] [be_mark_offline] (0x2000): Going offline!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-0441.html