#2866 Cannot authenticate AD trust users after disconnecting network
Closed: Fixed None Opened 8 years ago by orion.

We have an IPA/AD trust. If I disconnect from the network and then try to login as an AD user it fails. It appears that sssd is not properly going into offline mode. No idea why it still shows the server name as resolving (probably cached), or why the connection timeout does not appear to trigger offline mode.

sssd-1.12.2-58.el7_1.18.x86_64

sssd_domain.log:

(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [be_req_set_domain] (0x0400): Changing request domain from [nwra.com] to [ad.nwra.com]
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [be_pam_handler] (0x0100): Got request with the following data
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [pam_print_data] (0x0100): domain: ad.nwra.com
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [pam_print_data] (0x0100): user: user@ad.nwra.com
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [pam_print_data] (0x0100): service: kdm
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [pam_print_data] (0x0100): tty: :0
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [pam_print_data] (0x0100): ruser:
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [pam_print_data] (0x0100): rhost:
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [pam_print_data] (0x0100): authtok type: 1
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [pam_print_data] (0x0100): newauthtok type: 0
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [pam_print_data] (0x0100): priv: 1
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [pam_print_data] (0x0100): cli_pid: 11253
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [pam_print_data] (0x0100): logon name: not set
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA'
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [be_resolve_server_process] (0x0200): Found address for server ipa.server.com: [X.X.X.X] TTL 86400
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [write_pipe_handler] (0x0400): All data has been sent!
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [read_pipe_handler] (0x0400): EOF received, client finished
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success]
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [be_pam_handler_callback] (0x0100): Sending result [4][ad.nwra.com]
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [be_pam_handler_callback] (0x0100): Sent result [4][ad.nwra.com]
(Wed Nov 11 11:03:09 2015) [sssd[be[nwra.com]]] [child_sig_handler] (0x0100): child [11465] finished successfully.
(Wed Nov 11 11:03:11 2015) [sssd[be[nwra.com]]] [generic_ext_search_handler] (0x0040): sdap_get_generic_ext_recv failed [110]: Connection timed out
(Wed Nov 11 11:03:11 2015) [sssd[be[nwra.com]]] [ipa_get_ad_override_done] (0x0040): ipa_get_ad_override request failed.
(Wed Nov 11 11:03:11 2015) [sssd[be[nwra.com]]] [ipa_subdomain_account_got_override] (0x0040): IPA override lookup failed: 110
(Wed Nov 11 11:03:11 2015) [sssd[be[nwra.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,110,Account info lookup failed

pam messages:

Nov 11 10:54:10 pacas.cora.nwra.com kdm[11151]: :0[11151]: pam_unix(kdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=  user=user
Nov 11 10:55:08 pacas.cora.nwra.com kdm[11151]: :0[11151]: pam_sss(kdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=user
Nov 11 10:55:08 pacas.cora.nwra.com kdm[11151]: :0[11151]: pam_sss(kdm:auth): received for user user: 4 (System error)

sssd.conf:

[domain/nwra.com]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = nwra.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
chpass_provider = ipa
ipa_server = _srv_, ipa.server.com
dns_discovery_domain = nwra.com
ipa_automount_location = boulder
override_shell = /bin/bash
debug_level = 6

[sssd]
services = nss, sudo, pam, ssh, autofs
config_file_version = 2
domains = nwra.com
#full_name_format = %1$s
default_domain_suffix = ad.nwra.com
debug_level = 6



# grep hosts /etc/nsswitch.conf
hosts:      files dns mdns4_minimal myhostname

1) If you search the AD user entry with ldbsearch in the cache, do you see the= cachedPassword attribute? The command would look like ldbsearch -H /var/lib/sss/db/cache_$domain.

2) Can you attach the PAM responder logs, too?

Replying to [comment:1 jhrozek]:

1) If you search the AD user entry with ldbsearch in the cache, do you see the= cachedPassword attribute? The command would look like ldbsearch -H /var/lib/sss/db/cache_$domain.

Yes, and I can login offline at other times. But immediately after disconnecting it fails.

2) Can you attach the PAM responder logs, too?

sure.

Thank you for the log. It's defitely an SSSD bug, because we shouldn't return System Error unless some internal issue happened in SSSD.

Pavel agreed to take a look.

owner: somebody => pbrezina

Hi, I just want to clarify the problem here.

You have IPA-AD trust setup and you trying to login with an AD user. It works fine. When AD is offline you expect to login with cached password. You are unable to login on first try when you switch to offline but it works afterwards?

Can you also attach full domain log please?

hi orion, can you attach the domain logs please? If it contains some confidential data, you can also send it to us via email..

I'll send the logs via email. Test case from logs is:

  • login as AD user
  • logout
  • turn off wireless via keyboard kill switch
  • try to login as AD user again

Sorry this took so long, I think I have a patch ready. Are you able to test packages, please? If so, just let me know the OS, release and architecture.

Patches are on review.

patch: 0 => 1

btw I would prefer to get test results before pushing the patches. If the patches would help, then I would prefer to push into 1.13 as well (the patches are not invasive).

Where are the patches? I'm happy to test here.

I'm getting "Forbidden" on the actual rpms.

Looks like one got fixed, but not the rest.

chmod o+r *...please try now. Sorry about this.

Still failing, updated logs sent. Same test as before - successful login, disable network, failed login.

We had a debug session with orion on IRC and tracked the issue down to us using enumeration timeout for searching id views, which was taking too long and made the whole session time out.

I'll go ahead and commit the patches..

Also related was: 54189e0

We still need to fix the enum timeout.

milestone: NEEDS_TRIAGE => SSSD 1.14 alpha

Fields changed

resolution: => fixed
status: new => closed

Looks good to me with 1.14.0. Thanks.

Metadata Update from @orion:
- Issue assigned to pbrezina
- Issue set to the milestone: SSSD 1.14 alpha

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3907

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata