[Impact]
In this particular configuration, when ldap_rfc2307_fallback_to_local_users is set to true in /etc/sss/sssd.conf and a local user is a member of an ldap group and does not exist in the directory (other scenarios are possible), the sssd_be process segfaults and logins might be prevented.
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_fallback_to_local_users = True
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,dc=example,dc=com -W <<EOF
dn: ou=People,dc=example,dc=com
ou: People
objectClass: organizationalUnit
dn: ou=Group,dc=example,dc=com
ou: Group
objectClass: organizationalUnit
dn: cn=ldapusers,ou=Group,dc=example,dc=com
cn: ldapusers
objectClass: posixGroup
gidNumber: 10000
memberUid: localuser
EOF
adding new entry "ou=People,dc=example,dc=com"
adding new entry "ou=Group,dc=example,dc=com"
adding new entry "cn=ldapusers,ou=Group,dc=example,dc=com"
# 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=1001(localuser)
# /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-sssd-bad-initgroups-result-1684295 systemd[1]: Starting Apport crash forwarding receiver...
Nov 6 17:17:08 xenial-sssd-bad-initgroups-result-1684295 sssd[be[LDAP]]: Starting up
Nov 6 17:17:08 xenial-sssd-bad-initgroups-result-1684295 systemd[1]: Started Apport crash forwarding receiver.
# 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/dist-upgrade ....
# 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=1001(localuser),10000(ldapusers)
[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://pagure.io/SSSD/sssd/c/5a0fb268e836e600d864ded7de5d935946ae6c61), because it relied on dropping an unused parameter from sdap_fallback_local_user(), namely the *opts struct pointer (https://pagure.io/SSSD/sssd/c/77f960ab32c2d2245fed55671f24af287ea0ba50). It is indeed not used, but I rather not drop it for an SRU because I don't know if some library could be using it, and also because a new upstream version for this series (1.13.5) wasn't released yet with this change.
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.