For reference, putting this to bz, so other people can see it:

UPG are managed entries created by "managed entries plug-in". AFAIK they
are created only on ADD of users (here I'm not sure, but docs suggest
that [1])


migrate-ds doesn't handle UPGs well. More specifically it
unconditionally stops creation of UPGs during migration of users by
adding the NO_UPG_MAGIC constant into user's description attribute.

It doesn't reflect UPG settings(enablement of UPG definition). But from
the code it seems that there was some intention to do it which didn't
happen.


Workaround:
It might be possible to work around the issue by removing following lines from migrate-ds plugin code
(/usr/lib/python2.7/side-packages/ipalib/plugins/migration.py):
    # We don't want to create a UPG so set the magic value in description
    # to let the DS plugin know.
    entry_attrs.setdefault('description', [])
    entry_attrs['description'].append(NO_UPG_MAGIC)

but it needs to be tested first, see comment in the commit below. Also it assumes that uidnumber==gidnumber and both are migrated.

This was added in https://fedorahosted.org/freeipa/ticket/2562 commit
https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=b55c98f1c5b0d46aba3f1792ebd8ecc059173b6a


[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/managed-entries-attributes.html
[2]
https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA

Petr, removing those lines is only part of it.  You also need to be sure that no other users are members of the group before creating it as a private group (which can have no members). This needs to checked both via group membership and via the user primary group.

IIRC you are right, if the gid is different then I don't think it'll work using the managed entry plugin. That isn't to say it can't be faked by manually creating the group using pure ldap calls you're just getting close to no-man's land.

Actually the cloned upstream bug is not probably the right one for use case I was creating the workaround - IPA-IPA migration.

In migration from one IPA to another we are not changing POSIX groups into UPGs but rather we should not migrate UPGs and create new UPGs for users which had them(I assume that if GID==UID then there was an UPG)

I have a preliminary patch which does something like:

if upg_support_enambled and gid != uid
  prevent UPG create
else 
  let managed entry plugin create UPG

This works only if UIDs are migrated.

It also doesn't cover other use cases like forced creation of UPGs for all users or creation of UPG after migration.

There was also a question when ipa migrate-ds created a group which looked like:

ipa group-show lbar --all --raw
  dn: cn=lbar,cn=groups,cn=accounts,dc=example,dc=test
  cn: lbar
  description: User private group for lbar
  gidnumber: 903000004
  ipaUniqueID: 5ced9f72-7f5f-11e6-a667-001a4a2314d1
  mepManagedBy: uid=lbar,cn=users,cn=accounts,dc=example,dc=test
  objectClass: ipaobject
  objectClass: top
  objectClass: mepmanagedentry
  objectClass: ipausergroup
  objectClass: posixgroup
  objectClass: groupofnames
  objectClass: nestedgroup

This can happen when UPGs are not created by managed entry plugin and migration is done with options 
   --group-container=cn=groups,cn=accounts --group-objectclass=posixgroup

The reason is that UPG is a POSIX group(has posixgroup object class) and therefore is migrated but is normalized in a way that it gets also all the other object classes. It then presents itself incorrectly in Web UI, CLI...

To avoid it it is better to migrate with 
  --group-container=cn=groups,cn=accounts --group-objectclass=ipausergroup

Using ipausergroup will migrate also external groups but won't add additional object classed to UPGs.

Created attachment 1203005 [details]
freeipa-pvoborni-0966-migrate-ds-user-private-group-support-if-UIDs-are-mi.patch

Attaching a patch which does what I meant in comment 4 and comment 6

It will be later sent as upstream pull request.

I think there should probably be a separate option when doing IPA to IPA migration.

As for the patch, I don't think it's a safe assumption that the group is private just because the UID/GID match.

True, but if there is an overlap with other POSIX group then the other won't be migrated(will be reported) unless you pass --group-overwrite-gid which then changes it's GID (might not be wanted). 

The reason why it happens is that users are migrated first, UPGS are create at user creation and then migration of the other group will fail on "existing GID check".

Possible alternative solution might be to make it configurable via some option e.g.: --upg-mode={matching-ids,force-upgs,ńo-ups}

but I'd not like to over-engineer it.

As for comment 9 - special option for IPA-IPA migration - best to be solved in https://fedorahosted.org/freeipa/ticket/3656

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4738

The bugzilla doesn't have high enough priority in comparison to other IdM bugs/RFEs for 7.4. Moving to next release. Without sufficient justification it can be moved again later.

*** Bug 1476943 has been marked as a duplicate of this bug. ***