Kerberos加密类型带来的困扰

在计算机网络中访问资源的时候需要提供Kerberos票据。这些票据用账户的密码哈希值加密。密码通过某种加密算法之后会生成相应的密码哈希值。操作系统的类型和版本不同，其所支持的加密类型也不相同。这时候就可能造成操作系统A类型解密不了操作系统B类型的票据，或者低版本的操作系统C解密不了高版本操作系统D的票据。原因就是B和D采用了A和C不支持的加密类型。这时候就会出现访问被拒绝的相关错误信息。假如抓取网络包进行观察，会发现“ERR_ETYPE_NOSUPP”这个典型的错误。为了解决这些问题，我们先来介绍一些基本知识吧。

因为是加密类型导致了这些错误的出现，所以当然要先介绍加密类型。下表列出了一些常见的加密类型。

在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总能访问它。

根据上面的结论，再加上前面学到的修改加密类型选择的方式，您肯定已经想到如何解决这个问题了吧。

1. 根据前面叙述的四种影响加密类型的第二种，我们可以采用将所有Windows 2008 Server域控制器的KDC服务停止，这样只有Windows 2003 Server能够给予票据，保证Cluster资源可以访问。
2. 根据第三种，我们可以修改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技术工程师 | 微软亚太区全球技术支持中心

本博文仅供参考，微软公司对其内容不作任何责任担保或权利赋予。