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