Kadmin service principal revisited

Nicolas Williams Nicolas.Williams at sun.com
Sat Aug 30 16:36:19 EDT 2003

On Fri, Aug 29, 2003 at 05:46:36PM -0400, Jeffrey Hutzelman wrote:
> On Friday, August 29, 2003 15:48:52 -0500 "Douglas E. Engert" 
> <deengert at anl.gov> wrote:
> >Also I thought the name would come from the krb5.conf or srv records,
> >so should have a full name.
> Indeed, I don't see any need to call gethostname() here.  Clients should 
> use the hostname they got from DNS or configuration or whatever (this is 
> safe since we are assuming that kadmin/* will only exist for valid admin 
> servers).  The server should accept tickets for any kadmin/* principal in 
> its keytab (note that this also provides compatibility with clients that 
> are expecting to use kadmin/admin, as long as you put that in the admin 
> server's keytab.  Just don't deploy a multi-master setup this way!)

Why not?  RPCSEC_GSS has its own anti-replay protection, so it is
reasonable to run ONC RPC applications w/ RPCSEC_GSS, the Kerberos V
GSS mechanism and no replay cache, as long as the target principal
used by the clients is not used for any other non-ONC RPC protocol.

RPCSEC_GSS has the server assign a "context handle" to established
GSS-API contexts and binds every RPC header to a context named by a
context handle; as long as the server selects sufficiently random
context handles there is no replay issue.

I think kadmin/hostname at REALM principals are fine, though so would be
kadmin/admin at REALM (no replay issue, see above).

Clients can always support both princ names; if the KDC does know
kadmin/admin then the client can try kadmin/hostname.



More information about the krbdev mailing list