适用于 AD FS 的 Microsoft Entra Connect Health 代理
在本文中，你将了解如何安装和配置 Microsoft Entra Connect Health 代理。 以下文档专门用于使用 Microsoft Entra Connect Health 安装和监视 AD FS 基础结构。 有关通过 Microsoft Entra Connect Health 监视 Microsoft Entra Connect（同步）的信息，请参阅使用 Microsoft Entra Connect Health 进行同步。此外，有关使用 Microsoft Entra Connect Health 监视 Active Directory 域服务的信息，请参阅将 Microsoft Entra Connect Health 与 AD DS 结合使用。
了解如何下载代理。
注意
中国主权云中不提供Microsoft Entra Connect Health。
要求
下表列出使用 Microsoft Entra Connect Health 的要求：
| 要求 | 说明 |
|---|---|
| 你有一个 Microsoft Entra ID P1 或 P2 订阅。 | Microsoft Entra Connect Health 是 Microsoft Entra ID P1 或 P2 的一项功能。 有关详细信息，请参阅 注册 Microsoft Entra ID P1 或 P2。 若要开始 30 天免费试用，请参阅开始试用。 |
| 你是 Microsoft Entra ID 全局管理员。 | 目前，只有全局管理员帐户可以安装和配置运行状况代理。 有关详细信息，请参阅管理 Microsoft Entra 目录。 利用基于 Azure 角色的访问控制 (Azure RBAC)，你可以让组织中的其他用户访问 Microsoft Entra Connect Health。 要了解详情，请参阅 适用于 Microsoft Entra Connect Health 的 Azure RBAC。 重要说明：使用工作或学校帐户安装代理。 不能使用 Microsoft 帐户安装代理。 有关详细信息，请参阅以组织的身份注册 Azure。 |
| Microsoft Entra Connect Health 代理已安装在每台目标服务器上。 | 必须在目标服务器上安装和配置 Health 代理，以便他们能够接收数据并提供监视和分析功能。 例如，要从 Active Directory 联合身份验证服务 (AD FS) 基础结构获取数据，必须在 AD FS 服务器和 Web 应用程序代理服务器上安装代理。 同样，若要从本地 AD 域服务基础结构获取数据，必须在域控制器上安装代理。 |
| Azure 服务终结点具有出站连接。 | 在安装期间和运行时，代理需要连接到 Microsoft Entra Connect Health 服务终结点。 如果防火墙阻止出站连接，请将出站连接终结点添加到允许列表中。 |
| 出站连接基于 IP 地址。 | 有关基于 IP 地址的防火墙筛选的信息，请参阅 Azure IP 范围。 |
| 已为出站流量筛选或禁用 TLS 检查。 | 如果在网络层针对出站流量设置了 TLS 检查或终止，则代理注册步骤或数据加载操作可能会失败。 有关详细信息，请参阅设置 TLS 检查。 |
| 服务器上的防火墙端口正在运行代理。 | 代理需要打开以下防火墙端口，以便与 Microsoft Entra Connect Health 服务终结点通信： - TCP 端口 443 - TCP 端口 5671 最新版本的代理不需要端口 5671。 升级到最新版本，以便只需要端口 443。 有关详细信息，请参阅混合标识所需的端口和协议。 |
| 如果启用了 Internet Explorer 增强的安全性，则允许指定的网站。 | 如果启用了 Internet Explorer 增强的安全性，则在安装代理的服务器上允许以下网站： - https://login.microsoftonline.com - https://secure.aadcdn.microsoftonline-p.com - https://login.windows.net - https://aadcdn.msftauth.net - 受 Microsoft Entra ID信任的组织的联合服务器（例如 https://sts.contoso.com）。 有关详细信息，请参阅如何配置 Internet Explorer。 如果网络中存在代理，请参阅此表末尾显示的注释。 |
| 已安装 PowerShell 版本 5.0 或更高版本。 | Windows Server 2016 包括 PowerShell 版本 5.0。 |
重要
Windows Server Core 不支持安装 Microsoft Entra Connect Health 代理。
注意
如果具有高度锁定和受限的环境，与该表为 Internet Explorer 增强的安全性列出的 URL 相比，你需要添加更多的 URL。 还要添加下一部分的表中列出的 URL。
新版本的代理和自动升级
如果发布了新版本的 Health 代理，则将自动更新任何现有的已安装代理。
Azure 服务终结点的出站连接
在安装期间和运行时，代理需要连接到 Microsoft Entra Connect Health 服务终结点。 如果防火墙阻止出站连接，请确保以下表中的 URL 默认情况下不会被阻止。
不要禁用这些 URL 的安全监视或检查。 相反，像允许其他 Internet 流量一样允许它们。
这些 URL 允许与 Microsoft Entra Connect Health 服务终结点通信。 在本文的后面部分中，你讲了解如何使用 Test-AzureADConnectHealthConnectivity检查出站连接。
| 域环境 | 所需的 Azure 服务终结点 |
|---|---|
| 一般公众 | - *.blob.core.windows.net - *.aadconnecthealth.azure.com - **.servicebus.windows.net - 端口：5671（如果阻止了 5671，则代理将回退到 443，但建议使用端口 5671。最新版本的代理不需要使用此终结点。）- *.adhybridhealth.azure.com/- https://management.azure.com - https://policykeyservice.dc.ad.msft.net/ - https://login.windows.net - https://login.microsoftonline.com - https://secure.aadcdn.microsoftonline-p.com - https://www.office.com（*此终结点仅在注册过程中用于发现目的。）- https://aadcdn.msftauth.net - https://aadcdn.msauth.net - https://autoupdate.msappproxy.net - https://www.microsoft.com |
| Azure Government | - *.blob.core.usgovcloudapi.net - *.servicebus.usgovcloudapi.net - *.aadconnecthealth.microsoftazure.us - https://management.usgovcloudapi.net - https://policykeyservice.aadcdi.azure.us - https://login.microsoftonline.us - https://secure.aadcdn.microsoftonline-p.com - https://www.office.com（*此终结点仅在注册过程中用于发现目的。）- https://aadcdn.msftauth.net - https://aadcdn.msauth.net - https://autoupdate.msappproxy.us - http://www.microsoft.com - https://www.microsoft.com |
下载代理
若要下载并安装 Microsoft Entra Connect Health 代理：
- 请务必满足要求才能安装 Microsoft Entra Connect Health。
- 开始使用适用于 AD FS 的 Microsoft Entra Connect Health ：
- 开始使用 Microsoft Entra Connect Health 进行同步：
- 下载并安装最新版本的 Microsoft Entra Connect。 在安装 Microsoft Entra Connect 的过程中，会安装适用于同步的 Health 代理（1.0.9125.0 或更高版本）。
- 开始使用适用于 AD 域服务的 Microsoft Entra Connect Health ：
为 AD FS 安装代理
注意
AD FS 服务器应独立于同步服务器。 请勿在同步服务器上安装 AD FS 代理。
注意
在安装 Microsoft Entra Connect 的过程中，会安装适用于同步的 Health 代理（1.0.9125.0 或更高版本）。 如果尝试在 Microsoft Entra Connect 服务器上安装早期版本的 AD FS 健康状况代理，则会发生错误。 如果需要在计算机上安装适用于 AD FS 的健康状况代理，则应下载最新版本，然后卸载 Microsoft Entra Connect 安装期间中安装的版本。
在安装代理之前，请确保 AD FS 服务器主机名是唯一的，并且未存在于 AD FS 服务中。
要启动代理安装，请双击下载的 .exe 文件。 在第一个对话框中，选择“安装”。
出现提示时，请使用具有注册代理权限的 Microsoft Entra 帐户登录。 默认情况下，混合标识管理员帐户具有权限。
登录后，安装过程将完成，你可以关闭窗口。
此时，代理服务应自动启动，以便代理能够安全地将所需数据上传到云服务。
若要验证代理是否已安装，请在服务器上查找以下服务。 如果已完成配置，这些服务应已运行。 否则，它们会停止，直到完成配置。
- Microsoft Entra Connect 代理更新程序
- Microsoft Entra Connect Health 代理
为 AD FS 启用审核
注意
本部分仅适用于 AD FS 服务器。 不必再 Web 应用程序代理服务器上完成以下步骤。
使用情况分析功能需要收集和分析数据，因此 Microsoft Entra Connect Health 需要获取 AD FS 审核日志中的信息。 默认情况下未启用这些日志。 使用以下过程在 AD FS 服务器上启用 AD FS 审核和查找 AD FS 审核日志。
若要启用 AD FS 审核
在“开始”屏幕上，打开“服务器管理器”，然后打开“本地安全策略” 。 或在任务栏上，打开“服务器管理器”，然后选择“工具/本地安全策略”。
转到“Security Settings\Local Policies\User Rights Assignment”文件夹。 双击“生成安全审核”。
在“本地安全设置”选项卡上，验证是否列出了 AD FS 服务帐户。 如果未列出，请选择“添加用户或组”，然后将 AD FS 服务帐户添加到列表。 然后选择确定。
若要启用审核，请以管理员身份打开命令提示符窗口，然后运行以下命令：
auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable关闭“本地安全策略”。
重要
仅主 AD FS 服务器需要执行剩余步骤。
在 AD FS 服务器上启用审核属性
- 打开“AD FS 管理”管理单元。 （在“服务器管理器”中，选择“工具”>“AD FS 管理” 。）
- 在“操作”窗格中，选择“编辑联合身份验证服务属性” 。
- 在“联合身份验证服务属性”对话框中，选择“事件”选项卡。
- 选择“成功审核”和“失败审核”复选框，然后选择“确定”。 默认情况下应启用成功审核和失败审核。
在 AD FS 服务器上启用审核属性
重要
此步骤仅适用于主 AD FS 服务器。
打开 PowerShell 窗口并运行以下命令：
Set-AdfsProperties -AuditLevel Verbose
默认情况下启用“基本”审核级别。 有关详细信息，请参阅 Windows Server 2016 中的 AD FS 审核增强功能。
验证详细记录
若要验证是否启用了详细记录，请执行以下操作。
打开 PowerShell 窗口并运行以下命令：
Get-AdfsProperties验证 Auditlevel 是否设置为“详细”
验证 AD FS 服务帐户审核设置
- 转到“Security Settings\Local Policies\User Rights Assignment”文件夹。 双击“生成安全审核”。
- 在“本地安全设置”选项卡上，验证是否列出了 AD FS 服务帐户。 如果未列出，请选择“添加用户或组”，然后将 AD FS 服务帐户添加到列表。 然后选择确定。
- 关闭“本地安全策略”。
查看 AD FS 审核日志
启用 AD FS 审核日志后，应该能够使用事件查看器检查 AD FS 审核日志。
- 打开“事件查看器”。
- 转到“Window 日志”，然后选择“安全” 。
- 在右侧窗格中选择“筛选当前日志”。
- 对于“事件源”，请选择“AD FS 审核” 。
- 可以在此处获得 AD FS 事件的完整列表。
有关审核日志的详细信息，请参阅操作问题。
警告
组策略可以禁用 AD FS 审核。 如果禁用了 AD FS 审核，则不能使用有关登录活动的使用情况分析。 请确保没有组策略禁用 AD FS 审核。
下表提供了与审核级别事件对应的常见事件的列表
基本审核级别事件
| ID | 事件名称 | 事件描述 |
|---|---|---|
| 1200 | AppTokenSuccessAudit | 联合身份验证服务颁发了有效的令牌。 |
| 1201 | AppTokenFailureAudit | 联合身份验证服务未能颁发有效的令牌。 |
| 1202 | FreshCredentialSuccessAudit | 联合身份验证服务验证了新凭据。 |
| 1203 | FreshCredentialFailureAudit | 联合身份验证服务未能验证新凭据。 |
有关详细信息，请在此处参阅 AD FS 事件的完整列表。
详细审核级别事件
| ID | 事件名称 | 事件描述 |
|---|---|---|
| 299 | TokenIssuanceSuccessAudit | 已成功为信赖方颁发令牌。 |
| 403 | RequestReceivedSuccessAudit | 已收到 HTTP 请求。 有关标头，请参阅包含同一实例 ID 的审核 510。 |
| 410 | RequestContextHeadersSuccessAudit | 以下请求上下文标头存在 |
| 411 | SecurityTokenValidationFailureAudit | 令牌验证失败。 请参见内部异常了解详细信息。 |
| 412 | AuthenticationSuccessAudit | 信赖方“%4”的“%3”类型令牌已成功通过身份验证。 有关调用方标识，请参阅包含同一实例 ID 的审核 501。 |
| 500 | IssuedIdentityClaims | 有关包含实例 ID %1 的事件条目的详细信息。 可能有更多包含同一实例 ID 的事件，其中包含更多信息。 |
| 501 | CallerIdentityClaims | 有关包含实例 ID %1 的事件条目的详细信息。 可能有更多包含同一实例 ID 的事件，其中包含更多信息。 |
有关详细信息，请参阅此处的 AD FS 事件完整列表。
测试与 Microsoft Entra Connect Health 服务的连接性
有时，Microsoft Entra Connect Health 代理会与 Microsoft Entra Connect Health 服务断开连接。 此连接丢失的原因可能包括网络问题、权限问题和各种其他问题。
如果代理无法将数据发送到 Microsoft Entra Connect Health 服务达 2 小时以上，门户中会出现以下警报：“Health 服务数据不是最新的”。
可以运行以下 PowerShell 命令，确认受影响的 Microsoft Entra Connect Health 代理是否能够将数据上传到 Microsoft Entra Connect Health 服务：
Test-AzureADConnectHealthConnectivity -Role ADFS
Role 参数目前可接受以下值：
ADFSSyncADDS
注意
若要使用连接工具，必须先完成代理注册。 如果无法完成代理注册，请确保满足 Microsoft Entra Connect Health 的所有要求。 默认情况下，在代理注册过程中测试连接。
使用 Microsoft Entra Connect Health 监视 AD FS
AD FS 的警报
Microsoft Entra Connect Health 警报部分将提供活动警报列表。 每个警报均包含相关信息、解决方法步骤和相关文档的链接。
可以双击某个活动的警报或已解决的警报打开新的边栏选项卡，其中包含附加信息、解决警报的步骤，以及相关文档的链接。 还可以查看过去已解决警报的相关历史数据。
AD FS 的使用情况分析
Microsoft Entra Connect Health 使用情况分析可分析联合服务器的身份验证流量。 可以双击使用情况分析框打开使用情况分析边栏选项卡，显示多个指标和分组。
注意
要将使用情况分析与 AD FS 结合使用，请务必启用 AD FS 审核。 有关详细信息，请参阅 为 AD FS 启用审核。
若要选择其他指标、指定时间范围或更改分组，请右键单击使用情况分析图表并选择“编辑图表”。 然后可以指定时间范围、选择不同的指标以及更改分组。 可以查看基于不同“度量值”的身份验证流量分布，并使用以下部分中所述的相关“分组依据”参数对每个度量值进行分组:
度量值：请求总数 - 由 AD FS 服务器处理的请求总数。
| 分组依据 | 分组意味着什么，它为什么很有用？ |
|---|---|
| 全部 | 显示所有 AD FS 服务器处理的请求总数的计数。 |
| 应用程序 | 基于目标信赖方对请求总数分组。 此分组有助于了解具体某个应用程序正在接收多少百分比的总流量。 |
| 服务器 | 基于处理请求的服务器对请求总数分组。 此分组有助于了解总流量的负载分布。 |
| 工作区加入 | 基于请求是否来自已加入工作区（已知）的设备对请求总数分组。 此分组有助于了解是否使用标识基础结构未知的设备来访问资源。 |
| 身份验证方法 | 基于用于身份验证的身份验证方法对请求总数分组。 此分组有助于了解用于身份验证的常见身份验证方法。 可能的身份验证方法如下所示：
如果联合服务器接收带有 SSO Cookie 的请求，则该请求被计为 SSO（单一登录）。 在这种情况下，如果此 cookie 有效，则不会要求用户提供凭据并该用户可无缝访问该应用程序。 如果有多个受联合服务器保护的信赖方，则这种行为很常见。 |
| 网络位置 | 基于用户的网络位置对请求总数分组。 该位置可以是 Intranet 或 Extranet。 此分组有助于了解来自 Intranet 或 Extranet 的流量分别为多少百分比。 |
度量值：失败请求总数 - 失败了的由联合身份验证服务处理的请求总数。 （此度量值仅在 Windows Server 2012 R2 的 AD FS 上可用）
| 分组依据 | 分组意味着什么，它为什么很有用？ |
|---|---|
| 错误类型 | 基于预定义错误类型显示错误数。 此分组有助于了解常见类型的错误。
|
| 服务器 | 基于服务器对错误分组。 这种分组有助于了解各服务器的错误分布情况。 分布不均匀可能表示服务器处于错误状态。 |
| 网络位置 | 基于请求的网络位置（Intranet 或 Extranet）对错误分组。 这种分组有助于了解失败的请求类型。 |
| 应用程序 | 基于目标应用程序（信赖方）对失败分组。 这种分组有助于了解错误数最多的目标应用程序。 |
度量值：用户计数 - 使用 AD FS 主动进行身份验证的独立用户平均数
| 分组依据 | 分组意味着什么，它为什么很有用？ |
|---|---|
| 全部 | 此指标提供所选时间段内使用联合身份验证服务的用户平均数。 不对用户进行分组。 平均值取决于所选的时间段。 |
| 应用程序 | 基于目标应用程序（信赖方）对用户平均数分组。 这种分组有助于了解使用具体某个应用程序的用户数量。 |
AD FS 的性能监视
Microsoft Entra Connect Health 性能监视提供有关度量值的监视信息。 选择“监视”框会打开一个边栏选项卡，其中包含有关指标的详细信息。
通过选择边栏选项卡顶部的“筛选器”选项，可以按服务器进行筛选，以查看单个服务器的度量值。 要更改度量值，请右键单击监视边栏选项卡下的监视图表，并选择“编辑图表”（或选择“编辑图表”按钮）。 在打开的新边栏选项卡中，可从下拉列表中选择其他度量值，并指定查看性能数据的时间范围。
用户名/密码登录失败的前 50 个用户
AD FS 服务器上身份验证请求失败的常见原因之一就是请求所提供的凭据无效，也就是错误的用户名或密码。 这往往是用户的密码太复杂、忘记密码或打错字。
但也有其他原因导致 AD FS 服务器处理的请求数超过预期，例如：某个应用程序缓存了用户凭据、凭据过期，或者某个恶意用户尝试以一系列的常见密码登录到帐户。 这两个示例都是可能导致请求激增的合理原因。
Microsoft Entra Connect Health for ADFS 提供一份报告，内容有关因为用户名或密码无效而登录尝试失败的前 50 个用户。 处理场中所有 AD FS 服务器所生成的审核事件即可完成此报告。
可以在这份报告中轻松获取以下信息：
- 过去 30 天内用户名/密码错误的失败请求总数
- 每天由于用户名/密码不正确而登录失败的平均用户人数。
单击此部分可转到提供其他详细信息的主要报告边栏选项卡。 此边栏选项卡包含一个提供趋势信息的图形，可帮助建立有关用户名或密码错误的请求的基准。 此外，该边栏选项卡还提供在过去一周尝试失败次数最多的 50 个用户的列表。 请注意，可以通过过去一周前 50 个用户的情况来确定错误密码尝试的峰值。
该图形提供以下信息：
- 每天由于用户名/密码不正确而登录失败的总数。
- 每天登录失败的唯一用户总数。
- 最后一个请求的客户端 IP 地址
该报告提供以下信息：
| 报告项 | 说明 |
|---|---|
| 用户 ID | 显示使用的用户 ID。 此值是用户键入的内容，在某些情况下是使用的错误用户 ID。 |
| 失败尝试次数 | 显示该特定用户 ID 的尝试失败总次数。 该表已按最多失败尝试次数的降序排序。 |
| 上次失败时间 | 显示上次发生失败时的时间戳。 |
| 上次失败 IP | 显示最后一个错误请求中的客户端 IP 地址。 如果在此值中看到多个 IP 地址，则可能是因为其中包括了转发客户端 IP 以及用户上一次尝试的请求 IP。 |
注意
此报告每隔 12 小时以该段时间内收集的新信息自动进行更新。 因此，报告中不包括过去 12 小时内的登录尝试。