EAP-TLS Device Certificate for Entra Joined Devices with Intune

[kmo78]

In my environment, we have some devices that are hybrid AD joined and some that are only Entra Joined. I'm using SCEP certificates that are being issued by a third party CA. I'm running Cisco ISE 3.3 Patch 4. I've set the SCEP profile so that there are two Subject Alternative Names as follows:

URI: ID:Microsoft Endpoint Manager:GUID:{{DeviceID}}

URI: {{OnPremisesSecurityIdentifier}}

The hybrid joined devices are getting the SAN with the URL=tag:microsoft.com,2022-09-14:sid:<value> but Entra Joined devices are not, which is to be expected.

I've created one policy set that I feel should cover devices that are hybrid joined and those that are entra joined. The hybrid joined devices are authenticating as expected. When I look in the ISE Live Logs, I'm seeing the hybrid joined devices with the URL=tag.microsoft.com.

My issue is the Entra Joined devices keep failing authentication. I get the following error:

22047 User name attribute is missing in client certificate.

The Live logs shows a Username of host/MACHINENAME. My understanding is it should be showing URL=id:Microsoft Endpoint Manager:GUID:<GUID> since that is what is populated in the SAN. The live logs do show many attributes from the certificate but the SAN attribute is missing. When I view the certificate on the device I'm testing with, that certificate does contain the SAN.

Here is a screenshot of the authentication Policy:

The Intune_Wireless_MDM is a Certificate Authentication Profile. In that profile, I've tried different variations of which Certificate Attribute to use but none of them appear to work. My options are:

I've tired Subject Alternative Name and Subject Alternative Name - Other Name but neither appear to work. For the hybrid joined machines, Subject Alternative name is selected and working.

I have ISE configurated for MDM integration with Intune.

I've engaged TAC but haven't had much luck with getting an answer on a solution.

[Greg Gibbs]

I'm not sure I understand the reason for this setup.

Why would you have the CAP using the SAN for Identity in the Authentication process when the SAN field appears to contain nothing but the GUID and SID? This would also mean that you're seeing nothing but GUID/SID values in the Live Logs.

In my environment, the certificate CN is populated with something like the {{DeviceName}} variable and the SAN has the GUID (and SID, where applicable). I use the OU field in the certificate defining the join type (Hybrid Joined Device vs. Entra Joined Device) so I can use that as a matching condition in my AuthC/AuthZ Policies.
I use two different CAPs; one for Hybrid Entra Joined with AD as the Identity Store, and another for Entra Joined with Identity Store = n/a). This allows me to authorize Hybrid Entra Joined devices against AD (which is not currently possible with Entra Joined devices against Entra ID). 
For the Intune MDM integration, I use the SAN as the identity for the MDM lookups.

[kmo78]

Thanks for the response. I think I may have been misunderstanding how the MDM integration works. I was under the impression that the Identity had to be the GUID from Intune in order for ISE to identify the device in the MDM.

Thanks for describing your setup, I think I will be replicating those conditions.

I'm using a third party CA so my certificate doesn't have an OU field. I would need to find a way to determine which devices are hybrid and which are entra joined. If you have any recommendations on that, I'd love to hear them.

Again, I appreciate the response and it helped clarify some things I wasn't quite understanding.