2

I would like to remove all of the des keys from the principal below, but have no idea how to do so without someone inputting the password.

kadmin:  getprinc user
Principal: user@EXAMPLE.COM
Expiration date: [never]
Last password change: Thu May 26 08:52:51 PDT 2013
Password expiration date: [none]
Maximum ticket life: 0 days 12:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Tue Jul 16 15:17:18 PDT 2013 (administrator/admin@EXAMPLE.COM)
Last successful authentication: Wed Jul 24 14:40:53 PDT 2013
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 8
Key: vno 3, aes256-cts-hmac-sha1-96, no salt
Key: vno 3, arcfour-hmac, no salt
Key: vno 3, des3-cbc-sha1, no salt
Key: vno 3, des-cbc-crc, no salt
Key: vno 3, des-cbc-md5, no salt
Key: vno 3, des-cbc-md5, Version 5 - No Realm
Key: vno 3, des-cbc-md5, Version 5 - Realm Only
Key: vno 3, des-cbc-md5, AFS version 3
MKey: vno 2
Attributes: REQUIRES_PRE_AUTH
Policy: [none]

Also, the the kdc is using an OpenLDAP backend.

84104
  • 12,698
  • 6
  • 43
  • 75

1 Answers1

2

I don't think there is any easy way to do this with the MIT kerberos code. It's trivial with heimdal since del_enctype is one of the kadmin commands.

As far as I know the only way to do it with standard MIT is to dump the kdc database, remove the offending keytypes and reload the database. Since your backend store is OpenLdap, if you have access to the root dn of the ldap server, you might be able to find the individual key values in the ldap database and remove them.

The schema is listed here

http://k5wiki.kerberos.org/wiki/Kerberos.schema

It's not clear to me that it's possible to figure out the enctype of this w/o decrypting it with the master key.

attributetype ( 2.16.840.1.113719.1.301.4.39.1
            NAME 'krbPrincipalKey'
            EQUALITY octetStringMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.40)
  • 1
    It's actually slightly more complicated than that. The `krbPrincipalKey` attribute contains *all* the keys for a principal and their associated meta-data encrypted by the MKey, not as one might hope one key per attribute entry. – 84104 Nov 01 '13 at 22:27