On Jun 20, 2017, at 10:48 AM, Rob Crittenden via FreeIPA-users
<freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>>
wrote:
John Bowman via FreeIPA-users wrote:
What would be the best method to stand up a new IPA environment while
keeping as much of the existing data as possible?
I've read that the ipa migrate-ds only migrates the users and groups and
the recommended suggestion is to set up a replica. I'd like to sever
any ties to the existing environment but not have to start over
completely from scratch if at all possible. Ideally I would be able to
just point existing services to the new environment and hopefully
minimize impact, I'm sure I'd still have plenty of manual changes as
well, but one can dream.
Basically I'm just running in to too many issues with trying to expand
our existing environment some of which is related to having a mix of IPA
3.0 and 4.x I believe and likely some old and recent missteps that make
me question the stability of our environment.
Any tips/advice would be appreciated.
It is possible (I recently successfully completed such a migration) but will likely
require
extensive testing and a through plan for exactly how to execute the cutover and being
able
to rollback if needed. This should only be used as a last resort.
It wouldn't be as easy as re-pointing. There is no supported way to
migrate the Kerberos master key and without that you'd need all users to
change passwords, all clients would need to re-enroll and any Kerberized
services would need new keytabs.
In our case, migrate-ds worked to keep the passwords intact as the user-private issue
mentioned below wasn’t a concern. The user account expiration dates needed to be
saved and reset, though, or there would have been a stampede of expirations in
$password_age days.
Keytabs did have to be generated and replaced everywhere, though we came up with
an ansible playbook that backed up the old host keytabs and CA files, installed the new
ones, and restarted sssd so that kerberos logins/sudo/etc. would work.
A significant issue we ran into was the presence of fast_ccache files in /var/lib/sss/db
that
caused major inconsistencies with this procedure; after adding a line to remove them, it
was
a 100% success rate. HTTP and other keytabs/certs will also need to be replaced/daemons
bounced/etc. (Remember to update the CA file as well wherever there are any instances
of the old one.)
Some of the data (HBAC, sudo perhaps a few others) can be migrated as an
LDIF (YMMV).
We were able to migrate everything other than users/passwords using LDIF in this order:
groups
dns (This took a while as it required several ipactl restarts and reattempts.)
hosts
hostgroups (This and cn=ng,cn=alt required running ipa-managed-entries disable -e
"NGP Definition” to import)
Anything under cn=ng,cn=alt (After the import, run ipa-managed-entries enable -e "NGP
Definition”)
sudo
hbac
pwpolicy
kerberos
pbac
automember
And then anything under cn=sysaccounts,cn=etc, using the Directory Manager credentials to
get the password hashes.
There’s probably an optimal order, but this worked for us. ldapadd -D "cn=Directory
Manager" -f foo.ldif -c -W was used to
perform the imports.
Another thing to watch for is redundant defaults; HBAC doesn’t need two allow_all rules,
for
instance. If there any replicas, it also helps a lot to remove all references to them
from the
LDIFs before importing so they can then be recreated cleanly.
And if there aren’t already replica CAs, make them. When the docs say Red Hat strongly
recommends it, they aren’t kidding.
One problem with migrate-ds now is that makes existing user-private
groups into regular groups. This is undesirable for some.
You may be able to pick a master (or install a new one) with a CA and
break it off from the pack by breaking the replication agreements to
make it standalone. That could be the starting point. This also has some
risks and some things to clean up (like DNA ranges) but may be a cleaner
way of doing things.
I recommend starting with something like this..I can’t stress enough that the
complete rebuild is a last resort. It did work and is currently going quite well
but it was a significant undertaking in terms of time and effort.
rob
_______________________________________________
FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org<mailto:freeipa-users-leave@lists.fedorahosted.org>
—
Timothy R. Geier