Kerberos加密类型带来的困扰
在计算机网络中访问资源的时候需要提供Kerberos票据。这些票据用账户的密码哈希值加密。密码通过某种加密算法之后会生成相应的密码哈希值。操作系统的类型和版本不同，其所支持的加密类型也不相同。这时候就可能造成操作系统A类型解密不了操作系统B类型的票据，或者低版本的操作系统C解密不了高版本操作系统D的票据。原因就是B和D采用了A和C不支持的加密类型。这时候就会出现访问被拒绝的相关错误信息。假如抓取网络包进行观察，会发现“ERR_ETYPE_NOSUPP”这个典型的错误。为了解决这些问题，我们先来介绍一些基本知识吧。
因为是加密类型导致了这些错误的出现，所以当然要先介绍加密类型。下表列出了一些常见的加密类型。
Name |
Value |
Description |
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#1v1.5) |
rsaES-OAEP-ENV-OID |
14 |
(pkinit from PKCS#1v2.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) |
在Windows 2003 Server域中支持的加密类型包括DES-CBC-CRC，DES-CBC-MD5，和RC4-HMAC，其中RC4-HMAC最安全。
在Windows 2008 Server域中，加密类型在Windows 2003 Server的基础上新增了两个：aes128-cts-hmac-sha1-96和aes256-cts-hmac-sha1-96。他们比RC4-HMAC更安全。
当没有特别的设置时，域控制器在与客户端协商时使用最安全的加密类型给票据加密。当在Windows
2003 Server域中没有更高版本如Windows
2008 Server的计算机时，Kerberos加密解密票据一切正常。
然而，Windows
2003 Server域中存在一些Windows
2008 Server等高版本计算机时，情况就不一样了。当Windows
2008 Server成员计算机试图利用AES加密类型通过Windows 2003 Server域控制器的验证时，Windows 2003 Server就无法解除加密，从而验证失败。只有当Windows 2008 Server成员计算机采用RC4-HMAC等Windows 2003 Server支持的加密类型时，Windows 2003 Server才能成功解除加密。这时候加密类型确实给我们带来了一些困扰，但是我们可以修改加密类型的选择消除这些困扰。
在介绍如何修改加密类型的选择之前，有必要先介绍一下这几种加密类型在系统中的表示方法。在系统中，DES-CBC-CRC，DES-CBC-MD5，RC4-HMAC，aes128-cts-hmac-sha1-96和aes256-cts-hmac-sha1-96分别用字节中的一位来表示，从低位到高位。比如0x1F代表支持所有五种加密类型。0x1C表示不支持DES-CBC-CRC和DES-CBC-MD5。
目前，有四个因素可以影响客户端和域控制器之间加密类型的选择。
1. 修改客户端的本地策略或者注册表。当客户端与域控制器进行加密类型协商的时候，客户端会将所支持的加密类型提交给域控制器（按照优先级由高到低排列），然后让域控制器选择加密类型，一般来说都是选择排在最前面的那个加密类型。我们可以通过修改注册表键值DefaultEncryptionType来改变排在最前面的加密类型。该注册表键值如下：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\DefaultEncryptionType。也可以通过本地策略Computer Configuration – Windows Setting –
Security Setting – Local Policy – Security Options – network security:
Configure encryption types allows for Kerberos设置客户端的加密类型。如下图所示。
2. 域控制器在收到了客户端的请求之后，会检查自己所能支持的加密类型，然后结合客户端的请求决定最终的加密类型。
3. 在账户属性上设置加密类型。在Windows 2008域中的计算机账户上，可以设置MSDS-SupportedEncryptionTypes属性。对于Windows 7来说，该属性默认为0x1C（十进制28）。在Windows 2008域中的用户账户属性的Account Options中可以设置加密类型。如下两图所示。
4. 设置域控制器上注册表键值KdcUseRequestedEtypesForTickets为1可以使域控制器始终根据客户端的请求选择加密类型。注册表位置如下：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc。
讲到这里，您肯定已经知道如何去解决我们在开篇介绍的场景中的错误了吧。为了加深印象，这里在举两个例子，我们一起来试着解决它们吧。
例一、安装在Windows 2008 Server上的Exchange从Windows 2008 Server域控制器获得访问Cluster资源的票据后，试图用Cluster Virtual name进行访问，但是失败；当从Windows 2003 Server域控制器那里获得票据后，用Cluster Virtual name成功访问Cluster资源。同时Exchange总是能访问同样安装在Windows 2008 Server上的单一节点。Cluster Virtual name不支持AES加密类型。
结论：
Exchange从Windows 2008 Server域控制器上获得的票据是用AES加密的，所以Cluster Virtual name无法解开。
Exchange从Windows 2003 Server域控制器上获得的票据是用RC4-HMAC加密的，所以Cluster Virtual name可以解开。
那个单一节点安装在Windows 2008 Server上，所以支持AES加密类型，因而，Exchange总能访问它。
根据上面的结论，再加上前面学到的修改加密类型选择的方式，您肯定已经想到如何解决这个问题了吧。
- 根据前面叙述的四种影响加密类型的第二种，我们可以采用将所有Windows 2008 Server域控制器的KDC服务停止，这样只有Windows 2003 Server能够给予票据，保证Cluster资源可以访问。
- 根据第三种，我们可以修改Cluster Virtual name账号的MSDS-SupportedEncryptionTypes属性为0x7。这样设置之后访问Cluster的票据就不会用AES加密。
例二、Unix客户端时不时的无法获得票据。当经过Windows 2008 Server域控制器验证时，能够获得票据；但是经过Windows 2003 Server验证时，在网络包中出现“ERR_ETYPE_NOSUPP”错误。
因为Unix支持的加密类型包括des3-cbc-sha1，rc4-hmac，des-cbc-crc，des-cbc-md5，aes256-cts-hmac-sha1-96，aes128-cts-hmac-sha1-96， des-cbc-md4，rsa-sha1-cms，rsa-md5-cms，des-ede3-cbc-env，rc2-cbc-env，rsa-env。所以只需要在Unix客户端取消AES加密就可以了，最终客户端就会使用RC4-HMAC加密类型进行加密了。
好了，今天的内容就介绍到这里了，期待下次再见。
谢谢，
屈贝伟 | 企业平台支持部AD技术工程师 | 微软亚太区全球技术支持中心
本博文仅供参考，微软公司对其内容不作任何责任担保或权利赋予。