Radius Intune
Brittany Bhadd
With the Microsoft Cloud PKI root CA approach, you can create one or more PKIs within a single Intune tenant. Deploying Cloud PKI this way creates a two-tier hierarchy, so you can have multiple issuing CAs subordinate to the root CA. These CAs aren't public. Rather, you create both the root CA and issuing CAs in the cloud, private to the Intune tenant. The issuing CA issues certificates to Intune-managed devices by using the device configuration SCEP certificate profile.
Alternatively, you can bring your own certificate authority (BYOCA). With this approach, you deploy Microsoft Cloud PKI by using your own private CA. This option requires you to create an issuing CA in the cloud that's private to the Intune tenant. The issuing CA is anchored to a private CA, such as Active Directory Certificate Services (ADCS). When you create a Cloud PKI BYOCA issuing CA, a certificate signing request (CSR) is also created in Intune. Your private CA is required to sign the CSR.
Determine the location of the root trust anchor. A trust anchor is a CA certificate, or the public key of a CA, used by a relying party as the starting point for certificate trust or path validation. A relying party could have one or more trust anchors derived from more than one source. A trust anchor can be the public key of the root CA or it can be the public key of the CA that issues an end-entity certificate to the relying party.
When using certificates to perform certificate-based authentication, ensure that both relying parties have the CA certificate trust chain (which includes the public keys and root CA) of all certificates involved in a TLS/SSL based conversation. In this context, the relying parties are:
If the issuing CA certificate is missing, a relying party can request it via the Authority Information Access (AIA) property in the certificate by using the native OS platform certificate chaining engine.
When connecting to a relying party such as a Wi-Fi access point or VPN server, an SSL/TLS connection is first established by the managed Intune device when attempting to connect. Microsoft Cloud PKI doesn't provide these TLS/SSL certificates. You must obtain these certificates through another PKI or CA service. As a result, when you create a Wi-Fi or VPN profile, you also have to create a trusted certificate profile and assign it to managed devices to trust the TLS/SSL connection. The trusted certificate profile must contain the public keys for the root and issuing CAs responsible for issuing the TLS/SSL certificate.
There are methods for deploying CA certificates to relying parties not managed by Intune, such as radius servers, Wi-Fi access points, VPN servers, and web app servers supporting certificate-based authentication.
If the relying party isn't a member of Active Directory Domain, ensure the CA certificate trust chain for the Microsoft Cloud PKI root and issuing CA is installed in the security store of the relying party. The appropriate security store varies depending on the OS platform and the hosting application providing the service.
During a Cloud PKI root CA deployment, the Cloud PKI root certificate needs to be deployed to all relying parties. If an issuing CA certificate isn't present on a relying party, the relying party can automatically retrieve and install it by initiating certificate discovery. This process, known as the certificate chaining engine (CCE), is platform-specific and used to retrieve missing parent certificate. The URL of the issuing CA certificate is in the AIA property of a leaf certificate (the certificate issued to the device using a Cloud PKI issuing CA). A relying party can use the AIA property to retrieve parent CA certificates. The process is similar to CRL downloading.
Android OS requires servers to return an entire certificate chain and doesn't do certificate discovery following AIA paths. For more information, see Android developer docs. Be sure to deploy the full certificate chain to Android managed devices and relying parties.
The relying party should already have the private CA certificate chain. However, the BYOCA issuing CA certificate should also be deployed to relying parties. If the relying party is a member server in Active Directory Domain, use GPO as the deployment method.
If the Cloud PKI BYOCA issuing CA certificate isn't deployed to the relying party platform, then the AIA (URL) property of the Cloud PKI issued SCEP certificate (end-entity/leaf certificate) can be used by the CCE of the relying party to request and install the Cloud PKI BYOCA issuing CA certificate (public-key) in its trust store. However, this behavior is not guaranteed and dependent on each OS/Platform implementation of the CCE. It is a best practice to deploy the BYOCA issuing CA certificate to the managed device and relying party.
Before starting a deployment and issuing certificates, determine the location of the root trust anchor. It can be in the Cloud PKI root or private root CA. The location determines the certificate trust chain required by both Intune managed devices and relying parties.
Everything will deploy to the Devices they will get the Root CA, Request a Certificate, and deploy the Wi-Fi profile but when they attempt to connect it fails the Error Message I am getting on the NPS logs is:
On my PC if I do a cert request and use the template that Intune uses I can use that Cert on my PC and it will connect if i export it and manually make the wifi profile on my phone using the requested certificate it will work. it just seems when Intune requests the certificate it doesn't work
Has anyone got this to successfully work with Intune I've been pulling my hair out all week trying to get this working I don't want to do Device Certificates as from what I know I have to make dummy computer accounts in AD for each mobile device and even when I tried that I could not get them to connect either.
My understanding is if the User Certificate SCEP template was using the subject CN=UserPrincipalName it would map to the AD user but this doesn't seem to be the case it doesn't map as when I check the user account in ad for Published certificates its not there they are under the NDES Service account Published Certificates and even then if i export and add it to the user in question and also do a name mapping with that certificate i still get reason code 16
@Zachery Minton , For the error message, it seems there's mismatch when doing authentication. I notice we use user certificate. When we request it manually it is working. But it is not working when request from Intune.
If our issue is that the subject name in the two user certificates are not the same, maybe we can consider to change the NPS to authentication the certificate like samaccountname or distinguished name.
If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
I changed the SCEP Certificate Profile to use CN=OnPremisesSamAccountName and removed the WIFI profile and certificates from the android device and let it sent and push back a certificate was requested and sent to the device and it still results with the same error
So what I attempted to do I made a New SECP Configuration profile for Windows 10 and set it up exactly like the SECP Profile on Android and IOS Devices and Waited for it to push out a Certificate to my computer I was able to connect successfully to wifi on my PC using this Certificate I exported it and imported it to my android phone and it will not connect i still get the same error that it doesn't match a user.
@Zachery Minton , From our testing, when we use the same certificate which is working on win10 to connect WIFI on Android, it is failed. It seems the issue is not on certificate or maybe Android WiFi connection needs something specific. Here, we suggest to contact Radius NPS support to check on the issue to get more help. The following is a link with the Phone number we can contact
-us/topic/global-customer-service-phone-numbers-c0389ade-5640-e588-8b0e-28de8afeb3f2
So i managed to get this working by a suggestions from a Reddit user. In the Intine Wifi Profile for the Certificate Server Name if I enter the fqdn of the NPS Server which also happens to be my CA it will work this seems to work for Personal Android Wifi Profile,IOS Personal and Corporate Wifi Profiles, But it seems intune does not allow you to enter a Certificate Server Name on a Fully Managed Android Wifi Profile the option is missing which prevents the profile from working on Fully Managed Android Devices
In the official article, the settings is not displayed as well. But after discussing internally, I know although the "Certificate Server Name" is not set in Android Enterprise WiFi profile, it can also work.
-us/mem/intune/configuration/wi-fi-settings-android-enterprise#enterprise
For our issue, we needs to look into more logs to troubleshoot. Like Radius trace log, Android debug log and etc. For example, we can compare the Android debug log on one working device and one not working to see if the identity is correct and if other fields has any different. if the NPS server has sent the certificate to the client end and if the client send back its own certificate. As the log will contain some sensitive information. To protect our environment information, we can also consider opening an Intune Phone case to do log analysis to see if there's any more helpful information we can find on Intune side.
-us/mem/get-support
We've taken on a new client to roll out a bunch of Azure AD joined clients to the users. As part of this they will need to use their Meraki WiFi solution.
The Meraki is currently configured to use Radius on a Windows 2019 Server with NPS installed. There is an on premise AD which is synced down to Azure AD. The Radius server is currently configured to use the on premise Domain Users group for authentication. However to prevent personal devices being joined to the WiFi network using their AD creds the client wishes to use certficates to authenticate instead.
We have an internal CA and the root certificate is installed on all clients via InTune.
It seems the we potentially need to deploy PKCS certificates via InTune and leverage the InTune Certificate Connector to sit betweeen the CA and InTune.
However the part of this I'm struggling with and can't seem to find any information on is the actual connection between the certificates deployed via InTune and the Certificate Connector and the Radius Server authentication.
So basically we can get certificates to the clients but how does the Radius server know to authenticate them?