SSSD - wrong or missing Active Directory group information
This document (000021470) is provided subject to the disclaimer at the end of this document.
Environment
SUSE Linux Enterprise Desktop 15 SP5
SUSE Linux Enterprise Server 15 SP5
SUSE Linux Enterprise Server for SAP Applications 15 SP5
SUSE Linux Enterprise Desktop 12 SP5
SUSE Linux Enterprise Server 12 SP5
SUSE Linux Enterprise Server for SAP Applications 12 SP5
SUSE Linux Enterprise Server 15 SP5
SUSE Linux Enterprise Server for SAP Applications 15 SP5
SUSE Linux Enterprise Desktop 12 SP5
SUSE Linux Enterprise Server 12 SP5
SUSE Linux Enterprise Server for SAP Applications 12 SP5
Situation
Some systems, joined to Active Directory with SSSD, show wrong or missing AD group information
Wrong output on one system:
test-srv01:~ # getent -s sss group sales_01
sales_01:*:41273:
test-srv01:~ #
Correct output on a second system:
test-srv02:~ # getent -s sss group sales_01
sales_01:*:41273:user1,user2
test-srv02:~ #
test-srv01:~ # id user1
uid=63920(user1) gid=8053(prc_e) groups=8053(prc_e),42403(rmp_user1_e),8329(strs_e)
test-srv01:~ #
the group sales_01 is found in the backend, but can't be saved to local cache:
(Wed Apr 3 16:59:17 2024) [sssd[be[test.example.com]]] [sysdb_update_members_ex] (0x0020): Could not add member [user1@test.example.com] to group [sales_01@test.example.com]. Skipping.
(Wed Apr 3 16:51:32 2024) [sssd[be[test.example.com]]] [sdap_store_group_with_gid] (0x0040): Could not store group sales_01@test.example.com
The problem can be temporary solved only removing caches with:
rm /var/lib/sssd/db/*
but after some SSSD runtime, the issue comes back and it's not always reproducible.
Wrong output on one system:
test-srv01:~ # getent -s sss group sales_01
sales_01:*:41273:
test-srv01:~ #
Correct output on a second system:
test-srv02:~ # getent -s sss group sales_01
sales_01:*:41273:user1,user2
test-srv02:~ #
test-srv01:~ # id user1
uid=63920(user1) gid=8053(prc_e) groups=8053(prc_e),42403(rmp_user1_e),8329(strs_e)
test-srv01:~ #
the group sales_01 is found in the backend, but can't be saved to local cache:
(Wed Apr 3 16:59:17 2024) [sssd[be[test.example.com]]] [sysdb_update_members_ex] (0x0020): Could not add member [user1@test.example.com] to group [sales_01@test.example.com]. Skipping.
(Wed Apr 3 16:51:32 2024) [sssd[be[test.example.com]]] [sdap_store_group_with_gid] (0x0040): Could not store group sales_01@test.example.com
The problem can be temporary solved only removing caches with:
rm /var/lib/sssd/db/*
but after some SSSD runtime, the issue comes back and it's not always reproducible.
Resolution
Update to sssd-2.5.2-150500.10.20.2 or later (SLES15 SP5)
Update to sssd-1.16.1-7.65.1.x86_64 or later (SLES12 SP5)
Cause
The problem is caused when sysdb_store_group() is called with a name not matching the stored cache entry capitalization.
[sdap_save_group] (0x0400): Processing group lowercase@example.com
[sdap_check_ad_group_type] (0x4000): AD group [lowercase@example.com] has type flags 0x80000002
[sdap_save_group] (0x0400): Storing info for group lowercase@example.com.
[sysdb_check_ts_cache] (0x2000): Cannot find TS cache entry for [name=lowercase@example.com,cn=groups,cn=example.com,cn=sysdb]: [2]: No such file or directory
[ldb] (0x4000): Entry not found (name=lowercase@example.com,cn=groups,cn=example.com,cn=sysdb)
[sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait from ldb_modify with LDB_WAIT_ALL: No such object (32)]
[sysdb_set_entry_attr] (0x0080): Cannot set attrs for name=lowercase@example.com,cn=groups,cn=example.com,cn=sysdb, 2 [No such file or directory]
[sysdb_store_group] (0x0400): Error: 2 (No such file or directory)
[sdap_store_group_with_gid] (0x0040): Could not store group lowercase@example.com
[sdap_save_group] (0x0080): Could not store group with GID: [No such file or directory]
[sdap_save_group] (0x0080): Failed to save group [lowercase@example.com]: [No such file or directory]
The entry exists in the cache, although with different capitalization:
dn: name=UPPERCASE@example.com,cn=groups,cn=example.com,cn=sysdb
gidNumber: 123456
name: UPPERCASE@example.com
objectCategory: group
originalDN: CN=UPPERCASE,OU=xxx,OU=xxx,DC=example,DC=com
objectSIDString: S-1-5-21-1234567890-123456789-1234567890-123456
memberof: name=xxx@example.com,cn=groups,cn=example.com,cn=sysdb
orig_member: CN=xxx,OU=xxx,OU=xxx,DC=example,DC=com
orig_member: CN=yyy,OU=xxx,OU=xxx,DC=example,DC=com
nameAlias: lowercase@example.com
distinguishedName: name=UPPERCASE@example.com,cn=groups,cn=example.com,cn=sysdb
The problem is in that sysdb_store_group() searches the group including nameAlias, but subsequent modification fails because the DN is built based on the given name which may differ in case.
The problem was fixed upstream:
"Use the DN from existing entry when updating a cached group"
https://github.com/SSSD/sssd/pull/7360
https://github.com/SSSD/sssd/pull/7360/commits/517dcf2e353ae999948ed8d503988d0dee527134
[sdap_save_group] (0x0400): Processing group lowercase@example.com
[sdap_check_ad_group_type] (0x4000): AD group [lowercase@example.com] has type flags 0x80000002
[sdap_save_group] (0x0400): Storing info for group lowercase@example.com.
[sysdb_check_ts_cache] (0x2000): Cannot find TS cache entry for [name=lowercase@example.com,cn=groups,cn=example.com,cn=sysdb]: [2]: No such file or directory
[ldb] (0x4000): Entry not found (name=lowercase@example.com,cn=groups,cn=example.com,cn=sysdb)
[sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait from ldb_modify with LDB_WAIT_ALL: No such object (32)]
[sysdb_set_entry_attr] (0x0080): Cannot set attrs for name=lowercase@example.com,cn=groups,cn=example.com,cn=sysdb, 2 [No such file or directory]
[sysdb_store_group] (0x0400): Error: 2 (No such file or directory)
[sdap_store_group_with_gid] (0x0040): Could not store group lowercase@example.com
[sdap_save_group] (0x0080): Could not store group with GID: [No such file or directory]
[sdap_save_group] (0x0080): Failed to save group [lowercase@example.com]: [No such file or directory]
The entry exists in the cache, although with different capitalization:
dn: name=UPPERCASE@example.com,cn=groups,cn=example.com,cn=sysdb
gidNumber: 123456
name: UPPERCASE@example.com
objectCategory: group
originalDN: CN=UPPERCASE,OU=xxx,OU=xxx,DC=example,DC=com
objectSIDString: S-1-5-21-1234567890-123456789-1234567890-123456
memberof: name=xxx@example.com,cn=groups,cn=example.com,cn=sysdb
orig_member: CN=xxx,OU=xxx,OU=xxx,DC=example,DC=com
orig_member: CN=yyy,OU=xxx,OU=xxx,DC=example,DC=com
nameAlias: lowercase@example.com
distinguishedName: name=UPPERCASE@example.com,cn=groups,cn=example.com,cn=sysdb
The problem is in that sysdb_store_group() searches the group including nameAlias, but subsequent modification fails because the DN is built based on the given name which may differ in case.
The problem was fixed upstream:
"Use the DN from existing entry when updating a cached group"
https://github.com/SSSD/sssd/pull/7360
https://github.com/SSSD/sssd/pull/7360/commits/517dcf2e353ae999948ed8d503988d0dee527134
Additional Information
https://bugzilla.suse.com/show_bug.cgi?id=1223050
Disclaimer
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:000021470
- Creation Date: 20-Jun-2024
- Modified Date:24-Jul-2024
-
- SUSE Linux Enterprise Desktop
- SUSE Linux Enterprise Server
- SUSE Linux Enterprise Server for SAP Applications
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com
