Bug 1837090
| Summary: | SSSD fails nss_getby_name for IPA user with SID if the user has user private group | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Alexander Bokovoy <abokovoy> |
| Component: | sssd | Assignee: | Sumit Bose <sbose> |
| Status: | CLOSED ERRATA | QA Contact: | Jakub Vavra <jvavra> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.3 | CC: | atikhono, dlavu, grajaiya, jhrozek, lslebodn, mzidek, pbrezina, sbose, tscherf |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | sync-to-jira | ||
| Fixed In Version: | sssd-2.5.1-1.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-11-09 19:46:34 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Alexander Bokovoy
2020-05-18 19:31:53 UTC
Hi Alexander, thanks for the report. The issue is that from the LDAP client perspective there are really 2 LDAP objects on the IPA side although by default the group object is a managed object and does not get a SID assigned. But in general, thanks to different name spaces for user and group names on the Unix side, it would be possible to create a user and a group with the same name, where uid and gid have the same value and both get a SID assigned, one from the secondary range: # ldapsearch -LLL -H ldapi://%2fvar%2frun%2fslapd-RHEL75-DEVEL.socket -b 'dc=rhel75,dc=devel' '(|(cn=some-user-x)(uid=some-user-x))' dn ipaNTSecurityIdentifier uidNumber gidNumber SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=some-user-x,cn=groups,cn=accounts,dc=rhel75,dc=devel ipaNTSecurityIdentifier: S-1-5-21-2570728348-66687643-3266097796-1030 gidNumber: 1999600030 dn: uid=some-user-x,cn=users,cn=accounts,dc=rhel75,dc=devel ipaNTSecurityIdentifier: S-1-5-21-2570728348-66687643-3266097796-100000030 uidNumber: 1999600030 gidNumber: 1999600030 So my suggestion would be that SSSD does some extra checks if there are multiple object with the same name. In the sidbyname case we can check if the found objects have a SID and if there is only one we return this. If there is a user and a group object with matching uid and gid and different SIDs it might be possible to return ID_BOTH as type but I'm not sure which of the 2 SIDs will cause less inconsistencies in this case? So I think it might be better to return ID_USER and the user's SID in this case. Do you agree? bye, Sumit I would suggest to use objectclass=mepManagedEntry to filter out these objects. Or, alternatively, do not filter them but if you found objectclass=mepManagedEntry in the group entry, assume user and group are ID_BOTH. There is no way in FreeIPA to have a MEP entry that would have automatically generated SID, I tried that before reporting this bug. (In reply to Alexander Bokovoy from comment #3) > I would suggest to use objectclass=mepManagedEntry to filter out these > objects. > > Or, alternatively, do not filter them but if you found > objectclass=mepManagedEntry in the group entry, assume user and group are > ID_BOTH. > > There is no way in FreeIPA to have a MEP entry that would have automatically > generated SID, I tried that before reporting this bug. Yes, this would be possible as well, but would only handle the default user-private-group case not the one where there are two distinct object with different SIDs but same names, UIDs and GIDs. Shall we treat this case as an error and return nothing? byem Sumit If you have two distinct objects with different SIDs but the same name, UIDs and GIDs, that would probably be a result of manual assignment of those values. In FreeIPA you would probably achieve this with ipa user-add foobar ipa group-detach foobar and then manually assign ipaNTSecurityIdentifier value to the group 'foobar' while at the same time adding ipaNTGroupAttrs objectclass. I would say that this is pretty much an artificial use case because this SID cannot be created automatically with sidgen plugin. [root@master ~]# ipa user-add auser First name: A Last name: User ------------------ Added user "auser" ------------------ User login: auser First name: A Last name: User Full name: A User Display name: A User Initials: AU Home directory: /home/auser GECOS: A User Login shell: /bin/sh Principal name: auser Principal alias: auser Email address: auser UID: 1908200012 GID: 1908200012 Password: False Member of groups: ipausers Kerberos keys available: False [root@master ~]# ipa group-detach auser ---------------------------------------- Detached group "auser" from user "auser" ---------------------------------------- [root@master ~]# ipa group-show --all --raw auser dn: cn=auser,cn=groups,cn=accounts,dc=ipa,dc=test cn: auser description: User private group for auser gidnumber: 1908200012 ipaUniqueID: 599e8b88-999b-11ea-84bd-fa163efaafc4 objectClass: posixgroup objectClass: ipaobject objectClass: top objectClass: nestedgroup objectClass: ipausergroup objectClass: groupofnames [root@master ~]# ipa user-show --all --raw auser dn: uid=auser,cn=users,cn=accounts,dc=ipa,dc=test uid: auser givenname: A sn: User cn: A User initials: AU homedirectory: /home/auser gecos: A User loginshell: /bin/sh krbcanonicalname: auser krbprincipalname: auser mail: auser uidnumber: 1908200012 gidnumber: 1908200012 nsaccountlock: FALSE has_password: FALSE has_keytab: FALSE displayName: A User ipaNTSecurityIdentifier: S-1-5-21-3787809381-104084847-3373960542-1012 ipaUniqueID: 599ae668-999b-11ea-84bd-fa163efaafc4 memberof: cn=ipausers,cn=groups,cn=accounts,dc=ipa,dc=test objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: ipantuserattrs [root@master ~]# ipa group-mod auser --addattr=objectclass=ipantgroupattrs --addattr=ipantsecurityidentifier=S-1-5-21-3787809381-104084847-3373960542-9999 ---------------------- Modified group "auser" ---------------------- Group name: auser Description: User private group for auser GID: 1908200012 [root@master ~]# ipa group-show --all --raw auser dn: cn=auser,cn=groups,cn=accounts,dc=ipa,dc=test cn: auser description: User private group for auser gidnumber: 1908200012 ipaNTSecurityIdentifier: S-1-5-21-3787809381-104084847-3373960542-9999 ipaUniqueID: 599e8b88-999b-11ea-84bd-fa163efaafc4 objectClass: posixgroup objectClass: ipaobject objectClass: top objectClass: nestedgroup objectClass: ipausergroup objectClass: groupofnames objectClass: ipantgroupattrs [root@master ~]# I'm not sure we should support this case. On the other hand, a case where a group was detached but SID was never added might make sense to map back to user's SID if GID == UID. Hi,
I was doing:
ipa group-add some-user-x
ipa user-add some-user-x --uid=$GID_OF_SOME_USER_X_GROUP --gidnumber=$GID_OF_SOME_USER_X_GROUP --noprivate
and got different SIDs for both. I wonder if similar setups can be found on systems which were migrated from an existing LDAP infrastructure to IPA?
bye,
Sumit
Yes, that is possible too. Well, then we need to support both... Upstream ticket: https://github.com/SSSD/sssd/issues/5607 Pushed PR: https://github.com/SSSD/sssd/pull/5608 * `master` * 9cb89666eae3ab2d4a93fb531fc29e433356391f - nss: fix getsidbyname for IPA user-private-groups 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 (sssd bug fix and enhancement update), 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-2021:4435 |