Udostępnij za pośrednictwem

How to interpret encryption types definitions in krb5kdc.log on UNIX KDC, during configuration of trust relationship between MIT V5 Realm and Active Directory

  • Artykuł

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm

 

 

First of all why this is even important? Well, if you ever tried to configure a trust relationship between MIT V5 Realm and AD, I am sure you probably ran into some initial configuration issues and had to look into the krb5kdc.log file to figure out what the issue was. Basically a very typical issue to run into is the fact that AD and MIT Realm could not agree on mutual encryption types and krb5kdc is a good place to find out about this. Additionally, with introduction of Windows 2003 SP1 it is now possible to use RC4 encryption for Kerberos exchanges between MIT V5 Realms and Active Directory as opposed, now considered to be week, DES protocol. So by looking at the krb5kdc.log you can see what type of encryption is being used to ensure that RC4 is in fact being utilized. One of the problems that I encountered during such troubleshooting sessions was the fact that encryption types displayed in the log file are not presented in an intuitive format.

Let’s take a look at a sample log entry from krb5kdc.log:

 

Jul 17 11:19:57 rh01.mit.contoso.com krb5kdc[1864](info): TGS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 192.168.15.103: ISSUE: authtime 1153149597, etypes {rep= 23 tkt=23 ses=23}, j...@MIT.CONTOSO.COM for krbtgt/MIT.CONTOSO....@MIT.CONTOSO.COM

Let’s try to decipher this message. So first of all this is a TGS_REQ packet (client is requesting TGT) from client at IP 192.168.15.103. The client in the TGS_REQ is sending the encryption types that it supports in the following structure etypes {23 -133 -128 3 1 24 -135}. If you thought that the numbers in brackets represent corresponding encryption types then you are correct. The challenge for me was to find the translation from numbers to actual protocol names so that this message could have some meaning. After doing some digging and posting, I finally found that the translation table is defined in RFC 3961 Section 8 https://www.ietf.org/rfc/rfc3961.txt. For your convenience I pasted the table here as well.

 encryption type                etype      section or comment

       -----------------------------------------------------------------

       des-cbc-crc                        1             6.2.3

       des-cbc-md4                        2             6.2.2

       des-cbc-md5                        3             6.2.1

       [reserved]                         4

       des3-cbc-md5                       5

       [reserved]                         6

       des3-cbc-sha1                      7

       dsaWithSHA1-CmsOID                 9           (pkinit)

       md5WithRSAEncryption-CmsOID       10           (pkinit)

       sha1WithRSAEncryption-CmsOID      11           (pkinit)

       rc2CBC-EnvOID                     12           (pkinit)

       rsaEncryption-EnvOID              13   (pkinit from PKCS#1 v1.5)

       rsaES-OAEP-ENV-OID                14   (pkinit from PKCS#1 v2.0)

       des-ede3-cbc-Env-OID              15           (pkinit)

       des3-cbc-sha1-kd                  16              6.3

       aes128-cts-hmac-sha1-96           17          [KRB5-AES]

       aes256-cts-hmac-sha1-96           18          [KRB5-AES]

       rc4-hmac                          23          (Microsoft)

       rc4-hmac-exp                      24          (Microsoft)

       subkey-keymaterial                65     (opaque; PacketCable)

 

So now we can see that the client requested etypes {RC4-hmac -133 -128 des-cbc-md5 des-cbc-crc RC4-hmac-exp -135}. A bit clearer, but what about those negative values? Well negative values are reserved to implementers of protocol. Since the client in my case was XP workstation, then the negative values would be defined by Microsoft, and indeed in Microsoft Windows Platform SDK ntsecapi.h we can find:

#define KERB_ETYPE_RC4_MD4 -128 // FFFFFF80
#define KERB_ETYPE_RC4_PLAIN2 -129
#define KERB_ETYPE_RC4_LM -130
#define KERB_ETYPE_RC4_SHA -131
#define KERB_ETYPE_DES_PLAIN -132
#define KERB_ETYPE_RC4_HMAC_OLD -133 // FFFFFF7B
#define KERB_ETYPE_RC4_PLAIN_OLD -134
#define KERB_ETYPE_RC4_HMAC_OLD_EXP -135
#define KERB_ETYPE_RC4_PLAIN_OLD_EXP -136
#define KERB_ETYPE_RC4_PLAIN -140
#define KERB_ETYPE_RC4_PLAIN_EXP -141

So now using those 2 sources we can completely interpret the message as:

{RC4-HMAC RC4-HMAC-OLD RC4-MD4 DES-CBC-MD5 DES-CBC-CRC RC4-HMAC-EXP RC4-HMAC_OLD_EXP}. By the way the token was issued with etype = 23 which means RC4-HMAC, which is exactly what you want.

Comments