逐步实施 Active Directory 联合身份验证服务第二部分

在上一篇博客（逐步实施 Active Directory 联合身份验证服务）中，我向您展示了如何在内部网络和 DMZ 中安装和配置 Active Directory 联合身份验证服务 (ADFS)，该服务能够处理 Office 365 身份验证请求。在本博客中，我将向您展示如何配置 Office 365 以及如何测试它。

联合域

在典型的托管域中，用户帐户和密码哈希会同步到 Azure Active Directory。 Office 365 使用 Azure AD 中的域控制器对用户进行身份验证并授予他们对云中资源的访问权限。

在联合域中，用户访问 Office 365，但访问被拒绝，并且请求被重定向到 Azure Active Directory。在那里，发现主领域（用户的域），并根据主领域将请求重定向到 ADFS 服务器。如果我的用户帐户是 [email protected]，我的主领域是 Exchangelabs.nl，并且请求将重定向到之前创建的联合服务器，该联合服务器用于在 Azure Active Directory 中配置域。

我于 2017 年在 IT Dev Connections（旧金山）举办了一次有关此问题的会议，下面是一张可以下载的动画幻灯片，其中显示了客户端、Office 365、Azure AD 以及本地 ADFS 和域控制器之间的流程:

为了实现此功能，需要将 Azure Active Directory 中的域转换为联合域，以便 Azure AD 知道任何身份验证请求都需要重定向到本地 ADFS 环境。

将域添加到 Azure Active Directory 时，它会自动创建为托管域。如前所述，身份验证是针对 Azure AD 中的域控制器进行的。您可以使用 Get-MsolDomain -DomainName Exchangelabs.nl PowerShell 命令检查域，如以下屏幕截图所示：

要将其转换为联合域，请启动 PowerShell 命令（具有提升的权限）并输入以下命令：

[PS] C:\> Connect-MsolService

[PS] C:\> Set-MsolADFSContext -计算机 ams-adfs01.labs.local

[PS] C:\> Convert-MsolDomainToFederated -DomainName Exchangelabs.nl

注意。通过 Set-MsolADFSContext 命令使用本地第一个 ADFS 服务器的 FQDN，而不是联合 URL

这会将现有的本地基础结构连接到 Azure AD，并将域转换为联合域。现在，当使用与之前相同的命令检查 Azure AD 中的域时，您将看到它现在是一个联合域：

在 ADFS 管理控制台中，您将获得一个与 Office 365 一起使用的新依赖方信任 (RPT)：

要在 Azure AD 中详细了解联合设置，您可以使用 Get-MsolDomainFederationSettings 命令来显示更多信息：

清晰可见的是 Logon、Issuer 和 LogOffUri，它们指向我们的本地 ADFS 实施。可以使用 Get-MsolFederationProperty 命令检索更多信息，如以下屏幕截图所示：

要测试新配置，请导航到 Microsoft 在线门户并使用我们刚刚配置的域的帐户登录，即 [email protected]：

选择此帐户时，Azure AD 会确定主领域 (exchangelabs.nl) 并重定向到 Azure AD 联合设置中找到的本地 URL。您将在浏览器中看到这种情况实时发生：

几秒钟后，我们被重定向到本地 ADFS 环境：

清晰可见的是联合服务显示名称，它是在上一篇博文中使用第一个 ADFS 服务器配置的。

输入您的密码，奇迹的是，MFA 仍然有效（这对我来说是一个惊喜?）：

另一个有趣的测试是使用远程连接分析器（https://aka.ms/exrca），它具有单点登录测试。导航到远程连接分析器，单击 Office 365 选项卡并选择 Office 365 单点登录 -开启测试单选按钮。

输入用户名和密码，进行验证码测试并等待结果。您将看到类似于以下屏幕截图的内容：

登录尝试成功，但更有趣的是，您可以扩展所有测试步骤以查看幕后发生的情况并尝试了解 ADFS 的工作原理。

概括

在前两篇博文中，我演示了如何在本地基础设施中安装和配置 ADFS。我只安装了一台ADFS服务器和一台WAP代理，距离高可用环境还很远。为什么高可用？如果没有 ADFS 服务器，就无法再登录任何 Office 365 服务，因此任何 ADFS 实施都需要高可用的基础设施。

但客户正在转向云以停用其本地解决方案，并且通过 ADFS，我们正在构建用于验证云解决方案的本地解决方案。但出于合规性原因，可能需要针对本地域控制器进行身份验证（例如，云中没有密码）。另一方面，您也可以使用传递身份验证（PTA，请参阅我的博客文章 Azure AD Connect 传递身份验证）来实现此目的。 PTA 尚未提供与 ADFS 一样多的可能性，但它正在改进。

ADFS 是否面向未来？有人说不是，但只要我在 Microsoft 网站上找到类似 What's new in Active Directory Federation Services for Windows Server 2019 的文章，我就没有发现太多问题。

更多信息

• ADFS 内容地图 (Wiki) - https://social.technet.microsoft.com/wiki/contents/articles/2735.ad-fs-content-map.aspx#Office_365
• 实施您的 AD FS 设计计划 - https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/implementing-your-ad-fs-design-plan
• AD FS 2016 部署指南 - https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/ad-fs-deployment-guide
• Windows Server 2012 R2 AD FS 部署指南 - https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/windows-server-2012-r2-ad-fs-deployment-guide
• 使用 Azure 多重身份验证和 AD FS 保护云资源 - https://docs.microsoft.com/en-us/Azure/active-directory/authentication/howto-mfa-adfs
• 何时使用授权声明规则 - https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/when-to-use-an-authorization-claim-rule
• OWA 和 ECP 通过 WAP 使用 AD FS 登录 - https://vandijk.cloud/owa-and-ecp-login-with-ad-fs-through-the-wap/
• AD FS 用户登录自定义 - https://docs.microsoft.com/nl-nl/windows-server/identity/ad-fs/operations/ad-fs-user-sign-in-customization
• 用于云使用的 ADFS 高级自定义（第 2 部分，共 4 部分）- https://blogs.technet.microsoft.com/pauljones/2015/05/26/advanced-customization-of-adfs-for-cloud-usage-part- 4 中的 2/
• 用于云使用的 ADFS 高级自定义（第 3 部分，共 4 部分）- https://blogs.technet.microsoft.com/pauljones/2015/05/26/advanced-customization-of-adfs-for-cloud-usage-part- 4 中的 3/
• 用于云使用的 ADFS 高级自定义（第 4 部分，共 4 部分）- https://blogs.technet.microsoft.com/pauljones/2015/05/26/advanced-customization-of-adfs-for-cloud-usage-part- 4-of-4/