Table of Contents
Using Microsoft Cloud PKI With Always On VPN
Introduction
I have been playing around with Always On VPN recently. Using it with Domain, Hybrid and Entra Joined devices.
As you will be aware Always on VPN heavily relies on Certificates and requires an Active Directory Certificate Services (ADCS) PKI infrastructure. When using Domain and or Hybrid it is easy enough to deploy the certificates. However, when using an Entra Joined its not as straight forward deploying the certificates, you need to deploy Network Device Enrollment Services (NDES) and then the Intune Certificate Connector and also Entra Private Network Connector (the artist formerly known as App Proxy). This in itself is pretty straight forward but requires some level of maintenance.
Microsoft released Cloud PKI: Microsoft Cloud PKI for Microsoft Intune – Microsoft Intune | Microsoft Learn. This removes the need for the NDES infrastructure.
In my experience the ADCS is still required on premises to issue the NPS and the VPN certificates. But, you do not need to use it to issue the client certificates.
Licenses
Like all things in Microsoft 365 you do require a license for this. So, there is an additional cost. You can get a free trial for up to 250 users initially and its about £1.80 a month per user after the trial.
I have looked at 3rd Party solutions like SCEPMan, which is great, however there is a minimum of 50 users, and it also requires a Logic App in Azure.
I am using the 90 day trial and have assigned the license to my teat user.
Using a Bring Your Own Certificate Authority (BYOCA)
The idea of BYOCA is that you still use your on-premises Certificate Authority (CA) but have an Issuing CA in the cloud. This Issuing CA effectively then becomes part of your on-premises PKI and allows you to issue certificates to Entra Joined Clients directly from Intune without the need of NDES.
Create an Issuing CA
In the Microsoft Intune Portal go to Tenant Administrator > Cloud PKI and then select Create:
Downlaod the request file
Then on a device run the following:
certreq -submit -attrib "CertificateTemplate:SubCA" -config "akdev-ca.ad.andykemp.dev\AndyKempDev-CA" c:\Share\AndyKempDev-CloudCA.req c:\share\AndyKempDev-CloudCA.cer
certutil -ca.chain -config "akdev-ca.ad.andykemp.dev\AndyKempDev-CA" c:\share\AndyKempDev-CA_fullChain.p7bNB if there is an issue running this verify that you are running this from a Command Prompt and not a PowerShell prompt, I was getting frustrated as to why it wasn’t working until ran CMD from the PowerShell window.
The next task is to publish the Cloud Certificate as a Subordinate CA and to the NTAuthCertificates store. This is done with the cer file that was downloaded previously.
So, from an elevated command prompt run the following Commands to do this.
certutil -dspublish -f "c:\Share\AndyKempDev-CloudCA.cer" SubCA
certutil -dspublish -f "c:\Share\AndyKempDev-CloudCA.cer" NTAuthCA
With out these records in place the cloud certificates will not be recognised.
Publish cloud trusted certificate
The next step we need to do is to publish the Cloud CA to our client devices, this is done in a similar way to how we published the ADCS Root certificate. So, again with the same CER file that you downloaded earlier follow the below steps to create the trusted certificate policy.
Create a new Configuration policy in Intune
Select Windows 10 and later and then select Template as Profile type and then select Trusted certificate and click Create:
Provide a meaningful name for the new policy
Select the downloaded CER file and the Destination store is to be the Computer certificate store – Root:
Add the Assignments
No Applicability rules are needed
Confirm the settings and then click on Create:
NPS Trusted Root Certificate
As well as deploying the trusted root to the clients we need to deploy the same certificate to the computer trusted root store on the servers running NPS.
Follow the next steps to import the certificate to the Network Policy Server
Once the certificate has been imported restart the NPS box.
Create the user certificate profile
Now we need to Create the SCEP Profile, follow the steps as you did for the NDES SCEP, only with the called out differences:
Create a New Policy
Platform: Windows 10 or later
Profile type: Template
Template Name: SCEP Certificate
Provide a meaningful name
Then on the SCEP certificate properties apply the following settings:
Certificate type: User
Subject name format: CM={{Username}},E={{EmailAddress}}
User principal name (UPN): {{UserPrincipalName}}
URI: {{OnPremisesSecurityIdentifier}}
Certificate validity period: Years 1
Key storage provider (KSP): Enroll to Trusted Platform Module (TPM) KSP if present, otherwise Software KSP
Key usage: Key encipherment, Digital signature
Key size (bits): 2048
Hash algorithm: SHA-2
Root Certificate: AndyKempDev-CloudCA – Trusted Certificate
Extended key usage: Client Authentication 1.3.6.1.5.5.7.3.2 Client Authentication (1.3.6.1.5.5.7.3.2)
Renewal threshold (%): 20
SCEP Server URLs: https://{{CloudPKIFQDN}}/TrafficGateway/PassThroughRoutingService/CloudPki/CloudPkiService/Scep/0b7d8e41-6b84-4783-974c-8f6dfbe3b2d7/11638fd6-4bcc-44f2-8561-814fe468c005
On the assignments ensure that the devices and the users who will receive the certificate is added:
Add any Applicability rules if there are any of them.
Review the settings and then Create if you are happy with it.
Update the VPN Profile policy
Now you have your new certificate being issued you will want to update your VPN Profile policy in Intune so it used the new certificate and not the NDES cert. Simply go in to the VPN Profile and then edit the settings so that the Authentication certificate specified is the new one you have just created.
Conclusion
If you have been using the NDES certificate up until now ensure that that policy is no longer being deployed to the users in question. You may want to remove the certificate from the local store if needed, however the VPN Connection should use the new certificate if you updated the connection profile to use the new certificate.
You now have a working Cloud CA deploying your Always on VPN certificates to your end user devices meaning you no longer need to maintain your NDES SCEP infrastructure.