什么是 Azure Active Directory？

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

Azure AD 在全球 30 多个数据中心部署，利用 Azure 可用性区域（如果存在）。随着更多 Azure 区域的部署，这一数字正在快速增长。为了持久性，写入 Azure AD 的任何数据都会复制到至少 4 个且最多 13 个数据中心，具体取决于您的租户配置。在每个数据中心内，数据会再次复制至少 9 次，以确保持久性并扩展容量以处理身份验证负载。举例来说——这意味着在任何时间点，我们的最小区域中至少有 36 个目录数据副本可用。为了持久性，只有在成功提交到区域外数据中心后，对 Azure AD 的写入才算完成。这种方法既保证了数据的持久性，又提供了巨大的冗余——多个网络路径和数据中心可以处理任何给定的授权请求，系统会自动智能地重试并绕过数据中心内部和数据中心之间的故障。为了验证这一点，我们定期进行故障注入并验证系统对 Azure AD 所构建的系统组件故障的弹性。这甚至包括定期关闭整个数据中心，以确认系统能够容忍数据中心的丢失而不会对客户产生任何影响。…… Azure AD 已经是一个庞大的系统，运行在超过 30 万个 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 安装功能安装：

1
2

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，攻击者可能通过密码喷洒云账户然后获得对企业网络的访问权限。这不是理论或假设场景，并强调了 MFA 的重要性。

Office 365 密码喷洒工具 Ruler（Exchange）[Golang] SprayingToolkit（Lync/Skype for Business/OWA）[Python] LyncSniper（Lync/Skype for Business）[PowerShell] MailSniper（OWA/EWS）[PowerShell]

Office 365 密码喷洒缓解

通过启用“安全默认值”或配置自定义条件访问策略来禁用旧式身份验证。还强烈建议要求所有用户使用