On 9/28/15 11:33 AM, Rob Crittenden wrote:
Simo Sorce wrote:
On 27/09/15 09:21, Janelle wrote:

I continue to see these a lot, but only on some servers. It causes a lot
of confusions with my users. There must be a way to troubleshoot this
and find the issue. Also, there is nothing wrong with the password
policies. They are all set to default, and this occurs even when a
user's password has expired.  The only thing I can say is it tends to
happen on more heavily loaded servers than lightly loaded ones. And
perhaps the most important point - the password *IS* changed

Changing password for user expired-user.
Current Password:
New password:
Retype new password:
Password change failed. Server message: Current password's minimum life
has not expired

Password not changed.
passwd: Authentication token manipulation error

Thoughts? Anything?
This may be due to an implementation issue in the client.
libkrb5 tends to wait only 1 second for an operation to succeed/fail and
will send a new (identical) message if it gets back no answer, this is
due to the fact historically KRB5 has used UDP in preference which
doesn't guarantee message delivery, so the only option is to retry.

However if the first message actually went through and the only problem
is that the server was busy and slower a second message will be received
and processed just the same, only to find out the password has just been
changed and can't be changed again, hence the error message.

I guess one way to handle this would be to disable clients from using
UDP completely, although I am not 100% certain this will avoid the
problem, IIRC at least in some versions the client library would retry
after 1 second even on TCP.


udp_preference_limit 0 was added to /etc/krb5.conf in 4.2 to prefer TCP
for the initial request anyway. According to the man page it will always
fall back to UDP upon failure.


Something to add:  If I get the failure and then try again,  I get:

Current Password:
System is offline, password change not possible
passwd: Authentication token manipulation error

I also tried setting the kdc_timeout to 10 seconds (it says the default is 3) tcpdump shows everything running over TCP and it never goes to UDP at all, so this is now out of the picture.

Any other ideas? I guess I need to turn on debug_level to something about 7 to try and figure this out.


Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to