Kadmin service principal revisited
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