Microsoft DirectAccess Formally Deprecated

Today, Microsoft has announced the formal deprecation of DirectAccess. Microsoft DirectAccess is a widely deployed enterprise secure remote access solution that provides seamless, transparent, always-on remote network connectivity for managed (domain-joined) Windows clients. First introduced in Windows Server 2008 R2, it’s been a popular solution with many advantages over ordinary VPN technologies of the past.

Windows Server 2012

DirectAccess was almost entirely rewritten in Windows Server 2012. Many of the features and enhancements offered for DirectAccess with the Unified Access Gateway (UAG – a separate product with additional costs) were built into the operating system directly. In addition, Microsoft introduced integrated load balancing and geographic redundancy features.

Demise of DirectAccess

DirectAccess relies heavily on classic on-premises technologies like Active Directory. All DirectAccess servers and clients must be joined to a domain. In addition, all DirectAccess clients must be running the Enterprise edition of Windows. With organizations rapidly adopting cloud services such as Azure and Entra ID, Microsoft began to develop an alternative solution that better integrated with the cloud. That solution is Always On VPN. With that, Microsoft stopped developing DirectAccess after the release of Windows Server 2012 R2. No new features or capabilities have been added to DirectAccess since that time.

Deprecation

We’ve been speculating about the end of life for DirectAccess for quite some time now. However, this formal deprecation announcement from Microsoft is official. It is the end of the road for this technology. To be clear, though, DirectAccess is available today in Windows Server 2022 and Windows 11. DirectAccess will be included in the upcoming release of Windows Server 2025. However, formal deprecation from Microsoft means they will remove DirectAccess components from the next release of the operating system.

What Happens Now?

Organizations should begin formal planning efforts to migrate away from DirectAccess. Here are a few popular solutions to consider.

Always On VPN

Always On VPN is the direct replacement for DirectAccess. It was designed to provide feature parity for DirectAccess, with seamless, transparent, always-on remote network connectivity. However, Always On VPN better integrates with Entra ID and supports conditional access. It does not require domain-joined devices or servers and works well with cloud-native endpoints. Always On VPN is a good choice for organizations that employ hybrid Entra-joined devices.

Entra Private Access

Entra Private Access, part of the Entra Global Secure Access suite, is an identity-centric zero-trust network access (ZTNA) solution from Microsoft. It is in public preview now and has some compelling advantages over traditional VPNs. However, Entra Private Access is not feature complete today. In addition, it is best suited to cloud-native (Entra-joined only) endpoints.

Absolute Secure Access

Absolute Secure Access (formerly NetMotion Mobility) is a premium enterprise remote access solution with many advanced options. It is by far the best solution on the market today. Absolute Secure Access is a software solution that supports zero-trust configuration and includes many features to improve and enhance security, performance, and visibility. In addition, it provides cross-platform support, including Windows, macOS, iOS, and Android operating systems.

Learn More

We have several decades of experience working with secure remote access technologies. We can help you and your organization find the best solution for your needs. Fill out the form below for a free one-hour consultation to discuss your DirectAccess migration strategy today.

Additional Information

Deprecated Features for Windows Client

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

Microsoft Intune Cloud PKI

Recently, Microsoft introduced the general availability of its new PKI-as-a-service solution called Microsoft Intune Cloud PKI. Cloud PKI allows administrators to issue and manage user and device authentication certificates for Intune-managed endpoints without deploying Active Directory Certificate Services (AD CS) on-premises. Cloud PKI frees administrators from the burdens of deploying and managing AD CS, including the complicated Network Device Enrollment Service (NDES) server configuration required for Simple Certificate Enrollment Protocol (SCEP) certificate deployment with Intune.

Advantages

Microsoft Intune Cloud PKI offers many significant advantages over traditional on-premises AD CS deployments.

No Infrastructure

The most obvious advantage of using Cloud PKI is that you do not have to deploy and manage your own Certification Authority (CA). Although implementing AD CS isn’t that difficult, managing and operating a CA infrastructure securely can be quite challenging. In addition, a high-security AD CS deployment utilizes hardware secure modules (HSMs) to protect CA private keys, which are quite expensive and sometimes difficult to support.

Cloud-Hosted SCEP

Removing the requirement to configure and deploy your own NDES server to support SCEP certificates is certainly a welcome advantage. NDES is notoriously difficult to configure, secure, and troubleshoot when it doesn’t work correctly. Cloud PKI includes cloud hosted SCEP services that are highly available and redundant within the Microsoft Azure infrastructure.

Automatic Revocation

Cloud PKI automates the deployment of certificates to Intune-managed users and devices and automatically revokes certificates when they fall out of scope. Administrators can also manually revoke certificates using the Intune management console.

Reporting

Administrators can easily view the status of Cloud PKI-issued certificates in Intune. The UI shows the active, expired, and revoked certificates for the issuing CA.

Clicking View all certificates shows a detailed list of all certificates.

BYOCA

Another compelling feature of Cloud PKI is Bring Your Own CA (BYOCA). This feature enables administrators to deploy a cloud-hosted CA that is chained to their existing on-premises AD CS root CA. This is helpful for scenarios where AD CS is already in place and used to issue and manage certificates to existing domain-joined clients and servers. BYOCA effectively allows you to extend your existing CA infrastructure to the cloud and use Cloud PKI to issue and manage certificates for your Intune-managed endpoints while maintaining the full functionality and feature set of on-premises AD CS for non-Intune-managed devices.

Limitations

Although there are many advantages to Cloud PKI, there are some limiting factors to consider.

RSA Only

Today, Cloud PKI is limited to RSA keys only. Administrators can create CAs using RSA 2048, 3072, or 4096-bit keys. Elliptic Curve (EC) keys are not currently supported in Cloud PKI.

Intune Devices Only

Cloud PKI is limited to issuing certificates to Intune-managed devices only. Endpoints must be Entra-joined, or hybrid Entra-joined to enroll for certificates using Cloud PKI.

Inflexible Configuration

The Cloud PKI root and issuing CAs cannot be reconfigured after deployment. Since Cloud PKI root and issuing CAs don’t support the Any Purpose EKU (2.5.29.37.0), all EKUs must be defined when the CA is created. If, in the future, an administrator requires an EKU that was not present when the CA was deployed, an entirely new hierarchy (root and issuing CA) must be deployed.

No Strong Mapping

As of this writing, Cloud PKI does not yet support strong certificate mapping for KB5014754. Microsoft fixed this limitation with Entra Conditional Access certificates and is working to include support for SCEP and PKCS. Hopefully, this shortcoming will be addressed soon in Cloud PKI.

Cost

There’s been much discussion about the cost associated with Cloud PKI. Cloud PKI can be licensed as part of the Intune Suite, which is $10.00 per user per month. Cloud PKI licenses will also be available as a standalone add-on for $2.00 per user per month. For large organizations, this might be cost-prohibitive.

Summary

Overall, Microsoft Intune Cloud PKI is a welcome addition to the Microsoft suite of cloud services. Certificates are excellent phishing-resistant credentials that can be used to improve security for organizations of all sizes. However, managing a CA can be tedious and time-consuming. Leveraging the cloud for PKI and certificate management will be helpful in many scenarios. However, Cloud PKI has some potential drawbacks, and many may not fit everyone.

More Information

Want to learn more about Microsoft Intune Cloud PKI and how it can benefit your organization? Take the first step towards streamlined certificate management and enhanced security for your organization. Fill out the form below, and I’ll provide more information about using Intune Cloud PKI to safeguard your digital assets confidently.