Hello Rob,
Quick feedback on the procedure you provided.
It worked for me. There was just a small issue for users belonging to the admin group
where ipa user-mod complained about not having enough write permissions on the ipaUniqueID
attribute.
By removing them temporarily from the admins group, I could modify them. So not a big
deal.
I didn't try modifying the migration script.
I hope this can help others in future?
Many thanks
--
Antoine Gatineau
Freelance IT Consultant
Tel: +32 499 50 80 04
On Sunday, August 7, 2022 11:49:50 PM CEST Rob Crittenden wrote:
Antoine Gatineau via FreeIPA-users wrote:
> Hello all.
>
> I am trying to migrate my users from one ipa to another one.
> I was able to import the users and groups with 'ipa migrate-ds'. However the
migration process generates new ipaUniqueIds.
>
> IPA is my source of users for keycloak user federation and other applications that
use ipaUniqueId to identify the user.
>
> When syncing from ipa, they now report a conflict as they should.
>
> So is it possible (and how) to manually set the ipaUniqueId to the value it had
originally?
>
> I have seen that ipa user-mod --setattr is now locked for this attribute :
https://bugzilla.redhat.com/show_bug.cgi?id=634194
>
> Thank you for any pointer to a solution.
It will take a few steps and I haven't tested this fully. To disable the
check in the above BZ you'd need to set ipaUuidEnforce to FALSE in
cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=config using ldapmodify.
No users currently have write access to ipaUniqueID so I'd create a
permission to grant write on that. Then create a privilege and role to
grant that to whoever you want. I'd give it to the admins group.
That should allow you to use the setattr option.
Once you're done setting things I'd remove the permission/privilege/role
and set ipaUuidEnforce back to TRUE.
An alternative if you're still experimenting with the migration would be
to modify /usr/lib/python*/ipaserver/plugins/migration.py and comment
out the two lines:
entry_attrs['ipauniqueid'] = 'autogenerate'
And restart httpd. I think that should retain the current values when
you re-run the migration (you'd have to either remove all the
users/groups or re-do the install).
rob