Rebuilding IPA environment

[John Bowman]

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.

[Rob Crittenden]

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 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.

Some of the data (HBAC, sudo perhaps a few others) can be migrated as an
LDIF (YMMV).

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.

rob

[Timothy Geier]

On Jun 20, 2017, at 10:48 AM, Rob Crittenden via FreeIPA-users <[e-mail]> 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 -- [e-mail]
To unsubscribe send an email to [e-mail]

—
Timothy R. Geier

Well now that sounds a daunting endeavor.  It would definitely be a last resort type situation for sure.  Thank you both for laying it out and I definitely didn't expect it to be possible at all so at least its something.

I think the big problem we're having is the fact that we can't seem to create new CA replicas against our old IPA 3.0 CA.  I've upgraded the servers to the latest and greatest multiple times over the last year (which caused its own set of problems which are in a different thread) and each time it fails with a different error.  I can generally find the same problem in a bugzilla but even after patching to the recommended version it still fails with a new error.

The latest being:

[14/Jun/2017:06:49:45][http-bio-8443-exec-3]: ConfigurationUtils: updateDomainXML: status=1
[14/Jun/2017:06:49:45][http-bio-8443-exec-3]: Unable to update security domain: 2
java.io.IOException: Unable to update security domain: 2