DES vs 3DES Key Type Settings

In the processes outlined above, what happens if the user principal and the service principal do not use the same key type? The answer is - the process continues as described. Here's why.

There is no step in which the client or the service accepts a message encrypted by the other's key. The Kerberos Server acts as the only trusted party. Both the client application and the service share a secret with only the server.

The authenticator data that must be encrypted or decrypted by both the service and the client is encrypted in session keys. The server sends the required session keys to the client and service in packets that are encrypted with their respective keys. The Kerberos Server determines the strongest encryption allowed for the session key by checking the key type settings for the user and service principals. If both have a 3DES key stored in the database, the session key type that is returned is of type 3DES. If only one has a 3DES key and the other has a DES key, then the session key that is returned is of type DES.

Note that the server will never return a session key in the service ticket packet that uses stronger encryption than the session key included with a TGT packet. If a user principal has both a 3DES and DES key, and uses the DES key to obtain a TGT - all service tickets obtained using this TGT will contain DES session keys.

	WARNING! The krbtgt/<REALM NAME> is the ticket-granting principal. This is a reserved principal that is automatically created when a realm is added to the database. The krbtgt/<REALM NAME>principal must be assigned a key type or default keys issued by the Kerberos Server will use the 3DES encryption type.