Active Directory 中的错误配置会影响 Entra ID

我喜欢想象在微软的某个角落，负责 Entra ID（正式名称为 Azure AD）的团队陷入了持续的紧张状态。一方面，他们拥有独特且无疑令人满意的机会来设计下一代身份基础设施，该基础设施可以学习并超越过去的目录罪恶。集成多因素认证，管理员与非管理员界限清晰，根据行为风险因素强制重新认证！

但我也想象到，前瞻性的下一代 Entra ID 经常与已有 20 多年历史的目录基础设施联系在一起，一定会带来挫败感。该目录充满了众所周知的、根本无法修补的内在漏洞。

这种对视觉的妥协不仅仅是理论上或美学上的——一些最引人注目的 Entra ID 开发是通过滥用 Active Directory (AD) 实现的。

在这篇文章中，我们将研究 Active Directory 中影响 Entra ID 安全性的三个错误配置，以及如何最好地降低该风险。

具有管理权限的 Hybrid Entra ID 用户

在 Entra ID 领域，混合用户是链接到本地 Active Directory 用户并由其控制的用户帐户。在 Active Directory 的混合配置中使用 Entra ID 对于组织和最终用户来说都非常方便。它将本地用户无缝扩展到云中并提供单点登录。

当混合用户分配有管理角色、可以使用 Azure 特权身份管理请求角色成员资格或者是强大服务主体的所有者时，就会出现问题。如果是这种情况，攻击者只需接管本地帐户，然后接管 Entra ID 管理帐户 - 巧妙地绕过 Entra ID 中内置的现代安全控制。

为了避免 Active Directory 中的这种错误配置：Entra ID 中的所有管理帐户都应该是云本机帐户。

Entra ID 中权限分配方式的一项最新变化是“角色可分配组”。通过“角色可分配组”，可以创建一个可以分配特权角色的组。然后，该组的成员将获得该角色对 Entra ID 目录的管理权限。

从某种意义上说，这是一种更为传统的为用户分配权限的方式。它类似于在 Active Directory 中分配权限的方式 - 将用户帐户添加到“帐户操作员”等组中，该组授予目录的委派权限。

组织的潜在优势不难看出。许多组织都有预先存在的系统，可以帮助管理组成员的生命周期。通过角色可分配组，Entra ID 中的权限可以插入到这些现有系统中，并像本地 AD 一样进行管理。

但是，我在实施角色可分配组时会持谨慎态度，特别是对于全局管理员或用户管理员等最强大的角色。首先，使用组进行特权管理的一个有吸引力的方面是可以使用现有的工作流程和工具集来管理它们。但是权限，特别是高权限，应该是临时的，这意味着用于管理角色可分配组的任何工具集都应该能够进行“及时”分配。例如，Entra ID Governance 或 Azure AD Premium P2 附带的 Azure 特权身份管理可以执行此操作。

然而，与角色不同的是，Azure PIM 无法控制谁有资格成为组成员，也无法控制添加到组的其他方式，例如使用 Exchange 管理中心。总而言之，如果您通过组分配权限，则更难以设置控件来防止混合用户在 Entra ID 中获得管理权限。如果您选择使用角色可分配组，请注意此风险。

使用 Active Directory 验证 Entra ID 用户

在信息技术中，大多数决策都涉及权衡，通常是在安全性和可用性之间进行权衡。典型的例子：将成熟的身份验证模式从 Active Directory 扩展到 Entra ID 是很诱人的。毕竟，用户熟悉他们的 Active Directory 登录并且已经每天使用它。组织甚至可能已经拥有成熟的工具或流程来管理 Active Directory 身份验证。此外，服务台还接受过培训，了解如何在用户因身份验证问题致电时确保良好的用户体验。

坚持使用 Active Directory 身份验证的“优点”很明显，而且这些“优点”通常也得到组织动力的支持。 Microsoft 为您提供了一个系统，使您能够利用这些“优点”——Active Directory 联合服务或 ADFS。 ADFS 将 Entra ID 身份验证与本地 Active Directory 联合，使 Active Directory 成为 Entra ID 的身份验证系统。

但这种方法的缺点可能是毁灭性的。首先，Active Directory 本质上是一个不如 Entra ID 安全的平台，这在很大程度上是因为它是 20 多年前设计的。这意味着，要获得对混合云帐户的访问权限，攻击者可以针对本地 Active Directory 使用众所周知的技术，而不是相对更安全和现代的 Entra ID。

更重要的是，ADFS 系统本身已被证明容易受到攻击，并且已成为多次引人注目的 Microsoft 365 违规行为的渠道。值得注意的是，威胁参与者 Midnight Blizzard 因针对目标而闻名ADFS，是 2021 年底利用 Solarwinds 的 Orion 软件进行攻击的幕后黑手。

要避免 Active Directory 中的这种错误配置：从使用 ADFS 迁移到 Active Directory 和 Entra ID 之间的密码哈希同步。

虽然这可能是一项艰巨的任务，但它在安全性和可用性之间取得了良好的平衡。用户不必管理多个密码，并且可以拥有单点登录体验，同时利用多因素身份验证、无密码身份验证和条件访问策略等 Entra ID 安全功能。

在 Active Directory 和 Entra ID 之间使用密码同步需要注意的一件事：Entra ID 很乐意接受在本地 Active Directory 中设置的任何密码。 Entra ID 中的密码策略比 Active Directory 中的密码策略复杂得多，例如能够禁止已知被泄露的密码。尽管通过使用第二因素或无密码身份验证，密码在现代身份验证中变得不那么重要，但它们对于安全仍然很重要。幸运的是，微软对此有一个解决方案——Azure 密码保护。这使您能够将所有重要的 Entra ID 密码规则扩展回本地 Active Directory，确保其同步的密码受到的审查不低于专门使用 Entra ID 设置的密码。

当然，请记住第一点 - Entra ID 中具有特权的帐户不应该是混合的，即使采用正确设计的身份验证！

将 Azure AD Connect 视为成员服务器

Azure AD Connect 是将本地 Active Directory 连接到 Entra ID 的服务。该服务使混合目录……混合。

Azure AD Connect 也经历了长期的技术演变，其安全模型以及用于与 AD 和 Entra ID 交互的权限发生了重大变化。不幸的是，许多安装仍在使用具有过于强大的凭据的旧权限模型。

开源工具集（尤其是 AADInternals）提供的命令使 Azure AD Connect 系统的本地管理员能够提取 Azure AD Connect 用于与 Entra ID 和 Active Directory 交互的帐户的纯文本凭据。

这种组合是毁灭性的。这被用于“芒果沙尘暴”民族国家攻击。

“在勒索软件部署前两周，我们发现威胁行为者使用受损的凭据来访问 Azure AD Connect 设备。接下来，他们建立了一条通往攻击者控制的设备的 SSH 隧道。在攻击者控制的单独受感染设备上，证据表明 AADInternals 工具被克隆。此工具库中提供的功能之一是 Get-AADIntSyncCredentials，它允许安装了 Azure AD Connect 的设备上的任何本地管理员提取两个设备的纯文本凭据。 Azure AD 连接器帐户和 AD DS 连接器帐户。 ”

换句话说，攻击者利用对 Azure AD Connect 系统的访问权限，通过转储凭据来滥用该系统，从而使他们能够从本地主导地位转移到互联云环境的主导地位。

是的，通过现代化 Azure AD Connect 权限可以削弱这种特定攻击的影响。但这就像与保安玩打地鼠游戏。更根本的是，问题的出现是因为攻击者能够收集受损的凭据，从而允许他们对 Azure AD Connect 进行管理访问。

为了避免 Active Directory 中的这种错误配置：应像控制 Active Directory 的任何其他服务器一样控制对 Azure AD Connect 服务器的访问。

将 PAM 托管凭据与多个因素结合使用，并结合网络级别控制 - 无论您的工具包中有什么工具可以用来保护域控制器，也可以使用它们来保护 Azure AD Connect。

您可能知道这种受到超级保护的资产的概念是“Tier-0”或控制平面资产。无论如何，从实际角度来看，您不能像对待大多数其他成员服务器一样对待 Azure AD Connect 服务器。

结论

Entra ID 的最大风险是它与复杂的遗留本地 Active Directory 环境的联系。大多数组织不太可能完全切断这些联系，因为这对用户生产力的影响太大了。但是，如果您可以避免 Active Directory 中的这三种常见错误配置，则可以显着降低 Entra ID 目录的风险，而不会大幅降低用户的工作效率和满意度。