原始 KB 数： 4492348
现象
Active Directory 域服务 （AD DS） 林的子域中的计算机无法访问驻留在同一林中的不同域中的服务。 如果在与客户端计算机的通信上运行网络跟踪，跟踪将包含以下 Kerberos 消息：
6 9:35:19 AM 8/14/2018 17.8417442 192.168.1.101 192.168.1.2 KerberosV5 KerberosV5:AS Request Cname: Administrator Realm: contoso.com Sname: krbtgt/contoso.com {TCP:4, IPv4:1}
7 9:35:19 AM 8/14/2018 17.8452544 192.168.1.2 192.168.1.101 KerberosV5 KerberosV5:KRB_ERROR - KDC_ERR_ETYPE_NOSUPP (14) {TCP:4, IPv4:1}
在子域的域控制器上，事件查看器记录以下事件 14 条目：
Log Name: System
Source: Microsoft-Windows-Kerberos-Key-Distribution-Center
Event ID: 14
Task Category: None
Level: Error
Keywords: Classic
Description:
While processing an AS request for target service krbtgt, the account Administrator did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 17 3. The accounts available etypes : 23 -133 -128. Changing or resetting the password of Administrator will generate a proper key.
原因
配置子域（或仅客户端）时，会出现此问题，如下所示：
- 禁用 RC4_HMAC-MD5 加密类型，启用 AES128-CTS-HMAC-SHA1-96 和 AES256-CTS-HMAC-SHA1-96 加密类型。
- 禁用 NTLM 身份验证。
Kerberos 加密类型
RC4 加密被认为比较新的加密类型、AES128-CTS-HMAC-SHA1-96 和 AES256-CTS-HMAC-SHA1-96 不太安全。 Windows 10 安全技术实施指南等 安全指南 通过将其配置为仅使用 AES128 和/或 AES256 加密（请参阅 Kerberos 加密类型必须配置为防止使用 DES 和 RC4 加密套件）来提高计算机的安全性。
此类客户端可以继续连接到其自己的域中使用 AES128 或 AES256 加密的服务。 但是，其他因素可能会阻止客户端连接到另一个受信任域中的类似服务，即使这些服务也使用 AES128 或 AES256 加密。
在非常高的水平上，域控制器（DC）负责管理其自己的域中的访问请求。 作为 Kerberos 身份验证过程的一部分，DC 会检查客户端和服务是否可以使用相同的 Kerberos 加密类型。 但是，当客户端请求访问不同受信任域中的服务时，客户端的 DC 必须“引用”客户端到服务域中的 DC。 当 DC 生成引荐票证时，它不比较客户端和服务加密类型，而是比较客户端和信任的加密类型。
之所以出现问题，是因为信任本身的配置。 在 Active Directory 中，域对象具有关联的受信任域对象（TDO），表示它信任的每个域。 TDO 的属性描述信任关系，包括信任支持的 Kerberos 加密类型。 子域和父域之间的默认关系是支持 RC4 加密类型的双向可传递信任。 父域和子域都有描述此关系的 TDO，包括加密类型。
当客户端联系 child.contoso.com DC 以请求访问服务时，DC 确定该服务位于受信任的域中 contoso.com。 DC 检查信任配置，以确定信任支持的加密类型。 默认情况下，信任支持 RC4 加密，但不支持 AES128 或 AES256 加密。 另一方面，客户端无法使用 RC4 加密。 DC 无法标识常见的加密类型，因此无法生成引荐票证，并且请求失败。
NTLM 身份验证
Kerberos 身份验证失败后，客户端会尝试回退到 NTLM 身份验证。 但是，如果禁用 NTLM 身份验证，则客户端没有其他替代方法。 因此，连接尝试失败。
解决方法
若要解决此问题，请使用以下方法之一：
- 方法 1：配置信任以支持 AES128 和 AES 256 加密，以及 RC4 加密。
- 方法 2：配置客户端以支持 RC4 加密，以及 AES128 和 AES256 加密。
- 方法 3：配置信任以支持 AES128 和 AES 256 加密，而不是 RC4 加密。
选择取决于你的安全需求，以及尽量减少中断或保持向后兼容性的需要。
方法 1：配置信任以支持 AES128 和 AES 256 加密，以及 RC4 加密
此方法将较新的加密类型添加到信任配置，并且不需要对客户端或服务进行任何更改。 在此方法中 ksetup ，使用命令行工具配置信任。
若要配置信任的 Kerberos 加密类型，请在受信任的域中打开 DC 上的命令提示符窗口，然后输入以下命令：
ksetup /setenctypeattr <trustingdomain> RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96
注意
在此命令中， <trustingdomain> 表示信任域的完全限定域名（FQDN）。
在根域（服务所在的位置）和child.contoso.com子域（客户端所在的位置）的示例中contoso.com，打开 DC 上的contoso.com命令提示符窗口，然后输入以下命令：
ksetup /setenctypeattr child.contoso.com RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96
此命令完成后， child.contoso.com DC 可以成功生成客户端可用于访问 DC 的 contoso.com 引荐票证。
由于两个域之间的关系是双向可传递信任，因此请通过在 DC 上打开命令提示符窗口，然后输入以下命令来配置信任的另一 child.contoso.com 端：
ksetup /setenctypeattr contoso.com RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96
此命令完成后，contoso.comDC 可以为无法使用 RC4 加密但必须使用资源child.contoso.com的任何客户端contoso.com生成引荐票证。
有关 ksetup 工具的详细信息，请参阅 ksetup。
方法 2：配置客户端以支持 RC4 加密，以及 AES128 和 AES256 加密
此方法涉及更改客户端的配置，而不是信任。 可以更改单个客户端的配置，或使用组策略更改域中多个客户端的配置。 但是，此配置更改的主要缺点是，如果禁用 RC4 加密以提高安全性，则可能不可能回滚该更改。
有关更改客户端可以使用的加密类型的完整说明，请参阅 适用于 Kerberos 支持的加密类型的 Windows 配置。
方法 3：配置信任以支持 AES128 和 AES 256 加密，而不是 RC4 加密
此方法类似于配置信任属性的方法 1。
对于 Windows 林信任，信任双方都支持 AES。 因此，信任上的所有票证请求都使用 AES。 但是，检查引荐票证的第三方 Kerberos 客户端可能会通知你票证使用客户端不支持的加密类型。 为了继续允许此类客户端检查票证，请将其更新为支持 AES。
使用此方法时，请使用 Active Directory 域 和 Trusts MMC 管理单元配置信任。 若要使用此方法，请执行以下步骤：
在Active Directory 域和信任中，导航到受信任的域对象（在本示例中
contoso.com）。 右键单击对象，选择“属性”，然后选择“信任”。在信任此域的域（传入信任）框中，选择信任域（在本示例中）。
child.domain.com选择“属性”，选择“其他域支持 Kerberos AES 加密”，然后选择“确定”。
注意
若要验证信任配置，请在“信任域”对话框中选择“ 验证 ”。
重要
对于单向信任，受信任的域将信任域列为传入信任，而信任域将受信任的域列为传出信任。
如果关系是双向信任，则每个域将另一个域列为传入和传出信任。 在此配置中，请确保检查此域（传入信任）和此域信任的域（传出信任）的域配置。 在这两种情况下，都必须选中该复选框。
在 “信任 ”选项卡上，单击“ 确定”。
导航到信任域的域对象（
child.contoso.com）。重复步骤 1 - 4 以确保此域的信任配置镜像其他域的信任配置（在本例中，传入和传出信任列表包括
contoso.com）。
详细信息
有关 TDO 的详细信息，请参阅以下文章：
有关 Kerberos 加密类型的详细信息，请参阅以下文章：