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.
DescriptionAndreas Schneider
2019-02-11 15:33:47 UTC
Description of problem:
When PAM is setup to authenticate Windows domain users with pam_winbind and Samba's winbindd is running, there is a bug that a user context is set up with a wrong gid.
Samba only gets a valid access token upon successful authentication from a Domain Controller. This access token has all group memberships which have been calculated by a DC. The access token is cached and once it is cache the system can work with correct information.
If an Active Directory domain user logs in via SSH the first time, the cache is empty.
openssh looks up the username using getpwnam(). It then stores the 'struct passwd' in the session structure.
If know the user is authenticated using PAM through pam_winbind we get the correct access token and cache it. However openssh doesn't update the passwd structure to have correct user information, but sets up the user context (setuid, setgid, initgroups) using the outdated information.
The openssh server should update the passwd structure using getpwuid() before it sets up the users context!
This issue was not selected to be included either in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small amount of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.
Comment 3Andreas Schneider
2019-02-11 16:10:28 UTC
Comment 14Andreas Schneider
2019-03-11 14:11:01 UTC
Andrej, by default a users primary group is "Domain Users". That you see the effect you need to change the primary of the user you're testing with a different group than "Domain Users". The issue is that the users default group is "Domain Users" ...
Comment 16Andreas Schneider
2019-03-12 13:41:19 UTC
This means that maybe the patch I created calls getpwuid() at the wrong location (or too late) in the code.
The call to getpwuid() is in the correct place, just before sshd calling the permanently_set_uid() and initgroups() in do_setusercontext(), which takes care of the changing of UID and GID. Can not this be cached somewhere deeper in nsswitch?
I would ask you to run the sshd in debug mode (-ddd switches or LogLevel DEBUG3 in sshd_config) and under strace (with -ff to get the traces for all the children processes) to verify what does it do? You will probably need to configure the sshd to disable sandboxing using "UsePrivilegeSeparation yes" in sshd_config.
Comment 18Andreas Schneider
2019-03-12 15:53:23 UTC
Either there is nscd running or there is a winbind cache. I would need winbind debug logs for that to check.
Comment 21Andreas Schneider
2019-04-23 16:03:54 UTC
winbindd_dual_ndrcmd: Running command WBINT_GETNSSINFO (no domain)
931 info: struct wbint_userinfo
932 domain_name : *
933 domain_name : 'ORPHANTRUST'
934 acct_name : *
935 acct_name : 'wrong_gid'
...
result : NT_STATUS_REQUEST_NOT_ACCEPTED
This is strange. Also the log.winbind seems to have the log from log.winbindd-idmap. I do not see incoming getpwnam() calls from NSS. I can try to reproduce it it with the ssh package tomorrow.
After taking openssh-7.9p1-updated-cached-pw.patch patch, it has side effect to following test. Problem noticed in F30 release. But can be seen also in F29.
1st. create two users with the same UID/GID. (adduser -o option).
2nd. Log in. Second user is authenticated correctly, but then bash is started as user 1.
Can be reproduced always.
I am dropping the patch also from Fedora now, before we will figure out some better way how to do that. I would not say that creating 2 users with the same uid would be something that we could support or recommend, but this patch was wrong breaking existing use cases badly.