Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Changing a user password (via passwd) on a system configured to use Active Directory (AD) via sssd can report:
Password change failed. Server message: Authentication error
passwd: Authentication token manipulation error
but the password _is_ changed - and the user can then subsequently login using the new password
Version-Release number of selected component (if applicable):
krb5-libs-1.15.1-19.el7
How reproducible:
Random
Steps to Reproduce:
1. run /usr/bin/passwd on client set up to use AD via sssd
2. enter valid new password
Actual results:
Sometimes get the error:
Password change failed. Server message: Authentication error
passwd: Authentication token manipulation error
... but the password _is_ changed
Expected results:
passwd: all authentication tokens updated successfully.
Additional info:
The problem appears to be limited to one (or more) back end Domain Controllers (DC)
Turning up debugging on sssd shows that when passwd works OK, it logs the following when contacting on of the DC's on the kpasswd port (464) (logs edited for brevity):
Sending initial UDP request to dgram 10.50.72.11:464
Received answer (173 bytes) from dgram 10.50.72.11:464
when it 'fails':
Sending initial UDP request to dgram 10.17.40.13:464
Initiating TCP connection to stream 10.17.40.13:464
Sending TCP request to stream 10.17.40.13:464
Received answer (100 bytes) from stream 10.17.40.13:464
Terminating TCP connection to stream 10.17.40.13:464
Running tcpdump on the client on port 464 shows that when it fails, it sends a UDP Kerberos request to the DC on port 464 - but doesn't receive a reply - and the a second later, starts a TCP transaction and sends the same Kerberos request, but receives the Kerberos reply 'KRB5KRB_AP_ERR_REPEAT' - which I *think* means something like 'I've already had that request, so rejecting this request' - which is then logged as the error seen (above) ...
This leads me to think that the DC _did_ actually receive the initial UDP request - but for whatever reason, the reply didn't get through ... so the password _does_ get changed ...
A bit of Googling turns up something similar:
https://pagure.io/SSSD/sssd/issue/3756
which suggests setting 'udp_preference_limit = 0' in /etc/krb5.conf - but this didn't help
It also points to http://krbdev.mit.edu/rt/Ticket/Display.html?id=7905 - which has a patch 'Prefer TCP to UDP for password changes':
https://github.com/krb5/krb5/commit/d7b3018d338fc9c989c3fa17505870f23c3759a8
applying this patch to krb5-1.15.1-19 (applies without error) appears to fix the problem for me
Could this upstream patch be included?
Note: We haven't upgraded to EL 7.6 yet, but I suspect the issue will still be there with EL 7.6 (the patch also applies without error to krb5-1.15.1-34)
The issue will I think present in 7.6. If you need a timeline for a fix, or it expedited in any way, you need to go through the customer support portal (sorry).