"Donn Cave" <[EMAIL PROTECTED]> writes:
>> I seem to be too dense this morning to see how service principal
>> names could be authorization. I mean, with client principals it's
>> obvious enough, but I reckon that the service would be the one who
>> grants authorization, not the one who receives it, in at least the
>> typical use of service principals.
There is an implicit authorization of the server to the client, or
else mutual authentication would have no use. If I'm printing company
financials, I want to be very sure that the entity I'm talking to is
the correct printer. The authentication comes from mutual
authentication, and the authorization is implicit in the user ("Should
I print to the printer in the CFO's locked office, or the one in the
reception area?").
>> By extension, do you see any reason why all services should not just
>> use the "host" principal? That's not a sarcastic question - I think
>> the point could be argued, at least for services that all run as root
>> or have enough common privilege.
Yes, there is a reason. As several people have said, not all services
are tied to hosts. For example, afs uses the principal name
afs/cellname@REALM to authenticate. This is important, as the client
does not know in advance what host it is getting the data from; in the
case of replicated data, the file server host can change on the fly
without userspace ever being aware of it. Another example is the
krbtgt service; the instance there is the kerberos realm, not the
kerberos server host.
Also, since service principal names need to be defined in advance, you
want fine-grained naming because you don't want to require that a
particular service with root privileges. Just because server X does
so today doesn't mean there won't be a different implementation
tomorrow which runs as a separate user.
Sadly, it looks like LDAP uses the hostname of the server, which is
probably not what you really want.
Marc
