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
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
