0xcaa9001f: Co-Management MDM Enrollment Failed Fix

Your Configuration Manager clients are Microsoft Entra hybrid joined, co-management is switched on, and the devices never show up in Intune. On the client, CoManagementHandler.log keeps printing the same line every 15 minutes:

MDM enrollment failed with error code 0xcaa9001f 'Integrated Windows authentication supported only in federation flow.'. Will retry in 15 minutes...

Microsoft’s MDM enrollment error 0xcaa9001f article puts the cause on the Configuration Manager side. The client tries integrated Windows authentication against Microsoft Entra ID while the verified domain isn’t federated. That happens when the Cloud Management Azure service isn’t configured in Configuration Manager, or when AD User Discovery or Microsoft Entra user Discovery isn’t enabled for the affected users. Microsoft says both discovery methods must be enabled.

You fix it in the Configuration Manager console. Intune and the device don’t need changes.

Quick Fix checklist

1. Confirm the exact text in %WinDir%\CCM\logs\CoManagementHandler.log: 0xcaa9001f and “Integrated Windows authentication supported only in federation flow.”
2. Run dsregcmd /status and confirm AzureAdJoined : YES and DomainJoined : YES. If the device isn’t hybrid joined yet, fix that first.
3. In the Configuration Manager console, go to Administration > Cloud Services > Azure Services and check for a connection of type Cloud Management. If there isn’t one, run the Azure Services Wizard for Cloud Management.
4. On that Cloud Management connection, confirm Enable Microsoft Entra user Discovery is on.
5. Confirm Active Directory User Discovery is enabled and its containers include the affected users.
6. Wait for the client’s next retry, then check CoManagementHandler.log again.

What 0xcaa9001f means in Microsoft’s words

Microsoft’s article scopes the error to “co-managed Windows devices that are Microsoft Entra hybrid joined and managed by using Configuration Manager.” It lists three log entries.

In %WinDir%\CCM\logs\CoManagementHandler.log:

MDM enrollment failed with error code 0xcaa9001f ‘Integrated Windows authentication supported only in federation flow.’. Will retry in 15 minutes…

Under Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin:

System Migration Task Started. Impersonation result. Result: (An attempt was made to reference a token that does not exist.).Auto MDM Enroll: Failed (Unknown Win32 Error code: 0xcaa9001f)

Under Applications and Services Logs > Microsoft > Windows > Microsoft Entra ID > Operational:

Http request status: 400. Method: POST Endpoint Uri: https://login.microsoftonline.com/<AADTenantID>/oauth2/token Correlation ID: <ID> OAuth response error: invalid_grant Error description: AADSTS70002: Error validating credentials. AADSTS50155: Device is not authenticated.

The cause, quoted: “This issue occurs when integrated Windows authentication is tried by the Configuration Manager client against Microsoft Entra ID while the verified domain isn’t federated.” The article then names the two situations above and gives one solution: configure Azure Services for Cloud Management and enable both AD User Discovery and Microsoft Entra user Discovery for the users.

The same article adds a note: “Bring your own device (BYOD) enrollment or auto-enrollment by using Group Policy works successfully.” Only the Configuration Manager enrollment path fails.

Why the obvious diagnosis can be wrong

The Entra log makes it look like an identity problem

invalid_grant, AADSTS70002 and AADSTS50155 point you at Microsoft Entra ID first. The Microsoft Entra error code reference describes AADSTS50155 as “DeviceAuthenticationFailed - Device authentication failed for this user.” Its AADSTS70002 entry reads “InvalidClient - Error validating the credentials. The specified client_secret does not match the expected value for this client.”

Taken alone, that second entry points you at app secrets. Microsoft’s 0xcaa9001f article doesn’t mention secrets. Its fix is the Cloud Management service and the two discovery methods, so start there before you touch any app registration.

Group Policy enrollment works, so the tenant looks fine

If you test with the Group Policy auto-enrollment setting Enable automatic MDM enrollment using default Microsoft Entra credentials and it enrolls, it’s tempting to call the tenant healthy and blame the device. Microsoft’s note says that result is expected with this error: BYOD and Group Policy enrollment work while the Configuration Manager path fails. Both documented causes sit in Configuration Manager.

One discovery method isn’t enough

Having one of the two discovery methods on doesn’t clear this error. Microsoft’s article says both must be enabled. The Configure discovery page says the same thing for hybrid identities: “If the user is a federated or synchronized identity, you must use Configuration Manager Active Directory user discovery as well as Microsoft Entra user discovery.”

Federating the domain isn’t the documented fix

The message says integrated Windows authentication is “supported only in federation flow.” Microsoft’s fix doesn’t ask you to federate the domain. It asks you to finish the Configuration Manager cloud setup. Don’t plan an identity change to clear this code.

Adjacent codes in the same logs have different causes

Microsoft’s co-management auto-enrollment troubleshooting article documents several neighbors. Check which code you have before you change anything.

Code	What you see, per Microsoft	Microsoft’s cause	Where to fix
0xcaa9001f	”Integrated Windows authentication supported only in federation flow.”	Cloud Management Azure service missing, or AD User Discovery or Microsoft Entra user Discovery not enabled	Configuration Manager console
0x8018002a	0xCAA2000C with AADSTS50076 in the Microsoft Entra ID Operational log	MFA is Enforced, which blocks the client from enrolling with the signed-in user’s credentials	Per-user MFA state or Trusted IPs
0x80180023 (with 0x800706D9)	“MDM Enroll: OMA-DM client configuration failed”	The dmwappushservice service is missing from the device	The device’s services and registry
0x801c03f2	”The public key user certificate is not found on the device object”	Hybrid join failed: device object missing in Entra ID, or Usercertificate not populated	On-premises AD and Microsoft Entra Connect sync
0x80090016	”Keyset does not exist”	Windows isn’t the owner of the TPM	The TPM, see my 80090016 guide

If your devices enroll through Group Policy and log 0x8018002b instead, that’s a UPN or MDM user scope problem: see Auto MDM Enroll failed 0x8018002b.

Evidence to inspect

CoManagementHandler.log

Microsoft’s Configuration Manager log files reference lists CoManagementHandler.log as the log to “troubleshoot co-management on the client.” It lives in %WinDir%\CCM\logs\. To find the line without opening the whole file:

Select-String -Path "$env:WinDir\CCM\Logs\CoManagementHandler.log" -Pattern 'caa9001f'

DeviceManagement-Enterprise-Diagnostics-Provider Admin log

The 0xcaa9001f article spells the channel DeviceManagement-Enterprise-Diagnostic-Provider. Microsoft’s Windows enrollment errors article shows the full log name as Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin. To pull matching events:

Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 200 |
    Where-Object { $_.Message -match 'caa9001f' } |
    Select-Object TimeCreated, Id, Message

Both commands only read logs. I checked that they parse in PowerShell 7; I haven’t run them on an affected device for this article.

dsregcmd /status

Microsoft’s dsregcmd troubleshooting page defines a Microsoft Entra hybrid joined device as AzureAdJoined : YES and DomainJoined : YES (with EnterpriseJoined : NO). If you see AzureAdJoined : NO, the device hasn’t finished hybrid join, and the enrollment error isn’t your first problem. Start with hybrid join error 0x801c001d if the device can’t read the SCP.

The Configuration Manager console

Check two places:

• Administration > Cloud Services > Azure Services: is there a connection of type Cloud Management? Microsoft’s Configure Azure services page uses this node and connection type.
• Administration > Hierarchy Configuration > Discovery Methods: is Active Directory User Discovery enabled, with containers that include the affected users?

Fix: configure Cloud Management and both user discoveries

1. Configure the Cloud Management Azure service

Microsoft’s Configure Azure services page says the Cloud Management service “enables the site and clients to authenticate by using Microsoft Entra ID.” Run the Azure Services Wizard and select Cloud Management. Signing in to Azure in the wizard needs an administrative user; Microsoft’s Configure discovery page names Global Administrator for the manual app permission steps and warns that it’s a highly privileged role.

If you let Configuration Manager create the Microsoft Entra app, Microsoft says it configures the app with the permissions it needs. If you import an app you created in Azure first, you have to grant the server app the Microsoft Graph application permission Directory.Read.All and then Grant admin consent.

2. Enable Microsoft Entra user Discovery

Microsoft’s discovery page says Microsoft Entra user Discovery “isn’t enabled or configured the same as other discovery methods.” You turn it on while configuring the Cloud Management Azure service:

1. On the Discovery page of the wizard, select Enable Microsoft Entra user Discovery.
2. Select Settings and set a discovery schedule. You can also turn on delta discovery.

For a connection that already exists, select it in the Azure Services node and open Properties to review its configuration.

3. Enable Active Directory User Discovery

Go to Administration > Hierarchy Configuration > Discovery Methods, open Active Directory User Discovery, enable it, and add the containers that hold the affected users. Microsoft’s discovery page covers the container, account and polling schedule options.

4. Let the client retry

The client log says it retries in 15 minutes. After discovery has run, check CoManagementHandler.log for a new attempt. Microsoft’s article doesn’t say how long the fix takes to reach clients, so use the log to confirm it.

Verify the fix

1. CoManagementHandler.log no longer shows 0xcaa9001f on new attempts.
2. The DeviceManagement Admin log no longer shows Auto MDM Enroll: Failed (Unknown Win32 Error code: 0xcaa9001f).
3. The device appears in the Microsoft Intune admin center.
4. In Settings > Accounts > Access work or school, the device syncs. If sync fails with “we weren’t able to verify your credentials,” that’s the MFA sync issue in Microsoft’s co-management troubleshooting article, not this error.

What not to waste time on

• Re-imaging or resetting the device. Microsoft’s cause is site configuration.
• Changing MDM user scope when Group Policy enrollment already works for the same users.
• Rotating Microsoft Entra app secrets because the log says AADSTS70002. Fix Cloud Management and discovery first.
• Federating the domain to satisfy the wording of the error.

Prevention checklist

• Before you enable co-management, confirm a Cloud Management connection exists under Azure Services.
• Enable both Active Directory User Discovery and Microsoft Entra user Discovery, and keep them enabled.
• When you add new user OUs, add them to the Active Directory User Discovery containers.
• If you import your own Entra app, record the Directory.Read.All grant and admin consent in your build notes.
• Check the rest of Microsoft’s co-management prerequisites in the tutorial: Microsoft Entra ID P1 or P2, an Intune subscription, MDM authority set to Intune, and the client setting Automatically register new Windows 10 domain joined devices with Microsoft Entra ID set to Yes.
• Remember that Microsoft Entra registered (workplace joined) devices aren’t supported with co-management. They need to be Microsoft Entra joined or hybrid joined.

Takeaway

When 0xcaa9001f shows up in CoManagementHandler.log, I go straight to the Configuration Manager console: Cloud Management under Azure Services, then both user discovery methods. I’d only open Microsoft Entra ID or the device after those two checks pass.

Related ZakitPro guides:

• SCCM vs Intune in 2026: the hybrid reality guide for where co-management fits.
• Intune enrollment errors: 0x80180014, 0x80180018, 0x8018000A for other Windows enrollment codes.
• Intune device sync failures after Conditional Access changes (0x80180028) if enrollment works and sync breaks.

Sources

• MDM enrollment error 0xcaa9001f for co-managed Windows devices: symptoms, log entries, cause and solution.
• Troubleshoot auto-enrolling existing Configuration Manager devices in Intune: CoManagementHandler.log, 0x8018002a, 0x80180023, 0x801c03f2, 0x80090016 and the MFA sync issue.
• Configure discovery: Microsoft Entra user Discovery prerequisites, Directory.Read.All, and the hybrid identity note.
• Configure Azure services: the Cloud Management service and the Azure Services node.
• Tutorial: Enable co-management for existing clients: prerequisites, client settings and supported join states.
• Configuration Manager log files: CoManagementHandler.log.
• Troubleshooting Windows enrollment errors: the DeviceManagement Admin log name.
• Enroll a Windows device automatically using Group Policy: the Group Policy setting name.
• Troubleshoot devices by using the dsregcmd command: hybrid joined state values.
• Microsoft Entra authentication and authorization error codes: AADSTS50155 and AADSTS70002.