kadmin.local "ank -randkey" ignores kdc.conf's default_principal_flags?

[Marcus Watts]

> Date:    Thu, 03 Jun 2010 16:21:43 EDT
> To:      Marcus Watts <mdw at umich.edu>
> cc:      "kerberos at mit.edu" <kerberos at mit.edu>
> From:    Tom Yu <tlyu at MIT.EDU>
> Subject: Re: kadmin.local "ank -randkey" ignores kdc.conf's default_principal_f
>      ***lags?
> 
> Marcus Watts <mdw at umich.edu> writes:
> 
> >> Date:    Thu, 03 Jun 2010 14:23:14 EDT
> >> To:      Adam Megacz <megacz at cs.berkeley.edu>
> >> cc:      "kerberos at mit.edu" <kerberos at MIT.EDU>
> >> From:    Greg Hudson <ghudson at MIT.EDU>
> >> Subject: Re: kadmin.local "ank -randkey" ignores kdc.conf's default_principa
> l_f
> >>      ***lags?
> >> 
> >> On Wed, 2010-06-02 at 23:43 -0400, Adam Megacz wrote:
> >> > Related to my previous posting, I find that even though I have
> >> > 
> >> >   default_principal_flags = +preauth
> >> > 
> >> > in kdc.conf, when I use kadmin.local's "ank -randkey" command to create
> >> > a service principal, the principal is created with no attributes.
> >> 
> >> This is a known bug; it was fixed in 1.7.1 and 1.8.
> >
> > ... and here's a previous message I posted to this list which
> > is unobviously relevant here:
> > http://www.mail-archive.com/kerberos@mit.edu/msg15880.html
> 
> In older releases, "ank -randkey" has three phases.  The first phase
> creates the principal with all tickets disabled and with a fixed
> password.  To do so, it sets a bit in the request attribute mask sent
> to the server, indicating that the kadmin client is overriding the
> default princpal flags (which normally get filled in by the server if
> the client didn't indicate that it was going to override them).  Phase
> two is a "randkey" operation, and phase three is to clear the
> "DISALLOW_ALL_TIX" flag.  If you didn't explicitly specify any
> principal flags in the client, that means no principal flags are set
> when "ank -randkey" is finished.
> 
> This has since been fixed, as Greg said.

Yes.  I understand that the "long-term" fix Greg committed was based on
the patch I included in this message.  In my case, the impetus to make
this change was to improve password plugin checking behavior, which is why
I failed to submit this patch in the usual fashion.

				-Marcus Watts