Re: Mixing heimdal and MIT clients.

["Henry B. Hotz" <hotz@jpl.nasa.gov>]

I think all reasonably current distro's should work with all enctypes  
these days.

If the smbclient is linked against some Kerberos (e.g. a local/old  
version of Heimdal) that doesn't support all types, then you should  
find out what types are supported, and limit the types in its service  
principal to match.  (There's an entry in the Kerberos FAQ on this.)

If you do a kinit or pam_krb5 with one library that supports more  
enctypes (e.g. AES256) than the other then the other library will  
lose.  Either use the least capable library for the initial ticket,  
or limit the enctypes on the initial ticket.

On Jan 15, 2008, at 7:39 AM, Timothy J. Miller wrote:

>
> On Jan 15, 2008, at 8:48 AM, Timothy J. Miller wrote:
>
>> On Jan 15, 2008, at 8:35 AM, Timothy J. Miller wrote:
>>
>>> heimdal/klist works fine but I don't have the MIT klist installed  
>>> on the client system.
>>
>> OK, so compiling MIT took less time than I thought.  MIT klist  
>> works just fine with the heimdal-obtained ccache.
>>
>> So now I'm at a total loss as to what's happening.
>
> On a hint from another mailing list, I nuked the following from  
> krb5.conf [libdefaults]:
>
> default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
> default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
>
> Which were included by default by Ubuntu's krb5-common package.   
> Despite the fact that these didn't prevent heimdal clients from  
> working, those two lines certainly hosed up the MIT clients.
>
> With them gone, everything works now.
>
> Guess I need to read more about enctypes and their effects in both  
> libraries.
>
> -- Tim

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu