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.
DescriptionBrian J. Atkisson
2018-01-03 17:41:44 UTC
Description of problem:
ipa migrate-ds correctly imports groupofuniquenames objects into the IPA group structure and sets the member attribute correctly (rather than uniquemember), however, it leaves the groupofuniquenames objectClass present on the IPA LDAP object.
For example, the group in legacy LDAP looks like:
dn: cn=iso-access-rhev,ou=servicegroups,dc=example,dc=com
uniqueMember: uid=user1,ou=users,dc=example,dc=com
cn: iso-access-rhev
objectClass: groupOfUniqueNames
objectClass: top
The object created in IPA:
dn: cn=iso-access-rhev,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com
objectClass: ipaobject
objectClass: top
objectClass: groupofuniquenames
objectClass: ipausergroup
objectClass: groupofnames
objectClass: nestedgroup
member: uid=user1,cn=users,cn=accounts,dc=ipa,dc=example,dc=com
cn: iso-access-rhev
ipaUniqueID: ea8b635a-b2b2-11e7-a75f-001a4a0a0048
As you can see, migrate-ds converted the groupofuniquenames group to a groupofnames group and converted the uniqueMember attributes to member group. However, it left 'objectClass: groupofuniquenames' without being used.
If groupofuniquenames are not supported in IdM, then this objectclass should not be added during the migrate-ds import. If groupofuniquenames are supported, then the groupofuniquenames object should be imported into IPA as an actual groupofuniquenames object (with membership listed as uniqueMember: uid=user1,ou=users,dc=example,dc=com, rather than member: uid=user1,cn=users,cn=accounts,dc=ipa,dc=redhat,dc=com).
Version-Release number of selected component (if applicable):
ipa-server-common-4.5.0-21.el7_4.2.2.noarch
ipa-server-4.5.0-21.el7_4.2.2.x86_64
ipa-common-4.5.0-21.el7_4.2.2.noarch
ipa-server-dns-4.5.0-21.el7_4.2.2.noarch
ipa-client-4.5.0-21.el7_4.2.2.x86_64
ipa-client-common-4.5.0-21.el7_4.2.2.noarch
I think that using both these option would do the work. First should include it in search and second remove it from resulting LDAP entry.
--group-objectclass=STR
Objectclasses used to search for group entries in DS
--group-ignore-objectclass=STR
Objectclasses to be ignored for group entries in DS
Comment 3Florence Blanc-Renaud
2018-01-05 15:43:32 UTC
I tried and can confirm that if you specify
--group-ignore-objectclass=groupofuniquenames
the groupofuniquenames groups will be migrated to groupofnames objects, and the objectclass groupofuniquenames will be removed from the resulting entry.
This BZ has been evaluated multiple times over the last several years and we assessed that it is a valuable request to keep in the backlog and address it at some point in future. Time showed that we did not have such capacity, nor have it now nor will have in the foreseeable future. In such a situation keeping it in the backlog is misleading and setting the wrong expectation that we will be able to address it. Unfortunately we will not. To reflect this we are closing this BZ. If you disagree with the decision please reopen or open a new support case and create a new BZ. However this does not guarantee that the request will not be closed during the triage as we are currently applying much more rigor to what we actually can accomplish in the foreseeable future. Contributions and collaboration in the upstream community and CentOS Stream is always welcome!
Thank you for understanding
Red Hat Enterprise Linux Identity Management Team