Security

While using the encryption type RC4-HMAC-NT, AES128-SHA1 or AES256-SHA1 connection to the principal is failed due to KRB_AP_REQ cannot be decrypted by the server.
 After configuring the DES-BSC-CRC and DES-CBC-MD5 encryption type, from the client machine connection to the principal becomes successful.


To perform the kerberos connection test configuration is done as follows:


1. Set up AD DC on windows server 2012 R2


2. Created a domain user and checked the corresponding option in case of AES128-SHA1 "This account supports Kerberos AES 128 bit encryption" and "do not require Kerberos pre authentication".


3. On the windows server 2012 R2, in local Policies->Security Options ->"Network Security: configure encryption type allowed for Kerberos" AES_128_HMAC_SHA1 and AES_256_HMAC_SHA1 is selected


4. On windows 2012 R2, by using ADSIEDIT.msc, value of  msDS-SupportedEncryptionTypesis set to 28.


5. On the windows client machine [windows 8.1] which is in same domain, in local Policies->Security Options ->"Network Security: configure encryption type allowed for Kerberos" AES_128_HMAC_SHA1  and AES_256_HMAC_SHA1 is selected.


6. Created keytab file on windows 2012 Server R2 by using the KTPASS command [corresponding encryption type is used with -crypto option]


ktpass -princ host/<host name>@domain name -mapuser <domain user name> -pass <passwd of domain user> -crypto AES128-SHA1 -ptype KRB5_NT_PRINCIPAL -out C:\KeyTab\Test4AES-128-U6.keytab


and KTPASS executed successfully.



7. login in the windows machine [windows 8.1] with the domain user as used in KTPASS command and trying to access the  resource as configured as principal in KTPASS command.

Analysis is as follows:

1. From the wire shark network analyzer it is identified that in case of DES-CBC-MD5 encryption type length of the KRB_AP_REQ is 1808 bytes [which is dividable by block size (8 bytes) of DES-CBC-MD5] and in case of DES-CBC-MD5 connection becomes successful.

2. When RC4-HMAC-NT or AES128-SHA1 is configured then length of KRB_AP_REQ is 1813 and 1784 respectively and both are not be dividable by their block size and in these scenarios server failed to decrypt the KRB_AP_REQ.

3. As the length of KRB_AP_REQ is 1813 bytes [in case of RC4-HMAC-NT] and 1784 bytes [in case of AES128-SHA1] it seems it is not correctly padded therefore server fails to decrypt the request.

[Query]
Please suggest the settings to correct the padding and length of KRB_AP_REQ therefore Kerberos connection becomes successful in RC4-HMAC-NT, AES128-SHA1 and AES256-SHA1 scenarios.

In case there are some other viewpoints to resolve the problem please share.

Thank You