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" ?