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.
Bug 1652562 - local user's ldap group membership not returned correctly
Summary: local user's ldap group membership not returned correctly
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sssd
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Pavel Březina
QA Contact: sssd-qe
David Voženílek
URL:
Whiteboard: sync-to-jira
Depends On: 1682305
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-22 11:27 UTC by shridhar
Modified: 2020-05-02 19:10 UTC (History)
13 users (show)

Fixed In Version: sssd-2.2.3-2.el8
Doc Type: Known Issue
Doc Text:
.SSSD returns incorrect LDAP group membership for local users when the `files` domain is enabled If the System Security Services Daemon (SSSD) serves users from the local files and the `ldap_rfc2307_fallback_to_local_users` attribute in the [domain/LDAP] section of the `sssd.conf` file is set to True, then the files provider does not include group memberships from other domains. As a consequence, if a local user is a member of an LDAP group, the `id local_user` command does not return the user's LDAP group membership. To work around this problem, disable the implicit `files` domain by adding [literal,subs="+quotes,attributes"] ---- enable_files_domain=False ---- to the `[sssd]` section in the `/etc/sssd/sssd.conf` file. As a result, `id local_user` returns correct LDAP group membership for local users.
Clone Of:
Environment:
Last Closed: 2020-04-28 16:55:59 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
logs and cache data (25.90 KB, application/x-gzip)
2018-11-22 11:29 UTC, shridhar 		no flags Details
logs (9.66 KB, application/x-bzip)
2020-01-08 06:15 UTC, shridhar 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4984 0 None open Files domain prevents local group membership of a remote user from working 2021-02-02 11:32:37 UTC
Red Hat Product Errata RHBA-2020:1863 0 None None None 2020-04-28 16:56:22 UTC

Description shridhar 2018-11-22 11:27:07 UTC 
Description of problem:

When local user is added to the ldap-group(389-ds directory server) then running id <local user> command does not return ldap-group membership. The sss_cache of ldap domain also does not ldap-group membership.  More ever running 'getent group <ldap_group>' returns local user as its member. After running getent group <ldap_group>, sss_cache of LDAP-domain does updates local-users group membership but still does not return that membership with 'id <local_user>' command.


Version-Release number of selected component (if applicable):
sssd-2.0.0-23.el8.x86_64

How reproducible:
Alwasy

Steps to Reproduce:
0. Create local user on rhel8 and add it to the ldap-group on ldap-server.

1. Configure sssd as ldap-client to the directory server(389-ds  in this scenario)
[root@dell-r730-002-guest23 ~]# cat /etc/sssd/sssd.conf
 
[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP
 
[domain/LDAP]
debug_level = 0xFFF0
id_provider = ldap
ldap_uri = ldap://dell-r730-001-guest28.dsal.lab.eng.rdu2.redhat.com
ldap_search_base = dc=example,dc=com
 
ldap_rfc2307_fallback_to_local_users = True
[root@dell-r730-002-guest23 ~]# grep local_user /etc/passwd
local_user:x:1001:1001::/home/local_user:/bin/bash
[root@dell-r730-002-guest23 ~]# id local_user@ldap
uid=1001(local_user) gid=1001(local_user) groups=1001(local_user)
[root@dell-r730-002-guest23 ~]# ldbsearch -H /var/lib/sss/db/cache_LDAP.ldb "name=local_user@ldap"
asq: Unable to register control with rootdse!
# record 1
dn: name=local_user@ldap,cn=users,cn=LDAP,cn=sysdb
createTimestamp: 1542883459
gidNumber: 1001
homeDirectory: /home/local_user
loginShell: /bin/bash
name: local_user@ldap
objectCategory: user
uidNumber: 1001
nameAlias: local_user@ldap
isPosix: TRUE
lastUpdate: 1542883459
dataExpireTimestamp: 1542888859
distinguishedName: name=local_user@ldap,cn=users,cn=LDAP,cn=sysdb
 
2.[root@dell-r730-002-guest23 ~]# getent group ldap_group
ldap_group:*:201201:local_user,ldap_user,non_existant_user
[root@dell-r730-002-guest23 ~]# ldbsearch -H /var/lib/sss/db/cache_LDAP.ldb "name=local_user@ldap"
asq: Unable to register control with rootdse!
# record 1
dn: name=local_user@ldap,cn=users,cn=LDAP,cn=sysdb
createTimestamp: 1542883459
gidNumber: 1001
homeDirectory: /home/local_user
loginShell: /bin/bash
name: local_user@ldap
objectCategory: user
uidNumber: 1001
nameAlias: local_user@ldap
isPosix: TRUE
lastUpdate: 1542883459
dataExpireTimestamp: 1542888859
memberof: name=ldap_group@ldap,cn=groups,cn=LDAP,cn=sysdb
distinguishedName: name=local_user@ldap,cn=users,cn=LDAP,cn=sysdb
 
3.

Actual results:
id <local_user> is not returning the ldap-group membership correctly

Expected results:
id <local_user> should return the ldap-group membership correctly

Additional info:
We have this scenario automated for rfc2307.
Comment 1 shridhar 2018-11-22 11:29:45 UTC 
Created attachment 1507916 [details]
logs and cache data
Comment 2 Jakub Hrozek 2018-12-10 10:42:13 UTC 
The scope is too big for a 8.0 fix at this point, we need to fix the bug in 8.1. We can add a known issue in the meantime.
Comment 8 Pavel Březina 2019-04-25 08:18:45 UTC 
Shridhar, can you share the tests with me please? I see the same behavior with both sssd 1.16 and 2.0:

group-1 is ldap group

[pbrezina ~]$ id
uid=1000(pbrezina) gid=1000(pbrezina) groups=1000(pbrezina),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
(sssd restart)
[pbrezina ~]$ id pbrezina
uid=1000(pbrezina) gid=1000(pbrezina) groups=1000(pbrezina),10(wheel),20001(group-1)
(sssd restart)
[pbrezina ~]$ su pbrezina
[pbrezina ~]$ id
uid=1000(pbrezina) gid=1000(pbrezina) groups=1000(pbrezina),10(wheel),20001(group-1) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

So when initgroups is re-run the group is present in the list.
Comment 9 Pavel Březina 2019-06-11 10:34:22 UTC 
Bump. Are there any news on the need info?
Comment 10 Jakub Hrozek 2019-06-12 07:24:50 UTC 
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/4013
Comment 13 shridhar 2019-07-15 10:04:10 UTC 
Set ldap rfc2307 fallback to local users to true bz948263(In reply to Pavel Březina from comment #8)
> Shridhar, can you share the tests with me please? I see the same behavior
> with both sssd 1.16 and 2.0:
> 
Pavel,  specific testcase from rfc2307:  Set ldap rfc2307 fallback to local users to true bz948263

beaker job details:

https://beaker.engineering.redhat.com/recipes/6453227#task87589039
http://beaker-archive.host.prod.eng.bos.redhat.com/beaker-logs/2019/01/33197/3319728/6453227/87589039/404961578/resultoutputfile.log
Comment 14 Jakub Hrozek 2019-07-15 12:43:20 UTC 
(In reply to Pavel Březina from comment #8)
> Shridhar, can you share the tests with me please? I see the same behavior
> with both sssd 1.16 and 2.0:
> 
> group-1 is ldap group
> 
> [pbrezina ~]$ id
> uid=1000(pbrezina) gid=1000(pbrezina) groups=1000(pbrezina),10(wheel)
> context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> (sssd restart)
> [pbrezina ~]$ id pbrezina
> uid=1000(pbrezina) gid=1000(pbrezina)
> groups=1000(pbrezina),10(wheel),20001(group-1)
> (sssd restart)
> [pbrezina ~]$ su pbrezina
> [pbrezina ~]$ id
> uid=1000(pbrezina) gid=1000(pbrezina)
> groups=1000(pbrezina),10(wheel),20001(group-1)
> context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> 
> So when initgroups is re-run the group is present in the list.

But is sssd running and is sss before files in the nsswitch ?
Comment 15 Pavel Březina 2019-07-31 09:22:26 UTC 
Ok, I can reproduce it now. The implicit files domain must be enabled (or other files domain must be available).
Comment 16 Pavel Březina 2019-08-06 07:28:52 UTC 
I opened:
https://github.com/SSSD/sssd/pull/858

However, this fixes only the case when the nsswitch order is sss files but no files domain is available (e.g. enable_files_domain = false). Fixing it for the case when files domain is available will not be an easy task.

The reason why the group is not show with the files domain enabled is because the user is found in the files domain and therefore other domains are not searched. There is no simple hack that comes to my mind to workaround this but it can be fixes with group merging [1], but this is out of scope for 8.1.

Any ideas?

[1] https://pagure.io/SSSD/sssd/issue/3642
Comment 17 Jakub Hrozek 2019-08-06 08:21:03 UTC 
(In reply to Pavel Březina from comment #16)
> I opened:
> https://github.com/SSSD/sssd/pull/858
> 
> However, this fixes only the case when the nsswitch order is sss files but
> no files domain is available (e.g. enable_files_domain = false). Fixing it
> for the case when files domain is available will not be an easy task.
> 
> The reason why the group is not show with the files domain enabled is
> because the user is found in the files domain and therefore other domains
> are not searched. There is no simple hack that comes to my mind to
> workaround this but it can be fixes with group merging [1], but this is out
> of scope for 8.1.
> 
> Any ideas?
> 
> [1] https://pagure.io/SSSD/sssd/issue/3642

I think we would need either a files domain or global [sssd] domain option to merge the groups as you say. I agree a proper fix is out of scope for 8.1.

btw not to diminish your patch (thank you for working on the issue) but I would prefer if the patch didn't mark the issue as resolved until it is resolved also for the files domain case.
Comment 18 Pavel Březina 2019-08-06 09:52:13 UTC 
Ok, I switched 'resolves' to 'related to'.
Comment 19 Pavel Březina 2019-10-17 13:34:43 UTC 
First changes that solves the issue for disabled files provider landed to master:

* `master`
    * b32347d351259987c496a1be11a81ea19001451f - ldap: do not store empty attribute with ldap_rfc2307_fallback_to_local_users = true

Given this BZ has no customer case attache, I think we should resolve it with this patch and document it as known issue that it does not work when the files provider is enabled. Then open a new bugzilla for group merging feature (if there is not one already).
Comment 20 Michal Zidek 2019-10-18 14:23:38 UTC 
(In reply to Pavel Březina from comment #19)
> First changes that solves the issue for disabled files provider landed to
> master:
> 
> * `master`
>     * b32347d351259987c496a1be11a81ea19001451f - ldap: do not store empty
> attribute with ldap_rfc2307_fallback_to_local_users = true
> 
> Given this BZ has no customer case attache, I think we should resolve it
> with this patch and document it as known issue that it does not work when
> the files provider is enabled. Then open a new bugzilla for group merging
> feature (if there is not one already).

I agree. Changing state to POST.

We have upstream ticket for group merging: https://pagure.io/SSSD/sssd/issue/3642

Michal
Comment 21 Michal Zidek 2019-10-18 14:25:20 UTC 
Clearing needinfo flag.
Comment 23 shridhar 2020-01-08 06:14:39 UTC 
Tested with following version, results are still showing incorrect group membership.
[root@hpe-dl380pgen8-02-vm-8 ~]# rpm -q sssd
sssd-2.2.3-6.el8.x86_64

 ~]# cat /etc/sssd/sssd.conf 

[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP

[domain/LDAP]
debug_level = 0xFFF0
id_provider = ldap
ldap_uri = ldap://ipaqavma.idmqe.lab.eng.bos.redhat.com
ldap_search_base = dc=example,dc=com

ldap_rfc2307_fallback_to_local_users = True


~]# systemctl stop sssd ; rm -rf /var/lib/sss/db/* ; rm -rf /var/log/sssd/* ; systemctl start sssd

[root@hpe-dl380pgen8-02-vm-8 ~]# id local_user
uid=1001(local_user) gid=1001(local_user) groups=1001(local_user)

uploading logs
Comment 24 shridhar 2020-01-08 06:15:07 UTC 
Created attachment 1650591 [details]
logs
Comment 25 Pavel Březina 2020-01-08 11:08:49 UTC 
Shridhar, you need to explicitly disable the files domain ([sssd] enable_files_domain = false). The fix is lot more complicated when the files domain is enabled. I opened https://pagure.io/SSSD/sssd/issue/4134 to track it.
Comment 26 shridhar 2020-01-08 11:22:13 UTC 
Tested with following commands:
[root@ipaqavma ~]# rpm -q sssd
sssd-2.2.3-6.el8.x86_64
[root@ipaqavma ~]# 


With files domain disabled, group are returns correctly.
[root@ipaqavma ~]# cat /etc/sssd/sssd.conf 

[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP

[domain/LDAP]
debug_level = 0xFFF0
id_provider = ldap
ldap_uri = ldap://ipaqavmd.idmqe.lab.eng.bos.redhat.com
ldap_search_base = dc=example,dc=com

ldap_rfc2307_fallback_to_local_users = True
[root@ipaqavma ~]# vi /etc/sssd/sssd.conf 
[root@ipaqavma ~]# id local_user
uid=1001(local_user) gid=1001(local_user) groups=1001(local_user)
[root@ipaqavma ~]# cat /etc/sssd/sssd.conf 

[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP
enable_files_domain = False

[domain/LDAP]
debug_level = 0xFFF0
id_provider = ldap
ldap_uri = ldap://ipaqavmd.idmqe.lab.eng.bos.redhat.com
ldap_search_base = dc=example,dc=com

ldap_rfc2307_fallback_to_local_users = True
[root@ipaqavma ~]# systemctl stop sssd ; rm -rf /var/lib/sss/db/* ; rm -rf /var/log/sssd/* ; systemctl start sssd
[root@ipaqavma ~]# id local_user
uid=1001(local_user) gid=1001(local_user) groups=1001(local_user),201201(ldap_group)

with given work around of disabling files domain, ldap groups are returned correctly.
Marking bz verified.
Comment 29 David Voženílek 2020-01-30 10:00:05 UTC 
Could you please do a final check of the peer-reviewed version of the suggested DocText modification before I change it:


.SSSD returns incorrect LDAP group membership for local users when the `files` domain is enabled
 
If the System Security Services Daemon (SSSD) serves users from the local files and the `ldap_rfc2307_fallback_to_local_users` attribute in the [domain/LDAP] section of the `sssd.conf` file is set to True, then the files provider does not include group memberships from other domains. As a consequence, if a local user is a member of an LDAP group, the `id local_user` command does not return the user's LDAP group membership. To work around this problem, disable the implicit `files` domain by adding
 
[literal,subs="+quotes,attributes"]
----
enable_files_domain=False
----
 
to the `[sssd]` section in the `/etc/sssd/sssd.conf` file.
 
As a result, `id local_user` returns correct LDAP group membership for local users.



Thanks!
Comment 31 Pavel Březina 2020-01-30 12:06:01 UTC 
Ack.
Comment 34 errata-xmlrpc 2020-04-28 16:55:59 UTC 
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/RHBA-2020:1863
Note You need to log in before you can comment on or make changes to this bug.