提高在同一地点用户站点部署的联合认证应用程序的身份验证弹性。

许多组织在其身份和访问管理架构中为增强复原能力而设计时，需要考虑的一种情况是，在临时站点断开连接期间应用访问的连续性。 组织可能具有部署其应用程序的一个或多个物理站点。 其中一些用户位于这些站点，需要能够访问本地应用程序。 例如，工厂或商店的员工可能需要能够登录到管理该站点运营的内部开发的业务应用程序。

从历史上看，组织可以使用 Active Directory 域服务， 在每个站点部署域控制器，以便用户可以向本地域控制器进行身份验证。 通过 Microsoft Entra 对用户进行身份验证，并通过联合身份验证协议（例如 SAML）将应用程序连接到 Microsoft Entra ID 会带来好处，包括多重身份验证和基于风险的条件访问。 当应用程序与 Microsoft Entra 联合时，用户通过 Microsoft Entra 进行身份验证，然后 Microsoft Entra 提供携带声明并指示其身份验证状态的令牌给应用程序。 但是，如果站点与 Internet 之间的网络连接中断，则用户和应用程序无法访问 Microsoft Entra 云终结点。 连接中断后，无法再通过该路由将令牌从 Microsoft Entra 颁发到应用程序，直到中断修复为止。 已向应用程序进行身份验证并能够连接到应用程序的用户可能能够一段时间继续使用该应用程序。 但是，如果应用程序要求用户重新进行身份验证并且中断尚未修复，则用户将无法从 Microsoft Entra 获取新的访问令牌。 此外，在修复中断之前，任何以前未连接到应用程序的用户也可能发现自己无法使用该应用程序。

解决此问题并确保即使在临时站点断开连接期间也能向联合应用程序颁发令牌的一种方法是：

• 在每个站点维护 Active Directory 域控制器
• 确保站点上的用户可以向 Active Directory 或 Microsoft Entra 进行身份验证，并且可从两个标识提供者获取相同的声明
• 将应用程序配置为在正常作期间信任 Microsoft Entra 作为标识提供者，但在断开连接事件期间，信任 Active Directory 作为标识提供者

但是，对于某些预打包的联合应用程序，应用程序可能设计为一次使用单个标识提供者进行作，并且将应用程序配置为具有多个受信任的标识提供者可能不可行。 即使对于内部开发的应用程序专为单个标识提供者设计的组织，也可能需要大量的工程努力来实现一个更改具有不同配置模型的许多应用程序的过程。

本教程中所述的替代方法是将信赖方安全令牌服务（STS）（如 AD FS）添加到拓扑。 在此拓扑中，

• 在每个站点维护 Active Directory 域控制器
• 确保站点上的用户可以向 Active Directory 或 Microsoft Entra 进行身份验证
• 将应用程序配置为信任本地信赖方安全令牌服务（STS）
• 将信赖方 STS 配置为在正常操作期间信任 Microsoft Entra 作为标识提供者，而在断开连接事件期间信任 Active Directory 作为标识提供者。

本教程演示如何使用信赖方 STS 为联合应用程序配置 Microsoft Entra。 在正常作中，用户将对 Microsoft Entra 进行身份验证，Microsoft Entra 将为应用程序颁发令牌。 在站点断开连接的情况下，用户可以向 Active Directory 进行身份验证，并获取该应用程序的令牌，其声明与 Microsoft Entra 提供的声明类似。 尽管在断开连接期间，Microsoft Entra 功能（包括多重身份验证或基于风险的条件访问）不适用于应用程序，但用户将继续能够进行身份验证以访问这些应用程序。

重要

本指南适用于已熟悉跨多个站点部署域控制器并使用 AD FS 等联合技术为 Active Directory 用户提供对声明感知应用程序的访问权限的组织。 Active Directory、AD FS 和相关技术的体系结构和部署，以实现网络中断的高可用性和复原能力是一项重大投资。 在开始本文所述旅程前，请先确定您的 AD FS 部署拓扑。 如果尚未部署 AD 域以实现高可用性，或 已验证生产环境是否可以支持 AD FS 部署，则选择另一种方法进行复原。

建议您在生产租户中配置应用程序或故障转移之前，先在非生产性环境中测试本文中的各项步骤。

先决条件

本教程依赖于 Microsoft Entra 租户和 Active Directory 域。 在开始之前，请确保在 Microsoft Entra 中具有以下角色之一： Cloud Application AdministratorApplication Administrator 还需要管理 AD 的权限。

你需要确保在每个站点上有足够的基础结构组件来支持应用程序，而无需依赖连接到 Internet 或其他站点。 本教程演示了以下对象的配置：

• 一个或多个应用程序，其中每个应用程序都实现联合协议，例如 SAML，登录模式由信赖方发起。 有关详细信息，请参阅 单一登录 SAML 协议。 本教程演示了一个配置，如果有多个应用程序，则可以对同一组用户进行身份验证并对所有应用程序进行授权。 为每个应用程序配置不同的用户集超出了本教程的范围。
• 可以配置为作为信赖方 STS（例如 Active Directory 联合身份验证服务）运行的标识组件。 本教程假定 Windows Server 2025。 作为安全最佳做法，请将 Active Directory 联合身份验证服务联合服务器置于防火墙后面，并将其连接到企业网络，以防止从 Internet 泄露。 这种做法很重要，因为联合服务器具有授予安全令牌的完全授权。 因此，它们应具有与域控制器相同的保护。 如果联合服务器遭到入侵，恶意用户能够向受 Active Directory 联合身份验证服务保护的所有 Web 应用程序颁发完全访问令牌。 有关详细信息，请参阅 联合服务器的位置。
• Active Directory 域控制器。 在生产环境中，需要配置多个域控制器以实现高可用性。

应用程序可能具有超出这些标识要求的其他要求，例如日志保留、DNS/DHCP 或其他网络和基础结构服务的要求，这些要求超出了本教程的范围。

确保 Active Directory 和 Microsoft Entra ID 中的一致用户标识和属性

无论配置的身份提供者如何，应用程序都期望从信赖方安全令牌服务 (STS) 接收联合令牌中的相同用户声明。 为了使信赖方 STS 能够在 Microsoft Entra ID 无法访问时，仍提供与其预期相同的声明，现场必须有一个用户标识及其属性的本地源，供信赖方 STS 用于生成这些声明。 AD FS 支持将 Windows Server Active Directory 作为标识源，这些 Active Directory 用户属性作为声明源。

维护一致性的一种方法是在 AD 中创建和更新用户的标识管理过程，然后将这些用户从 AD 同步到 Microsoft Entra。 检查您的 AD 环境和关联的 Microsoft Entra 代理是否已准备好在应用程序所需的架构支持下，将用户传入和传出 AD。

如果已将用户配置为从 Active Directory 同步到 Microsoft Entra，请继续下一部分。

1. 启用 Active Directory 回收站。 Microsoft Entra 生命周期工作流需要回收站功能才能从 AD 中删除用户。 有关详细信息，请参阅 使用 Active Directory 管理中心启用和管理 Active Directory 回收站。

2. 根据需要扩展 Active Directory 架构。 对于 Microsoft Entra 和您的应用程序所需而不在 AD 用户架构中的每个用户属性，您需要选择一个内置的用户扩展属性。 或者，你需要 扩展 Windows Server AD 架构 ，以便让 AD 保留该属性。 此要求还包括用于自动化的属性，例如工作人员的加入日期和休假日期。

   例如，一些组织可能使用属性 extensionAttribute1 和 extensionAttribute2 来保存这些属性。 如果选择使用内置扩展属性，请确保这些属性尚未由任何其他基于 LDAP 的应用程序使用，或者由与 Microsoft Entra ID 集成的其他应用程序使用。 某些组织已创建新的 AD 属性，其名称特定于其要求，例如 contosoWorkerId。 但是，使用新属性扩展架构会对 Windows Server 域管理产生重大影响。 有关详细信息，请参阅 扩展架构。

3. 将具有来自权威来源的属性的用户导入。 如果尚未这样做，请将 Microsoft Entra 配置为将来自 Workday、SuccessFactors 或 其他人力资源来源 的员工预配为 AD 中的用户。 可以将工作人员记录的属性映射到 AD 架构中的用户属性。

4. 设置 Microsoft Entra 和 Active Directory 之间的同步。 配置 Microsoft Entra Connect 同步或 Microsoft Entra 云同步 ，以便将这些用户从 AD 同步到 Microsoft Entra。 此外，部署预配代理，以便执行 生命周期工作流用户帐户任务，例如从 AD 中删除用户。

5. 扩展 Microsoft Entra ID 架构，并将 Active Directory 架构中的映射配置为Microsoft Entra ID 用户架构。 如果使用 Microsoft Entra Connect Sync，请执行以下步骤 Microsoft Entra Connect Sync：目录扩展 以使用属性扩展 Microsoft Entra ID 用户架构。 为 AD 的属性配置 Microsoft Entra Connect 同步映射，并将其映射到 Microsoft Entra ID 中的属性。

   如果使用 Microsoft Entra Cloud Sync，请执行 Microsoft Entra Cloud Sync 目录扩展和自定义属性映射 中的步骤，以使用任何其他必要属性扩展 Microsoft Entra ID 用户架构。 为 AD 的属性配置 Microsoft Entra Cloud Sync 映射，并将其映射到 Microsoft Entra 中的属性。 确保同步 生命周期工作流所需的属性。

6. 创建一个阻止登录的离职工作流。 在 Microsoft Entra 生命周期工作流中，配置一个离职工作流，其中包含阻止用户登录到本地环境的任务 Disable user account 。 此工作流可以按需运行。 如果您没有配置来自记载源的入站预配，以阻止员工在预定离职日期之后登录，请配置一个离职工作流，使该任务能在这些员工的预定离职日期运行。 有关详细信息，请参阅 管理从本地同步的用户。

7. 创建一个离职者工作流以删除用户帐户。 在 Microsoft Entra 生命周期工作流中，配置离职流程，并使用 Delete user 任务从 Active Directory 中删除用户。 安排此工作流在工作人员的计划离职日期之后运行一段时间，例如 30 或 90 天。

有关为具有多个属性的应用程序设置 HR 入站流的详细信息，请参阅 为用户预配计划部署 Microsoft Entra。

为 Active Directory 中的用户提供身份验证选项

配置从 HR 源到 AD 的入站预配时，Microsoft Entra 会在 AD 中创建用户，这适用于以前没有 AD 用户帐户的现有员工以及以后加入的任何新员工。 这些用户需要在断开连接时能够向 AD 进行身份验证，并且能够在正常作期间向 Microsoft Entra ID 进行身份验证。 需要计划为需要使用 AD 的应用程序访问权限的员工颁发凭据。

如果连接到 AD 的唯一应用程序是为复原而配置的，则具有一致身份验证的一种方法是在 AD 中创建用户，然后为从 AD 同步到 Microsoft Entra 的用户启用 密码哈希同步 。 确保用户在 AD 中设置了密码，并且他们在 AD 中知道其密码。 尽管它们在正常作期间可能具有多重身份验证要求，但当网络事件断开连接时，他们可以使用其密码向 Active Directory 域进行身份验证。

另一种选择是使用 Microsoft Entra 基于证书的身份验证（CBA），这使得 Microsoft Entra 能够使用由企业公钥基础设施（PKI）颁发的 X.509 证书对用户进行身份验证。 AD 还支持证书身份验证，某些组织已向其用户颁发智能卡、虚拟智能卡或软件证书。 如果用户将从支持 Windows Hello 企业版的设备与应用程序进行交互，则还应考虑让用户在 Windows Hello 企业 版中注册，以便进行更强身份验证。

部署信赖方 STS

如果尚未这样做，请在站点的一个或多个 Windows Server 上 部署 AD FS 或类似标识技术。 此 AD FS 将配置为作为信赖方 STS 运行，因此不能与配置为标识提供者的另一个 AD FS 相同的安装，以便向 Microsoft Entra 提供声明。

注释

如果您已经将 AD FS 用作 Microsoft Entra 的标识提供者，则此受信任方 STS 应在单独的已加入域的服务器上独立安装。 按角色分隔 AD FS 部署有助于避免Microsoft Entra 和 AD FS 之间的循环依赖关系。

注释

本指南不介绍如何部署 AD 以实现高可用性，也不介绍如何在 Windows Server 环境中部署 联合服务器场 或其他高可用性注意事项。

如果使用基于证书的身份验证，则还需要将 AD FS 配置为使用证书对用户进行身份验证。 有关详细信息，请参阅 为用户证书身份验证配置 AD FS 支持。

保护依赖方 STS

应用程序将信赖方 STS 视为可信，信赖方 STS 将提供指示用户已通过身份验证的令牌。 这要求确保 STS、托管它的服务器以及任何上游域控制器或其他资源被锁定到与环境中其他标识基础结构相同的安全标准。

有关详细信息，请参阅 保护 Active Directory 联合身份验证服务的最佳做法。

将联合应用程序连接到信赖方 STS

需要确定站点中的哪些应用程序适合连接到信赖方 STS，而不是直接连接到 Microsoft Entra。 这应该是在连接丢失期间维护操作所需的最低配置。 注意事项包括：

• 仅依赖Microsoft身份验证库（MSAL） SDK进行令牌颁发的应用程序无法连接到受信任方 STS。
• 以前使用单个联合元数据终结点或颁发者证书硬编码的应用程序可能需要进行其他更改，以便在与信赖方 STS 集成之前删除该依赖项。
• 支持多个标识提供者的应用程序可能希望保留与 Microsoft Entra 的现有连接。
• 与信赖方 STS 关联的应用程序将表示为 Microsoft Entra 中的单个应用程序，因此这些应用程序需要具有相同的用户、CA 策略、提供的声明以及其他适用的设置。 如果两个应用程序依赖 Microsoft Entra 将令牌的颁发限制在不同的用户群体，或具有不同的证书颁发机构（CA）要求，则它们不能同时连接到同一个信赖方安全令牌服务（STS）。

将 Microsoft Entra 配置为信赖方 STS 的标识提供者

按照“启用单一登录”教程执行步骤，以便通过信赖方安全令牌服务为企业应用程序启用单一登录。 在本教程中，你将在 Microsoft Entra 中创建应用程序的表示形式，为该应用程序配置从 Microsoft Entra 到信赖方 STS 的单一登录，以及配置从信赖方 STS 到应用程序的单一登录。 执行该教程将验证，在正常操作期间，带有声明的令牌是否可以从 Microsoft Entra 流经信赖方 STS 到应用程序。

注释

Microsoft Entra 中每个依赖方 STS 使用一个应用程序表示，与连接到该依赖方 STS 的应用程序数量无关。 如果有多个应用程序连接到单个信赖方 STS，则它们将在 Microsoft Entra 中共享一个通用应用程序，因此必须在 Microsoft Entra 中具有相同的用户、CA 策略、提供的声明和其他设置。

在信赖方 STS 中将 AD 配置为 LDAP 源

接下来，在信赖方 STS 中配置 Active Directory 是应用程序所需的声明的声明源。 以下步骤使用 AD FS 显示，但可以改用另一个信赖方 STS。

1. 在部署 AD FS 的服务器上以管理员身份登录。
2. 启动 AD FS Management。
3. 在 AD FS 菜单中，选择 Claims Provider Trusts。
4. 确保有两个声明提供程序，Microsoft Entra 和 Active Directory，并且确保这两个都已启用。 在默认情况下，Active Directory 声明提供程序存在。
5. 选择 Active Directory 和选择 Edit Claim Rules。
6. 确认在您的环境中，应用程序需要用于声明的 LDAP 属性是否有相关规则。
7. 在 AD FS 菜单中，选择 Relying Party Trusts。
8. 选择目标应用程序，然后选择 Edit Claim Issuance Policy。
9. 确认发送到应用程序的声明的规则提供所有必要的声明。 有关详细信息，请参阅 传递或筛选传入请求。

准备 AD 测试用户，以便通过 Microsoft Entra 登录到应用程序

测试配置时，应将 Active Directory 中创建的指定测试用户分配给 Microsoft Entra 中应用程序的角色。 AD 用户的此选择将验证用户是否能够通过 Microsoft Entra 和信赖方 STS 登录到应用程序。

1. 标识 Active Directory 中的测试用户。 确保知道该用户的密码，以便你可以作为该用户向 Active Directory 和 Microsoft Entra 进行身份验证。

2. 如果最近在 AD 中创建用户，请等待从 AD 同步到 Microsoft Entra ID 完成。

   如果使用 Microsoft Entra Cloud Sync，可以通过检索表示 Microsoft Entra Cloud Sync 的服务主体的steadyStateLastAchievedTime来监视同步状态的属性。如果没有服务主体 ID，请参阅“查看同步架构”。

3. 以至少云应用程序管理员身份登录到 Microsoft Entra 管理中心。

4. 浏览到 Entra ID>企业应用程序>所有应用程序。

5. 在搜索框中输入现有应用程序的名称，并从搜索结果中选择该应用程序。

6. 在左侧菜单的“管理”部分中，选择“属性” 。

7. 确保 为用户登录启用 的值设置为 “是”。

8. 确保 所需的工作分配 值设置为 “是”。

9. 如果进行了任何更改，请选择“ 保存”。

10. 在左侧菜单的“ 管理 ”部分中，选择“ 用户和组”。

11. 选择“添加用户/组”。

12. 选择“无已选择”。

13. 在搜索框中，键入测试用户的名称，然后选择用户并点击选择。

14. 选择“ 分配 ”以将用户分配到应用程序的默认 用户 角色。

15. 在左侧菜单的 “安全性 ”部分中，选择 “条件访问”。

16. 选择“What if”。

17. 选择 “未选择用户或服务主体”，选择 “未选择用户”，然后选择以前分配给该应用程序的用户。

18. 选择 “任何云应用”，然后选择企业应用程序。

19. 选择“What if”。 验证将应用的任何策略是否允许用户登录到应用程序。

将每个应用程序的声明提供程序设置为Microsoft Entra

在 Microsoft Entra 和信赖方 STS 中配置应用程序后，用户可以登录它。 用户首先在 Microsoft Entra 上进行身份验证，然后由信赖方 STS（比如 AD FS）将 Microsoft Entra 提供的令牌转换为您的应用程序所需的格式和声明。 此外，用户将能够通过对 AD 进行身份验证来登录该系统，并获得由 AD FS 提供的具有类似声明的令牌。

在本部分中，您将配置信赖方 STS，使其在正常操作期间为每个应用程序提供 Microsoft Entra 作为身份提供者。 以下步骤使用 AD FS 显示，但可以改用另一个信赖方 STS。

1. 在安装了 AD FS 的 Windows Server 上启动 PowerShell。
2. 使用命令 Get-AdfsRelyingPartyTrust | ft Name,ClaimsProviderName获取应用程序列表。
3. 使用命令 Get-AdfsClaimsProviderTrust | ft Name 获取声明提供者的列表。 应该有两个名称，一个用于 Active Directory，另一个用于 Microsoft Entra。
4. 使用 Set-AdfsRelyingPartyTrust 命令配置Microsoft Entra 是每个应用程序的唯一声明提供程序。 例如，如果应用程序命名 appname，则键入 Set-AdfsRelyingPartyTrust -TargetName "appname" -ClaimsProviderName "Microsoft Entra"。 对每个应用程序重复此作。 有关详细信息，请参阅 为每个信赖方配置标识提供者列表。

在正常操作期间验证单一登录

在本部分中，你将验证用户可以在正常操作期间无缝地使用 Microsoft Entra 进行身份验证并登录到应用程序。

1. 在 Web 浏览器专用浏览会话中，连接到应用程序并启动登录过程。 应用程序将 Web 浏览器重定向到信赖方 STS AD FS，AD FS 确定可以提供适当声明的标识提供者。
2. 根据上一部分中的配置，AD FS 将选择Microsoft Entra 标识提供者。 AD FS 将 Web 浏览器重定向到 Microsoft Entra 登录终结点（ https://login.microsoftonline.com 如果使用 Microsoft Entra ID 全局服务）。
3. 使用测试用户的标识登录到 Microsoft Entra，此前在本节中配置了 AD 测试用户，以便准备好登录到应用程序。 然后，Microsoft Entra 根据实体标识符找到企业应用程序，并在其回复 URL 终结点处将 Web 浏览器重定向到 AD FS，并使用 Web 浏览器传输 SAML 令牌。
4. AD FS 验证 SAML 令牌是由 Microsoft Entra 颁发的，然后从 SAML 令牌中提取和转换声明，并将 Web 浏览器重定向到应用程序。 确认应用程序已通过此过程从 Microsoft Entra 收到所需的声明。

将应用程序信任的声明提供程序更改为 Active Directory 后，进行单一登录验证。

在本部分中，你将验证将应用程序的标识提供者切换到 Active Directory 时，用户仍然可以对应用程序进行身份验证和登录。

1. 在安装了 AD FS 的 Windows Server 上启动 PowerShell。
2. 在 PowerShell 会话中，配置 Active Directory 现在是应用程序的唯一声明提供程序，使用命令 Set-AdfsRelyingPartyTrust替换 Microsoft Entra。 例如，如果应用程序命名 appname，则键入 Set-AdfsRelyingPartyTrust -TargetName "appname" -ClaimsProviderName "Active Directory"。
3. 若要清除浏览器中的任何登录状态，请关闭以前打开的任何 Web 浏览器专用浏览会话。
4. 在新 Web 浏览器专用浏览会话中，连接到该应用程序并启动登录过程。 应用程序将 Web 浏览器重定向到 AD FS，AD FS 确定可以提供适当声明的标识提供者。
5. 根据步骤 2 中的配置，AD FS 将选择 Active Directory。
6. 使用测试用户的 Active Directory 标识登录到 AD FS。 AD FS 将在 Active Directory 中对用户进行身份验证。
7. AD FS 将用户的 LDAP 属性转换为声明，并将 Web 浏览器重定向到应用程序。 确认应用程序已通过此过程从 Active Directory 收到所需的声明。
8. 在 PowerShell 会话中，使用命令 Set-AdfsRelyingPartyTrust 再次将 Microsoft Entra 配置为应用程序的声明提供程序，并提供 -ClaimsProviderName 参数的值。 还可以允许所有声明提供程序使用命令，例如 Set-AdfsRelyingPartyTrust -TargetName "appname" -ClaimsProviderName @()。

配置谁可以登录到应用程序

接下来需要配置谁可以登录到每个应用程序。 AD FS 和 Microsoft Entra 在其策略中具有不同的机制来界定令牌颁发的范围，因此可能需要在这两者中进行更改。

1. 以前，在 Microsoft Entra 中为应用程序的角色分配了测试用户，你可能希望立即删除该测试用户的角色分配。
2. 如果有多个应用程序连接到同一信赖方 STS，则在 Microsoft Entra 中，可能只能有一个代表所有这些应用程序的应用程序对象。 对于角色分配，可以使用动态组或权利管理等功能将用户分配到应用程序角色。 如果用户在应用程序角色中拥有角色成员资格，那么用户将能够从 Microsoft Entra 接收令牌。
3. 此外，AD FS 还应用分配给应用程序的访问控制策略。 为应用程序选择的任何策略都需要由 AD FS 针对来自 Microsoft Entra 的令牌以及对 AD 进行身份验证的用户进行评估。 由于来自 Microsoft Entra 的令牌不会通过 Active Directory，因此无法使用 “允许特定的组 访问控制策略”，因为该策略会拒绝Microsoft Entra 令牌。 如果要控制 AD FS 中用于从 AD 颁发令牌的访问，则需要改用其他策略。 有关访问控制策略的详细信息，请参阅 AD FS 中的访问控制策略。

配置任务以执行自动故障转移到 AD 和 Microsoft Entra

然后，您需要为站点的连接配置一个监视器。 通过调用应用程序的Microsoft Entra命令，当检测到断开连接时，此监视器将触发 AD FS 中每个应用程序的标识提供者从Active Directory到Set-AdfsRelyingPartyTrust的自动切换。 （可选）你可以配置一个监视器，以在检测到连接恢复时将 AD FS 配置重置为 Microsoft Entra。

对于简单的环境，可以使用 PowerShell 脚本和内置任务计划程序实现监视器。 对于横向扩展部署，部署监视器取决于组织中正在使用的 IT 自动化系统，并且不在本文的范围内。

配置 AD FS 故障转移到 AD 的示例计划任务

1. 创建一个脚本，用于检测站点中的网络连接失败，并调用 Set-AdfsRelyingPartyTrust 以更改标识提供者。 可以在 中找到 https://github.com/microsoft/Entra-reporting/blob/main/PowerShell/sample-changeover-multiple-apps.ps1脚本的示例。 请注意，如果下载脚本，则需要使用文件资源管理器取消阻止脚本，然后才能在 PowerShell 中运行它。
2. 使用 AD FS 将脚本复制到 Windows Server。
3. 编辑脚本以匹配 AD FS 配置和在该站点的 AD FS 中配置的应用程序列表。
4. 在安装了 AD FS 的 Windows Server 上启动 PowerShell。
5. 注册源，以便脚本可以写入应用程序事件日志。 例如，如果脚本命名 AD FS changeover script，则键入命令 New-EventLog -LogName Application -Source "AD FS changeover script"。
6. 启动 事件查看器 并导航到新创建的日志。
7. 在 PowerShell 中运行脚本进行测试，以确保它能在交互式会话中正确运行。
8. 启动 任务计划程序 并查看任务计划程序库。
9. 如果任务计划程序中还没有任务的文件夹，请创建一个文件夹。
10. 选择任务的文件夹，然后选择“ 创建任务”。
11. 填写任务的“常规”选项卡设置。
12. 切换到 “触发器” 选项卡。选择“新建”，并为任务设定一个符合组织风险和网络指导原则的重复周期。
13. 更改为操作选项卡。选择“新建”，然后选择一个用于启动程序的操作。 指定 powershell.exe 为程序，并指定调用 PowerShell 脚本所需的参数。 例如，-NonInteractive -WindowStyle Hidden -File c:\scripts\ad_fs_changeover_script.ps1。 然后选择“确定”以关闭操作窗口，再选择“确定”以关闭任务窗口。 有关详细信息，请参阅 powershell.exe。
14. 选择 “运行”，等待一分钟，然后选择“ 刷新”。 确保脚本已启动并成功完成，并检查 事件查看器 以查看是否记录了任何错误。

配置会话失效（可选）

应用程序可能还具有由已经过身份验证的用户产生的会话。 例如，基于浏览器的应用程序可能会对用户进行身份验证，然后存储一个浏览器 Cookie，指示用户已经过身份验证。 你可能希望让自己的应用程序尽可能短地依赖断开连接的标识提供程序。 例如，如果用户以前没有使用过应用程序，那么用户第一次尝试连接到应用程序的时间是站点断开连接时，则由 Windows Server AD 执行身份验证。 身份验证后，应用程序可能已存储会话 Cookie，使用户能够继续与应用程序交互，而无需重新进行身份验证。 但是，重新连接站点后，你可能希望Microsoft Entra 重新对用户进行身份验证，以便可以应用条件访问等Microsoft Entra 策略。 这将要求使派生自 Windows Server AD 的用户的任何会话状态失效，例如，通知应用程序不允许在特定时间范围内生成的会话状态。 向应用程序提供此项的方式因应用程序而异。

完成配置

测试初始登录配置后，需要确保信赖方 STS 在将新证书添加到 Microsoft Entra 时保持最新状态。 某些信赖方 STS 可能内置了一个过程来监视标识提供者的联盟元数据。

有关配置 AD FS 以实现高可用性的详细信息，请参阅如何部署 联合服务器场。

后续步骤

• Microsoft Entra ID 中的应用程序管理是什么？
• 管理环境中应用程序的访问
• 使用信赖方安全令牌服务为企业应用程序启用单一登录