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: I will deliver an Intune and Certificates Masterclass on the ViaMonstra online academy on May 14-16, 2024. This comprehensive training event will cover all aspects of Intune certificate management and will include a full review of Intune Cloud PKI. You can learn more and register here.

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

Mastering Certificates with Intune Training Course

I’m excited to announce I’ll present a three-day LIVE online training event covering all things Microsoft Intune and certificates. This training event takes place on the ViaMonstra online academy May 14-16, 2024.

Course Material

This training course comprehensively examines all aspects of delivering certificates using Microsoft Intune, including common deployment scenarios, PKCS and SCEP configuration, Intune certificate connector configuration, high availability strategies, implementation and security best practices, and troubleshooting.

Cloud PKI

Cloud PKI, a new cloud-based PKI-as-a-Service solution from Microsoft, will also be covered in depth. I’ll provide an overview of the service and discuss the advantages and limitations of Cloud PKI. We’ll also cover different configuration and deployment scenarios, including Bring Your Own CA (BYOCA). In addition, I’ll share security best practices for Microsoft Cloud PKI deployments.

Register Now

Space is limited, so don’t miss out on this excellent opportunity to learn about these critically essential technologies. Reserve your spot in this training class today!

Additional Information

Mastering Certificates and Microsoft Intune

Microsoft Cloud PKI

ViaMonstra Online Academy

Always On VPN Static IP Address Assignment

A question that occasionally arises when I’m conducting an Always On VPN planning and design workshop for a customer is static IP address assignment options for VPN connections. Typically, the use case is a specific user that requires special access to a sensitive system internally. Assigning a static IP address to the user allows administrators to create firewall rules restricting access to this connection.

Static IP Assignment

Assigning a static IP address to a user is accomplished by editing the properties of their user account in Active Directory. Open the Active Directory Users and Computers console (dsa.msc), navigate to the Dial-in tab on the target individual’s Active Directory user account, and check the box next to Assign Static IP Addresses.

Next, click the Static IP Addresses button, check the box next to Assign a Static IPv4 address, and enter an IP address. Optionally, check the box next to Assign a static IPv6 address and enter a prefix and Interface ID, if required.

NPS Configuration

Once the user account in Active Directory is configured with a static IP address assignment, each NPS server in the organization must be registered in Active Directory. More details on Active Directory registration for NPS servers can be found here.

Caveats

Assigning static IP addresses to VPN users has many drawbacks and limitations. Consider the following.

Device IP

Assigning a static IP address to a device is not supported. You can only assign a static IP address to a user in Active Directory.

Address Assignment

The IP address you assign to the user must be from the same subnet as the VPN server’s internal network interface. If there is more than one VPN server, all VPN servers must be on the same subnet.

Multisite

Assigning static IP addresses to users is not supported when VPN servers are deployed in multiple locations.

Concurrent Sessions

Users with a static IP address assignment must only log on to one device at a time. If a user attempts to log in to multiple devices simultaneously, subsequent connections will fail due to the duplicate IP address assignment.

NPS

Always On VPN administrators may have discovered the option to assign a static IP address using NPS policy. Unfortunately, this option is severely limited. A separate NPS policy is needed for each user that requires a static IP address. However, NPS does not support assigning NPS policies to users, only groups. Technically speaking, you could create a separate group for each user needing a static IP address, but that’s not scalable. Also, it offers no real advantage over using the Active Directory method described above.

Summary

Although it’s possible to assign a static IP address to a user, there is currently no option to assign a static IP address to a device. In addition, static IP address assignment imposes other limitations that make the option challenging. Also, the inability to connect to geographically dispersed VPN servers is severely limiting.

Additional Information

Always On VPN and NPS Active Directory Registration

Always On VPN Client IP Address Assignment Methods

Always On VPN and IPv6