addprinc -randkey broken in 1.7?

Marcus Watts mdw at
Wed Sep 16 17:04:00 EDT 2009

 Russ Allbery <rra at> writes:
> Date:    Wed, 16 Sep 2009 13:13:13 PDT
> To:      "Leonard J. Peirce" <leonard.peirce at>
> cc:      kerberos at
> From:    Russ Allbery <rra at>
> Subject: Re: addprinc -randkey broken in 1.7?
> "Leonard J. Peirce" <leonard.peirce at> 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:


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

More information about the Kerberos mailing list