On 06.01.2017 16:42, Ian Harding wrote:
On 01/05/2017 07:17 AM, Rob Crittenden wrote:
Timothy Geier wrote:
This is something I’ve looked at lately and a manual proof of concept I
just did makes it seem theoretically possible (...)
Why migrate at all?
Maybe I'm just not smart enough, but I suspect others have wished they
could just throw in the towel and start over.  I would if it were
relatively easy, that is, if I could export and reimport users (ideally
with passwords), hosts, groups, hbac rules, etc.  I woudln't even mind
having to re-enroll them.

There are some ways to migrate passwords between FreeIPA instances, but I would say that mine it's not for the faint-hearted. You absolutely MUST be faimiliar with LDAP and Kerberos. I had to change my realm name, as it was decided that "mine" IPA would replace few other user databases - here's what have worked for me (details omitted to prevent inexperienced from copy-paste disaster):

First, you have to prepare new FreeIPA instance. Start with single machine and ipa-server-install - "migration" would render all Kerberos keys in target instance unusable, so do not create any replicas, do not create any additional users and do not join any hosts. Then, extract Kerberos master key from old deployment and transfer it to new instance. It is stored in krbMKey attribute of K/M principal in Kerberos subtree of 389 DS instance used by IPA. Now the tricky part - you have to recreate principal keys for all LDAP entries with krbPrincipalKey. You can, for example, create completely random principals with kadmin.local and copy their krbPrincipalKeys to broken entries. You also have to re-export service keytabs - also using kadmin.local; there are 6 *.keytab files on IPA server with DNS and CA roles installed - host, 389 Directory Server, Dogtag, Apache, BIND and DNSSEC key sync daemon. After you've done that, restart all IPA services (`ipactl restart` or simply reboot whole machine).

Finally, copy all user entries from old IPA LDAP instance to your new deployment (make sure krbPrincipalName and krbCanonicalName match your new realm name) and all users would be able to authenticate using their existing passwords (using both Kerberos and simple LDAP bind). Now, you can create additional replicas and re-enroll existing hosts.

This is very tricky solution and definitely not a proper one. But hey, it works! No issues so far, but YMMV.

Other option could be to use (deprecated) -P/--master-password switch during FreeIPA installation - if you, by any chance, know previously generated master password (or you are able to recover it).

You can probably also try using `kdb5_util dump` with ` -mkey_convert` switch and then import data using `kdb5_util load`. I think this would be the best solution, as two previous make old and new instance share (master) key material - which seems security unwise, if you don't plan to trash old instance anyway. Unfortunately, I had troubles getting it to work, so I moved to a more "brute force" approach. :(

Best regards
Mateusz Małek

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to