[Freeipa-users] Upgrade from FreeIPA 1.2 to 2.1 - getting tickets from upgraded server

[Rob Crittenden]

Dan Scott wrote:
> Hi,
>
> On Wed, Sep 21, 2011 at 16:28, Rob Crittenden<rcritten at redhat.com>  wrote:
>> Dan Scott wrote:
>>>
>>> Hi,
>>>
>>> I have a FreeIPA 1.2 realm running.
>>>
>>> I've installed a new server running 2.1 and migrated the user accounts
>>> across. I've installed a client and am trying to authenticate against
>>> the new server. I get the following errors:
>>>
>>> djscott at pc35:~$ kinit
>>> Password for djscott at EXAMPLE.COM:
>>> kinit: Preauthentication failed while getting initial credentials
>>> djscott at pc35:~$
>>>
>>> The server krb5kdc log contains the following:
>>>
>>> Sep 21 16:02:00 fileserver1.example.com krb5kdc[17795](info): AS_REQ
>>> (4 etypes {18 17 16 23}) 192.168.1.35: NEEDED_PREAUTH:
>>> djscott at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional
>>> pre-authentication required
>>> Sep 21 16:02:03 fileserver1.example.com krb5kdc[17795](info): preauth
>>> (timestamp) verify failure: No matching key in entry
>>> Sep 21 16:02:03 fileserver1.example.com krb5kdc[17795](info): AS_REQ
>>> (4 etypes {18 17 16 23}) 192.168.1.35: PREAUTH_FAILED:
>>> djscott at EXAMPLE.COM for krbtgtEXAMPLE.COM at EXAMPLE.COM,
>>> Preauthentication failed
>>>
>>> I've been to the page:
>>>
>>> https://fileserver1.example.com/ipa/migration/
>>>
>>> And tried to migrate my password, but I receive:
>>>
>>> "There was a problem with your request. Please, try again later. If
>>> the problem persists, contact your administrator."
>>>
>>> The same error occurs when I try to authenticate as myself on the
>>> server, although 'id djscott' returns the correct list of groups, so
>>> it appears that LDAP is working, but Kerberos is not. I guess it's
>>> something to do with the password migration?
>>>
>>> Anyone know how I can figure out what's going wrong?
>>>
>>> Thanks,
>>>
>>> Dan Scott
>>
>> It looks like the Apache error log is probably not going to have a ton of
>> information for you, but wouldn't hurt to check.
>>
>> I'd start with the 389-ds access log when doing a migration. You should see
>> the following sequence:
>>
>> - anonymous bind to search for the naming contexts. It looks like we use the
>> first one there which is bad (ticket
>> https://fedorahosted.org/freeipa/ticket/1834)
>> - it attempts a bind with dn uid=<login>,cn=users,cn=accounts,<naming
>> context>
>>
>> For some reason we convert the LDAP errors into IOErrors, not entirely sure
>> why but we should have beefed up logging in any case (ticket
>> https://fedorahosted.org/freeipa/ticket/1835)
>>
>> See what either or both of them is returning and that may provide the clues
>> we need to figure it out.
>>
>> If you still have migration mode enabled you can generate your credentials
>> with sssd by logging into the client normally. If migration mode is on then
>> sssd will initiate a kerberos password change for you.
>
> Well, I'm not entirely sure what the problem was, but SSHing to
> another server appears to have migrated the password successfully.
> It's working fine now.
>
> So I need to leave migration mode enabled until all users have
> migrated their passwords, correct? Is this all that migration mode
> does? Re-generate the Kerberos hashes?
>
> Thanks,
>
> Dan

Yes, migration mode enables you to authenticate with a stored LDAP 
password to generate missing Kerberos principal keys.

I assume that the other server has sssd configured so it performed the 
password migration.

rob