Principal naming

[Bob Liu]

You should look at it this way... primary/instance at REALM

In the case
of a user, it's the same as your username.  For a host, the primary is
the word host.

     
The instance is an optional string that qualifies the
primary.   In the case of a user, the instance is usually null, but a
user might also have an additional principal, with an instance called
"admin".

You might want to check out "kadm5.acl " to see how "/instance" is being used.


> Date: Fri, 18 Jan 2013 11:44:31 -0600
> Subject: Re: Principal naming
> From: nico at cryptonector.com
> To: jblaine at kickflop.net
> CC: kerberos at mit.edu
> 
> On Fri, Jan 18, 2013 at 11:25 AM, Jeff Blaine <jblaine at kickflop.net> wrote:
> > Can anyone explain away the reasoning behind the decision
> > to make user principals need the form:
> >
> >      specific_part/contextual_part
> >
> >      e.g. jennifer/admin
> >
> > and service principals the OPPOSITE - of the form
> >
> >      contextual_part/specific_part
> >
> >      e.g. host/daffodil.mit.edu
> >
> > What happened? Who knows the history and reason for this?
> 
> I wasn't there, so I don't know, but it's something to live with.
> Well, there's actually no need for /admin principals -- you could just
> not have them and modify the kadmin client to stop baking that in (or
> use it with the -c ccache option).
> 
> There's really no point to the /admin thing: since the server requires
> INITIAL tickets there's no risk of use of stolen TGTs for accessing
> kadmin, and if you were to have different pre-authentication
> requirements for kadmin than for initial TGTs the protocol does allow
> that.
> 
> So, yeah, I think it'd be a good idea to start making changes to
> kadmin to stop insisting on /admin principals.
> 
> Nico
> --
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos