On Tue, May 13, 2008 at 09:58:05AM -0400, Kevin Coffman wrote:
> On Tue, May 13, 2008 at 4:45 AM, Jan Sanders
> wrote:
> > Russ Allbery wrote:
> > > Jan Sanders 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!


That is correct. The only time one should restrict the enctypes in this
situation is during the creation the nfs/ service principal
key entries in the keytab on a system that did not support the same set
of enctypes the Solaris KDC supports. There is a shortcoming in the
kadmin protocol used when doing a ktadd such that the KDC is not aware
of the specific set of enctypes supported on the system where the kadmin
utility is running. The workaround to this is to explicitly state the
enctypes on the ktadd command if one does not wish to have keys
generated for the set of enctypes supported on the KDC.

Note that I'm saying only restrict the enctypes when creating keytab
entries for a server that does not support the same set of enctypes as
the KDC. As long as the Linux and other NFS clients are using a
properly implemented krb that is requesting only supported enctypes for
that system when acquiring a NFS service ticket everything should work
fine. If you want to read more about enctypes see this blog entry:
http://blogs.sun.com/wfiveash/entry/...wanted_to_know

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


The initial Solaris 10 krb code was buggy in the way ktadd interacted
with various enctype parameters including supported_enctypes. I suggest
you update all your Solaris 10 systems to Solaris 10 Update 5 which has
updated krb code.

> > 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.
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos


--
Will Fiveash
Sun Microsystems Inc.
http://opensolaris.org/os/project/kerberos/