Learn more about these different git repos.
Other Git URLs
When listing user that has no groups with 'id' command on client computer: 'no such user' is returned.
$ id r00a030 id: r00a030: no such user
After 15 seconds (after sssd negative cache timeout expires) 'id' command for same user correctly lists this user with its primary group.
$ id r00a030 uid=18648(r00a030) gid=200(users) groups=200(users)
sssd-1.10.0-19.el7_5.5.x86_64
This seems to be an issue with sss_nss_getgrouplist_timeout function in src/sss_client/idmap/sss_nss_ex.c.
Actually the inconsistency originates in sss_get_ex function.
The first request is not found in cache so gets handled by sss_nss_make_request_timeout function. This returns with NSS_STATUS_SUCCESS but since num_results will be 0 sss_get_ex will return with ENOENT.
The subsequent request is in cache and is returned by sss_nss_mc_get and the return value is 0.
With the first request sss_nss_getgrouplist_timeout will return immediately with ENOENT. ngroup and group input parameters are not touched.
Subsequent times (due to good return value) sss_nss_getgrouplist will populate input parameters ngroup and group. These will only contain the primary gid number of the user as there are no other groups.
Would it be a good idea to make sss_nss_getgrouplist handle the ENOENT return value from sss_get_ex in a non-destructive way (ignore it) ?
Breakpoint 2, sss_get_ex (inp=inp@entry=0x7fffffffe1e0, flags=flags@entry=0, timeout=timeout@entry=6316112) at src/sss_client/idmap/sss_nss_ex.c:170 170 { (gdb) si check_flags (skip_data=<synthetic pointer>, skip_mc=<synthetic pointer>, flags=<optimized out>, inp=<optimized out>) at src/sss_client/idmap/sss_nss_ex.c:116 116 && (flags & SSS_NSS_EX_FLAG_INVALIDATE_CACHE) != 0) { (gdb) n sss_get_ex (inp=inp@entry=0x7fffffffe1e0, flags=flags@entry=0, timeout=timeout@entry=6316112) at src/sss_client/idmap/sss_nss_ex.c:170 170 { (gdb) 184 ret = check_flags(inp, flags, &skip_mc, &skip_data); (gdb) 171 uint8_t *repbuf = NULL; (gdb) 184 ret = check_flags(inp, flags, &skip_mc, &skip_data); (gdb) 189 if (!skip_mc && !skip_data) { (gdb) 190 ret = sss_nss_mc_get(inp); (gdb) 193 return 0; (gdb) 191 switch (ret) { (gdb) 195 return ERANGE; (gdb) 191 switch (ret) { (gdb) 207 ret = sss_nss_timedlock(timeout, &time_left); (gdb) 208 if (ret != 0) { (gdb) 214 ret = sss_nss_mc_get(inp); (gdb) 215 switch (ret) { (gdb) 214 ret = sss_nss_mc_get(inp); (gdb) 215 switch (ret) { (gdb) 233 ret = sss_nss_make_request_timeout(inp->cmd, &inp->rd, time_left, (gdb) 235 if (ret != NSS_STATUS_SUCCESS) { (gdb) 241 SAFEALIGN_COPY_UINT32(&num_results, repbuf, NULL); (gdb) 244 if (num_results == 0) { (gdb) 245 ret = ENOENT; (gdb) 318 free(repbuf); (gdb) 320 sss_nss_unlock(); (gdb) 321 return ret; (gdb) 322 }
Breakpoint 2, sss_get_ex (inp=inp@entry=0x7fffffffe1e0, flags=flags@entry=0, timeout=timeout@entry=6316112) at src/sss_client/idmap/sss_nss_ex.c:170 170 { (gdb) si check_flags (skip_data=<synthetic pointer>, skip_mc=<synthetic pointer>, flags=<optimized out>, inp=<optimized out>) at src/sss_client/idmap/sss_nss_ex.c:116 116 && (flags & SSS_NSS_EX_FLAG_INVALIDATE_CACHE) != 0) { (gdb) n sss_get_ex (inp=inp@entry=0x7fffffffe1e0, flags=flags@entry=0, timeout=timeout@entry=6316112) at src/sss_client/idmap/sss_nss_ex.c:170 170 { (gdb) 184 ret = check_flags(inp, flags, &skip_mc, &skip_data); (gdb) 171 uint8_t *repbuf = NULL; (gdb) 184 ret = check_flags(inp, flags, &skip_mc, &skip_data); (gdb) 189 if (!skip_mc && !skip_data) { (gdb) 190 ret = sss_nss_mc_get(inp); (gdb) 193 return 0; (gdb) 191 switch (ret) { (gdb) 322 }
Is users a local group (in /etc/group) ?
This is an AD user with posix attributes in AD: uidNumber: 18648 gidNumeer: 200 loginShell: /bin/bash etc.
This user is not referenced anywhere else. Not in local files and also not in any mappings on freeIPA server. It is also not in any group with posix attributes defined in AD.
Group with gid 200 is actually defined in freeIPA server.
I have similar users that are actually in some AD group with posix attributes and there is no issue with those. This only affects users that are not in any group.
I will try to reproduce this but I think you are right the ENOENT should not be returned to the caller in the case.
Btw, in general SSSD will return the primary group here even if there are no secondary groups. But only if the primary group is defined in the same domain. So I would expect that if you remove the gid 200 group from the IPA domain and defined a group in AD with gid 200 (or use an AD group with a different gid and change the primary group of the user to this gid) you would no see this inconsistency.
I tried to do that: "configure AD group with right gid" when we set this up. This did not work. Users primary group was not resolved by client computers at all. So I gave a short posix range from 200 to freeipa and set gid 200 there.That was a while back though so I'm not sure if that behaviour has changed by now or not.
Still... this seems to be the recommended setup from Red Hat: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/trust-managing
"If the Windows administrator manually defines POSIX UID and GID attributes for a user, create a matching group on the IdM server with the same GID for the user. Creating the group ensures that the user is associated with a primary user group. If such group does not exist, the IdM server is unable to look up all groups to which the user belongs."
Thank you for the pointer to the documentation. I think this is a typo and it should be '... create a matching group on the AD server with the same GID ...'. Since AD and IdM might handled by different administrators it is in general better to keep everything in one administrative domain. @abbra, do you agree that the documentation should be changed as I mentioned above?
Yes, I agree with @sbose's view on it. It is better to keep everything in the same administrative domain. This also would be consistent with Samba way of handling primary groups and wouldn't create surprises at an application level.
Metadata Update from @pbrezina: - Issue tagged with: Canditate to close
Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfill this request I am closing the issue as wontfix.
If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.
Thank you for understanding.
Metadata Update from @pbrezina: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/4900
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.