什么是 Azure Active Directory？

许多人对 Active Directory 很熟悉，它是 Windows Server 提供的本地目录和身份验证系统，但 Azure Active Directory 到底是什么？Azure Active Directory（Azure AD 或 AAD）是一个多租户云目录和身份验证服务。Azure AD 是 Office 365（和 Azure）用于账户、组和角色的目录服务。它也是一个身份提供者（IPD）并支持联合身份验证（SAML 等）。注意：鉴于云变化迅速，本文的某些内容可能在原始发布日期后很快过时。Azure AD 具有高可用性并全球部署。

Azure AD 在全球 30 多个数据中心部署，利用 Azure 可用性区域（如果存在）。随着更多 Azure 区域的部署，这个数字正在快速增长。为了持久性，写入 Azure AD 的任何数据都会复制到至少 4 个且最多 13 个数据中心，具体取决于租户配置。在每个数据中心内，数据会再次复制至少 9 次以实现持久性，同时也扩展容量以服务身份验证负载。举例来说——这意味着在任何时间点，我们的最小区域中至少有 36 份目录数据副本可用。为了持久性，写入 Azure AD 只有在成功提交到区域外数据中心后才完成。这种方法既保证了数据的持久性，又提供了巨大的冗余——多个网络路径和数据中心可以服务任何给定的授权请求，系统会自动智能地重试并绕过数据中心内和跨数据中心的故障。为了验证这一点，我们定期进行故障注入并验证系统对 Azure AD 构建的系统组件故障的弹性。这甚至延伸到定期关闭整个数据中心以确认系统可以容忍数据中心的丢失，且对客户零影响。…… Azure AD 已经是一个庞大的系统，运行在超过 300,000 个 CPU 核心上，并能够依赖 Azure 云的大规模可扩展性动态快速地扩展以满足任何需求。这包括流量的自然增加，例如某个区域上午 9 点的身份验证峰值，以及由我们的 Azure AD B2C 服务的新流量激增，它支持一些世界上最大的事件，并经常看到数百万新用户的涌入。……为了支持健康检查（这些检查控制安全部署并为我们的工程团队提供系统健康洞察），Azure AD 发出大量内部遥测、指标和信号，用于监控系统健康。在我们的规模下，每周有超过 11 PB 的信号输入到我们的自动化健康监控系统。https://azure.microsoft.com/en-us/blog/advancing-azure-active-directory-availability/

Azure Active Directory 不是云 AD

Azure Active Directory 不是托管在云中的 Active Directory。没有标准的 AD 身份验证方法，如 NTLM 或 Kerberos；没有 LDAP；也没有组策略（GPO），因此 Azure AD 不适用于传统的本地应用程序。有云托管的 Active Directory 环境可用于管理 Microsoft Azure（Azure Active Directory 域服务）、Amazon AWS（Amazon Managed Microsoft AD）和 Google Cloud（Managed Service for Microsoft Active Directory (AD)）中的云工作负载。这些都是托管的 Microsoft Active Directory 环境，有 2 个或更多域控制器，租户管理员不会获得对托管 AD 环境的域管理员权限；只提供委派访问，通常包括在特定 OU 中创建/管理资源和特定 GPO 的能力。注意：我这里没有空间比较这些服务，但如果有兴趣，我可能会写一篇未来的文章（我在 2017 年做了一些研究，比较了 Microsoft Azure 和 Amazon AWS 的托管 AD 服务产品）。

主要管理工具

大多数 AD 管理员熟悉的工具是 Active Directory 用户和计算机，又名 ADUC（MMC 工具）。Azure Active Directory 管理员将主要使用 https://portal.azure.com 的 Web 控制台来管理环境。管理本地 Active Directory 和现在 Azure AD/Office 365 的管理员将使用本地 MMC 工具以及 Web 管理门户（及其相关各种 URL）。有用于管理 Azure AD 的 PowerShell cmdlet（类似于本地），但云功能通常比 PowerShell 工具发布得更快，这意味着即使在使用 PowerShell 时，仍应使用云管理门户。

与 Azure Active Directory 交互

由于 Azure AD 没有 LDAP，与 AAD 交互涉及通过 Graph API（或 PowerShell 模块）连接。我喜欢 PowerShell，所以我使用 PowerShell 模块（或门户网站）进行管理和报告。有两个主要的 PowerShell 模块用于与 Azure AD 交互：MSOnline 和 AzureAD。这些可以通过 PowerShell 安装功能安装：Install-Module -Name MSOnline -Force 和 Install-Module -Name AzureAD -Force。AzureAD 模块可能最终会取代 MSOnline PowerShell 模块，但 MSOnline 中有一些功能尚未移植到 Azure AD 模块（目前）。

Azure AD PowerShell 模块和 Cmdlet 比较

（模块和 cmdlet 数据截至 2020 年 1 月）

在上表中，我对两个 Azure AD PowerShell 模块的 cmdlet 进行了分类，并尝试链接提供相同或类似功能的 cmdlet。我计划在未来发布更多关于这些 cmdlet 的内容。

不幸的是，单点登录（SSO）到这些模块并不是一件简单的事情。可以在 PowerShell 中捕获凭据并在模块之间重用，但前提是没有强制执行 MFA（这会降低账户安全性）。Microsoft 云环境最初仅支持用户名和密码身份验证。这种“旧式身份验证”不包括多因素身份验证（“MFA”），因此出于安全原因，应禁用旧式身份验证（通过安全默认值、条件访问等）。Azure Active Directory 身份验证库提供“现代身份验证”，完全支持 MFA（和无密码！）。

根据 Microsoft 的说法，ADAL：Azure Active Directory 身份验证库（ADAL）v1.0 使应用程序开发人员能够向云或本地 Active Directory（AD）验证用户身份，并获取用于保护 API 调用的令牌。ADAL 通过以下功能使身份验证对开发人员更容易：

• 可配置的令牌缓存，存储访问令牌和刷新令牌
• 当访问令牌过期且刷新令牌可用时自动刷新令牌
• 支持异步方法调用

有一个 ADAL PowerShell 模块（Install-Module -Name adal.ps），它提供跨模块（支持它的模块）的某种程度的 SSO。安装 ADAL 模块后，运行以下命令以在会话中加载 ADAL 令牌：

1
2
3
4
5
6

$clientId = "1b730954-1685-4b74-9bfd-dac224a7b894" # Azure AD PowerShell
$redirectUri = [Uri]::new('urn:ietf:wg:oauth:2.0:oob')
$authority = "https://login.windows.net/common/oauth2/authorize"
$resourceUrl = "https://graph.windows.net"

$ADALresponse = get-adaltoken -Resource $resourceUrl -ClientId $clientId -RedirectUri $redirectUri -Authority $authority -PromptBehavior:Always

一旦捕获了 $ADALResponse 变量，您就可以在 Azure AD 模块中利用此令牌：

1
2
3
4
5
6

$ConnectAzureADInfo = connect-azuread -AadAccessToken $ADALresponse.AccessToken -AccountId $ADALresponse.UserInfo.DisplayableId

$ConnectMsolInfo = connect-msolservice -AdGraphAccessToken $ADALresponse.AccessToken

# 看起来 Microsoft Teams PowerShell 模块也支持 ADAL，不过我添加了一个包含已登录用户 UPN 的新变量。
Connect-MicrosoftTeams -AadAccessToken $ADALresponse -AccountId $AssessmentAccountUPN

对 Azure Active Directory 的访问权限

对于 Active Directory，几乎所有内容都可以作为普通用户查看。Azure AD 用户可以查看有关用户和组的信息，但在可访问的内容方面有一些限制。在 Azure AD 中，特权组称为“角色”（即组）以标识特殊访问。Office 365 中有几个这些管理员角色，它们提供对全部或特定部分 Office 365 的管理员级权限。（分配角色）许多组织在全局管理员（又名租户管理员）角色中有一个报告账户，这实际上是企业管理员、域管理员和架构管理员组合成一个组。全局管理员对 Azure AD 和所有 Office 365 服务拥有完全控制权。这就是为什么许多组织有超过 5 个全局管理员（Microsoft 的最大推荐数量）。只有云账户应添加到角色中，以便它们可以利用 Azure MFA（和无密码）以及由 PIM 控制的角色成员资格。还强烈建议创建一个（或两个）“紧急访问”管理员账户，以确保对租户的持续特权访问。Microsoft 发布了一份关于如何保护特权访问的文档。强烈建议使用特权身份管理（PIM）来控制角色成员资格，并且每个将使用 PIM 的账户都需要 Azure AD Premium 2（P2）许可证。PIM 提供对具有所需权限的管理员角色的即时访问。当管理员需要管理员权限时，他们可以通过 PIM 请求和获得访问权限（可以发送审批或自动批准）。Microsoft 建议所有角色中的账户都由 PIM 管理（并拥有 AAD P2 许可证）。还有一个用于 PIM 的 Powershell 模块可以安装：Install-Module -Name Microsoft.Azure.ActiveDirectory.PIM.PSModule。在 2019 年秋季，Microsoft 添加了一个名为“全局读取者”的新角色，该角色具有对全局管理员可以看到的所有 Azure AD/Office 365 服务的只读/仅查看权限（有一些例外，因为 Microsoft 仍在向所有 Office 365 服务推出全局读取者只读功能）。全局读取者的成员资格应提供给需要 Microsoft 云（Azure AD 和 Office 365）环境仅查看访问权限的安全团队或审计员。

攻击 Azure Active Directory

Office 365 服务可从互联网访问（默认情况下，使用条件访问限制访问），这使它们对攻击者具有吸引力。攻击者利用几种攻击方法针对 Azure AD 和 Office 365。

账户枚举

使用老式的 Active Directory，任何 Active Directory 用户都可以枚举所有用户账户和管理员组成员身份，只要具有对域控制器的网络访问权限。Azure Active Directory 用户可以枚举所有用户账户和管理员组成员身份，只要具有对 Office 365 服务的访问权限（默认情况下是互联网）。用户枚举通常可以在没有账户的情况下使用 O365creeper 进行，该工具尝试使用电子邮件地址列表向 O365 进行身份验证。根据响应代码，该工具确定电子邮件地址是否是有效的用户账户（或不是）。Azure AD 枚举工具 O365 Creeper – Office 365 身份验证页面（Python）[账户发现]OWA（Golang）ActiveSync（Python）MSOnline/AzureAD PowerShell 模块（PowerShell）

密码喷洒

攻击者以及许多渗透测试人员和红队人员利用的一种常见方法称为“密码喷洒”。密码喷洒很有趣，因为它是自动化的密码猜测。这种针对所有用户的自动化密码猜测通常避免账户锁定，因为使用特定密码的登录尝试是针对每个用户执行的，而不是针对一个特定用户，这是账户锁定设计要击败的。攻击者从一个他们将要尝试的密码列表开始，从最可能的密码（“Fall2017”、“Winter2018”等）开始。当密码喷洒开始时，我们从列表中的第一个密码开始。该第一个密码用于尝试作为每个用户（或子集）进行身份验证。这个密码针对每个用户尝试，一旦所有用户都用该密码测试过，我们就移动到下一个。

密码喷洒相对容易执行且非常有效。我们与许多组织合作过，这些组织的账户通过密码喷洒其云环境而被入侵。许多联合客户没有意识到这是他们的工作来寻找这个，而不是云的工作。密码喷洒存在超出云的实际风险。如果云账户和本地使用相同的密码，并且没有配置 MFA，攻击者可能密码喷洒云账户，然后获得对企业网络的访问权限。这不是