在 AD 中拥有服务帐户对 Kerberos 使用 RC4 而不是 AES 的影响？

信息安全 AES 活动目录 kerberos rc4
2021-08-27 10:35:39

请耐心等待，我知道这很草率，但这是背后的故事：

我们有一个使用 Jira 的合作伙伴，并且正在使用带有自定义身份验证后端的 spnego，该后端需要令牌中的某些组成员身份。假设提供的令牌满足要求，则授予用户对 Jira 的 SSO 访问权限。

我们与该合作伙伴有来自我们的一个子域的双向非传递外部信任。由于这是一种陈旧而顽固的外部信任，而不是选择性的森林信任，因此 AD 不会维护 Kerberos 所需的信息，以用于域之间的交互式登录以外的任何事情。

他们这边为这项服务注册了一个 SPN，但是我这边的客户找不到这个 SPN，因为 Kerberos 推荐是不可能的。这显然是一个问题，因为它会导致客户端回退到 NTLM 而他们不进行 SSO。

建议的解决方法是在我们这边也创建一个服务帐户，并在我们这边为与他们相同的服务注册一个 SPN。每一侧的密码必须相同。这将不需要通过推荐来找到合适的 SPN，因为我们有效地在我们这边镜像它，并“欺骗”我们孩子的客户使用它，而不是他们那边的正确客户。他们还建议我们将这些镜像帐户的加密算法降低到 RC4 而不是 AES。

这是我的知识开始动摇的地方，我不知道为什么需要将加密算法降低到 RC4 的步骤。我也不知道它可能对安全造成什么影响。

这意味着什么？为什么我们不能坚持使用 AES 来完成这项工作？

2个回答

我能想到他们为什么要使用 RC4 的最大原因是因为与 Jira 的兼容性（或者这个我们无法审查的自定义身份验证后端。）

AES128 支持与 Server 2008 和 Vista 一起引入，AES256 与 2008 R2 和 Win7 一起引入。但是，在预身份验证期间，当与 Windows 2000 客户端交谈时，KDC 将自动协商到（例如）RC4。所以应该没有必要强迫它。

当然你也可以配置用户和电脑账号支持或不支持DES、AES128、AES256等。

这意味着它的加密类型不如较新的 AES 加密类型强。但这也不可怕。

我当然很想听听他们为什么要使用 RC4 的理由。您提出的使用镜像 SPN 的技巧与蠕虫完全不同，但客户端和 KDC 之间使用的加密类型应该与它是否有效无关。

您（或他们，提议更改的人）没有给出切换到 RC4 的理由，是吗？RC4 是一种流密码，在某些特定情况下很容易受到攻击：

RC4 的弱点不利于其在新系统中的使用。当输出密钥流的开头没有被丢弃，或者使用非随机或相关密钥时，它尤其容易受到攻击。（维基百科）

因此，使用 RC4 的含义是（至少）上述内容的脆弱性。我不明白为什么 AES 不成立，没有改变的理由..

其它你可能感兴趣的问题
上一篇如何使用 NMap 对阻止所有尝试的 SonicWall 进行端口扫描？ 下一篇哪些 OID 颁发策略适用于智能卡和浏览器证书？