Bug 822350
| Summary: | Passwords cannot be migrated | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Martin Kosek <mkosek> | ||||
| Component: | ipa | Assignee: | Martin Prpič <mprpic> | ||||
| Status: | CLOSED DEFERRED | QA Contact: | IDM QE LIST <seceng-idm-qe-list> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.3 | CC: | mkosek, ssorce | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: |
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.
|
Story Points: | --- | ||||
| Clone Of: | |||||||
| : | 822608 822612 (view as bug list) | Environment: | |||||
| Last Closed: | 2012-05-17 15:55:05 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 822608, 822612 | ||||||
| Attachments: |
|
||||||
|
Description
Martin Kosek
2012-05-17 06:40:51 UTC
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.
|