SSSD / sssd

#3248 Cached credential setup consistently goes offline (never to comeback) upon the AD provider's recovery
Closed: Invalid Opened by lasanthak.

Closed: Invalid
Reopen Issue

This behavior is observed on a setup where, under normal circumstances everything runs very well, i.e. when both sssd client and AD provider are connected.

During an enforced absence (for testing) of the AD provider, sssd client authenticates users very well with cached user credential (as expected by the configuration).

However, on return of the AD provider, sssd client behaves erratically. Sometimes, outright user authentications are refused and other times it takes a long time to authenticate.

Debug logs at level 7 shows, on periodic basis (around 70+ seconds) sssd client attempts to go online with AD provider, but fails consistently dropping back to offline (logs attached).

Notably, the service can only be restored by restarting sssd service at the client.

How can this be controlled ?

Client (sssd) is on an Ubuntu 16.04.1 server with Samba 4.3.11 and SSSd 1.13.4.

AD DC is also running on an Ubuntu 16.04.1 server and Samba 4.3.11 AD DC setup with internal DNS.

Level 7 log of the SSSd at the time trying to go online
sssd_L7_0.txt

Configuration of the SSSd
sssd.conf

It looks like SSSD fails to execute adcli to check if the machine account password needs renewal, most probably it is not installed.

If this is the case you hit https://fedorahosted.org/sssd/ticket/3016 which is fixed in 1.13.5, so the patch might not be available in your Ubuntu build. If there is a newer build for your platform please try to upgrade. If no newer version is available please install adcli as a workaround, if can be removed if a SSSD version with a fix is available for your platform.

If might help if you can check the Ubuntu bug tracking system if this issue is already known or if you need to open a ticket.

HTH

bye,
Sumit

Yep, the workaround suggested works like a charm. Thanks a lot.

I shall check on the Ubuntu bug tracker. Should it require, I will open a ticket there.

Replying to [comment:1 sbose]:

install adcli as a workaround...

_comment0: Yep, the workaround suggested works like a charm. Thanks a lot.

I shall check on the Ubuntu bug track and should it require, will open a ticket.

Replying to [comment:1 sbose]:

install adcli as a workaround...

=> 1480327838221757

I've looked at Ubuntu bug tracker, there are several bugs resembling this issue. Some of those bugs are worked around by installing adcli.

I have opened a ticket (https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1645291) for this particular issue at Ubuntu.

PS: Another painful problem I faced and found to be already reported at Ubuntu (https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1597916).

Since it seems no bug is in the upstream packages, but 'just' the Ubuntu packages must be patched, I'm closing this ticket as worksforme.

resolution: => worksforme
status: new => closed

Metadata Update from @lasanthak:
- Issue set to the milestone: NEEDS_TRIAGE

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/4281

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.
Metadata
None
None
None
None
Normal
0
defect
SSSD
1.13.4
None
0
0
0
0
0
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.