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@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]
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'
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?
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@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$@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
Thanks for the suggestion Sumit. Your kinit command gave this output:
kinit: Pre-authentication failed: Permission denied while getting initial credentials
I wasn't sure if I should run that direct from my domain user account or with su privilege, so tried the same with sudo and that gave:
kinit: Keytab contains no suitable keys for IAN-LAPTOP@SV.US.SONICWALL.COM while getting initial credentials
ldap_child.log contains just this (repeatedly):
(Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [main] (0x0400): ldap_child started. (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [unpack_buffer] (0x0200): Will run as [0][0]. (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [become_user] (0x0200): Trying to become user [0][0]. (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [become_user] (0x0200): Already user [0]. (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [IAN-LAPTOP$@SV.US.SONICWALL.COM] (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13904]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Preauthentication failed (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13904]]]] [main] (0x0020): ldap_child_get_tgt_sync failed. (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13904]]]] [prepare_response] (0x0400): Building response for result [-1765328360] (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13904]]]] [main] (0x0400): ldap_child completed successfully (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Preauthentication failed (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [main] (0x0020): ldap_child_get_tgt_sync failed. (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [prepare_response] (0x0400): Building response for result [-1765328360] (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [main] (0x0400): ldap_child completed successfully
Ian
On Tue, Feb 05, 2019 at 10:13:41PM -0000, Ian Puleston wrote:
Thanks for the suggestion Sumit. Your kinit command gave this output:
kinit: Pre-authentication failed: Permission denied while getting initial credentials
I wasn't sure if I should run that direct from my domain user account or with su privilege, so tried the same with sudo and that gave:
kinit: Keytab contains no suitable keys for IAN-LAPTOP@SV.US.SONICWALL.COM while getting initial credentials
Are you sure you quoted the trailing '$' in the principal name? e.g. you should call this: kinit -k 'IAN-LAPTOP$@SV.US.SONICWALL.COM'
ldap_child.log contains just this (repeatedly):
(Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [main] (0x0400): ldap_child started. (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [unpack_buffer] (0x0200): Will run as [0][0]. (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [become_user] (0x0200): Trying to become user [0][0]. (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [become_user] (0x0200): Already user [0]. (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [IAN-LAPTOP$@SV.US.SONICWALL.COM] (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13904]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Preauthentication failed (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13904]]]] [main] (0x0020): ldap_child_get_tgt_sync failed. (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13904]]]] [prepare_response] (0x0400): Building response for result [-1765328360] (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13904]]]] [main] (0x0400): ldap_child completed successfully (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Preauthentication failed
This means the machine credentials in the keytab cannot be used to authenticate to the server, most probably the client has to be re-joined or the keytab otherwise regenerated.
(Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [main] (0x0020): ldap_child_get_tgt_sync failed. (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [prepare_response] (0x0400): Building response for result [-1765328360] (Tue Feb 5 14:00:15 2019) [[sssd[ldap_child[13905]]]] [main] (0x0400): ldap_child completed successfully
Ian _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
Hi,
Thanks for the help. I now seem to have the problem sorted out and things are now working OK after a configuration change:
I did have to rejoin the domain first, and that did not go very smoothly. Having successfully used "realm leave", trying to do "realm join" (with the help of an IT guy for the administrator password) would not work, failing to accept my password. Then the IT guy had the idea to rename my laptop so that it would start fully afresh, creating a new "computer" entry in AD (actually the IT guy created that manually, I think), and rather surprisingly to me, this worked.
However, I then found that I was back to an earlier state where I could not log in with my valid domain password while connected to the network, but could log in with the (new) cached credentials if I disconnected from it. I was earlier having this issue before getting into the state that I reported above, and I now think that it is probably what led to that.
So I did some debugging and found this in the SSSD log after a failed login:
(Tue Feb 26 16:20:37 2019) [sssd[be[sv.us.sonicwall.com]]] [ad_gpo_site_name_retrieval_done] (0x0400): Could not autodiscover AD site. This is not fatal if ad_site option was set. (Tue Feb 26 16:20:37 2019) [sssd[be[sv.us.sonicwall.com]]] [ad_gpo_site_name_retrieval_done] (0x0040): Could not autodiscover AD site value using DNS and ad_site option was not set in configuration. GPO will not work. To work around this issue you can use ad_site option in SSSD configuration. (Tue Feb 26 16:20:37 2019) [sssd[be[sv.us.sonicwall.com]]] [ad_gpo_process_som_done] (0x0040): Unable to get som list: [2](No such file or directory) (Tue Feb 26 16:20:37 2019) [sssd[be[sv.us.sonicwall.com]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.
So I added the ad_site name into my sssd.conf, and with that all now seems to be working fine.
But what is rather strange about this is that after that authentication failure while online, I would pull out the Ethernet cable and log in with cached credentials, and the SSSD log for the latter includes this:
(Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [ad_srv_plugin_send] (0x0400): About to find domain controllers (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [ad_get_dc_servers_send] (0x0400): Looking up domain controllers in domain sv.us.sonicwall.com and site SunnyvaleSite (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain 'SunnyvaleSite._sites.sv.us.sonicwall.com' (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.SunnyvaleSite._sites.sv.us.sonicwall.com' (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [request_watch_destructor] (0x0400): Deleting request watch (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [resolv_discover_srv_done] (0x0040): SRV query failed [11]: Could not contact DNS servers (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'not working' (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [resolve_srv_done] (0x0040): Unable to resolve SRV [1432158237]: SRV lookup error (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'AD' as 'not resolved'
So it has remembered the site name, yet did not try to use that when it could not look it up while online?
On Wed, Feb 27, 2019 at 12:59:27AM -0000, Ian Puleston wrote:
Hi,
Thanks for the help. I now seem to have the problem sorted out and things are now working OK after a configuration change:
I did have to rejoin the domain first, and that did not go very smoothly. Having successfully used "realm leave", trying to do "realm join" (with the help of an IT guy for the administrator password) would not work, failing to accept my password. Then the IT guy had the idea to rename my laptop so that it would start fully afresh, creating a new "computer" entry in AD (actually the IT guy created that manually, I think), and rather surprisingly to me, this worked.
However, I then found that I was back to an earlier state where I could not log in with my valid domain password while connected to the network, but could log in with the (new) cached credentials if I disconnected from it. I was earlier having this issue before getting into the state that I reported above, and I now think that it is probably what led to that.
So I did some debugging and found this in the SSSD log after a failed login:
(Tue Feb 26 16:20:37 2019) [sssd[be[sv.us.sonicwall.com]]] [ad_gpo_site_name_retrieval_done] (0x0400): Could not autodiscover AD site. This is not fatal if ad_site option was set. (Tue Feb 26 16:20:37 2019) [sssd[be[sv.us.sonicwall.com]]] [ad_gpo_site_name_retrieval_done] (0x0040): Could not autodiscover AD site value using DNS and ad_site option was not set in configuration. GPO will not work. To work around this issue you can use ad_site option in SSSD configuration. (Tue Feb 26 16:20:37 2019) [sssd[be[sv.us.sonicwall.com]]] [ad_gpo_process_som_done] (0x0040): Unable to get som list: [2](No such file or directory) (Tue Feb 26 16:20:37 2019) [sssd[be[sv.us.sonicwall.com]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.
So I added the ad_site name into my sssd.conf, and with that all now seems to be working fine.
But what is rather strange about this is that after that authentication failure while online, I would pull out the Ethernet cable and log in with cached credentials, and the SSSD log for the latter includes this:
(Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [ad_srv_plugin_send] (0x0400): About to find domain controllers (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [ad_get_dc_servers_send] (0x0400): Looking up domain controllers in domain sv.us.sonicwall.com and site SunnyvaleSite (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain 'SunnyvaleSite._sites.sv.us.sonicwall.com' (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.SunnyvaleSite._sites.sv.us.sonicwall.com' (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [request_watch_destructor] (0x0400): Deleting request watch (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [resolv_discover_srv_done] (0x0040): SRV query failed [11]: Could not contact DNS servers (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'not working' (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [resolve_srv_done] (0x0040): Unable to resolve SRV [1432158237]: SRV lookup error (Tue Feb 26 16:18:41 2019) [sssd[be[sv.us.sonicwall.com]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'AD' as 'not resolved'
So it has remembered the site name, yet did not try to use that when it could not look it up while online?
So authentication always (almost) tries to connect to the back end. This looks to me like the auth request tries to connect and fails. I also see "SunnyvaleSite" being used. Is it not the correct one?
Or maybe I don't understand exactly what do you mean by "did not try to use that when it could not look it up while online" ?
"SunnyvaleSite" is correct, and adding that as ad_site is what fixed (or worked-around) the problem.
what do you mean by "did not try to use that when it could not look it up while online" ?
When I was online (without ad_site in sssd.conf) the log showed the "Could not autodiscover AD site" messages above, and there, or just after it, the attempt ended.
When I was offline then it showed the "Looking up domain controllers in domain sv.us.sonicwall.com and site "SunnyvaleSite" (with that DNS lookup failing since I was offline) before it logged me in with the cached info.
So somehow it knew the site name without being able to look it up online.
On Thu, Feb 28, 2019 at 12:29:30AM -0000, Ian Puleston wrote:
"SunnyvaleSite" is correct, and adding that as ad_site is what fixed (or worked-around) the problem.
what do you mean by "did not try to use that when it could not look it up while online" ?
When I was online (without ad_site in sssd.conf) the log showed the "Could not autodiscover AD site" messages above, and there, or just after it, the attempt ended.
When I was offline then it showed the "Looking up domain controllers in domain sv.us.sonicwall.com and site "SunnyvaleSite" (with that DNS lookup failing since I was offline) before it logged me in with the cached info.
So somehow it knew the site name without being able to look it up online.
IIRC they way the code works is that it always goes through the site discovery branch (because the site discovery request also discovers the forest name) and then just throws away the site override if there's an ad_site explicitly defined.
sssd-users@lists.fedorahosted.org
-
Ian Puleston -
Jakub Hrozek -
Sumit Bose