kinit always warning about passw expiration

Ken Hornstein kenh at cmf.nrl.navy.mil
Wed Dec 6 04:53:15 EST 2006


>No.  The protocol carries information about when the password is due to 
>expire; it's up to the client to decide what to do with this data (of 
>course, if the password is expired, the KDC will return an error).
>
>There are two ways in which password expiration data can be carried in the 
>Kerberos protocol, both of which are optional.  In one of these cases (the 
>use of last-req to carry key or account expiration data), if the data is 
>provided, the MIT client code always prints a warning; in the other (the 
>key-expiration field), the warning is printed only if the password expires 
>within 7 days.
>[...]
>So, this difference is a result of a difference in client behavior, with 
>the proviso that as of the version I looked at (possibly fairly old), MIT 
>Kerberos does not provide any mechanism for changing the client 
>configuration; it always warns about last-req data for password or account 
>expiration, and warns about key-expiration only if the expiration date is 
>within 7 days.

Some additional context to this, since I was the one who pushed for the
last-req entry for password expiration way back when.

My beef with the key-expiration field was that RFC 1510 specified that
it was to be filled in with either the account expiration or password
expiration date (and in fact, at least one version of the MIT KDC used
the account expiration date).  This meant that a conforming client (okay,
none of those actually EXISTED, but pretend that they did), would have
to display a message like "Your account or password may expire in
3 days" ... which we would all agree isn't the best in terms of user
communication.

So, I pushed a bit and got specific last-req entries that specified
account and password expiration times.

My thinking when I wrote the first implementation of the client code
that did this for MIT Kerberos was that the most useful thing would
be to have the client display the password expiration time any time the
KDC would send it.  That way you could keep the configuration in one
place (the KDC), and you could do interesting things with it that might
not be possible if you hardcoded a time limit on the client (like, if
you had a large user population that took a long holiday at the same time;
you might want to let users know before they leave that their password
was going to expire; you could also do things on a per-user basis).
Since that was my idea, I never wrote any code that bounds the last-req
password expiration warning on the client.  Anyway, that's how things
ended up where they did.  Just FYI.

--Ken



More information about the Kerberos mailing list