[krbdev.mit.edu #6821] The +preauth default in kdc.conf isn't always obeyed.

D.H.Davis@bath.ac.uk via RT rt-comment at krbdev.mit.edu
Wed Nov 17 11:00:08 EST 2010


On Wed, 17 Nov 2010, Greg Hudson via RT wrote:

> From: Greg Hudson via RT <rt-comment at krbdev.mit.edu>
> To: D.H.Davis at bath.ac.uk
> Date: Wed, 17 Nov 2010 15:33:13
> Subject: [krbdev.mit.edu #6821] The +preauth default in kdc.conf isn't always
>     obeyed. 
>
> Prior to 1.8, addprinc -randkey was implemented in three
> RPCs: create the principal with a dummy password and the
> disallow-all-tix flag, randomize its password, unset the
> disallow-all-tix flag.  This had the unfortunate side effect of
> ignoring the KDC's default flags.
>
> There is now a better way (create the principal with a null
> password), but clients and servers both have to be at 1.8 for it
> to work.

Thanks for the very prompt reply.

I wondered if something like this was happening when I noticed
-randkey with 1.6.3 and 1.7.1 kadmin produced principals with a Key
vno of 2, whereas -randkey with a 1.8.x kadmin produced principals
with a Key vno of 1.

I note you're using RT so please flag this ticket as closed, if
you haven't done so already.  It would be unreasonable to expect
the improved interface to be back-ported to earlier versions of
kerberos.

(This arose because I've recently switched to using the +preauth
 default for all principals associated with humanoids.  Easily
 done by making it the default in kdc.conf.  Typically I, and I
 suspect others, use -randkey when generating host and service based
 principals.  So I was expecting to have to turn off preauth on such
 principals as I'm not quite ready to go there yet.  I was puzzled
 when I didn't have to turn off +preauth with a production KDC
 running 1.6.3.  It had already been done for me!)
-- 
Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK
D.H.Davis at bath.ac.uk               Phone: +44 1225 386101




More information about the krb5-bugs mailing list