[Freeipa-users] IPA to IPA migration

[Mateusz Małek]

Hi,

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