Presence/absence of the keytab

[Scott Lowe]

On 2006-05-04 12:29:53 -0400, Donn Cave <donn at u.washington.edu> said:

> In article <m2psiuqlxo.fsf at darwin.oankali.net>,
>  "Richard E. Silverman" <res at qoxp.net> wrote:
> 
>>>>>>> "SL" == Scott Lowe <slowe at eplus.com> writes:
>> 
>> SL> Yesterday, however, I was able to successfully authenticate via
>> SL> Kerberos from VMware ESX Server 2.5.3 (the console operating
>> SL> system is Linux-based) *without* generating a keytab.  This seems
>> SL> to fly in the face of all the information and instructions I've
>> SL> seen.
>> 
>> SL> So, I'm curious...any thoughts as to why this worked?
>> 
>> A keytab is needed for a host on which a kerberized service runs; it holds
>> the service princpal's secret key, which the service software needs.
>> 
>> You don't need anything special on a host to allow someone to "kinit" on
>> it.  The only secret needed is your password.
> 
> True, though there is a sort of grey area inhabited by services
> that use Kerberos to perform password authentication.  This is
> functionally like "kinit", but semantically quite different, and
> without a service principal to validate the authentication results,
> they're vulnerable.
> 
> So depending on what `successfully authenticate' actually means here,
> the information and instructions that say to get a service principal
> and a keytab may be worth listening to, even if the service appears
> to work without it.
> 
>    Donn Cave, donn at u.washington.edu

I suppose if I were seeking to use a fully Kerberized server 
application that accept Kerberos tickets from Kerberos clients, then a 
keytab would be necessary.  In this instance, the service does not 
accept Kerberos authentication from connecting systems, but acts a 
Kerberos client on the back-end to perform authentication (using PAM).  
It seems to make sense, then, that a keytab would not be necessary.  At 
least, not in this situation.

Thanks for your response.

-- 
Regards,
Scott Lowe
ePlus Technology, Inc.