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? _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org
