Hi @wimr
The issue in the scenario you mentioned seems to be in the Intune–NDES–CA chain, and it hasn't reached the ClearPass side yet.
The problem is probably this:
You want a certificate from Intune with the SCEP profile (both Device and User profiles).
The request goes to the NDES server, and NDES uses the SCEP template to issue the certificate from the backend Microsoft CA.
Oceanleaf
You can check the following link:
https://www.oceanleaf.ch/intune-ndes-scep-explained
However, the "Issued to" field on the certificate issued by the CA is always the Ndes Service Account (as shown on the screen), meaning it shows the NDES service account instead of the client's identity.
This behavior occurs in two situations:
The Subject Name setting of the certificate template you use for SCEP is incorrect ("Build from this Active Directory information").
Or you are autoenrolling this template for the NDES service account, effectively getting certificates for itself instead of the clients.
A cert with the correct CN/SAN that can be used for EAP-TLS on the device/user is not being generated; ClearPass cannot recognize the user/device from the certificate.
You need to check the SCEP Template on the CA;
- Subject Name tab
It should be selected: "Supply in the request"
(It should definitely not be "Build from this Active Directory information").
This is because you define the Subject and SAN in the Intune SCEP profile (CN={{DeviceId}}, CN={{UserPrincipalName}}, etc.). The CA must retrieve this from the request; otherwise, it will use the DN of the RA account (NDES service account), and you will encounter the problem you are experiencing.
The following link is a useful document:
https://msendpointmgr.com/2016/04/12/prepare-your-environment-for-scep-certificate-enrollment-with-microsoft-intune
-Security tab
Grant Read + Enroll permissions to the NDES service account.
Do not grant Autoenroll. If you grant Autoenroll, the CA will distribute user certificates from this template to its own NDES account; you will see the service account in the Issued To field.
-Intune SCEP profiles side
The profiles in the screenshots generally look correct;
Points to note:
The Device profile must be assigned to device groups (not user groups). This way, the device certificate can be delivered even if the user is not logged in.
The User profile must be assigned to user groups. When the user logs in, the Intune management extension user context retrieves this certificate.
Ensure that the Intune Certificate Connector health status is shown as "Active"/"OK" in the portal.
- Verification steps
After fixing the above, it would be good to check on a test device;
Device certificate
mmc → Certificates snap-in → Computer account → Personal \ Certificates
The new cert should have:
The Issued to field should look like CN={{DeviceId}}, it should never be Ndes Service Account.
Intended Purposes should be Client Authentication.
User certificate
mmc → Certificates (Current User) → Personal \ Certificates
Issued to = CN=<user's UPN>.
In the CA console, make sure you now see certificates issued to different DeviceId/UPNs in the Issued Certificates list; you should not see a single NDES account.
If the "Issued to: Ndes Service Account" screen is the RA certificate on the NDES server, this is normal (it comes from the Enrollment Agent / CEP Encryption templates and only resides on the NDES server). The problem is if a certificate with this name is generated on the client side or in the CA from the SCEP template.
- On the ClearPass / EAP-TLS side:
After the certificates are fixed, in ClearPass:
802.1X service → Use EAP-TLS (you can do both machine and user).
When creating role maps:
For the Device cert, use the DeviceId / AAD_Device_ID values within the SAN,
For the User cert, use the UserPrincipalName or Subject CN in the SAN to match with AD / Intune.
These corrections are optional :)
-------------------------------------------