Microsoft Intune Cloud PKI and Certificate Templates

Microsoft recently announced the general availability of its new PKI-as-a-Service platform called Microsoft Intune Cloud PKI. With Intune Cloud PKI, administrators create certification authorities (CAs) to issue and manage user and device authentication certificates for Intune-managed endpoints. Cloud PKI also provides hosted Authority Information Access (AIA) and Certificate Revocation List (CRL) Distribution Point (CDP) services, in addition to Simple Certificate Enrollment Protocol (SCEP) service, so administrators do not have to deploy on-premises infrastructure to take advantage of certificate-based authentication.

Certificate Templates

After deploying your Intune Cloud PKI root and issuing CAs, you may wonder where to find the associated certificate templates. If you are familiar with traditional on-premises Active Directory Certificate Services (AD CS) implementations, this is how you define the purpose, key policy, security parameters, and lifetime of the certificate issued using that template. However, Intune Cloud PKI does not use certificate templates in the traditional way many administrators are familiar with.

Note: Microsoft may introduce support for certificate templates for Intune Cloud PKI in the future. However, it is not supported at the time of this writing.

SCEP Profile

Administrators define certificate policies and security parameters using Intune’s SCEP device configuration profile instead of certificate templates. In essence, the SCEP profile functions as the certificate template. With the Intune device configuration profile, administrators can define the following settings.

Certificate Type

The certificate type can be either a user or a device. Intune Cloud PKI can issue certificates for either or both, as required.

Subject Name (User)

The subject name is unimportant for user authentication certificates because the User Principal Name (UPN) defined in the Subject Alternative Name field is used to authenticate the user. In this field, the administrator can use whatever they like. However, it’s common to use the username here. Avoid using the email attribute here because there’s no guarantee that every user will have this defined on the Active Directory (AD) user object.

Subject Name (Device)

Administrators should supply the device’s fully qualified domain name (FQDN) for device authentication certificates in the subject name field. For hybrid Entra joined devices, administrators can use the {{FullyQualifiedDomainName}} variable. For native Entra-joined devices, you can use {{DeviceName}} and append your DNS suffix, for example, {{DeviceName}}.corp.example.net.

Note: Intune supports numerous variables to populate fields for certificates. You can find a list of supported variables in the following locations.

User Certificate Variables: https://learn.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep#create-a-scep-certificate-profile:~:text=Manager%20blog%20post.-,User%20certificate%20type,-Use%20the%20text

Device Certificate Variables: https://learn.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep#create-a-scep-certificate-profile:~:text=on%20the%20device.-,Device%20certificate%20type,-Format%20options%20for

Subject Alternative Name (User)

The Subject Alternative Name (SAN) field for user authentication certificates should be populated with the User Principal Name (UPN) value. Ensure this value is appropriately configured internally and supports sign-in to AD.

Subject Alternative Name (Device)

The SAN field for device authentication certificates should be populated with the device’s FQDN. Follow the guidance for device subject names covered previously.

Certificate Validity Period

This field allows the administrator to define the certificate’s validity period. The best practice is to limit the lifetime to no more than one year. A shorter lifetime is recommended for certificates not backed by a Trusted Platform Module (TPM).

Key Storage Provider

This value is critical to ensuring integrity for issued user and device authentication certificates. The best practice is to select Enroll to Trusted Platform Module (TPM) KSP, otherwise fail. However, if you must issue certificates to endpoints without a TPM (e.g., legacy devices, virtual machines, etc.), consider a separate profile with a shorter certificate lifetime to limit exposure.

Key Usage

Digital signature and Key encipherment are required for user and device authentication certificates.

Key Size

The 2048-bit key size is the minimum recommended value for certificates with RSA keys. Using 4096-bit is not recommended for end-entity certificates and can potentially cause conflicts in some cases. Intune Cloud PKI does not support the 1024-bit key size.

Hash Algorithm

SHA-2 is the best practice for the hash algorithm. SHA-1 has been deprecated and should not be used.

Root Certificate

Select the Cloud PKI root CA certificate.

Extended Key Usage

The minimum requirement for user and device authentication certificates is Client Authentication (1.3.6.1.5.5.7.3.2).

Renewal Threshold

This value specifies at what point the certificate can be renewed. 20% is commonly used for certificates with a one-year lifetime.

SCEP Server URLs

This value can be found on the configuration properties page of your Cloud PKI issuing CA. The URI will include a variable in the URL. The variable is there by design. Copy and paste this URL exactly as displayed in the SCEP URL field.

Training

Are you interested in learning more about issuing and managing certificates with Microsoft Intune? Would you like to know how to securely and optimally implement PKCS and SCEP infrastructure on-premises? Do you want more details about deploying and managing Microsoft Intune Cloud PKI? Register now for my upcoming three-day live Certificates and Intune Masterclass training event at the ViaMonstra online training academy. We’ll deep-dive into all aspects of certificate management using Intune with on-premises AD CS and Intune Cloud PKI. I’ll be sharing many advanced techniques for adequately securing your certificate infrastructure. Space is limited, so register now!

Additional Information

Mastering Certificates with Intune Training Course

Microsoft Intune Cloud PKI Overview

Microsoft Intune Cloud PKI and Active Directory

Microsoft Intune Certificate Connector Failure

Microsoft Intune Certificate Connector Configuration Failed

Microsoft Intune Certificate Connector Configuration Failure

Microsoft Intune Certificate Connector Service Account and PKCS

Considerations for Always On VPN with Azure VPN Gateway and Virtual WAN

Always On VPN Device Tunnel and Custom Cryptography Native Support Now in Intune

Organizations migrating on-premises applications, data, and infrastructure to the cloud may also consider terminating Always On VPN connections there. Using one of the native Azure VPN services might be compelling at first glance. After all, having an Azure-managed VPN gateway service sounds intuitive. However, some severe limitations exist for using Azure VPN services for Always On VPN deployments.

Azure VPN Gateway

The following are limitations for Always On VPN with Azure VPN gateway.

Authentication Methods

Azure VPN gateway supports both EAP and machine certificate authentication. However, it can only support one authentication method at a time. With only EAP or certificate authentication, administrators must choose between a device or user tunnel. A single Azure VPN gateway cannot support both at the same time. For native Entra ID joined devices, this is not a problem. However, for native on-premises Active Directory or hybrid Entra ID joined devices, this is a problem, as the device tunnel is essential in these scenarios.

Note: Technically speaking, administrators could deploy another Azure VPN gateway to work around this limitation. However, Azure limits VPN gateway deployments to one per virtual network. This requires administrators to deploy a second VPN gateway in a separate virtual network, which then requires virtual network peering to be enabled, complicating the configuration greatly.

SSTP

Although the Azure VPN gateway supports SSTP, it is, unfortunately, a second-class citizen. Today, all SKUs of the Azure VPN gateway are limited to just 128 SSTP connections (256 in active/active mode). There is currently no way to increase this. If more than 256 connections are required, you must use IKEv2.

RADIUS

In addition, there is currently no option to change the default timeout value (30 seconds) for RADIUS authentication requests. This short timeout value presents a challenge when using MFA with the NPS extension or with Azure Conditional Access, as users may be unable to respond to the push notification before the timeout expires, resulting in failed authentication attempts.

In addition, Azure does not support routing traffic to on-premises RADIUS servers over ExpressRoute connections. In this scenario, administrators must route RADIUS traffic to on-premises servers over a site-to-site connection.

Geographic Redundancy

Geographic redundancy using Azure Traffic Manager (or another global server load balancer) with two or more gateways is not supported when using the Azure VPN gateway. Azure manages the certificate used on the gateway, which includes a certificate with the subject name of the individual gateway. There is no option to supply a custom certificate with a global hostname in the subject, which is required to support geographic redundancy. With that, administrators are limited to the redundancy provided natively by the Azure VPN gateway.

IPv6

Azure does not support Azure VPN gateway in a virtual network that includes IPv6 addressing.

Azure Virtual WAN

Azure Virtual WAN includes many of the same limitations as the Azure VPN gateway, in addition to the following.

SSTP

Unlike the Azure VPN gateway, there is no support for SSTP in Azure Virtual WAN.

IPv6

IPv6 is not currently supported at all in Azure Virtual WAN.

Summary

Intuitively, it seems that leveraging native Azure VPN gateway services would be ideal. However, due to the limitations outlined in this article, administrators must decide carefully if any of these prevent adoption in their environment. Although not formally supported, many organizations deploy Windows Server Routing and Remote Access (RRAS) servers in Azure to address these limitations.

Additional Information

Always On VPN Options for Azure Deployments

Always On VPN with Azure Gateway

Always On VPN Device Tunnel with Azure VPN Gateway

Always On VPN and RRAS in Azure

What is Azure VPN Gateway?

What is Azure Virtual WAN?

Always On VPN Disconnects in Windows 11

Always On VPN administrators migrating their endpoints to Windows 11 may encounter a scenario where Always On VPN randomly disconnects when the VPN profile is deployed using Microsoft Intune. The same configuration deployed to Windows 10 devices works reliably, however. In addition, Always On VPN profiles deployed using PowerShell (natively or with SCCM) or PowerON DPC do not experience this problem.

Troubleshooting

Administrators troubleshooting this issue will find the root cause is associated with the Always On VPN profiles being removed and replaced each time the device syncs with Intune. This occurs even if there are no changes to the configuration. Removing and replacing the Always On VPN profiles on each device sync is unnecessary, of course, but is also highly disruptive to connected users.

Intune and XML

The Intune team identified the issue, and a fix was made available in the August update. However, many of you have reported the issue persists with some Windows 11 clients after installing the latest updates. Further investigation indicates that although the issue has been resolved when using Intune and the native VPN device configuration profile template, the problem still occurs when using the Custom device configuration template.

Workaround

Microsoft is aware of the issues with deploying Always On VPN client configuration settings using XML in Intune, but there’s no indication when or if they will fix it. Until then, administrators have two options to address this problem.

Native VPN Template

When deploying Always On VPN client configuration settings to Windows 11 endpoints, use the native VPN device configuration template, as shown here.

Using the native VPN template does have some limitations, however. The following settings are not exposed using the native VPN template and can only be configured using XML.

XML

If you must use XML, I’ve had some success by ensuring the order of XML settings is exactly as Intune expects. Follow the steps below to confirm the XML settings order in your XML configuration file.

  1. Deploy your XML file with Intune.
  2. Run Get-VpnClientProfileXML.ps1 to extract the deployed XML settings.
  3. Compare the order of settings to your existing XML.
  4. Make changes to ensure all settings in your XML are in the same order as the extracted XML.
  5. Publish a new XML configuration file using Intune and test.

I’ll caution you that this workaround doesn’t always work reliably. Some customers report that this solved their problems entirely, while others have indicated it does not. My testing shows the same results. Let us know in the comments below if this works for you!

Additional Information

Always On VPN Windows 11 Issues with Intune

Always On VPN PowerShell Script Issues in Windows 11