addprinc -randkey broken in 1.7?

[Marcus Watts]

 Russ Allbery <rra at stanford.edu> writes:
> Date:    Wed, 16 Sep 2009 13:13:13 PDT
> To:      "Leonard J. Peirce" <leonard.peirce at gmail.com>
> cc:      kerberos at mit.edu
> From:    Russ Allbery <rra at stanford.edu>
> Subject: Re: addprinc -randkey broken in 1.7?
> 
> "Leonard J. Peirce" <leonard.peirce at gmail.com> writes:
> 
> > When running (in kadmin)
> 
> >   addprinc -randkey host/host.domain
> 
> > I get a complaint about the password not containing enough character
> > classes.  Did I miss something?  Not really a big deal since I can
> > just specify a password.
> 
> > It used to work in 1.6.
> 
> addprinc -randkey hasn't worked for principals that have a password policy
> set for somet time for me.  The way -randkey works under the hood is that
> it adds the principal disabled with a fixed password (which is indeed
> pretty bad except that it's very long), then randomizes the key, and then
> enables the principal.
> 
> This has other strange artifacts (or at least did -- I don't know if
> they've been fixed).  For example, adding a principal with -randkey and
> -disallow_all_tix results in an enabled principal, igoring the
> -disallow_all_tix option.

Ah!  I have a patch for this.  I thought I had submitted this to MIT
long since, but I can't find any record that this happened.

Here's the patch:

/afs/umich.edu/user/m/d/mdw/build/krb5.15x/patches/krb5-1.6.3-ankfix1.patch

This changes the protocol to use a 'null' password to indicate randkey operation.
If a new client talks to an old server, the behavior is to fall back to the old case.
Obviously this was for 1.6.3, but it might apply to 1.7.

					-Marcus Watts