Description of problem: When user is migrated from a remote LDAP, he needs to migrate his password in IPA hosted page in https://IPA.DOMAIN/ipa/migration/. However, when I migrated the user and then his password on the page, I could not kinit as that user because IPA kept rejecting the new password. When I tried the same password change with password reset by admin, it worked: # ipa migrate-ds ldap://vm-074.idm.lab.bos.redhat.com --with-compat --schema RFC2307 --user-container ou=People --group-container ou=users,ou=Groups Password: ----------- migrate-ds: ----------- Migrated: user: tu, tu1, tu2, tu3 group: tu, tu1, tu2, tu3 Failed user: Failed group: ---------- 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. >>> Now, "tu" password was migrated on given page # kinit tu Password for tu.BOS.REDHAT.COM: Password expired. You must change it now. Enter new password: Enter it again: Password change rejected. Please try again. Enter new password: Enter it again: Password change rejected. Please try again. Enter new password: kinit: Password read interrupted while getting initial credentials # kinit admin Password for admin.BOS.REDHAT.COM: # ipa passwd tu New Password: Enter New Password again to verify: ------------------------------------------------ Changed password for "tu.BOS.REDHAT.COM" ------------------------------------------------ # kinit tu Password for tu.BOS.REDHAT.COM: Password expired. You must change it now. Enter new password: Enter it again: >>> Password change succeeded krb5kdc log: ... May 17 02:26:53 vm-034.idm.lab.bos.redhat.com krb5kdc[4738](info): AS_REQ (4 etypes {18 17 16 23}) 10.16.78.34: CLIENT KEY EXPIRED: tu.BOS.REDHAT.COM for krbtgt/IDM.LAB.BOS.REDHAT.COM.BOS.REDHAT.COM, Password has expired May 17 02:26:53 vm-034.idm.lab.bos.redhat.com krb5kdc[4738](info): AS_REQ (4 etypes {18 17 16 23}) 10.16.78.34: NEEDED_PREAUTH: tu.BOS.REDHAT.COM for kadmin/changepw.BOS.REDHAT.COM, Additional pre-authentication required May 17 02:26:56 vm-034.idm.lab.bos.redhat.com krb5kdc[4738](info): AS_REQ (4 etypes {18 17 16 23}) 10.16.78.34: ISSUE: authtime 1337236016, etypes {rep=18 tkt=18 ses=18}, tu.BOS.REDHAT.COM for kadmin/changepw.BOS.REDHAT.COM May 17 02:27:44 vm-034.idm.lab.bos.redhat.com krb5kdc[4738](info): AS_REQ (4 etypes {18 17 16 23}) 10.16.78.34: NEEDED_PREAUTH: admin.BOS.REDHAT.COM for krbtgt/IDM.LAB.BOS.REDHAT.COM.BOS.REDHAT.COM, Additional pre-authentication required May 17 02:27:45 vm-034.idm.lab.bos.redhat.com krb5kdc[4738](info): AS_REQ (4 etypes {18 17 16 23}) 10.16.78.34: ISSUE: authtime 1337236065, etypes {rep=18 tkt=18 ses=18}, admin.BOS.REDHAT.COM for krbtgt/IDM.LAB.BOS.REDHAT.COM.BOS.REDHAT.COM May 17 02:29:08 vm-034.idm.lab.bos.redhat.com krb5kdc[4738](info): TGS_REQ (4 etypes {18 17 16 23}) 10.16.78.34: ISSUE: authtime 1337236065, etypes {rep=18 tkt=18 ses=18}, admin.BOS.REDHAT.COM for HTTP/vm-034.idm.lab.bos.redhat.com.BOS.REDHAT.COM May 17 02:29:08 vm-034.idm.lab.bos.redhat.com krb5kdc[4738](info): TGS_REQ (4 etypes {18 17 16 23}) 10.16.78.34: ISSUE: authtime 1337236065, etypes {rep=18 tkt=18 ses=18}, HTTP/vm-034.idm.lab.bos.redhat.com.BOS.REDHAT.COM for ldap/vm-034.idm.lab.bos.redhat.com.BOS.REDHAT.COM May 17 02:29:08 vm-034.idm.lab.bos.redhat.com krb5kdc[4738](info): ... CONSTRAINED-DELEGATION s4u-client=admin.BOS.REDHAT.COM May 17 02:29:19 vm-034.idm.lab.bos.redhat.com krb5kdc[4738](info): AS_REQ (4 etypes {18 17 16 23}) 10.16.78.34: CLIENT KEY EXPIRED: tu.BOS.REDHAT.COM for krbtgt/IDM.LAB.BOS.REDHAT.COM.BOS.REDHAT.COM, Password has expired May 17 02:29:19 vm-034.idm.lab.bos.redhat.com krb5kdc[4738](info): AS_REQ (4 etypes {18 17 16 23}) 10.16.78.34: NEEDED_PREAUTH: tu.BOS.REDHAT.COM for kadmin/changepw.BOS.REDHAT.COM, Additional pre-authentication required May 17 02:29:21 vm-034.idm.lab.bos.redhat.com krb5kdc[4738](info): AS_REQ (4 etypes {18 17 16 23}) 10.16.78.34: ISSUE: authtime 1337236161, etypes {rep=18 tkt=18 ses=18}, tu.BOS.REDHAT.COM for kadmin/changepw.BOS.REDHAT.COM May 17 02:29:27 vm-034.idm.lab.bos.redhat.com krb5kdc[4738](info): AS_REQ (4 etypes {18 17 16 23}) 10.16.78.34: NEEDED_PREAUTH: tu.BOS.REDHAT.COM for krbtgt/IDM.LAB.BOS.REDHAT.COM.BOS.REDHAT.COM, Additional pre-authentication required May 17 02:29:27 vm-034.idm.lab.bos.redhat.com krb5kdc[4738](info): AS_REQ (4 etypes {18 17 16 23}) 10.16.78.34: ISSUE: authtime 1337236167, etypes {rep=18 tkt=18 ses=18}, tu.BOS.REDHAT.COM for krbtgt/IDM.LAB.BOS.REDHAT.COM.BOS.REDHAT.COM Version-Release number of selected component (if applicable): ipa-server-2.2.0-13.el6.x86_64 How reproducible: Steps to Reproduce: 1. Install IPA server 2. Enable migration and migrate users from remote LDAP 3. Migrate user password on https://$IPAHOSTNAME/ipa/migration/ 4. Try to kinit as user Actual results: Password change is prompted, but password is rejected Expected results: Password change is prompted, new password is accepted
Can you post the kadmind.log it should say why the password change was rejected.
It says: May 17 09:10:43 vm-034.idm.lab.bos.redhat.com kadmind[15003](Notice): chpw request from 10.16.78.34 for tu2.BOS.REDHAT.COM: Database record is incomplete or corrupted
And this is the record in LDAP (after password migration): dn: uid=tu2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com cn: Test User2 objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: organizationalperson objectClass: top objectClass: ipasshuser objectClass: inetorgperson objectClass: person objectClass: inetuser objectClass: krbprincipalaux objectClass: posixaccount objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: 11102 gidNumber: 11102 gecos: Test User2 sn: User homeDirectory: /home/tu2 uid: tu2 krbPrincipalName: tu2.BOS.REDHAT.COM userPassword:: e1NTSEF9UXpRVWtubDRXNmJtcGRFTThkMlI1blpPZ0ZvZElQV1ltQjlYVlE9PQ= = ipaUniqueID: f8260958-9fe8-11e1-ba99-00163e7c2cdf memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= com memberOf: cn=tu2,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com krbPrincipalKey:: MIIBnKADAgEBoQMCAQGiAwIBAaMDAgEBpIIBhDCCAYAwaKAbMBmgAwIBBKES BBBodlRXNDY+ZjdNVTtKKnh0oUkwR6ADAgESoUAEPiAAgP2+l8E9oj0bJw0lDy3hcPKEG83TVtvD/ roqjF0e5Y83QJ7nCBnlLTBpr03zBewzDhENEDeRPbPMku8kMFigGzAZoAMCAQShEgQQX2ZgIC1Bb1 lMYFFTNlhaOKE5MDegAwIBEaEwBC4QAJWCgqYXFs+xNZOIiEAFUGsScliOtDn7EcQnD+ycMhZ/dUJ sSKuiApQXAZ0VMGCgGzAZoAMCAQShEgQQX0RAOS9kWHZ8bzZQe10+T6FBMD+gAwIBEKE4BDYYALze CJE25i7EFq9pcjcFOD5UR8grzOeOPVTPVtZsV7bZhIYLZOdkhv4C1ppqyn/lQtw2WYcwWKAbMBmgA wIBBKESBBB3SmlRMHJYJUZDQXtyZWovoTkwN6ADAgEXoTAELhAA6Rh8pL80wW0HQuXPc7mESlZmZx RTVWF0YD1J77HqFPdAhrEE32wmfP+ke1A= krbLastPwdChange: 20120517130930Z krbPasswordExpiration: 20120517130930Z krbLastSuccessfulAuth: 20120517131034Z
The krbPrincipalKey is there so it should be ok. For some reason though it seem kadmin is not liking it, yet it likes it when you do an ipa passwd change that uses exactly the same routines to set the password. I wonder if kadmin is complaining about the missing krbExtraData. Can you manually copy the krbExtraData attribute from a working user to this entry and see if after that kadmin is happy ?
It worked! I copied krbExtraData from other user that was added with user-add: # cat extradata.ldif dn: uid=tu2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com changetype: modify add: krbExtraData krbExtraData:: AAJA07RPa2FkbWluZEBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA== # ldapmodify -h localhost -D "cn=Directory Manager" -w kokos123 -x -f extradata.ldif modifying entry "uid=tu2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" # ldapsearch -h localhost -D "cn=Directory manager" -x -W -b "uid=tu2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" # tu2, users, accounts, idm.lab.bos.redhat.com dn: uid=tu2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com cn: Test User2 objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: organizationalperson objectClass: top objectClass: ipasshuser objectClass: inetorgperson objectClass: person objectClass: inetuser objectClass: krbprincipalaux objectClass: posixaccount objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: 11102 gidNumber: 11102 gecos: Test User2 sn: User homeDirectory: /home/tu2 uid: tu2 krbPrincipalName: tu2.BOS.REDHAT.COM userPassword:: e1NTSEF9UXpRVWtubDRXNmJtcGRFTThkMlI1blpPZ0ZvZElQV1ltQjlYVlE9PQ= = ipaUniqueID: f8260958-9fe8-11e1-ba99-00163e7c2cdf memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= com memberOf: cn=tu2,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com krbPrincipalKey:: MIIBnKADAgEBoQMCAQGiAwIBAaMDAgEBpIIBhDCCAYAwaKAbMBmgAwIBBKES BBBodlRXNDY+ZjdNVTtKKnh0oUkwR6ADAgESoUAEPiAAgP2+l8E9oj0bJw0lDy3hcPKEG83TVtvD/ roqjF0e5Y83QJ7nCBnlLTBpr03zBewzDhENEDeRPbPMku8kMFigGzAZoAMCAQShEgQQX2ZgIC1Bb1 lMYFFTNlhaOKE5MDegAwIBEaEwBC4QAJWCgqYXFs+xNZOIiEAFUGsScliOtDn7EcQnD+ycMhZ/dUJ sSKuiApQXAZ0VMGCgGzAZoAMCAQShEgQQX0RAOS9kWHZ8bzZQe10+T6FBMD+gAwIBEKE4BDYYALze CJE25i7EFq9pcjcFOD5UR8grzOeOPVTPVtZsV7bZhIYLZOdkhv4C1ppqyn/lQtw2WYcwWKAbMBmgA wIBBKESBBB3SmlRMHJYJUZDQXtyZWovoTkwN6ADAgEXoTAELhAA6Rh8pL80wW0HQuXPc7mESlZmZx RTVWF0YD1J77HqFPdAhrEE32wmfP+ke1A= krbLastPwdChange: 20120517130930Z krbPasswordExpiration: 20120517130930Z krbLastSuccessfulAuth: 20120517131034Z krbExtraData:: AAJA07RPa2FkbWluZEBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA== # kinit tu2 Password for tu2.BOS.REDHAT.COM: Password expired. You must change it now. Enter new password: Enter it again: # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: tu2.BOS.REDHAT.COM Valid starting Expires Service principal 05/17/12 09:50:21 05/18/12 09:50:21 krbtgt/IDM.LAB.BOS.REDHAT.COM.BOS.REDHAT.COM
Upstream ticket: https://fedorahosted.org/freeipa/ticket/2764
Created attachment 585245 [details] Fix for the failure to change the password The attached password should fix the kadmin error, and allow it to successfully complete the password change.
I verified that the patch fixes the error, thanks simo.
Fixed upstream: master: https://fedorahosted.org/freeipa/changeset/46c6ff69ac2a4fa39e99f954bd9cfbd78bfd70c9 ipa-2-2: https://fedorahosted.org/freeipa/changeset/f883b2547d887eac7976d0372f5b25d48a1b3a4d
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: When user is migrated from remote LDAP, his entry in Directory Server does not contain Kerberos credentials needed for Kerberos log in. When user visits password migration page, Kerberos credentials are generated for the user and can log in via Kerberos authentication. However, IPA did not generate the credentials right when the migrated password did not follow password policy set on the IPA server. Consequence: When the password migration was done and user tried to log in via Kerberos authentication, he was prompted to change his password as it did not follow the password policy, but the password change was never successful and user was not able to use Kerberos authentication. Workaround: Admin can reset the password for migrated user with "ipa passwd" command. Result: User Kerberos credentials in the Directory Server are properly generated and user is able to log in to Kerberos authentication system.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,4 +1 @@ -Cause: When user is migrated from remote LDAP, his entry in Directory Server does not contain Kerberos credentials needed for Kerberos log in. When user visits password migration page, Kerberos credentials are generated for the user and can log in via Kerberos authentication. However, IPA did not generate the credentials right when the migrated password did not follow password policy set on the IPA server. +When a user is migrated from a remote LDAP, the user's entry in the Directory Server does not contain Kerberos credentials needed for a Kerberos login. When the user visits the password migration page, Kerberos credentials are generated for the user and logging in via Kerberos authentication works as expected. However, Identity Management does not generate the credentials correctly when the migrated password does not follow the password policy set on the IPA server. Consequently, when the password migration is done and a user tries to log in via Kerberos authentication, the user is prompted to change the password as it does not follow the password policy, but the password change is never successful and the user is not able to use Kerberos authentication. To work around this issue, an administrator can reset the password of a migrated user with the ipa passwd command. When reset, user's Kerberos credentials in the Directory Server are properly generated and the user is able to log in using Kerberos authentication.-Consequence: When the password migration was done and user tried to log in via Kerberos authentication, he was prompted to change his password as it did not follow the password policy, but the password change was never successful and user was not able to use Kerberos authentication. -Workaround: Admin can reset the password for migrated user with "ipa passwd" command. -Result: User Kerberos credentials in the Directory Server are properly generated and user is able to log in to Kerberos authentication system.