[Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds)

[Dmitri Pal]

On 03/16/2015 03:49 PM, Steven Jones wrote:
> Hi,
>
> Our present IPA started on RHEL6.2 (I think) and has a self-signed cert which  has the wrong encoding.   I am just replacing it now, its preventing RHEL7.1 joining/working/replicating.
>
> Now I am waiting on a BZ, so upgrading to RHEL7.1 isnt easy or quick.
>
> regards
>
> Steven
> ________________________________________
> From: freeipa-users-bounces at redhat.com <freeipa-users-bounces at redhat.com> on behalf of Benjamin Reed <ranger at opennms.org>
> Sent: Tuesday, 17 March 2015 8:01 a.m.
> To: freeipa-users at redhat.com
> Subject: [Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds)
>
> So given my RHEL6 machine started on an older FreeIPA 3.0, was a
> self-signed cert, and has gone through all kinds of hell and I'm having
> an impossible time setting up new master(s), I've decided to start over.
>
> I installed the EPEL7 FreeIPA 4.1.3 RPMs, in the hopes that being on the
> latest would give me the best chance at migrating.
>
> I did the following:
>
> --- 8< ---
> ipa-server-install
> ipa config-mod --enable-migration=true
> ipa-compat-manage disable
> service ipa restart # ipa-compat-manage wants a restart
> ipa migrate-ds \
>      --bind-dn=uid=admin,cn=users,cn=accounts,dc=XXX,dc=XXX \
>      --user-container=cn=users,cn=accounts \
>      --group-container=cn=groups,cn=accounts \
>      --group-overwrite-gid \
>      ldap://XXX:389
> ipa-compat-manage enable
> ipa-config-mod --enable-mogration=false
> service ipa restart
> --- 8< ---
>
> It all seems to have (kinda) worked, I can log in to the UI as admin and
> see all of my users and groups.  There are a couple of snags.
>
> 1. When the migration completed, it said:
>
>> Passwords have been migrated in pre-hashed format.
>> IPA is unable to generate Kerberos keys unless provided
>> with clear text passwords. All migrated users need to
>> login at https://your.domain/ipa/migration/ before they
>> can use their Kerberos accounts.
> If I try to actually do this as a regular user, the web UI just says:
>
>> The password or username you entered is incorrect. Please try again
>> (make sure your caps lock is off).
>> If the problem persists, contact your administrator.
> I'm not sure where to look in the logs to figure out what's going on,
> but nothing in the kerberos logs jump out at me.  The dirsrv log has these:


Do not turn the migration off using ipa-config-mod 
--enable-mogration=false until your users migrated their passwords.
The migration UI would not work if migration mode is turned off.

>
>> [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password
>> Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should
>> be added before the CoS Definition.
>> [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password
>> Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should
>> be added before the CoS Definition.
> ...which seems fishy.

This is something for the team to take a look at.
I can't say whether is an issue or a red herring.

>
> 2. If I manually reset my user's password in the UI and then try to log
> in as that user, it does work, but I'd like to avoid having to
> hand-reset every single user's account for obvious reasons.  When I *do*
> log in as my reset user, I always get this on the shell:
>
>> id: cannot find name for group ID 18600003

Did you clean the SSSD cache on the client?

> That gid is the `ipausers` GID from the old server.  It appears that
> modern FreeIPA doesn't assign a GID to `ipausers` which is fine, but I
> can't figure out how to *remove* the old GID from existing users and
> have everything be correct.  I've tried adding a group and forcing its
> GID to match the missing GID and deleting it again, but now it just
> seems to have cached it... when I do an `id` on my user, it still shows
> my user's GID as being 18600003(temp) even though the "temp" group has
> been removed.
>
> Any ideas how to do this migration properly?

You want to flush caches on the clients for thing to work properly after 
such migration.
These recommendations will get you further, let us know if you see any 
other issues.

>
> Thanks,
> Ben
>
> --
> Benjamin Reed
> The OpenNMS Group
> http://www.opennms.org/
>
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.