Public bug reported:
Title: SSSD: getent group for AD groups fails silently on Ubuntu 24.04
despite successful authentication and direct LDAP lookups.
Environment:
Operating System: Ubuntu 24.04.2 LTS (Noble Numbat)
SSSD Version: 2.9.4
Active Directory Environment: Windows Server 2019/2022 (mention your
version if you know it)
Summary of the Problem:
After a fresh installation and joining an Active Directory domain, SSSD is
unable to resolve any AD group memberships via getent group <ad_group_name>.
The command returns no output and no error. However, user lookups (getent
passwd <ad_user>) and direct LDAP queries (ldapsearch) for the group from the
same machine succeed. The SSSD service starts cleanly with no errors in the
system logs after initial Kerberos and SPN issues were resolved.
Steps to Reproduce:
Perform a standard installation of Ubuntu 24.04.2 LTS.
Install sssd-ad, sssd-tools, realmd, and adcli.
Join the server to an Active Directory domain using realm join.
Configure /etc/sssd/sssd.conf to use access_provider = simple and list
valid AD groups in simple_allow_groups.
Clear the SSSD cache (rm -f /var/lib/sssd/db/*) and restart the sssd
service.
Run getent group "AD Group Name".
Expected Results:
The getent group command should return a single line with the group's name,
password placeholder, GID, and a comma-separated list of its members.
Actual Results:
The getent group command returns no output. The command exits immediately with
a success status code, but no data is printed.
Diagnostic Troubleshooting Summary (This is your most important section):
An exhaustive troubleshooting process was performed. We have confirmed the
following:
Network/Firewall: Connectivity to the Domain Controllers on all required
ports (LDAP, Kerberos, etc.) is working.
AD Permissions: A direct ldapsearch from the Linux client using user
credentials successfully finds and displays the target AD group and its
members. This proves underlying AD permissions are correct.
Kerberos Client Authentication: Initial Preauthentication failed errors
were resolved by re-joining the machine to the domain. The machine's
keytab is now valid.
Kerberos Service Authentication: Initial GSSAPI errors (Server not found
in Kerberos database) were resolved by adding the missing DNS/ Service
Principal Names (SPNs) to the Domain Controllers.
SSSD Service: The sssd service now starts cleanly with no errors
reported by systemctl status sssd.
nsswitch.conf: The /etc/nsswitch.conf file is correctly configured with
group: ... sss.
sssd.conf: The configuration has been validated and uses the simple
access provider, which logs show has processed the simple_allow_groups
list correctly. Even with full debug_level = 9, the domain log shows no
errors during the lookup attempt.
SSSD Cache: The sssctl group-show command shows that SSSD is able to
find the group and place it in the cache (though the entry was marked as
expired). Even after a forceful cache wipe (rm -f /var/lib/sssd/db/*),
the getent lookup still fails.
Conclusion: All external dependencies (AD, Networking, Kerberos) and
local configurations (sssd.conf, nsswitch.conf) have been proven to be
correct. The failure appears to be happening silently inside the SSSD
nss responder process, which fails to return the group data from the
SSSD backend, even though the backend can successfully retrieve it. This
points to a software bug in SSSD 2.9.4 on Ubuntu 24.04.
** Affects: sssd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2115365
Title:
After a clean install and domain join, getent group <AD_GROUP> fails
silently, even though all authentication is working and ldapsearch can
see the group.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2115365/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
