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