Hide Forgot
+++ This bug was initially created as a clone of Bug #676526 +++ Description of problem: I have freeipa server and client installed. Users on client computers are supposed to login with GDM, even first time, when account just created. But changing password in gdm doesn't work and fails with 'authentication token manipulation error'. I try to change password for existing user using command passwd and it also failed with the same error, kpasswd works fine. Some messages from log fileunsuccesful attempt to change password: console output from passwd command: -sh-4.1$ passwd Changing password for user dimaktt. Kerberos 5 Password: Warning: Your password will expire in less than one hour. New password: Retype new password: passwd: Authentication token manipulation error /var/log/secure: Feb 10 08:54:19 dguryanov-laptop passwd: pam_unix(passwd:chauthtok): user "dimaktt" does not exist in /etc/passwd Feb 10 08:54:31 dguryanov-laptop passwd: pam_unix(passwd:chauthtok): user "dimaktt" does not exist in /etc/passwd Feb 10 08:54:31 dguryanov-laptop passwd: pam_krb5[29752]: password change failed for dimaktt.RU: Cannot contact any KDC for requested realm Feb 10 08:54:31 dguryanov-laptop passwd: gkr-pam: couldn't change password for the login keyring. /var/log/audit/audit.log: type=USER_CHAUTHTOK msg=audit(1297317274.044:690): user pid=29752 uid=1100 auid=500 ses=1 msg='op=PAM:chauthtok acct="dimaktt" exe="/usr/bin/passwd" hostname=? addr=? terminal=pts/14 res=failed' type=USER_CHAUTHTOK msg=audit(1297317274.044:691): user pid=29752 uid=1100 auid=500 ses=1 msg='op=change password id=1100 exe="/usr/bin/passwd" hostname=? addr=? terminal=pts/14 res=failed' /var/log/dirsrv/slapd-SERVER000-SW-RU/access: ..... [10/Feb/2011:08:54:25 +0300] conn=6 op=351 RESULT err=0 tag=101 nentries=1 etime=0 [10/Feb/2011:08:54:25 +0300] conn=6 op=352 SRCH base="dc=server000,dc=sw,dc=ru" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=kadmin/changepw.RU))" attrs="krbPrincipalName krbcanonicalname objectClass krbPrincipalKey krbMaxRenewableAge krbMaxTicketLife krbTicketFlags krbPrincipalExpiration krbTicketPolicyReference krbUPEnabled krbPwdPolicyReference krbPasswordExpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth nsAccountLock krbLastPwdChange krbExtraData krbObjectReferences krballowedtodelegateto" [10/Feb/2011:08:54:25 +0300] conn=6 op=352 RESULT err=0 tag=101 nentries=1 etime=0 [10/Feb/2011:08:54:25 +0300] conn=6 op=353 SRCH base="uid=dimaktt,cn=users,cn=accounts,dc=server000,dc=sw,dc=ru" scope=0 filter="(objectClass=*)" attrs="objectClass" [10/Feb/2011:08:54:25 +0300] conn=6 op=353 RESULT err=0 tag=101 nentries=1 etime=0 [10/Feb/2011:08:54:25 +0300] conn=6 op=354 MOD dn="uid=dimaktt,cn=users,cn=accounts,dc=server000,dc=sw,dc=ru" [10/Feb/2011:08:54:25 +0300] conn=6 op=354 RESULT err=50 tag=103 nentries=0 etime=0 I've tried to fix problem and looked in source of kpasswd command and pam_krb5: kpasswd calls krb5_change_password for changing password, pam_krb5-2.3.11-1/src/v5.c contains follwing code: #ifdef HAVE_KRB5_SET_PASSWORD int v5_change_password(krb5_context ctx, krb5_creds *creds, char *password, int *result_code, krb5_data *result_code_string, krb5_data *result_string) { return krb5_set_password(ctx, creds, password, creds->client, result_code, result_code_string, result_string); } #else int v5_change_password(krb5_context ctx, krb5_creds *creds, char *password, int *result_code, krb5_data *result_code_string, krb5_data *result_string) { return krb5_change_password(ctx, creds, password, result_code, result_code_string, result_string); } #endif HAVE_KRB5_SET_PASSWORD is defined, so it calls krb5_set_password. I've changed line #ifdef HAVE_KRB5_SET_PASSWORD to #if 0 and built and installed new rpm - and all began to work. Version-Release number of selected component (if applicable): pam_krb5-2.3.11-2.fc14.x86_64 ipa-client-1.2.2-6.fc14.x86_64 ipa-server-1.2.2-6.fc14.x86_64 How reproducible: always Steps to Reproduce: 1. setup ipa server and client (it can be on the same host) 2. copy /etc/ldap.conf to /etc/nss_ldap.conf (maybe another bug, ipa-client-install configures /etc/ldap.conf, but nss uses /etc/nss_ldap.conf) 3. change pam_sss.so to pam_krb5.so in /etc/pam.d/system-auth (tried also with pam_sss - also doesn't work by default) 4. create user account in ipa and create password for it using ipa-passwd 5. su - to new user 6. try to change password using passwd command Actual results: passwd command fails Expected results: passwd command succesfully changes password
Hmm, this is also a limitation of kadmind versions before 1.7, so we'll fail against RHEL 5 and earlier, so we should change this back.
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: This field is the basis of the errata or release note for this bug. It can also be used for change logs. The Technical Note template, known as CCFR, is as follows: Cause What actions or circumstances cause this bug to present. Consequence What happens when the bug presents. Fix What was done to fix the bug. Result What now happens when the actions or circumstances above occur. Note: this is not the same as the bug doesn’t present anymore.
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: @@ -3,11 +3,10 @@ The Technical Note template, known as CCFR, is as follows: Cause - What actions or circumstances cause this bug to present. + When attempting to change a user's password, the pam_krb5 module would format the password change request in such a way that older versions of kadmind, such as those included in Red Hat Enterprise Linux 5 and earlier, would not be able to parse it. Consequence - What happens when the bug presents. + Password changes performed by pam_krb5 can fail. Fix - What was done to fix the bug. + The module reverted to using APIs which format the request in such a way that older versions of kadmind would be able to parse the request. Result - What now happens when the actions or circumstances above occur. + Password changes succeed.- Note: this is not the same as the bug doesn’t present anymore.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0711.html