7:20 p.m.
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]
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?
1:29 a.m.
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...
4:13 p.m.
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(a)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$(a)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
1:59 a.m.
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(a)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$(a)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$(a)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(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...
6:59 p.m.
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?
2:13 a.m.
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" ?
6:29 p.m.
"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.
2:06 a.m.
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.
1877
days inactive
1906
days old
sssd-users@lists.fedorahosted.org
7 comments
3 participants
participants (3)
-
Ian Puleston -
Jakub Hrozek -
Sumit Bose