Re: Encryption Type wrong
- From: Jan Sanders <jsanders@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 13 May 2008 10:45:24 +0200
Russ Allbery wrote:
Jan Sanders <jsanders@xxxxxxxxxxxxxxxxxxxxxxxx> writes:Yes, that is correct. If I use the default settings for Kerberos the behaviour is the same as above.
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.
Good to know. But unfortunately I am stuck with des-cbc-crc:normal. All clients are configured to use only des-cbc-crc:normal.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.
The first question I'd have is why are you doing this? Normally you neverI 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.
want to restrict enctypes.
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).
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.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?
cheers
Jan Sanders
.
- Prev by Date: Use of GSS-API
- Next by Date: krb5 RHEL 5.1 and NetworkManager
- Previous by thread: Re: Encryption Type wrong
- Next by thread: Re: Encryption Type wrong
- Index(es):
Relevant Pages
|
