Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
This bug is created as a clone of upstream ticket:
https://pagure.io/SSSD/sssd/issue/3362
After upgrade from 1.14 to 1.15 I noticed odd behavior of filter_* settings
If local user or group absent this works fine and prevents accounts that exist in LDAP from showing up in the host
Example of config:
# grep named /etc/sssd/sssd.conf
filter_users = avahi,dbus,haldaemon,ldap,named,news,nscd,radiusd,root
filter_groups = named,stapdev,stapusr,uuidd
# grep sss /etc/nsswitch.conf
passwd: files sss
shadow: files sss
group: files sss
Now without local named account the user does not exist as expected:
# grep named /etc/passwd /etc/group
# id named
id: named: no such user
However, both user and group named still show up as enumerated "leaking:" from LDAP
# getent passwd named
# getent passwd | grep named:
named:*:25:25:Service Account named:/var/named:/bin/bash
# getent group named
# getent group | grep named
named:*:25:
Now, trying to add local user with running SSSD causes error and weird behavior. the user appears to be created but yet not found in local files.
# useradd -u 25 named
useradd: UID 25 is not unique
# getent passwd 25
named:*:25:25:Service Account named:/var/named:/bin/bash
# getent passwd named
named:*:25:25:Service Account named:/var/named:/bin/bash
# grep named /etc/passwd
# id named
uid=25(named) gid=25(named) groups=25(named)
# grep named /etc/passwd /etc/group
#
After sssd restart it disappears
# service sssd restart
Redirecting to /bin/systemctl restart sssd.service
# id named
id: named: no such user
After downgrade to sssd 1.14 all works as expected and user/group named never shows up from LDAP
[](/SSSD/sssd/issue/raw/files/134205d6c25db2201b743351f39cbe2c8e75e0b8311f6c4f81904cdd11f8af86-sssd.conf)
(In reply to Sumit Bose from comment #7)
> * master:
> * 6a1da829eaa1eee3e854f0cadc0b6effff776ab4
>
> fixes a '6a1da829eaa1eee3e854f0cadc0b6effff776ab4' in the patch set above
sorry I meant 'may be used uninitialized in this function' compiler error.
Verified the bug on SSSD version: sssd-1.15.2-49.el7.x86_64
Steps followed during verification:
1. Reproduce the bug with an older sssd build like sssd-1.15.1-1.el7.x86_64
2. Install the above old build and create a user-group in ldap server.
3. Filter them out in the NSS section. Example:
[nss]
debug_level = 0xFFF0
filter_users = testuser1
filter_groups = TestGroup
4. Clear the cache and restart sssd service.
5. Run the following commands:
# id 2121
uid=2121(testuser1) gid=2121 groups=2121
# getent passwd -s sss testuser1
testuser1:*:2121:2121:testuser1:/home/testuser1:/bin/bash
# getent passwd -s sss TestGroup
# getent group -s sss 23011
TestGroup:*:23011:
# getent passwd -s sss TestGroup
# rpm -q sssd
sssd-1.15.1-1.el7.x86_64
6. As seen from the output of above commands, the older sssd build fetched the filtered (blocked) testuser1 and TestGroup. The trick is to fetch them using their UID's first.
7. Upgrade the sssd to latest version: sssd-1.15.2-49
8. Repeat step 5 and see the results.
# id 2121
id: 2121: no such user
# getent passwd -s sss testuser1
# getent group -s sss 23011
# getent passwd -s sss TestGroup
# rpm -q sssd
sssd-1.15.2-49.el7.x86_64
The bug appears to be fixed.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHEA-2017:2294