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

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.

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.

Warning
Warning
Warning
Warning.

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?