Encryption Type wrong

[Kevin Coffman]

On Tue, May 13, 2008 at 4:45 AM, Jan Sanders
<jsanders at techfak.uni-bielefeld.de> wrote:
> 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.

There is no need to cripple your entire realm to only des-cbc-crc for
NFSv4.  If you need help properly configuring Kerberos for NFSv4 on
Linux (I assume you are talking about Linux), let me know.  Again,
there is no reason to limit your entire realm to des-cbc-crc for this
one service!

> >   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.

Is that a typo?  I think Solaris expects config files in /etc/krb5
(not /etc/krb).  Please see my note above before continuing, though.