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

Tue Mar 17 11:33:03 UTC 2015

On 03/16/2015 08:01 PM, Benjamin Reed wrote:
> 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 \

Note that this Bind DN will not migrate passwords at all, as admin does not
have the privilege to *read* userPassword attribute by design. You need to
migrate using Directory Manager.

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

As Dmitri mentioned, this should not be done before password migration is over.

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

The problem here is that migrate-ds is designed to migrate users from general
LDAP, usually without Kerberos integration. However, you are migrating from
FreeIPA LDAP with full Kerberos support and the already generated Kerberos keys.

You thus need to do a small tweaking of migrate-ds options to filter
already-generated kerberos keys from the old FreeIPA instance and to also let
it migrate private user groups.

This is what I did to migrate users from my RHEL-6 test VM to FreeIPA 4.1.3:

# ipa config-mod --enable-migration=true

# echo Secret123 | ipa migrate-ds --bind-dn="cn=Directory Manager"
--user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts
--group-objectclass=posixgroup
--user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference}
--with-compat ldap://vm-086.rhel-6.test
-----------
migrate-ds:
-----------
Migrated:
  user: fbar, non-upg
  group: fbar
Failed user:
  admin: This entry already exists
Failed group:
  admins: This entry already exists. Check GID of the existing group. Use
--group-overwrite-gid option to overwrite the GID
  editors: This entry already exists. Check GID of the existing group. Use
--group-overwrite-gid option to overwrite the GID
  ipausers: This entry already exists. Check GID of the existing group. Use
--group-overwrite-gid option to overwrite the GID
----------
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.

This migrated both fbar and non-pug users, with fbar's UPG and with userPassword:

# ipa user-show fbar --all --raw
  dn: uid=fbar,cn=users,cn=accounts,dc=f21
  uid: fbar
  givenname: Foo
  sn: Bar
  cn: Foo Bar
  initials: FB
  homedirectory: /home/fbar
  gecos: Foo Bar
  loginshell: /bin/sh
  mail: fbar at idm.lab.bos.redhat.com
  uidnumber: 1873800001
  gidnumber: 1873800001
  nsaccountlock: FALSE
  has_password: TRUE
  has_keytab: FALSE
  displayName: Foo Bar
  ipaUniqueID: fa9a125e-cc92-11e4-9bbd-001a4a104e33
  krbPrincipalName: fbar at F21
  memberofindirect: cn=ipausers,cn=groups,cn=accounts,dc=f21
  mepManagedEntry: cn=fbar,cn=groups,cn=accounts,dc=f21
  objectClass: ipasshgroupofpubkeys
  objectClass: ipaobject
  objectClass: meporiginentry
  objectClass: organizationalperson
  objectClass: top
  objectClass: ipasshuser
  objectClass: inetorgperson
  objectClass: person
  objectClass: krbticketpolicyaux
  objectClass: krbprincipalaux
  objectClass: inetuser
  objectClass: posixaccount

I am now able to log in as fbar to the host and thus get the new Kerberos keys
generated/migrated:

# ssh fbar@`hostname`
fbar at ipa.f21's password:
Could not chdir to home directory /home/fbar: No such file or directory
-sh-4.3$ logout
Connection to ipa.f21 closed.

# ipa user-show fbar --all --raw
  dn: uid=fbar,cn=users,cn=accounts,dc=f21
...
  krbExtraData: AAJPDQhVZmJhckBGMjEA
  krbLastPwdChange: 20150317111735Z
  krbLastSuccessfulAuth: 20150317111735Z
  krbPasswordExpiration: 20150615111735Z
  krbPrincipalName: fbar at F21
...

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

As for the users without UPG, I think the best bet is to change your ipausers
to POSIX (user-mod --posix) and then change it's GID to the original one. Of
course, as Dmitri suggests, clearing SSSD cache should help too.

> Any ideas how to do this migration properly?

Please let me know if my advise helps. If yes, I think we should add it to
either migrate-ds command online help and/or migration instructions on FreeIPA
wiki.

BTW, please also note that I found a bug in FreeIPA 4.1.3 migrate-ds command
which hides the real reason why users/groups were not migrated. See

https://fedorahosted.org/freeipa/ticket/4952

Native IPA 4.1.* package in RHEL/CentOS 7.1 do not have this bug.