Bug 1652562 - local user's ldap group membership not returned correctly [NEEDINFO]
Summary: local user's ldap group membership not returned correctly
Keywords:
Status: ASSIGNED
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
Filip Hanzelka
URL:
Whiteboard:
Depends On: 1682305
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-22 11:27 UTC by shridhar
Modified: 2019-08-06 09:52 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
.SSSD returns incorrect LDAP group membership for local users If the System Security Services Daemon (SSSD) serves users from the local files, 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 the problem, either revert the order of the databases where the system is looking up the group membership of users in the `/etc/nsswitch.conf` file, replacing `sss files` with `files sss`, or 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
pbrezina: needinfo? (sssd-maint)


Attachments (Terms of Use)
logs and cache data (25.90 KB, application/x-gzip)
2018-11-22 11:29 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'.


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