通过

排查 Microsoft Entra Connect Sync 基于应用程序的身份验证问题

Microsoft Entra Connect Sync 的基于应用程序的身份验证（ABA）使用应用程序标识（具有证书的服务主体），而不是用户名和密码进行身份验证以Microsoft Entra ID。 此方法通过消除在同步服务器上存储管理员凭据的需要来提高安全性。 本文可帮助你排查 Microsoft Entra Connect Sync 中 ABA 的已知问题，并提供解决这些问题的步骤。

已知问题

自动升级后缺少连接参数 - 在自动升级到启用了 ABA 的 Microsoft Entra Connect 版本后，Microsoft Entra （Azure AD） 连接器的连接字段（如应用程序和证书）在 Synchronization Service Manager UI 中显示为空白。 在连接器属性中选择“确定”会导致配置向导中出现未设置 ApplicationManagedBy错误，并阻止下一个自动证书轮换。

使用同一连接器帐户的多个服务器 - ABA 旨在为每个服务器设计仅使用一组服务主体或证书。 如果两个Microsoft Entra Connect Sync 服务器共享相同的自定义Microsoft Entra （Azure AD） 连接器帐户（Microsoft Entra ID 中的本地服务帐户），则自动 ABA 设置会向他们提供一个共享应用程序注册，导致服务器使用相同的Microsoft Entra ID 应用或服务主体。

当一台服务器更新该应用的证书时，另一服务器的身份验证中断，导致第二台服务器上的同步错误。 如果在安装 Microsoft Entra Connect 同步服务后克隆了服务器，则默认Microsoft Entra （Azure AD） 连接器帐户（即 Sync_SERVERNAME_############@contoso.partner.onmschina.cn）也会发生此问题。

升级后 Microsoft Entra Connector 的连接参数缺失

症状

Microsoft Entra Connect 服务器自动更新到版本 2.5.x 并自动切换到基于应用程序的身份验证后，Synchronization Service Manager 中的 Microsoft Entra （Azure AD） 连接器不显示新连接参数的值，ApplicationManagedBy、CertificateManagedBy 和 CertificateId 字段为空。 如果打开连接器属性并选择 “确定 ”（即使不更改任何内容），它将保存连接器配置并清除这些 ABA 参数定义。

因此，运行 Microsoft Entra Connect 配置向导时，它失败并出现错误： 未设置 ApplicationManagedBy。 同步继续使用当前证书，直到它过期，但由于配置不完整，自动证书滚动更新会失败，并且同步到 Microsoft Entra ID 在下一次续订时中断。

原因

同步服务管理器 UI 不会更新以处理新的 ABA 字段，当你在此旧 UI 中打开并保存连接器时，它会删除基于应用程序的身份验证设置。 此问题仅出现在自动升级后自动转换为 ABA 的实例中。 如果使用向导或全新安装手动启用了 ABA，则不会发生此问题。

决议

使用 PowerShell 修复函数还原Microsoft Entra Connector 配置中缺少的参数。 在受影响的服务器上执行以下步骤：

  1. 使用 “以管理员身份运行”启动新的 PowerShell 会话。

  2. 若要使用 ADSyncTools 模块，需要从 PowerShell 库安装或更新它，如下所示。

    注释

    此 ADSyncTools 函数的最低要求版本为 2.3.0。

    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Install-Module ADSyncTools # If ADSyncTools isn't installed, or;
Update-Module ADSyncTools # If ADSyncTools is already installed

  3. 导入 ADSyncTools 模块：

    Import-Module ADSyncTools

  4. 运行修复函数：

    Repair-ADSyncToolsEntraAppParameters

此过程还原缺少的参数。 还应能够运行配置向导，而不会出错。 同步服务将使用基于应用程序的身份验证，并且将来的证书滚动更新会成功。

重要

启用 ABA 时，避免使用同步服务管理器 UI 查看或编辑 Microsoft Entra （Azure AD） 连接器的属性。 即使选择 “确定 ”而不进行更改，也可以删除所需的设置。 始终使用 Microsoft Entra Connect 向导（或 PowerShell 命令）对连接器进行配置更改。

共享同一自定义Microsoft Entra Connector 帐户的多个服务器

症状

请考虑一个部署，其中包含两个Microsoft Entra Connect Sync服务器，一个作为活动服务器，一个作为备用的暂存服务器。如果这些服务器被配置为使用同一Microsoft Entra ID连接器帐户（即，旧版身份验证的相同Microsoft Entra服务帐户凭据），则在启用ABA后可能会遇到以下身份验证错误。

Log Name:      Application
Source:        Directory Synchronization
Date:          12/01/2025 0:00:00 AM
Event ID:      906
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      EntraConnect.Contoso.com
Description:
[MSAL] AcquireTokenWithCertificate: Exception caught while acquiring token via certificate. [invalid_client] - A configuration issue is preventing authentication - check the error message from the server for details. You can modify the configuration in the application registration portal. See https://aka.ms/msal-net-invalid-client for details.  Original exception: AADSTS700027: The certificate with identifier used to sign the client assertion is not registered on application. [Reason - The key was not found., Please visit the Azure Portal or directly use MS Graph to see configured keys for app Id '<guid>'. Review the documentation at https://learn.microsoft.com/en-us/graph/deployments to determine the corresponding service endpoint and https://learn.microsoft.com/en-us/graph/api/application-get?view=graph-rest-1.0&tabs=http to build a query request URL, such as 'https://microsoftgraph.chinacloudapi.cn/beta/applications/<guid>']. Trace ID: <guid> Correlation ID: <guid> Timestamp: <datetime>

通常，第二台服务器（或上次切换到 ABA 的服务器）将正常工作，并且首先配置了 ABA 的服务器将开始无法连接到具有此类证书错误的Microsoft Entra ID。 如果尝试修复第一个服务器（例如，手动重新运行 ABA 设置），则第二台服务器上的身份验证中断。

原因

根据设计，一次只能有一台服务器使用一个Microsoft Entra ID 应用程序进行身份验证。 自动 ABA 注册使用连接器的服务帐户来标识应用程序注册。 当两个不同的服务器共享同一帐户时，系统错误地为两者使用单个应用程序标识。 这两个服务器最终都配置了相同的应用程序和服务主体。 这不受支持，因为每个Microsoft Entra Connect 实例都应具有唯一的应用程序。

当安装了 Microsoft Entra Connect 的服务器被克隆到另一台生产服务器时，会出现相同的问题，因为这些服务器会共享同一计算机标识符，而这种克隆方法是不被支持的产品部署方式。 简言之，服务器的身份冲突是因为它们与一个应用注册相绑定。 默认情况下，Microsoft Entra Connect 向导使用每个服务器的唯一帐户，因为它使用服务器的名称来标识应用程序注册，而不是 Microsoft Entra 连接器的服务帐户，从而避免了此问题。

注释

若要防止此问题，请确保每个Microsoft Entra Connect 实例都使用唯一的连接器帐户和唯一的计算机标识符。 如果有多个同步服务器（例如，在暂存环境下）使用相同的 Microsoft Entra （Azure AD） 连接器帐户，请按照每个服务器上记录的解决步骤进行操作，这样每个实例都能获得其自己的应用程序注册。

警告

不要使用 全局管理员 帐户作为 Microsoft Entra （Azure AD） 连接器帐户。 默认情况下配置的 Microsoft Entra 服务帐户对同步期间所需的内容具有更受限的权限，而管理员帐户在云中具有无限制的权限。 如果配置有全局管理员帐户的本地Microsoft Entra Connect 服务器遭到入侵，则会使整个 Microsoft Entra 租户面临风险。

决议

为每个Microsoft Entra Connect 服务器提供其自己的应用程序标识。 为此，必须单独重新配置每个服务器，方法是将其还原为旧式身份验证，然后运行 ABA 配置，以便每个服务器创建自己的应用注册。 在此方案中，有两台配置了 ABA 的服务器：ServerA 运行正常，ServerB 处于损坏状态。 在每个服务器上执行以下步骤，从工作服务器开始，然后移动到处于中断状态的服务器。

  1. 在 ServerA 上，暂时暂停同步计划程序：在 Microsoft Entra Connect 服务器上以管理员身份打开 PowerShell 并运行：

    Set-ADSyncScheduler -SyncCycleEnabled $false

  2. 将 ServerA 还原为旧身份验证：在 PowerShell 窗口中运行以下命令，将服务帐户分配回 Microsoft Entra （Azure AD） 连接器。 系统会提示输入凭据。 在 Microsoft Entra ID 中提供全局管理员或混合标识管理员的用户名和密码。 以下 cmdlet 将 Microsoft Entra （Azure AD） 连接器配置为使用名为 Sync_<Servername>_<SyncMachineIdentifier> 的同步帐户（替换应用标识）。

    $cred = Get-Credential
$connAccountName = "Sync_$($env:COMPUTERNAME)_$((Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Azure AD Connect').SyncMachineIdentifier.Substring(0, 12))"
Add-ADSyncAADServiceAccount -AADCredential $cred -Name $connAccountName

  3. 验证旧身份验证是否正在使用（可选）：可以通过运行命令 Get-ADSyncEntraConnectorCredential确认连接器重新使用服务帐户。 在输出中，检查 ConnectorIdentityType 是否为 ServiceAccount（而不是应用程序）。 这意味着连接器现在正在使用提供的帐户凭据。

  4. 检查 ServerA 计算机标识符：在切换到 ServerB 之前，请记下 ServerA 中的当前计算机标识符：

    Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Azure AD Connect" | Select-Object SyncMachineIdentifier

  5. 切换到 ServerB 并轮换 ABA 证书：若要修复 ServerB 的 entra ID 身份验证Microsoft（中断状态），请在 ServerB 上运行 Microsoft Entra Connect 向导，然后选择“ 轮换应用程序证书”，然后完成所有步骤以恢复 ABA。

  6. 暂时暂停同步计划程序（ServerB）：在 Microsoft Entra Connect 服务器上以管理员身份打开 PowerShell 并运行：

    Set-ADSyncScheduler -SyncCycleEnabled $false

  7. 检查 ServerB 计算机标识符：从 ServerB 获取当前计算机标识符，并将其与 ServerA 的值进行比较。

    Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Azure AD Connect" | Select-Object SyncMachineIdentifier

  8. 生成新的计算机标识符：如果两个服务器具有相同的计算机标识符，请运行以下命令以生成新的 ID：

    # 1. Stop ADSync service
Stop-Service ADSync

# 2. Generate and set new identifier
$newId = [Guid]::NewGuid().ToString("N")
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Azure AD Connect" -Name SyncMachineIdentifier -Value $newId

# 3. Confirm new identifier
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Azure AD Connect" | Select-Object SyncMachineIdentifier

# 4. Restart ADSync service
Start-Service ADSync

  9. 将 ServerB 还原为旧身份验证：在 PowerShell 窗口中运行以下命令，将服务帐户分配回 Microsoft Entra （Azure AD） 连接器。 系统会提示输入凭据。 在 Microsoft Entra ID 中提供全局管理员或混合标识管理员的用户名和密码。 以下 cmdlet 将 Microsoft Entra （Azure AD） 连接器配置为使用名为 Sync_<Servername>_<SyncMachineIdentifier> 的同步帐户（替换应用标识）。

    $cred = Get-Credential
$connAccountName = "Sync_$($env:COMPUTERNAME)_$((Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Azure AD Connect').SyncMachineIdentifier.Substring(0, 12))"
Add-ADSyncAADServiceAccount -AADCredential $cred -Name $connAccountName

  10. 从 Microsoft Entra ID 中删除应用：转到 Microsoft Entra 管理中心 并导航到 “应用注册>所有应用程序”，然后删除一个或多个具有证书冲突（即） ConnectSyncProvisioning_*以前的应用。

  11. 在 ServerB 上重新配置 ABA：在 ServerB 上启动 Microsoft Entra Connect 向导，选择“配置基于应用程序的身份验证”，并完成在此服务器上启用 ABA 的设置步骤。 这会注册一个专用于 ServerB 的新Microsoft Entra应用程序。

  12. 恢复同步计划程序：运行以下命令以重新启用同步，并确认正常同步已恢复。

    Set-ADSyncScheduler -SyncCycleEnabled $true

  13. 切换到 ServerA：在 ServerA 上重复步骤 11 和 12。

完成这些步骤后，每个Microsoft Entra Connect 服务器都会链接到其自己的应用程序标识，Microsoft Entra ID。 它们将不再相互冲突。 这两个服务器都应能够同时运行同步，而不会发生身份验证错误。 可以在 应用注册 下的 Microsoft Entra 管理中心中验证，现在有两个不同的应用条目（每个服务器都有一个名称 ConnectSyncProvisioning_<Servername>_<SyncMachineIdentifier>）。

通过解决本指南中讨论的问题，在升级后还原缺少的连接参数，以及分离多个服务器的应用程序标识，可以使用基于应用程序的身份验证维护正常运行且更安全Microsoft Entra Connect 环境。

始终使用 Microsoft Entra Connect 向导或记录的 PowerShell 命令进行配置更改。 有关设置和管理 ABA 的详细信息，请参阅 使用应用程序标识对 Microsoft Entra ID 进行身份验证。

  • Last updated on