Home / ubuntu / Questions / 1537494
Accepted
stumblebee
Asked: 2025-01-08 08:30:36 +0800 CST

Dependency failed for SSSD

  • 772

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
22.04

1 Answers

  1. Best Answer

    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
    • 1