On Wed, Jan 30, 2019 at 01:20:16AM -0000, Ian Puleston wrote: > Hi, > > I have a laptop running F28 and which is set up with "Enterprise Login" to > authenticate against my company's Active Directory domain network using > realmd & SSSD. When we set this up a few months back and joined the laptop to > the Windows domain it worked great, letting me log in with my AD user name > ([email protected]) and password. It still works great generally, except that my > AD password expired and I changed it, but I can't get the laptop to update to > the new password. It just goes on requiring me to enter the old AD account > password that it has cached. That is fine when I'm offline and away from > work, but when I'm in the office and plugged into the corporate network then > I'd expect it to update itself with the new password from the domain server, > which just isn't happening. > > Is there some way to force SSSD to re-sync its cached password with the > domain server? > > Some more detail: > > After logging out and then back in while connected to the corporate AD domain > (and using the old cached password) I checked the logs in /var/log/sssd: > > sssd_<domain>.log: > (Thu Jan 24 17:43:30 2019) [sssd[be[sv.us.sonicwall.com]]] [id_callback] > (0x0010): The Monitor returned an error [org.freedesktop.DBus.Error.NoReply] > > sssd_nss.log has a bunch of these: > (Thu Jan 24 17:38:04 2019) [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data > Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline] > (Thu Jan 24 17:44:27 2019) [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data > Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline] > > and sssd_pam.log a bunch of the same: > (Thu Jan 24 17:38:07 2019) [sssd[pam]] [sss_dp_get_reply] (0x0010): The Data > Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline] > (Thu Jan 24 17:44:27 2019) [sssd[pam]] [sss_dp_get_reply] (0x0010): The Data > Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline]
Hi, to "re-sync" the cached password hash SSSD has to run a successful online authentication with the new password against AD. It looks like SSSD is constantly offline and as a result only accepting the old cached password. > > And also, while using sudo to view those I got this error a couple of times: > sudo: PAM account management error: Authentication service cannot retrieve > authentication info > > But I've verified that I can ping the sv.us.sonicwall.com domain server from > the laptop after logging in, so network connectivity is not the issue. > > With more detailed logging enabled, I can see that it successfully pulls a > list of 12 domain controllers from the LDAP server, then tries to kinit with > each in turn. A couple don't respond, but those that do all fail as follows: > > (Thu Jan 24 18:51:27 2019) [sssd[be[sv.us.sonicwall.com]]] [sdap_kinit_send] > (0x0400): Attempting kinit (default, IAN-LAPTOP$, SV.US.SONICWALL.COM, 86400) > (Thu Jan 24 18:51:27 2019) [sssd[be[sv.us.sonicwall.com]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' > (Thu Jan 24 18:51:27 2019) [sssd[be[sv.us.sonicwall.com]]] [resolve_srv_send] > (0x0200): The status of SRV lookup is resolved > (Thu Jan 24 18:51:27 2019) [sssd[be[sv.us.sonicwall.com]]] > [be_resolve_server_process] (0x0200): Found address for server > stc4svdc01.sv.us.sonicwall.com: [10.50.129.149] TTL 3600 > (Thu Jan 24 18:51:27 2019) [sssd[be[sv.us.sonicwall.com]]] > [create_tgt_req_send_buffer] (0x0400): buffer size: 54 > (Thu Jan 24 18:51:27 2019) [sssd[be[sv.us.sonicwall.com]]] > [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for TGT child > ... > (Thu Jan 24 18:51:27 2019) [sssd[be[sv.us.sonicwall.com]]] > [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Preauthentication failed], > expired on [0] > (Thu Jan 24 18:51:27 2019) [sssd[be[sv.us.sonicwall.com]]] [sdap_kinit_done] > (0x0100): Could not get TGT: 14 [Bad address] > (Thu Jan 24 18:51:27 2019) [sssd[be[sv.us.sonicwall.com]]] > [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret > [1432158226](Authentication Failed) > (Thu Jan 24 18:51:27 2019) [sssd[be[sv.us.sonicwall.com]]] > [sdap_cli_connect_recv] (0x0040): Unable to establish connection [13]: > Permission denied > (Thu Jan 24 18:51:27 2019) [sssd[be[sv.us.sonicwall.com]]] > [fo_set_port_status] (0x0100): Marking port 389 of server > 'stc4svdc01.sv.us.sonicwall.com' as 'not working' > (Thu Jan 24 18:51:27 2019) [sssd[be[sv.us.sonicwall.com]]] > [fo_set_port_status] (0x0400): Marking port 389 of duplicate server > 'stc4svdc01.sv.us.sonicwall.com' as 'not working' You might find more details in the ldap_child.log file, but I guess the main information will still be 'Preauthentication failed'. Most probably your host credentials from the keytab got out of sync. To test this please call kinit -k '[email protected]' (do not forget the "'"s). If this works please send ldap_child.log since there might be a different issue. If this fails as well, please rejoin the AD domain. HTH bye, Sumit > > I don't really know this stuff, but that looks like the Kerberos ticket has > expired? What I've read says that renewing an expired ticket should happen > automatically when I use the password, but that doesn't seem to be happening. > > Ideas? > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
