Fix ApplicationManagedBy isn't set and AADSTS700027 in Entra Connect Sync

"ApplicationManagedBy isn't set" means the application-based authentication settings on the Microsoft Entra connector were wiped, usually by saving the connector in Synchronization Service Manager; fix it by running Repair-ADSyncToolsEntraAppParameters from ADSyncTools 2.3.0 or later. AADSTS700027: The certificate with identifier used to sign the client assertion is not registered on application usually means two sync servers share one application registration, through a shared connector account or a cloned server. Fix that by reverting each server to a service account and reconfiguring application-based authentication so every server gets its own ConnectSyncProvisioning_ application.

Who this is for and what you will have at the end

This guide is for administrators of Microsoft Entra Connect Sync servers that already use application-based authentication, including servers switched automatically during an upgrade to 2.5.x. You need local administrator rights on the servers and a Hybrid Identity Administrator or Global Administrator account in Microsoft Entra ID.

At the end you will have:

• A diagnosis of which of the three common failures you have.
• Repaired connector parameters, or a dedicated application identity for each server.
• A working certificate rotation, verified in the wizard and the event log.
• Habits that stop the problem coming back before the 7 April 2027 deadline, when legacy authentication stops working.

If you haven't upgraded or switched to application-based authentication yet, start with upgrading Entra Connect Sync to 2.6 with application-based authentication.

Identify the failure

Microsoft also notes that several application-based authentication issues have been fixed in recent versions. For example, 2.6.91.0 fixed a certificate rotation issue that could remove the last usable application key during directory replica delays. Upgrading to the latest build is part of every fix below.

Collect diagnostics

Run these in an elevated PowerShell session on each sync server:

# Application or ServiceAccount
Get-ADSyncEntraConnectorCredential
 
# Scheduler state; SchedulerSuspended must be False for automatic rotation
Get-ADSyncScheduler
 
# Machine identifier used in the application name
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Azure AD Connect" | Select-Object SyncMachineIdentifier

In Event Viewer, filter the Application log for source Directory Synchronization and event ID 906 to find token errors, and for event IDs 1011 and 1012 to find certificate warnings and errors.

A community thread on Microsoft Q&A about this error (a user report, not Microsoft guidance) used two more read-only checks. The first reads the global setting; the second lists the Microsoft Entra connector's connectivity parameters, which should include values for CertificateId, ApplicationManagedBy and CertificateManagedBy:

(Get-ADSyncGlobalSettings).Parameters["Microsoft.AADConnector.ApplicationManagedBy"]
 
Get-ADSyncConnector | Where-Object {$_.ConnectorTypeName -ne "AD"} |
    Select-Object -ExpandProperty ConnectivityParameters |
    Format-Table Name, Value -Auto

In that thread, the global setting showed EntraConnectSync while the connector parameters were missing, and Get-ADSyncEntraConnectorCredential failed with the same ApplicationManagedBy error. Checking the connector, not only the global setting, avoids that trap.

Finally, compare certificates. In the wizard, View or export current configuration shows the application (client) ID and the Certificate thumbprint. In the Microsoft Entra admin center, open App registrations, find the ConnectSyncProvisioning_<Servername>_<SyncMachineIdentifier> application with that client ID, and look at Certificates & secrets. In Microsoft Graph, a certificate credential's customKeyIdentifier defaults to the certificate thumbprint, which is what you are matching. If the server's thumbprint isn't among the application's certificates, the server is signing with a key the application doesn't know, which is exactly what AADSTS700027 reports.

Fix 1: Restore the cleared connector parameters

Why it happens

The Synchronization Service Manager UI wasn't updated for the new application-based authentication fields. When a server switched to application-based authentication during an automatic upgrade, opening the Microsoft Entra connector's properties in that UI and selecting OK saves the connector without those fields. Microsoft states the issue doesn't occur when application-based authentication was enabled with the wizard or on a fresh installation. Sync continues on the current certificate, but the next automatic rollover fails.

Run the repair

1. Start PowerShell with Run as Administrator on the affected server.
2. Install or update ADSyncTools. The minimum version for the repair function is 2.3.0.

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

3. Import the module and run the repair:

Import-Module ADSyncTools
Repair-ADSyncToolsEntraAppParameters

The function restores the missing parameters. Afterwards the configuration wizard should open without errors, sync continues on application-based authentication, and future rollovers succeed.

If the repair reports missing parameters

In the Microsoft Q&A thread, Repair-ADSyncToolsEntraAppParameters from ADSyncTools 2.3.1 stopped with Required authentication parameters missing from connector configuration. The administrator who posted the question resolved it by temporarily reverting to a service account and then re-running the application-based authentication setup in the wizard. The commands are the same ones Microsoft documents for reverting a server in Fix 2:

Set-ADSyncScheduler -SyncCycleEnabled $false
 
$cred = Get-Credential   # Hybrid Identity Administrator or Global Administrator
$connAccountName = "Sync_$($env:COMPUTERNAME)_$((Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Azure AD Connect').SyncMachineIdentifier.Substring(0, 12))"
Add-ADSyncAADServiceAccount -AADCredential $cred -Name $connAccountName
 
Get-ADSyncEntraConnectorCredential   # ConnectorIdentityType should be ServiceAccount

Then start the Microsoft Entra Connect wizard, choose Additional tasks > Configure application-based authentication to Microsoft Entra ID, and sign in when prompted. Confirm that Get-ADSyncEntraConnectorCredential now returns Application and that the connector parameters have values, then re-enable the scheduler:

Set-ADSyncScheduler -SyncCycleEnabled $true

The same service account commands appear in Microsoft's own troubleshooting procedure for shared applications below. In the Q&A case the existing app registration was updated, so it didn't need to be deleted first.

Fix 2: Give each server its own application

Why it happens

Application-based authentication is designed for one service principal and certificate per server. Automatic enrollment identifies the application registration by the connector's service account, so two servers that share a custom Microsoft Entra connector account end up on one application. The same happens with the default Sync_SERVERNAME_############@contoso.onmicrosoft.com account if a server was cloned after Entra Connect was installed, because both copies carry the same machine identifier. When one server rotates the certificate, the other fails. Typically the server that switched last works and the one configured first fails.

Procedure

In this example, ServerA works and ServerB is broken. Start with the working server.

On ServerA:

1. Pause the scheduler with Set-ADSyncScheduler -SyncCycleEnabled $false.
2. Revert to a service account, entering Hybrid Identity Administrator or Global Administrator credentials:

$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. Optionally confirm ConnectorIdentityType is ServiceAccount with Get-ADSyncEntraConnectorCredential.
4. Note ServerA's SyncMachineIdentifier.

On ServerB:

5. Run the wizard, select Rotate application certificate and complete all steps to recover application-based authentication.
6. Pause the scheduler with Set-ADSyncScheduler -SyncCycleEnabled $false.
7. Read ServerB's SyncMachineIdentifier and compare it with ServerA's.
8. If they match, generate a new identifier:

Stop-Service ADSync
 
$newId = [Guid]::NewGuid().ToString("N")
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Azure AD Connect" -Name SyncMachineIdentifier -Value $newId
 
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Azure AD Connect" | Select-Object SyncMachineIdentifier
 
Start-Service ADSync

9. Revert ServerB to a service account with the same three commands as step 2.
10. In the Microsoft Entra admin center, go to App registrations > All applications and delete the conflicting ConnectSyncProvisioning_* application or applications.
11. Run the wizard on ServerB, select Configure application-based authentication and complete the setup. This registers a new application dedicated to ServerB.
12. Resume the scheduler with Set-ADSyncScheduler -SyncCycleEnabled $true.

Back on ServerA:

13. Repeat steps 11 and 12.

App registrations should now list two distinct ConnectSyncProvisioning_<Servername>_<SyncMachineIdentifier> applications, and both servers can run without certificate errors. To prevent a repeat, give each server a unique connector account and a unique machine identifier. Cloning a server with Entra Connect installed isn't a supported deployment method.

Fix 3: Recover an expired or stale certificate

Entra Connect warns with event 1011 once the certificate has used 70 percent of its lifetime, around day 63 for the default 90-day certificate, and logs error 1012 after it expires. The messages are written at the scheduler frequency, so a suspended scheduler means fewer warnings and no automatic rotation.

1. Run Get-ADSyncScheduler. If SyncCycleEnabled is False because someone disabled it during maintenance, re-enable it with Set-ADSyncScheduler -SyncCycleEnabled $true. SchedulerSuspended is set by Entra Connect during upgrades and shouldn't be changed with PowerShell; finish or rerun the upgrade instead.
2. Rotate immediately in the wizard: Additional tasks > Rotate application certificate. Manual rotation works even if the current certificate has already expired.
3. If you use your own certificate (BYOC), generate a new certificate, upload the .cer file to the application's Certificates & secrets, grant the ADSync service account read access to the private key, and run Invoke-ADSyncApplicationCredentialRotation -CertificateSHA256Hash $certHash with the scheduler disabled, following Microsoft's BYOC procedure.
4. If Entra Connect logs an error that it couldn't remove the old certificate credential, remove it with Remove-EntraApplicationKey -CertificateId <certificateId>, using the ID from the event or the admin center.

Verify the fix

Get-ADSyncEntraConnectorCredential      # ConnectorIdentityType: Application
Get-ADSyncScheduler                     # SyncCycleEnabled: True
Start-ADSyncSyncCycle -PolicyType Delta

• The wizard opens without ApplicationManagedBy isn't set, and View or export current configuration shows the client ID, a certificate thumbprint and a Not valid after date in the future.
• The thumbprint in the wizard matches a certificate on the server's own application in App registrations.
• No new event 906 entries appear after the delta cycle, and the export to Microsoft Entra ID succeeds in the run history.
• Each server has its own ConnectSyncProvisioning_ application.

Prevent it from coming back

• Don't edit the Microsoft Entra connector in Synchronization Service Manager. Microsoft warns that even selecting OK without changes can remove required settings. Use the Entra Connect wizard or documented PowerShell.
• One connector account and one machine identifier per server. Never share the connector account between active and staging servers, and never clone a sync server.
• Never use a Global Administrator account as the connector account. A compromised sync server would put the whole tenant at risk.
• Keep the scheduler running. Automatic rotation depends on it.
• Monitor events 906, 1011 and 1012 on every server, staging servers included.
• Stay current. Recent builds fixed TPM-backed certificate handling and certificate rotation problems.

Last resort: temporary rollback

If sync is down and you need time, revert to a service account with Add-ADSyncAADServiceAccount after disabling the scheduler, confirm ServiceAccount with Get-ADSyncEntraConnectorCredential, and re-enable the scheduler. The recreated account can take up to 15 minutes to work, so a brief "Access Denied" is expected. Legacy authentication stops working after 7 April 2027, so reconfigure application-based authentication as soon as the root cause is fixed.

Checklist

• Failure identified from the wizard error, event 906 or events 1011 and 1012.
• ADSyncTools 2.3.0 or later installed; Repair-ADSyncToolsEntraAppParameters run where parameters were cleared.
• Fallback revert and reconfigure used only if the repair fails.
• Shared applications split: unique machine identifiers, conflicting apps deleted, one app per server.
• Expired certificates rotated; scheduler running.
• Wizard thumbprint matches the application's certificate.
• Synchronization Service Manager no longer used to edit the Microsoft Entra connector.

References

• Troubleshoot Microsoft Entra Connect Sync application-based authentication
• Authenticate to Microsoft Entra ID by using application identity
• Microsoft Entra Connect: Version release history
• Microsoft Entra Connect Sync: Scheduler
• Hardening updates for Microsoft Entra Connect Sync
• keyCredential resource type
• Microsoft Q&A: Entra ID Connect error ApplicationManagedBy is not set correctly