Improved support for password/principal expiration

[James F.Hranicky]

On Fri, 02 May 2003 14:22:52 -0400
Ken Hornstein <kenh at cmf.nrl.navy.mil> wrote:

> >Currently, Kerberos cannot notify users of both impending principal 
> >expiration and impending password expiration due to the fact that 
> >there is only one field (key_exp) in struct _krb5_enc_kdc_rep_part {}.
> 
> I'm ahead of you there, James :-)

Great!

> _on the client side only_ in the 1.3 alpha code (look at gic_pwd.c:327).
> This gives the KDC the ability to _unambigiously_ indicate password
> expiration to clients.  Because of time issues I wasn't able to get
> the KDC-side support in there, but it's a small change.

Very cool -- so then I assume that if this is the standard way to do this,
the prompts sent back when checking key_exp should be changed to something
like 

	"This account will expire in %d <whatever>s"

right?

Are you saying this change won't go into the 1.3 code release, or that
it's just not in the alpha currently?

> rather than add my own.  I cannot speak for MIT, but I would doubt
> very much that they would accept code that created a new ASN.1 element
> in an AS_REP without it going through the IETF process and everyone
> thoroughly understood the backwards compatibility issues.

No problem, sounds like a big deal, especially in light of your fix.
It's not like I'm Microsoft ;->

> varies by site).  The code I wrote lets you set a KDC-specific variable
> that controls the threshold for password expiration notification.
> Since the last-req field is optional, not sending means "don't display
> the password expriation warning".

Ok, would this be set in kdc.conf or through kadmin?

> Sigh.  Unfortunately, this ends up being very complex in practice, since
> sending back a display string opens up the whole internationalization
> mess.  I personally think your best bet here is to work on a client-side
> configuration (as much as I loath client-side configuration, I don't see
> a reasonable alternative here).

Hmmm...I meant customization of the banner sent to the GIC prompter, so
it would be client side -- the KDC interaction would stay relatively
unchanged...something in krb5.conf?

[libdefaults]
   gic_princ_exp_msg = /usr/local/etc/krb5/princ_exp_msg
   gic_pass_exp_msg  = /usr/local/etc/krb5/pass_exp_msg

Contents of /usr/local/etc/krb5/princ_exp_msg :

	Information on renewing accounts can be found at
	http://www.my.domain.com/accounts/renewals .

Contents of /usr/local/etc/krb5/pass_exp_msg :
	
	Information on changing your password can be found at
	http://www.my.domain.com/accounts/passchange .

Something like that...

Unfortunately, I'm not sure I could do anything else as the as_reply doesn't
get passed out of krb5_g_i_c_p() .

> >the expiration. Since I plan on using password expiration as well, the 
> >above modifications would probably be necessary to make such a scheme
> >work well.
> 
> Right, and here is a case where there really is a difference between
> client expiration and password expiration, so that makes everything more
> complicated (since most people are only interested in password expiration).

Sure, and this would mean str*cat'ing one message onto the banner containing
the other if both messages were to be displayed. I don't think it's hugely
more complicated -- what do you think?

I could try to code some of this up if you'd like.

Jim