Dependency failed for SSSD

Question

When I booted my system today, I got the following error messages:

Jan 07 19:38:25 ubuntu20 systemd[1]: Condition check resulted in System Security Services Daemon being skipped.
Jan 07 19:38:25 ubuntu20 systemd[1]: Reached target User and Group Name Lookups.
Jan 07 19:38:25 ubuntu20 systemd[1]: sssd-nss.socket: Bound to unit sssd.service, but unit isn't active.
Jan 07 19:38:25 ubuntu20 systemd[1]: Dependency failed for SSSD NSS Service responder socket.
Jan 07 19:38:25 ubuntu20 systemd[1]: sssd-nss.socket: Job sssd-nss.socket/start failed with result 'dependency'.
Jan 07 19:38:25 ubuntu20 systemd[1]: sssd-autofs.socket: Bound to unit sssd.service, but unit isn't active.
Jan 07 19:38:25 ubuntu20 systemd[1]: Dependency failed for SSSD AutoFS Service responder socket.
Jan 07 19:38:25 ubuntu20 systemd[1]: sssd-autofs.socket: Job sssd-autofs.socket/start failed with result 'dependency'.
Jan 07 19:38:25 ubuntu20 systemd[1]: sssd-pac.socket: Bound to unit sssd.service, but unit isn't active.
Jan 07 19:38:25 ubuntu20 systemd[1]: Dependency failed for SSSD PAC Service responder socket.
Jan 07 19:38:25 ubuntu20 systemd[1]: sssd-pac.socket: Job sssd-pac.socket/start failed with result 'dependency'.
Jan 07 19:38:25 ubuntu20 systemd[1]: sssd-pam-priv.socket: Bound to unit sssd.service, but unit isn't active.
Jan 07 19:38:25 ubuntu20 systemd[1]: Dependency failed for SSSD PAM Service responder private socket.
Jan 07 19:38:25 ubuntu20 systemd[1]: Dependency failed for SSSD PAM Service responder socket.
Jan 07 19:38:25 ubuntu20 systemd[1]: sssd-pam.socket: Job sssd-pam.socket/start failed with result 'dependency'.
Jan 07 19:38:25 ubuntu20 systemd[1]: sssd-pam-priv.socket: Job sssd-pam-priv.socket/start failed with result 'dependency'.
Jan 07 19:38:25 ubuntu20 systemd[1]: sssd-ssh.socket: Bound to unit sssd.service, but unit isn't active.
Jan 07 19:38:25 ubuntu20 systemd[1]: Dependency failed for SSSD SSH Service responder socket.
Jan 07 19:38:25 ubuntu20 systemd[1]: sssd-ssh.socket: Job sssd-ssh.socket/start failed with result 'dependency'.
Jan 07 19:38:25 ubuntu20 systemd[1]: sssd-sudo.socket: Bound to unit sssd.service, but unit isn't active.
Jan 07 19:38:25 ubuntu20 systemd[1]: Dependency failed for SSSD Sudo Service responder socket.
Jan 07 19:38:25 ubuntu20 systemd[1]: sssd-sudo.socket: Job sssd-sudo.socket/start failed with result 'dependency'.
Jan 07 19:38:25 ubuntu20 systemd[1]: Starting Accounts Service...

It seems because of this sudo has also stopped working. I'm now getting sudo: 3 incorrect password attempts. Everything was fine yesterday, I have not made any changes to my system or installed any software.

Update:

~$ systemctl status sssd
○ sssd.service - System Security Services Daemon
     Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
  Condition: start condition failed at Tue 2025-01-07 19:38:24 EST; 30min ago
             ├─ ConditionPathExists=|/etc/sssd/sssd.conf was not met
             └─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was not met

Jan 07 19:38:25 ubuntu20 systemd[1]: Condition check resulted in System Security Services Daemon being skipped.

~$ systemctl start sssd

Which prompted me, "Authentication Required", My password was accepted.

~$ systemctl status sssd
○ sssd.service - System Security Services Daemon
     Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
  Condition: start condition failed at Tue 2025-01-07 20:12:37 EST; 15min ago
             ├─ ConditionPathExists=|/etc/sssd/sssd.conf was not met
             └─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was not met

Jan 07 19:38:25 ubuntu20 systemd[1]: Condition check resulted in System Security Services Daemon being skipped.
Jan 07 20:12:37 ubuntu20 systemd[1]: Condition check resulted in System Security Services Daemon being skipped.

Now sudo is working. Why does SSSD interfere with sudo functionality?

~$ journalctl -xeu sssd.service

Support: http://www.ubuntu.com/support
A start job for unit sssd.service has finished successfully.
The job identifier is 199.
-- Boot 12bc6c7bf6f14ab8a277022b764c4482 --
Jan 07 19:27:30 ubuntu20 systemd[1]: Condition check resulted in System Security Services Daemon being skipped.
Subject: A start job for unit sssd.service has finished successfully
Defined-By: systemd
Support: http://www.ubuntu.com/support
A start job for unit sssd.service has finished successfully.
The job identifier is 183.
-- Boot 002196eb090942a8bf85fb57d3466b96 --
Jan 07 19:38:25 ubuntu20 systemd[1]: Condition check resulted in System Security Services Daemon being skipped.
Subject: A start job for unit sssd.service has finished successfully
Defined-By: systemd
Support: http://www.ubuntu.com/support
A start job for unit sssd.service has finished successfully.
The job identifier is 103.
Jan 07 20:12:37 ubuntu20 systemd[1]: Condition check resulted in System Security Services Daemon being skipped.
Subject: A start job for unit sssd.service has finished successfully
Defined-By: systemd
Support: http://www.ubuntu.com/support

Have you examined systemctl status sssd.service and journalctl -xeu sssd.service? — steeldriver, Jan 08 '25 at 01:05
@steeldriver I updated my question and now I am really confused. — stumblebee, Jan 08 '25 at 01:44
... so it looks like you have SSSD installed, but not configured (ConditionPathExists=|/etc/sssd/sssd.conf was not met) similar to the "bug" reported here four Dependency failed for SSSD — steeldriver, Jan 08 '25 at 01:50
@steeldriver So it seems. But I never installed SSSD. Any idea how it got there? I did see that "bug" — stumblebee, Jan 08 '25 at 01:52
I deleted my answer because the bug report stated that the service not starting if the service isn't used is not an issue. I can undelete the answer if requested. — mchid, Jan 08 '25 at 03:24
sssd is used for centrally managing usernames and passwords using ldap or active directory..Pam will use it during authentication and authorization, for instance when you login or do sudo. If you only have local users on that computer, you do not need sssd and it should be removed or disabled. The /etc/nss.conf should then not point to sssd and only use files. — sleepyhead, Jan 08 '25 at 04:11
@mchid Please undelete your answer. I welcome any advice or insight you have. Note I have updated my question. — stumblebee, Jan 08 '25 at 13:54
@stumblebee Actually, I realized it wouldn't work anyhow. My solution was to create a dummy directory to silence the warning but the condition asks for the directory to be not empty. By creating a dummy directory the directory would still be empty so it wouldn't satisfy the dependency. My guess would be that running /usr/share/sssd/generate-config might configure it but if it needs to be set up, then it would be best just to read the guide instead. — mchid, Jan 10 '25 at 22:16
@stumblebee Well that and I also mentioned that the directory comes from the sssd-common package and suggested to reinstall that package while forcing installation of any missing configuration files: sudo apt install --reinstall -o DPkg::Options::="--force-confmiss" sssd-common Although again, I don't think that would fix the problem as the package only provides an empty directory as far as I can tell from the list of files provided by this package. — mchid, Jan 10 '25 at 22:19
@stumblebee Both of these are pretty generic solutions and apply to most situations where there's a missing configuration file or missing directory. But it appears that sssd is just set up this way by default, and not in use unless it's configured by the user. — mchid, Jan 10 '25 at 22:21
@mchid I have been using Ubuntu on my personal computer since 16.04 to now 22.04 and I have never enabled/configured SSSD on my computer. I'm still trying to figure out how SSSD just recently got enabled and took sudo away from me. — stumblebee, Jan 11 '25 at 02:14
@stumblebee In the bug report, they say it was installed by default. And the manifest file of default packages for Ubuntu 22.04.5 has a few sssd packages listed wget https://releases.ubuntu.com/jammy/ubuntu-22.04.5-desktop-amd64.manifest -q -O - | cut -f 1 | grep sssd — mchid, Jan 11 '25 at 06:57
@stumblebee To figure out what went wrong, you can search the logs using journalctl --since=DATE to view logs after a certain date like maybe the day before the problem started and you can pipe that to grep maybe to search for entries mentioning sssd like journalctl --since=2025-01-11 | grep -i sssd for example, to search all logs since midnight this morning (january 11th). And I think sudo reveals more logs sometimes that apply to the system and not just your user: sudo journalctl --since=2025-01-11 — mchid, Jan 11 '25 at 07:05
@stumblebee But all of those sockets that failed are included in the default packages. If you think this is the result of a bug, then I'd file a separate bug report related to the problem with respect to sudo as I didn't find anything mentioned about that in the previous bug report. — mchid, Jan 11 '25 at 07:20

score 2 · Accepted Answer · edited Jan 09 '25 at 23:28

SSSD is mainly used for organizations with multiple users and multiple computers.

SSSD allows users and their passwords to be managed centrally using Windows Active Directory or LDAP with or without Kerberos. (The AD is at its core an LDAP and Kerberos server with Microsoft schema's)

It requires configuration in /etc/sssd/sssd.conf

https://documentation.ubuntu.com/server/how-to/sssd/with-active-directory/

sssd depends on libnss-sss and libpam-sss to integrate into NSS and PAM and is involved in the login, authentication and authorization process.

GLIBC uses the NSS configured in /etc/nsswitch.conf to determine where linux stores it's users. Normally users, their passwords and the groups they belong to are kept in files in /etc, but you can add other sources for user management as well

passwd: files
shadow: files
group:  files

PAM provides pluggable authentication modules, that define rules for auth, session and account. Those rules can restrict what would be accepted as password or how many login attempts can be tried before locking an account.

When you call sudo, pam and nss are invoked and in your case will try and fail to lookup your user in ldap.

The same applies for SSH logins and when trying to list files, because the file system stores files by user-id and group-id and shows a name by looking it up from NSS.

In short SSSD is generally not needed, unless you have a sizable amount of computers and multiple users. It must have been installed accidentally and you can remove it. Make sure /etc/nsswitch has passwd, shadow and groups are set to files or compat, rules in /etc/pam.d/ are not blocking logins and that the /etc/sudoers is correct.

Alternatively, You can disable sssd from starting:

sudo systemctl stop sssd
sudo systemctl disable sssd

Dependency failed for SSSD

1 Answers1