Expired passwords and tickets

[Greg Hudson]

On Fri, 2011-09-09 at 11:38 -0400, Mauricio Tavares wrote:
> o To renew/change a user principal password before it expires, the
> said user must have a ticket, right?

The user needs a ticket for the kadmin/changepw service.  This entry is
usually marked as unavailable for TGS requests, meaning the user has to
provide the password again to get a ticket for this service.

> o A user should be able to change the user principal password in, say,
> a Mac without much fuss. What if user is in a Windows box which
> connected to the KDC using the Microsoft kerberos stack (as opposite
> to KFW)?

We use the same protocol (RFC 3244) as Microsoft's Kerberos
implementation for changing passwords, so in theory it should be okay.
But I'm not directly aware of whether this scenario works or not.

> o If the password has expired, is the only way to renew it to login as
> an admin and change it?

No, the KDC allows expired principals to get tickets for the
kadmin/changepw service, just not for the krbtgt service.

> o Is there a way to reminding user of impending doom, i.e. of password
> expiration date steadily approaching?

Yes.  The KDC provides ticket expiration information in the reponse to
an AS request.  It's up to the client to do something useful with it.
Our client library uses the prompter to warn the user, or (in more
recent versions) can invoke an application-specified callback if one is
provided.

> 	Now, talking about the tickets themselves,if user is connected to NFS
> server and ticket expires, what happens? Are the mountpoints suddenly
> unreachable?

That depends on the application and on the library implementation.  In
AFS, for instance, when your tokens (derived from your tickets) expire,
you lose access to the filesystem.  That's a deliberate decision by AFS.
I don't know if NFS makes a similar decision.  The underlying GSSAPI
library might decide to stop accepting messages when the tickets expire.
MIT krb5 did that up until version 1.9, but the resulting app behavior
was typically pretty bad, so as of version 1.9 we no longer check.
Heimdal doesn't check in any version.

Note that some application protocols don't use Kerberos or GSSAPI to
process messages, only to authenticate.  SSH, for instance, uses its own
crypto protocol to protect the data stream.  Applications like this
typically won't care about ticket expiry regardless of the underlying
Kerberos library version.  (The application could query the GSSAPI
security context for the expiry time, but doing so is pretty rare.)