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)