sssd fails with 'Exiting the SSSD. Could not restart critical service [tpad].
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
sssd (Ubuntu) |
Fix Released
|
High
|
Andreas Hasenack | ||
Xenial |
Fix Released
|
High
|
Andreas Hasenack |
Bug Description
[Impact]
In this particular configuration, when ldap_rfc2307_
The original scenario is a bit more complex and involves setting up an Active Directory server, but with the help from the bug reporter (thanks @pam-s!) we managed to narrow it down to this simple test case.
[Test Case]
# Install the packages. When prompted, choose any password for the ldap admin
$ sudo apt update; sudo apt install sssd slapd
# create the sssd config
$ sudo tee /etc/sssd/sssd.conf <<EOF
[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP
[domain/LDAP]
id_provider = ldap
ldap_uri = ldap://localhost
ldap_search_base = dc=example,dc=com
ldap_rfc2307_
EOF
$ sudo chmod 0600 /etc/sssd/sssd.conf
# reconfigure slapd for domain example.com, organization example. For the rest, accept defaults
$ sudo dpkg-reconfigure slapd
# add the base ldif. When prompted, use the password you chose when reconfiguring slapd earlier
$ ldapadd -x -D cn=admin,
dn: ou=People,
ou: People
objectClass: organizationalUnit
dn: ou=Group,
ou: Group
objectClass: organizationalUnit
dn: cn=ldapusers,
cn: ldapusers
objectClass: posixGroup
gidNumber: 10000
memberUid: localuser
EOF
adding new entry "ou=People,
adding new entry "ou=Group,
adding new entry "cn=ldapusers,
# create a localuser with that name
$ sudo useradd -M localuser
# restart sssd
$ sudo service sssd restart
# take note of the sssd_be process id:
$ pidof sssd_be
15474
# in one terminal, keep tailing /var/log/syslog
$ sudo tail -f /var/log/syslog
# in another terminal, run this id command. It will possibly hang for a bit, and won't show the "ldapusers" group membership
$ id localuser
(hangs a bit)
uid=1001(localuser) gid=1001(localuser) groups=
# /var/log/syslog will emit messages like these, about a crash and sssd_be restarting (if you don't have apport installed, you will just see the "starting up" bit about sssd_be):
Nov 6 17:17:08 xenial-
Nov 6 17:17:08 xenial-
Nov 6 17:17:08 xenial-
# verify that the sssd_be process id changed, confirming that it crashed and was restarted:
$ pidof sssd_be
15485
# install the fixed packages from proposed
$ apt install/
# repeat the id command. Now it finishes quickly, shows the "ldapusers" group membership, and there won't be any sign of an sssd_be restart in /var/log/syslog:
$ id localuser
uid=1001(localuser) gid=1001(localuser) groups=
[Regression Potential]
The patch is very specific, but given in how many different ways sssd can be configured, it would really help if users actually tested the package from proposed in their deployments. Specially considering it's a login service.
That being said, the patch is applied in the 1.13, 1,14 and current 1.15 series upstream and is more than a year old by now. It could rely on other changes that I missed, though, but at least one I chose to ignore (see [other info]).
[Other Info]
The exact upstream patch wasn't applied (https:/
Changed in sssd (Ubuntu): | |
assignee: | nobody → Andreas Hasenack (ahasenack) |
status: | Triaged → In Progress |
description: | updated |
description: | updated |
Changed in sssd (Ubuntu Xenial): | |
status: | New → In Progress |
assignee: | nobody → Andreas Hasenack (ahasenack) |
Changed in sssd (Ubuntu): | |
status: | In Progress → Fix Released |
Changed in sssd (Ubuntu Xenial): | |
importance: | Undecided → High |
Thanks for filing this bug in Ubuntu.
This one will be a bit complex for me to reproduce locally, as your sssd.conf file has a lot of customizations and multiple servers for each domain. It would be best if we could reduce this complexity as much as possible and still reproduce the problem.
Have you tried with just one of your two domains to see if the crash still happens? For example, list just "gc" or just "tpad" in [sssd]->domains and then login with credentials from each.