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