Keytab on each client?
Ken Raeburn
raeburn at MIT.EDU
Thu Jan 5 08:17:03 EST 2006
On Jan 5, 2006, at 02:19, Amir Saad wrote:
> thanks for your reply
> please consider the following example:
> i have two clients , A and B , client B is my LDAP server
> now i have created a principal for ldap service , if client A wants
> to connect LDAP using kerberos
> the KDC will send two tickets one of them is encrypted by the LDAP
> principal key, right?
> to decrypt it, the client B (which is the LDAP server) must know
> its key, how ? i mean client B has no keytab file, how it can
> decrypt the ticket?
I think your terminology may be getting in the way.
The application (LDAP) server machine (which you seem to be
describing as a "client") must have the keytab with the LDAP service
principal key. The application client machines -- random user's
systems, for example -- which is what Paul and the rest of us
probably assumed you meant by "client", should not get a copy of it.
In a Kerberos environment, there are three kinds of system
configurations to consider: Kerberos KDC servers, application
servers, and client systems that use both kinds of services. (Or
KDC, server, and client, if there's little risk of confusion.)
Describing application server systems as "clients" is just going to
be confusing. Most application services won't interact directly with
the KDC in day-to-day operation. After you set up the service and
its keytab, their interaction is only with the application clients.
(That's not an absolute rule -- it's possible for an application
server to interact with a second service, playing the role of the
client to both the second service and to Kerberos in that case, but
it's uncommon. It's also possible for two Kerberos clients with
tickets -- e.g., users' systems -- to communicate via user-to-user
authentication, in which case one has to play the server role; that's
also uncommon. Both cases require careful attention to terminology
used.) Of course, it's possible to configure one system as an
application server system *and* as a client system users can log in
to; in that case, since the two roles are usually well-separated in a
secure system, the best choice of terminology depends on the aspect
of the system you're referring to.
Ken
More information about the Kerberos
mailing list