Hello everyone, in this post, we will discuss a conditional access configuration I have seen in many Entra Tenants. Most of them use conditional access policies to control and allow access to resources only from compliant devices. These device compliance policies are managed through Intune. Nearly all of these compliance conditional access policies looks like this one:
| Property | Value |
| Name | Internals-BaseProtection-AllApps-AnyPlatform-CompliantAndMFA |
| User or workload identities | All users or scoped to a user group |
| Target resources | All resources but Microsoft Intune Enrollment excluded |
| Grant controls | Require MFA and require device to be marked as compliant |
But why should we exclude Microsoft Intune Enrollment from our compliance policy? Almost nearly all answered of this question with: we need it to solve the “chicken-egg-problem”.
What is the “chicken-egg-problem” they assume?
When defining a conditional access policy with: require device to be marked as compliant grant control, people often assume that there will be a problem registering new devices in Intune. Normally, new devices can’t be comply with the device compliance policy before they are registered in Intune. With such a conditional access policy in place (I described above) the registration process will be blocked, because the device can’t be comply to the device compliance policy at this point of process. This is named a “chicken-egg-problem”.
But is this behavior really true? No it isn’t in my opinion and I have done some and can confirm that it works as expected for windows and android (I couldn’t try it with iOS, MacOS). Let my try to explain…
Register your devices in Intune with device compliance CAP in place
First of all, Microsoft noted, that you don’t need to exclude “Microsoft Intune Enrollment”, if your conditional access policy enforce device compliance and is scoped to “all resources”.
Require compliant, hybrid joined devices, or MFA – Microsoft Entra ID | Microsoft Learn
This statement let me assume, that there must be hardcoded compliance exclusions for:
- Device Registration Service
- Microsoft Intune Enrollment
- Microsoft Intune Web Company Portal
These hardcodes exclusions must be similar to the hardcoded compliance exclusion for “Company Portal App”, which was documented by Yuya Chudo at blackhat EUROPE 2024 conference and used for the TokenSmith exploit.
There is another caveat when using exclusion in your policy and target it to “all resources”. In this case, you also exclude several low privileged scopes:
Targeting Resources in Conditional Access Policies – Microsoft Entra ID | Microsoft Learn
These low privilege scopes also be excluded from you conditional access policy and in case of exploitation, these privileges can be used to gather more information about your tenant resources. For example via GraphRunner.
Device & Intune registration process
For a better understanding what happens during the Device and Intune registration process, lets have a look at the following flo-diagram:
--- config: theme: neo-dark --- sequenceDiagram autonumber participant UX as Cloud Experience Host (Join Web App) participant Entra as Microsoft Entra ID participant DRS as Azure DRS participant Intune as Intune (Enrollment/MDM) participant TPM as TPM / Key Store UX->>Entra: [A] Endpoint discovery (OpenID config) Entra-->>UX: OpenID metadata UX->>UX: [B] Build sign-in request UX->>Entra: [C] Realm discovery / POST credentials Entra-->>UX: ID token (user session) UX->>Intune: [D] Retrieve MDM terms of use Intune-->>UX: MDM terms of use UX-->>Intune: User accepts terms UX->>DRS: [E] DRS discovery (request discovery data) DRS-->>UX: Discovery data document UX->>TPM: [F] Generate device key pair (dk) + CSR TPM-->>UX: dk public key UX->>TPM: Derive transport key (tk) TPM-->>UX: tk public key UX->>DRS: [G] Submit ID token, CSR, tkpub, attestation DRS->>Entra: Validate ID token / tenant Entra-->>DRS: OK DRS-->>UX: ENTRA DEVICE CERT + DeviceId <-- Entra cert issued here note over UX,DRS: Entra device certificate UX->>UX: [H] Install device cert (LocalMachine\My) UX->>Intune: Start MDM enrollment Intune-->>UX: Enrollment challenge / MDM profile UX->>TPM: Generate management key pair TPM-->>UX: mgmt public key UX->>Intune: CSR + challenge response Intune-->>UX: INTUNE MDM CLIENT CERT <-- Intune cert issued here note over UX,Intune: Intune MDM Device certificate UX->>Intune: First check-in using MDM client cert (mTLS)
Walkthrough
Requirements
Conditional Access Policy
I have the following conditional access policy in place and enabled in my lab tenant:
Intune compliance policy for windows
Additionally, I have the following basic compliance policy in Intune in place.
Basics
| Property | Value |
|---|---|
| Name | custom compliance policy |
| Plattform | Windows 10 and later |
| Profiltyp | Windows 10/11 compliance policy |
Compliance Settings
| Category | Property | Value |
|---|---|---|
| Device Health | Secure Boot | Required |
| Device Health | Code Integrity | Required |
Microsoft Defender for Endpoint
| Property | Value |
|---|---|
| Require the device to be at or under the machine risk score | Low |
Assignments
Included groups
This compliance policy is assigned to the two Entra groups, which decide windows devices based on their deviceTrust property value.
| Group | Filter | Filter mode | dynamic rule |
|---|---|---|---|
| MDM-Intune-managed_CloudJoined-Devices | None | None | (device.deviceTrustType -eq “AzureAD”) and (device.accountEnabled -eq True) and (device.deviceManagementAppId -eq “0000000a-0000-0000-c000-000000000000”) |
| MDM-Intune-managed_HybridJoined-Devices | None | None | (device.deviceTrustType -eq “ServerAD”) and (device.accountEnabled -eq True) and (device.deviceManagementAppId -eq “0000000a-0000-0000-c000-000000000000”) |
Process walkthrough
Meanwhile the device gets prepared, it goes through multiple phases:
Enrollment
- Enrollment service discovery
- Entra ID device join
- Entra ID certificate enrollemt
- Intune service discovery
- Intune device registration
- Intune certificate enrollment
All these phases are described in detail in the diagram above.
OOBE
Now that everything is ready, we can start with the installation. For this test, the chosen device name is t2-cloud-03 :
Login to Microsoft Entra ID
MFA kicks in
Discover tenant realm
Request
Corresponding event log entry: Microsoft\Windows\User Device Registration\Admin
Response
Device registration service sends back the related endpoints for my tenant based on the previous request.
Corresponding event log entry: Microsoft\Windows\User Device Registration\Admin
Device Registration
Just afterwards the device registration endpoints are discovered, the application (dsreg) creates a TPM bounded RSA 2048 bit key pair (known as device key [dkpub/dkpriv & transport key [tkpub/tkpriv]). Additionally, dsreg initiate a PKCS device certificate request using dkpub and dkpriv, signs the request with dkpriv. The device certificate is used for a long-term device authorization. The requests consists of
- access token
- certificat request signed with dkpub
- transport key
- metadata
Request
Response
The device registration is completed when device id and the device certificate are received from the device registration service. Additionally, If you have not configured that your registration user should not be a member of the local administrator group, the user is assigned to the local administrator group identified by the well-know SID: S-1-5-32-544.
Corresponding event log entry: Microsoft\Windows\User Device Registration\Admin
You can verify this by looking in your machine cert store
Sign-in Logs
Lets have a look into the Sign-In and Audit-Logs in Entra.
Audit log
Corresponding event log entry: Microsoft\Windows\User Device Registration\Admin
A this point, the first steps of device registration were completed successfully and our device is entra joined although there is a conditional access policy in place which enforce device compliance for all resources.
Intune Registration
Now, lets have a look at the Intune registration processes and how the associated endpoints are discovered.
Discover intune service endpoints
Request
This is the MDM discovery call from the Windows Enroll Client (ENROLLClient) to Intune. It is part of the start of MDM registration (after successful device registration/DRS) and queries which enrollment and policy endpoints your tenant should use.
Response
Intune enrollment
After the relevant endpoints are discovered, mdm enrollment client starts the enrollment process. At this point, intune mdm enrollment client must perform an authentication to get the needed information. And do you remember, we have previously defined a conditional access policy which enforces devices to be marked as compliant for authenticate successfully? Chaka – instead of the referred policy, intune starts the enrollment process although the device isn’t comply with the compliance policy at this point.
Request
Decoded token:
Repsonse
The response contains instructions on how to define the request for the microsoft intune mdm device certificate.
In one of the following responses, the mdm enrollment client receives the microsoft intune mdm device certificate.
Result
The previous steps shown the device registration und intune enrollment process for a new none-compliant device meanwhile a conditional access policy which enforce device compliance is in place.
Finally, lets take another look into the Entra Portal. You can find there two related events:
- Device Registration Service
- Microsft Intune Enrollment
Both steps completed successfully.
If you take a closer look into the Microsoft Intune Enrollment event, you also notice that the task completed successfully:
But your conditional access report results in state: failure
But this failure report is unimportant for the initial enrollment process. The Microsoft intune enrollment process was completed successfully meanwhile a conditional access policy with scoped to all resources (without exclusions) for MFA and required devices marked to be compliant was enabled.
After the device was enrolled successfully, the assigned compliance policies were deployed and the compliant state appears.
