Keytab on each client?

[Ken Raeburn]

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