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 (name(a)x.y.com) 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 'IAN-LAPTOP$(a)SV.US.SONICWALL.COM'
(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 -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> 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/sssd-users@lists.fedorahoste...