Bug 1652562 - local user's ldap group membership not returned correctly
Summary: local user's ldap group membership not returned correctly
Keywords:
Status: VERIFIED
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-01-30 12:33 UTC (History)
12 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:
Type: Bug
Target Upstream Version:


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

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.


Note You need to log in before you can comment on or make changes to this bug.