Microsoft Intune Cloud PKI and Active Directory

Recently, Microsoft introduced a new PKI-as-a-Service offering called Cloud PKI. This cloud-based PKI can issue and manage certificates to Intune-managed endpoints. Administrators can now deploy user and device authentication certificates using Intune Cloud PKI without deploying Active Directory Certificate Services (AD CS) on-premises. Numerous blog posts and YouTube videos show how to configure and deploy Intune Cloud PKI, so I won’t reinvent the wheel with a complete configuration guide here. This article will focus instead on integrating Microsoft Intune Cloud PKI with on-premises Active Directory (AD).

Note: Administrators must deploy certificates to all enterprise domain controllers and RADIUS servers to support certificate-based authentication with AD. However, Cloud PKI for Intune can only issue certificates to Intune-managed endpoints today. It cannot issue certificates to servers. Administrators must use another CA (AD CS or another Cloud PKI solution) to issue and manage domain controller and RADIUS server certificates on-premises to support this scenario.

AD Integration

While Intune Cloud PKI eliminates the need for on-premises AD CS infrastructure, there will be times when Cloud PKI-issued certificates will be used to authenticate to on-premises AD, either through a RADIUS server such as Windows Network Policy Server (NPS), which is common for VPN and Wi-Fi deployments, or other methods. Additional configuration is required to support this scenario.

Publish Root/Issuing CA Certificates

The Intune Cloud PKI root and issuing CA certificates must be published in AD to support on-premises AD authentication using Intune Cloud PKI-issued certificates. Follow the steps below to complete this task.

Note: Arguably, you could skip publishing the Intune Cloud PKI root and issuing CA certificates in on-premises AD because Cloud-PKI certificates can only be issued to Intune-managed endpoints, in which case you are likely already deploying the Cloud PKI root and issuing CA certificates using Intune. I’m including these steps for completeness. However, publishing the Intune Cloud PKI issuing CA certificate in the NtAuthCA certificate store in AD is required to support on-premises AD authentication using Intune Cloud PKI-issued certificates, so that step is mandatory.

RootCA Store

On a domain-joined computer on-premises, open an elevated PowerShell or command window and run the following command to publish the Intune Cloud PKI root CA certificate to the RootCA certificate store in AD.

certutil.exe -dspublish -f <path to Cloud PKI root CA certificate> RootCA

SubCA Store

Next, run the following command to publish the Cloud PKI issuing CA certificate to the SubCA certificate store in AD.

certutil.exe -dspublish -f <path to Cloud PKI issuing CA certificate> SubCA

NtAuthCA Store

Finally, run the following command to publish the Intune Cloud PKI issuing CA certificate to the NtAuthCA certificate store in AD. Publishing the Intune Cloud PKI issuing CA certificate in the NtAuthCA store in AD allows certificates issued by Intune Cloud PKI to be used to authenticate on-premises AD if required. Be sure to run this command even if you did not run the previous commands to publish the Intune Cloud PKI root and issuing CA certificates in AD.

certutil.exe -dspublish -f <path to Cloud PKI issuing CA certificate> NtAuthCa

GUI

If you have an existing on-premises AD CS deployment, you can use the Enterprise PKI management console to publish the Intune Cloud PKI certificates in AD as an alternative to the command line. First, open the Enterprise PKI tool (pkiview.msc) on an existing on-premises Certification Authority (CA) server. Right-click the Enterprise PKI root node and choose Manage AD Containers. Add the Intune Cloud PKI root CA certificate to the Certification Authorities container. Next, add the Intune Cloud PKI issuing CA certificate to the Enrollment Services container. Finally, add the Intune Cloud PKI issuing CA certificate to the NTAuthCertificatesContainer.

Summary

Administrators can use the Microsoft Intune Cloud PKI solution to issue and manage user and device authentication certificates for their Intune-managed endpoints. Using the commands above, administrators can also integrate their Intune Cloud PKI with on-premises Active Directory to support user and device authentication for common workloads such as Wi-Fi and VPN. Critically, when integrating Cloud PKI with on-premises Active Directory, your Intune administrators should be considered Tier-0 administrators, and appropriate security controls should be enforced.

Additional Information

Microsoft Intune Cloud PKI

Mastering Certificates with Microsoft Intune Training Course – May 14-16, 2024

Always On VPN Masterclass at ViaMonstra Online Academy – September 2023

I’m pleased to announce that my popular Always On VPN Deep Dive Workshop training event is coming to the ViaMonstra Online Academy! Many of you have requested a virtual, live, online training event for Microsoft Always On VPN, so here’s your opportunity to learn all about this secure remote access technology without having to leave the comfort of your home or office.

Live and Online

This live, online 4-day virtual training event will take place September 18-20, 2023. The cost for the training is $3,195.00 and will include ten training modules and numerous hands-on labs. Don’t miss out on this excellent opportunity to learn more about designing, implementing, managing, and support Always On VPN. Space is limited, so register today!

Additional Information

Always On VPN Masterclass at ViaMonstra Online Academy

Always On VPN Free Mini-Course at ViaMonstra Online Academy

Always On VPN and VpnStrategy

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Always On VPN supports a variety of VPN protocols for the user tunnel. Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP) are the most common. I wrote about the advantages and disadvantages of each in this post. To summarize, IKEv2 provides the highest security options but suffers from operational limitations. SSTP offers excellent security and is generally more reliable.

VpnStrategy

Always On VPN administrators must choose between IKEv2 and SSTP when configuring the Always On VPN user tunnel. Some administrators may prefer to use IKEv2 when available but then fall back to SSTP if it is not. To accomplish this requires editing the rasphone.pbk file and setting the value of VpnStrategy to 8, as described here.

Challenges

Unfortunately, setting the VpnStrategy value to 8 poses some challenges. Updating rasphone.pbk requires editing a text file on each endpoint post-deployment. Updating rasphone.pbk can be automated using the Update-Rasphone.ps1 script or Microsoft Intune proactive remediation.

Limitations

By default, Windows will overwrite the VpnStrategy setting in rasphone.pbk when fallback occurs. For example, setting VpnStrategy to prefer IKEv2 over SSTP will be reset to use SSTP first if a connection with IKEv2 fails. There’s a registry setting available that’s supposed to prevent this, but it doesn’t always work as expected.

Windows 11

There’s good news for administrators deploying Always On VPN on Windows 11. Microsoft recently introduced support for additional NativeProtocol types in XML. Specifically, VPN protocol preference can now be defined using the ProtocolList native protocol type. When using the ProtocolList native protocol type, each supported VPN protocol is listed in order of preference using the syntax shown below.

In addition, the RetryTimeInHours value defines the time Windows will try the last successful connection protocol. Setting this value to 0 overrides this and ensures the preferred protocol (the first protocol in the list) will always be attempted first.

SSTP Only

Previously the VPNv2CSP only supported IKEv2 or Automatic as values for the native protocol type. Windows 11 now supports SSTP as a native protocol type. Administrators configuring Always On VPN user tunnel connections using SSTP exclusively can now use this option.

Caveats

While the settings above are supported in both Windows 11 21H2 and 22H2, there are some known issues when enabling these settings. Specifically, when administrators define the ProtocolList value for the native protocol type, IKEv2 is always shown as the active protocol, even when an SSTP connection is established.

Also, if ProtocolList is used, the VPN connection cannot be managed using PowerShell. The VPN profile will not be displayed when running Get-VpnConnection at the time of this writing. Hopefully Microsoft will fix this soon.

Additional Information

Always On VPN CSP Updates

Always On VPN IKEv2 and SSTP Fallback

Always On VPN and Intune Proactive Remediation

Always On VPN Protocol Recommendations for Windows Server RRAS

Always On VPN IKEv2 Features and Limitations