有关保护 Active Directory 联合身份验证服务的最佳做法

• 适用于:

  ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

本文档提供有关安全规划和部署 Active Directory 联合身份验证服务 (AD FS) 与 Web 应用程序代理 (WAP) 的最佳做法。 其中包含有关其他安全配置、特定用例和安全要求的建议。

本文档适用于 Windows Server 2012 R2、2016 和 2019 中的 AD FS 与 WAP。 这些建议适用于本地网络或云托管环境（例如 Microsoft Azure）。

标准部署拓扑

对于本地环境中的部署，我们建议使用标准部署拓扑，其中包含：

• 内部公司网络中的一个或多个 AD FS 服务器。
• 外围网络或 Extranet 网络中的一个或多个 Web 应用程序代理 (WAP) 服务器。

在每个层（AD FS 和 WAP）中，硬件或软件负载均衡器放置在服务器场前面，用于处理流量路由。 根据需要将防火墙放置在负载均衡器的外部 IP 地址前面。

注意

AD FS 需要完全可写的域控制器（而不是只读域控制器）才能正常运行。 如果规划的拓扑包含只读域控制器，则该只读域控制器可用于身份验证，但 LDAP 声明处理需要连接到可写域控制器。

强化 AD FS 服务器

下面是有关强化和保护 AD FS 部署的最佳做法和建议列表：

• 确保只有 Active Directory 管理员和 AD FS 管理员对 AD FS 系统拥有管理员权限。
• 减少所有 AD FS 服务器上的本地管理员组成员身份。
• 要求所有云管理员使用多重身份验证 (MFA)。
• 尽量减少通过代理实现的管理功能。
• 通过主机防火墙限制网络访问。
• 确保 AD FS 管理员使用管理员工作站来保护其凭据。
• 将 AD FS 服务器计算机对象放置在不托管其他服务器的顶级 OU 中。
• 应用于 AD FS 服务器的所有 GPO 应该只对这些服务器应用，而不会应用于其他服务器。 这可以限制通过 GPO 修改提升特权的可能性。
• 确保安装的证书受到防盗保护（不要将其存储在网络上的共享中），并设置日历提醒以确保它们在过期之前续订（过期的证书会破坏联合身份验证）。 此外，我们建议在附加到 AD FS 的硬件安全模块 (HSM) 中保护签名密钥/证书。
• 将日志记录设置为最高级别，并将 AD FS（和安全性）日志发送到 SIEM 以便与 AD 身份验证以及 AzureAD（或类似服务）相关联。
• 移除不必要的协议和 Windows 功能。
• 为 AD FS 服务帐户使用较长（>25 个字符）的复杂密码。 建议使用组托管服务帐户 (gMSA) 作为服务帐户，因为它会自动管理服务帐户密码，无需用户持续管理该密码。
• 更新到最新 AD FS 版本以获得安全性和日志记录改进（像往常一样先进行测试）。

所需的端口

下图描绘了必须在 AD FS 和 WAP 部署组件之间启用的防火墙端口。 如果部署不包含 Microsoft Entra ID/Office 365，则可以忽略同步要求。

注意

仅当使用用户证书身份验证时，才需要端口 49443；此端口对于 Microsoft Entra ID 和 Office 365 是可选的。

注意

端口 808 (Windows Server 2012R2) 或端口 1501 (Windows Server 2016+) 是 AD FS 使用的网络 TCP 端口，供本地 WCF 终结点将配置数据传输到服务进程和 PowerShell。 可以通过运行 Get-AdfsProperties 并选择 NetTcpPort 来查看此端口。 这是一个本地端口，不需要在防火墙中打开，但会显示在端口扫描中。

联合服务器之间的通信

AD FS 场上的联合服务器通过 HTTP 端口 80 来与该场中的其他服务器和 Web 应用程序代理 (WAP) 服务器通信，以进行配置同步。 确保只有这些服务器能够相互通信，并且没有其他服务器用作深层防御措施。

组织可以通过在每台服务器上设置防火墙规则来实现这种状态。 这些规则应该只允许从场中服务器和 WAP 服务器的 IP 地址进行入站通信。 某些网络负载均衡器 (NLB) 使用 HTTP 端口 80 来探测各个联合服务器上的运行状况。 确保在配置的防火墙规则中包含 NLB 的 IP 地址。

Microsoft Entra Connect 和联合服务器/WAP

此表介绍了 Microsoft Entra Connect 服务器与联合身份验证服务器/WAP 服务器之间通信所需的端口和协议。

协议	端口	说明
HTTP	80 (TCP/UDP)	用于下载 CRL（证书吊销列表）以验证 SSL 证书。
HTTPS	443 (TCP/UDP)	用于与 Microsoft Entra ID 同步。
WinRM	5985	WinRM 侦听器。

WAP 和联合服务器

此表描述了联合服务器与 WAP 服务器之间通信所需的端口和协议。

协议	端口	说明
HTTPS	443 (TCP/UDP)	用于身份验证。

WAP 和用户

此表描述了用户与 WAP 服务器之间通信所需的端口和协议。

协议	端口	说明
HTTPS	443 (TCP/UDP)	用于设备身份验证。
TCP	49443 (TCP)	用于证书身份验证。

有关混合部署所需端口和协议的信息，请参阅混合部署参考连接端口。

有关 Microsoft Entra ID 和 Office 365 部署所需端口和协议的信息，请参阅文档 Office 365 URL 和 IP 地址范围。

启用的终结点

安装 AD FS 和 WAP 时，会在联合身份验证服务和代理上启用一组默认的 AD FS 终结点。 这些默认终结点是根据最常需要和使用的方案选择的，没有必要更改它们。

为 Microsoft Entra ID/Office 365 启用的最少量终结点代理（可选）

仅为 Microsoft Entra ID和 Office 365 方案部署 AD FS 和 WAP 的组织可以进一步限制在代理上启用的 AD FS 终结点数量，以进一步减少攻击面。 下面是在这些方案中必须在代理上启用的终结点列表：

端点	目的
/adfs/ls/	基于浏览器的身份验证流和最新版本的 Microsoft Office 使用此终结点进行 Microsoft Entra ID 和 Office 365 身份验证
/adfs/services/trust/2005/usernamemixed	用于 Exchange Online 以及版本低于 Office 2013 2015 年 5 月更新版的 Office 客户端。 以后的客户端使用被动 \adfs\ls 终结点。
/adfs/services/trust/13/usernamemixed	用于 Exchange Online 以及版本低于 Office 2013 2015 年 5 月更新版的 Office 客户端。 以后的客户端使用被动 \adfs\ls 终结点。
/adfs/oauth2/	用于配置为直接向 AD FS 进行身份验证（即不通过 Microsoft Entra ID）的任何新式应用（本地或云中）
/adfs/services/trust/mex	用于 Exchange Online 以及版本低于 Office 2013 2015 年 5 月更新版的 Office 客户端。 以后的客户端使用被动 \adfs\ls 终结点。
/federationmetadata/2007-06/federationmetadata.xml	要求任何被动流使用；供 Office 365/Microsoft Entra ID 用来检查 AD FS 证书。

可以使用以下 PowerShell cmdlet 在代理上禁用 AD FS 终结点：

Set-AdfsEndpoint -TargetAddressPath <address path> -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/certificatemixed -Proxy $false

身份验证的扩展保护

身份验证扩展保护是一项可以缓解中间人 (MITM) 攻击的功能，默认已连同 AD FS 一起启用。 可以使用以下 PowerShell cmdlet 验证设置：

Get-ADFSProperties

属性为 ExtendedProtectionTokenCheck。 默认设置为“允许”，这样就可以实现安全优势，同时不用担心不支持该功能的浏览器出现兼容性问题。

用于保护联合身份验证服务的拥塞控制

联合身份验证服务代理（WAP 的一部分）提供拥塞控制以保护 AD FS 服务免受大量请求的影响。 如果联合服务器过载（根据在 Web 应用程序代理与联合服务器之间检测到的延迟来判断），Web 应用程序代理将拒绝外部客户端身份验证请求。 默认情况下，为此功能配置了建议的延迟阈值级别。 若要验证设置，可执行以下操作：

1. 在 Web 应用程序代理计算机上，启动一个提升的命令窗口。
2. 导航到 AD FS 目录：%WINDIR%\adfs\config。
3. 将拥塞控制设置从其默认值更改为 <congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" />。
4. 保存并关闭该文件。
5. 通过依次运行 net stop adfssrv 和 net start adfssrv 重新启动 AD FS 服务。

有关此功能的指导，请参阅在 Windows Server 2012 R2 上为 AD FS 配置 Extranet 访问。

代理上的标准 HTTP 请求检查

代理还会对所有流量执行以下标准检查：

• FS-P 本身通过短生存期证书向 AD FS 进行身份验证。 如果怀疑外围网络服务器遭到入侵，AD FS 可以“撤销代理信任”，以便不再信任来自可能遭入侵代理的任何传入请求。 撤销代理信任会撤销每个代理自身的证书，使其无法出于任何目的成功向 AD FS 服务器完成身份验证。
• FS-P 终止所有连接，并在内部网络上创建与 AD FS 服务的新 HTTP 连接。 这会在外部设备和 AD FS 服务之间提供一个会话级缓冲区。 外部设备永远不会直接连接到 AD FS 服务。
• FS-P 执行 HTTP 请求验证，这会专门筛选出 AD FS 服务不需要的 HTTP 标头。

建议的安全配置

确保所有 AD FS 和 WAP 服务器接收最新更新。 对于 AD FS 基础结构，最重要的安全建议是确保通过某种方式，使用所有安全更新以及本页上指定为重要的适用于 AD FS 的可选更新，来使 AD FS 和 WAP 服务器保持最新状态。

Microsoft Entra 客户要监视自己的基础结构并让其保持最新状态，建议采用适用于 AD FS 的 Microsoft Entra Connect Health（这是 Microsoft Entra ID P1 或 P2 的一项功能）。 Microsoft Entra Connect Health 包括监视和警报，如果 AD FS 或 WAP 计算机缺少专用于 AD FS 和 WAP 的任意重要更新，就会触发警报。

若要详细了解 AD FS 的运行状况监视，请参阅 Microsoft Entra Connect Health 代理安装。

使用 Microsoft Entra ID 保护和监视 AD FS 信任的最佳做法

在将 AD FS 与 Microsoft Entra ID 联合时，联合身份验证配置（AD FS 和 Microsoft Entra ID 之间配置的信任关系）必须受到密切监视，任何异常或可疑的活动都必须被捕获。 为此，建议你设置警报，这样你就会在联合身份验证配置发生更改时收到通知。 若要了解如何设置警报，请参阅监视对联合身份验证配置的更改。

其他安全配置

可以配置以下附加功能以提供更多保护。

帐户的 Extranet“软”锁定保护

借助 Windows Server 2012 R2 中的 Extranet 锁定功能，AD FS 管理员可以设置允许的最大失败身份验证请求数 (ExtranetLockoutThreshold) 和 observation window 期限 (ExtranetObservationWindow)。 达到此最大身份验证请求数 (ExtranetLockoutThreshold) 时，AD FS 将根据设置的期限 (ExtranetObservationWindow) 停止尝试对为 AD FS 提供的帐户凭据进行身份验证。 此操作可以防止此帐户遭受 AD 帐户锁定，换言之，它可以防止此帐户失去对依赖 AD FS 进行用户身份验证的公司资源的访问权限。 这些设置适用于 AD FS 服务可对其进行身份验证的所有域。

可以使用以下 Windows PowerShell 命令设置 AD FS Extranet 锁定（示例）：

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow ( new-timespan -Minutes 30 )

有关参考，请参阅配置 AD FS Extranet 锁定，其中详细介绍了此功能。

通过 Extranet 在代理上禁用 WS-Trust Windows 终结点

WS-Trust Windows 终结点（/adfs/services/trust/2005/windowstransport 和 /adfs/services/trust/13/windowstransport）仅用于面向 Intranet 的终结点，这些终结点使用 HTTPS 上的 WIA 绑定。 将其公开给 Extranet 可能会允许针对这些终结点的请求绕过锁定保护。 应使用以下 PowerShell 命令在代理上禁用这些终结点（即通过 Extranet 禁用），以保护 AD 帐户锁定。 在代理上禁用这些终结点不会对最终用户造成已知影响。

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/2005/windowstransport -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport -Proxy $false

注意

如果 AD FS 场在 Windows 内部数据库 (WID) 上运行并且包含辅助 AD FS 服务器，请在禁用主服务器上的终结点后，等待辅助节点上发生 SYNC，然后在其上重启 AD FS 服务。 在辅助节点上使用 PowerShell 命令 Get-AdfsSyncProperties 来跟踪最后一个 SYNC 进程。

区分 Intranet 和 Extranet 访问策略

AD FS 能够区分源自本地、公司网络的请求以及通过代理从 Internet 传入的请求的访问策略。 可以按应用程序或全局实现这种区分。 对于高业务价值的应用程序或包含敏感信息的应用程序，请考虑要求执行多重身份验证。 可以通过 AD FS 管理管理单元设置多重身份验证。

要求多重身份验证 (MFA)

可将 AD FS 配置为专门针对通过代理传入的请求、单个应用程序以及对 Microsoft Entra ID/Office 365 和本地资源的条件访问要求执行强身份验证（例如多重身份验证）。 支持的 MFA 方法包括 Microsoft Azure MF 和第三方提供程序。 系统会提示用户提供附加信息（例如包含一次性代码的短信），并且 AD FS 与提供程序特定的插件配合工作以允许访问。

支持的外部 MFA 提供程序包括为 AD FS 配置其他身份验证方法页中列出的提供程序。

启用保护以防与 Microsoft Entra ID 联合时绕过云 Microsoft Entra 多重身份验证

启用保护以防与 Microsoft Entra ID 联合时绕过云 Microsoft Entra 多重身份验证，并且以防将 Microsoft Entra 多重身份验证用作联合用户的多重身份验证。

为 Microsoft Entra 租户中的联合域启用保护可确保当联合用户访问由需要 MFA 的条件访问策略管理的应用程序时，始终执行 Microsoft Entra 多重身份验证。 这包括执行 Microsoft Entra 多重身份验证，即使联合标识提供者已（通过联合令牌声明）表明已执行本地 MFA。 每次强制执行 Microsoft Entra 多重身份验证可确保遭入侵的本地帐户无法通过模仿标识提供者已执行的多重身份验证来绕过 Microsoft Entra 多重身份验证，除非你使用第三方 MFA 提供程序对联合用户执行 MFA，否则强烈建议这样做。

可以使用新的安全设置 federatedIdpMfaBehavior 来启用保护，该设置作为内部联合 MS Graph API 或 MS Graph PowerShell cmdlet 的一部分公开。 federatedIdpMfaBehavior 设置确定当联合标识用户访问由需要 MFA 的条件访问策略管理的应用程序时，Microsoft Entra ID 是否接受联合标识提供者执行的 MFA。

管理员可以选择以下值之一：

属性	说明
acceptIfMfaDoneByFederatedIdp	Microsoft Entra ID 接受联合标识提供者执行的 MFA。 若非如此，则执行 Microsoft Entra 多重身份验证
enforceMfaByFederatedIdp	Microsoft Entra ID 接受联合标识提供者执行的 MFA。 否则将请求重定向到标识提供者以执行 MFA。
rejectMfaByFederatedIdp	Microsoft Entra ID 始终执行 Microsoft Entra 多重身份验证，并且拒绝标识提供者执行的 MFA。

可以使用以下命令将 federatedIdpMfaBehavior 设置为 rejectMfaByFederatedIdp 以启用保护。

MS GRAPH API

 PATCH /domains/{domainsId}/federationConfiguration/{internalDomainFederationId} 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

} 

示例：

PATCH /domains/contoso.com/federationConfiguration/2a8ce608-bb34-473f-9e0f-f373ee4cbc5a 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

示例：

Update-MgDomainFederationConfiguration -DomainId <domainsId> -InternalDomainFederationId <internalDomainFederationId> federatedIdpMfaBehavior "rejectMfaByFederatedIdp" 

示例：

Update-MgDomainFederationConfiguration -DomainId “contoso.com” -InternalDomainFederationId “2a8ce608-bb34-473f-9e0f-f373ee4cbc5a” federatedIdpMfaBehavior "rejectMfaByFederatedIdp" 

硬件安全模块 (HSM)

在其默认配置中，由 AD FS 用来为令牌签名的密钥永远不会离开 Intranet 上的联合服务器。 它们永远不会出现在外围网络或代理计算机上。 （可选）为了提供更多保护，我们建议在附加到 AD FS 的硬件安全模块 (HSM) 中保护这些密钥。 Microsoft 不生产 HSM 产品，但市场上有多种支持 AD FS 的产品。 若要实施此建议，请按照供应商指导创建用于签名和加密的 X509 证书，然后如下所示使用 AD FS 安装 PowerShell cmdlet 指定自定义证书：

Install-AdfsFarm -CertificateThumbprint <String> -DecryptionCertificateThumbprint <String> -FederationServiceName <String> -ServiceAccountCredential <PSCredential> -SigningCertificateThumbprint <String>

其中：

• CertificateThumbprint 是 SSL 证书
• SigningCertificateThumbprint 是签名证书（带有 HSM 保护的密钥）
• DecryptionCertificateThumbprint 是加密证书（带有 HSM 保护的密钥）