Encryption Type wrong

[Jan Sanders]

Russ Allbery wrote:
> Jan Sanders <jsanders at TechFak.Uni-Bielefeld.DE> writes:
>
>   
>> I am having a little problem here. I am running a KDC on Solaris and a
>> number of clients on GNU/Linux. For both the KDC and the
>> Kerberos-Clients I have configured them to use only the
>> dec-crc-cbc:default encryption type.  When creating a principal on the
>> server using addprinc wo/-e des-cbc-crc:default the principal is created
>> with 4 keys. getprinc reveals:
>>
>> Key: vno 21, AES-128 CTS mode with 96-bit SHA-1 HMAC, no salt
>> Key: vno 21, Triple DES cbc mode with HMAC/sha1, no salt
>> Key: vno 21, ArcFour with HMAC/md5, no salt
>> Key: vno 21, DES cbc mode with RSA-MD5, no salt
>>     
>
> I'm not sure what to say beyond it looks like you've not actually
> configured the KDC to use only that encryption type.  The KDC is clearly
> using a wide variety of encryption types, probably its default set.
>   
Yes, that is correct. If I use the default settings for Kerberos the 
behaviour is the same as above.
>   
>> But the ordinary user once in a while wants to change the password and
>> will use kpasswd. kpasswd does not have the ability to choose the
>> encryption type and then a users ends up not having a key with
>> des-cbc-crc:normal.
>>     
>
> That's correct.  kpasswd will use whatever the default enctypes are in the
> Kerberos kadmind configuration.
>
>   
>> Unfortunately GNU/Linux kinit breaks if the KDC does not have a key with
>> the des-cbc-crc:normal encryption type in store.
>>     
>
> This on the other hand definitely isn't the case; GNU/Linux kinit will
> work fine with no DES enctypes at all.  However, it is certainly true that
> if you specifically configure it to only use des-cbc-crc:normal and no
> such keys are available, it won't work.
>   
Good to know. But unfortunately I am stuck with des-cbc-crc:normal. All 
clients are configured to use only des-cbc-crc:normal.
> The first question I'd have is why are you doing this?  Normally you never
> want to restrict enctypes.
I have a number of GNU/Linux boxes that will have to use kerberized nfs4 
in the near future. At the moment the NFS people are working on 
supporting mor than just des-crc-cbc:normal for use with nfs4. But there 
are still some older boxes that won't have this feature.
Indeed it might be necessary, though undesired, to upgrade those boxes.
>   If you just remove all the enctype
> restrictions, everything will work as expected and be able to negotiate a
> mutually acceptable enctype.  If you're worried about old Java code, you
> could still allow 3DES, which is generally acceptable to just about
> everything except Microsoft clients (which can use RC4).
>   

>   
>> The kdc.conf on the Solaris machine:
>>
>> [libdefaults]
>>         default_realm = MY.DOMAIN
>>         default_keytab_name = /etc/krb5/krb5.keytab
>>
>> [kdcdefaults]
>>         kdc_ports = 88,750
>>
>> [realms]
>>         MY.DOMAIN = {
>>                 profile = /etc/krb5/krb5.conf
>>                 database_name = /var/krb5/principal
>>                 admin_keytab = /etc/krb5/kadm5.keytab
>>                 acl_file = /etc/krb5/kadm5.acl
>>                 kadmind_port = 749
>>                 max_life = 8h 0m 0s
>>                 max_renewable_life = 7d 0h 0m 0s
>>                 default_principal_flags = +preauth
>>                 supported_enctypes = des-cbc-crc:normal
>>         }
>>     
>
> This looks right, but it's clearly not working.  Could kadmind be loading
> some other kdc.conf?
>   
I used truss to trace file opening for kadmind and kadmin.local and it 
opens the (I believe only) krb.conf in /etc/krb.  I was wondering if 
some (subtle) syntax error in the file makes Kerberos regress to deafult 
values.

cheers

Jan Sanders