[Freeipa-users] Password migrating into IPA with SSSD failed

[David Copperfield]

Hi folks,

 Tried serveral times to do the password migration following documented steps at http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Migrating_from_a_Directory_Server_to_IPA.html#migr-kerb, and every time it failed. A solid example will be very helpful here, documented steps will be greatly appreciated.

The existing document states all the steps as listed below.

	1. A user tries to log into a machine with SSSD. 
	2. SSSD attempts to perform Kerberos authentication against the IPA server. 
	3. Even though the user exists in the system, the authentication will fail with the error key type is not supported because the Kerberos hashes do not yet exist. 
	4. SSSD the performs a plaintext LDAP bind over a secure connection. 
	5. IPA intercepts this bind request. If the user has a Kerberos 
principal but no Kerberos hashes, then the IPA identity provider 
generates the hashes and stores them in the user entry. 
	6. If authentication is successful, SSSD disconnects from IPA and 
tries Kerberos authentication again. This time, the request succeeds 
because the hash exists in the entry. 
The steps 4-6 are a little difficult to understand: Are these steps SSSD/IPA's internal information exchange mechanism? or do I have to setup something at IPA client/server side to fullfill? like setup pam_ldap or nslcd/nss_ldap?

I've mirgated all my users and groups from openLDAP into IPA without user password/hash ( another bug here: needs --group-objectclas='posixGroup' option, and optionally --schema='RFC2307'), the passwords were not migrated, and so I tried the above method to setup new passwords seamlessly for users, unfortunately all tries failed.

What I have done are listed bleow, any helps are greatly appreciated.

1, prepare IPA server for password migration:
    ipa config-mod --enable-migration=TRUE
2, On two IPA clients, ssh from one to another under an account with password already manually setup, and it proves working without password prompt (kinit/ssh works).

3, on the same two IPA clients, ssh from the same source node to destination node, but this time with a migrated user account without password, assumed it should asking for password and save the password hash into IPA master --- but it failed. The detailed error are attached below (users with password hash succeeded at step gssapi-keyex).

    

[root at ipaclient01 tmp]# ssh -x ipaclient02 -l guest -v
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
guest at ipaclient02's password: 

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
Permission denied, please try again.
guest at ipaclient02's password: 

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
Permission denied, please try again.
guest at ipaclient02's password: 

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
4, Please have a check and let me know if there are any steps missed at client side; and please let me know if any 
configs are need to verify. Thanks.

--David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120430/d0055a66/attachment.htm>