All posts tagged DirectAccess

WEBINAR: Preparing for 100-Day Certificates with CertKit

Join me and the CertKit team on Tuesday, October 6, 2026, at 9:00 AM PDT for a free, live webinar about the upcoming reduction in public TLS certificate lifetimes. Beginning March 15, 2027, the maximum validity period for public TLS certificates will be reduced to 100 days. This change will make manual certificate management increasingly difficult for many organizations.

Automation

Shorter certificate lifetimes require organizations to identify, enroll, deploy, and renew certificates more frequently. Automation can help reduce the administrative effort and the risk of service interruptions caused by expired certificates. This is especially important for public-facing Microsoft workloads such as Internet Information Services (IIS), Remote Desktop Services (RDS), Always On VPN, DirectAccess, and other services that use public TLS certificates.

Visibility

Effective certificate management begins with knowing which certificates exist, where they are installed, and when they expire. Without this visibility, organizations may overlook certificates until they are close to expiration or have already expired.

Internal Certificates

Certificates issued by a private certification authority (CA) aren’t subject to the lifetime restrictions imposed on public TLS certificates. However, they still require inventory, monitoring, and renewal. A consistent approach to managing public and private certificates can help reduce operational overhead.

How CertKit Helps

CertKit is a cloud-based service for managing public and private TLS certificates. During the webinar, we’ll demonstrate how CertKit provides visibility into certificate inventories and expiration dates while automating common lifecycle tasks such as enrollment, deployment, and renewal. We’ll also review recent additions to the service.

Register Now

The webinar takes place on Tuesday, October 6, at 9:00 AM PDT. Registration is required. Everyone who registers will be notified when the session recording is available.

Leave a comment
by Richard M. Hicks on September 22, 2026  •  Permalink
Posted in Always On VPN, Cloud PKI, PKI, PowerShell, TLS, Training and Events, Windows Server
Tagged , , , , , , , , , ,

Posted by Richard M. Hicks on September 22, 2026

https://directaccess.richardhicks.com/2026/09/22/webinar-preparing-for-100-day-certificates-with-certkit/

Intranet Certificate Monitoring with CertKit

CertKit is a cloud-based solution that automates the issuance and management of public TLS certificates. It also provides certificate monitoring and alerting for public-facing workloads. However, many organizations have internal (non-public-facing) services that also use TLS. CertKit agent v1.13.0, currently in preview, closes this gap by providing visibility into TLS certificates used by intranet resources. After installing the latest release of the agent, CertKit can now provide visibility into the status of TLS certificates for internal resources.

Intranet Monitoring

After installing or updating the CertKit agent to v1.13.0, administrators can select an internal TLS service to monitor. Follow the steps below to enable this feature.

Certificate Collection

I recommend creating a separate Certificate Collection to support intranet monitoring. In the CertKit management console, click Add Collection, enter a unique, descriptive name, and click Add Collection.

Install the Agent

Once the new collection is created, navigate to the Agents tab, select your platform, then download, install, and register the agent.

Monitor New Host

After the agent is installed and registered, navigate to the Monitoring tab and click Monitor New Host. Enter the fully qualified domain name (FQDN) of the resource and specify its TLS port. Under Host Visibility, select Internal, and then choose the agent to monitor the host from. When finished, click Monitor Host.

Note: The server running the CertKit agent does not require a TLS certificate of its own to monitor internal resources.

Monitored Hosts

CertKit can track certificates for any internal workload that uses TLS. In this example, the monitored resources include web applications, security appliances, load balancers, and HTTP CRL distribution points. The list also includes LDAPS on the domain controllers and the RDP and WinRM HTTPS services on the management workstation.

The circle next to each resource indicates its certificate status. Green indicates a healthy certificate, yellow indicates one approaching expiration, and red indicates an expired certificate or another detected issue.

Note: The RDP certificate on the management workstation appears red because it contains only the Remote Desktop Authentication EKU (1.3.6.1.4.1.311.54.1.2). It intentionally does not include Server Authentication, which CertKit currently expects when validating the service. CertKit is aware of this limitation and plans to address it in a future release.

Host Discovery

CertKit provides robust discovery for public websites but does not currently offer equivalent functionality for intranet resources. Administrators can identify internal systems listening on a specific port by using Nmap.

nmap.exe -Pn -p [port] --open [internal subnet]

For example:

nmap.exe -Pn -p 443 --open 172.16.0.0/24

Alternatively, add the -oX switch to save the output in XML format.

nmap.exe -Pn -p 443 --open 172.16.0.0/24 -oX scan.xml

The resulting Nmap XML file output can be converted to CSV format using this PowerShell code.

Summary

CertKit agent v1.13.0 extends certificate monitoring to internal TLS services, giving administrators greater visibility into certificates that were previously difficult to track. Although intranet host discovery remains a manual process, tools such as Nmap and PowerShell can help identify resources to add to the monitoring platform

Getting Started with CertKit

Need help improving certificate visibility and management across your organization? Want to automate public TLS certificate enrollment for workloads such as DirectAccess, Always On VPN, IIS, SQL, and more? I can help you assess your certificate environment, identify monitoring gaps, and develop a strategy for managing certificates across internal and public-facing workloads. Fill out the form below, and I’ll provide you with more information.

← Back

Thank you for your response. ✨

Additional Information

CertKit Website

What Is CertKit?

CerKit Agent Support for Always On VPN SSTP and DirectAccess IPHTTPS TLS Certificates

IIS TLS Certificate Deployment with CertKit

The Case for 6-Day Public TLS Certificates

DirectAccess IPHTTPS and Let’s Encrypt 6-Day TLS Certificates

Leave a comment
by Richard M. Hicks on August 26, 2026  •  Permalink
Posted in Always On VPN, Certificate-Based Authentication, Cloud PKI, DirectAccess, PKI, PowerShell, TLS, Windows Server
Tagged , , , , , , , , , , , , ,

Posted by Richard M. Hicks on August 26, 2026

https://directaccess.richardhicks.com/2026/08/26/intranet-certificate-monitoring-with-certkit/

Windows Server 2025 Marks the End of Microsoft DirectAccess

Well, the time has finally come. Microsoft DirectAccess, first introduced in Windows Server 2008 R2, will be removed from the next release of Windows Server. This means that Windows Server 2025 is officially the end of the line for DirectAccess.

Why Is This Happening?

DirectAccess has had a good run, no doubt. However, DirectAccess is built on legacy technologies, making it difficult to implement and support in modern environments. For example, DirectAccess requires the following:

  • Domain-joined servers and clients
  • Active Directory group policy management
  • NTLMv2 for authentication
  • Complex IPv6 transition and translation technologies

Further, DirectAccess does not support:

  • Modern endpoint management using Microsoft Intune
  • Integration with Entra ID and Entra Conditional Access
  • Fine-grained user access control (zero trust)
  • Windows Professional or other non-Microsoft endpoints

Microsoft’s strategic focus has shifted toward cloud-native identity, device management, and Zero Trust access solutions, making DirectAccess increasingly difficult to align with modern enterprise requirements and ultimately resulting in Microsoft discontinuing DirectAccess.

What’s Next

Organizations should consider migrating from DirectAccess to Always On VPN or Entra Private Access. Always On VPN provides a traditional VPN-based remote access solution with broad deployment flexibility, while Entra Private Access offers a cloud-native Zero Trust approach for accessing private applications and resources.

Migration Path

Organizations currently relying on DirectAccess should begin planning their migration strategy now. Although Windows Server 2025 continues to support DirectAccess, future Windows Server releases will not, making proactive migration planning essential.

Get Expert Guidance on DirectAccess Migration

Every DirectAccess deployment is different. The right migration strategy depends on your existing infrastructure, identity platform, management approach, and security requirements. Complete the form below to discuss your environment and receive guidance on transitioning to Always On VPN or Entra Private Access.

Additional Information

Microsoft DirectAccess Deprecation on Future Windows Server Releases

Leave a comment
by Richard M. Hicks on June 12, 2026  •  Permalink
Posted in DirectAccess, Windows Server
Tagged , , , , , , , ,

Posted by Richard M. Hicks on June 12, 2026

https://directaccess.richardhicks.com/2026/06/12/windows-server-2025-marks-the-end-of-microsoft-directaccess/

The Case for 6-Day Public TLS Certificates

In February 2025, Let’s Encrypt introduced the option to enroll for public TLS certificates with a 6-day validity period.  This represents a significant shift toward short-lived certificates and aligns with the broader industry trend of reducing certificate lifetimes to improve security. While this may seem aggressive at first glance, organizations that have embraced automation will find that extremely short-lived certificates offer compelling security and operational advantages in some scenarios.

Benefits

Extremely short-lived TLS certificates offer several important security and operational benefits, particularly for organizations that have already embraced automation for certificate lifecycle management. Key advantages include:

  • Minimized Risk of Key Compromise – 6-day certificates dramatically reduce the exposure window of private key compromise events, giving attackers a limited window of opportunity to exploit key access.
  • Automation Validation – Short-lived certificates force organizations to adopt and validate automated enrollment and renewal processes, ensuring that certificate lifecycle management is reliable and resilient.
  • IP Address Support – 6-day TLS certificates from Let’s Encrypt support IP addresses, allowing administrators to secure workloads that do not have entries in DNS.

Use Cases

6-day TLS certificates are well-suited for a range of modern workloads, especially those that benefit from frequent key rotation, automation, and dynamic provisioning. 6-Day TLS certificates are well-suited for the following workloads:

  • High Value Resources – Using 6-day TLS certificates is beneficial for high-security or sensitive workloads where frequent key rotation is desired.
  • Test Labs – High-frequency certificate rotation allows for thorough testing of automation processes to ensure operational reliability of production deployments. Rapid iteration of 6-day TLS certificates allows administrators to identify potential issues and implement changes before long-term certificates expire.
  • Ephemeral Infrastructure – 6-day TLS certificates work well with dynamic workloads such as containers, where environments are rapidly provisioned and destroyed. These hosts might only live for a few hours or days, making short-lived certificates an ideal choice in this scenario.
  • Workload Bootstrapping – 6-day TLS certificates can be used where a certificate is required only to perform initial configuration. For example, an IP-based TLS certificate can be used to configure TLS services, then later migrated to a long-term certificate when DNS is configured and the service is placed into production.

Enterprise Usage

Administrators will find that 6-day public TLS certificates work well with many popular Windows Server workloads. Here are a few examples.

  • Always On VPN – Enterprise secure remote access is a popular target for attackers because the service is exposed to the Internet. Using 6-day TLS certificates ensures frequent key rotation, reducing exposure to key compromise.
  • Remote Desktop Services – Many organizations continue to use Remote Desktop Gateway to provide access to on-premises applications, another workload that is exposed to the Internet. Using 6-day TLS certificates is equally effective in this scenario.

What About DirectAccess?

Although DirectAccess would be another ideal Windows Server workload for 6-day TLS certificates, my testing shows that it does not work. The root cause is that 6-day TLS certificates from Let’s Encrypt do NOT include subject information (the field is blank). Unfortunately, because of the way in which DirectAccess validates this certificate, it requires information in this field. More details can be found here.

https://directaccess.richardhicks.com/2026/03/16/directaccess-iphttps-and-lets-encrypt-6-day-certificates/

Summary

If you are automating certificate enrollment and renewal, it shouldn’t matter if the certificate is valid for 6 days or 60 days. In fact, shorter lifetimes can significantly improve your security posture by minimizing risk and enforcing operational discipline around certificate management. Organizations that invest in automation today will be well-positioned to adopt even shorter certificate lifetimes in the future, while those relying on manual processes will find it increasingly difficult to keep up.

Questions?

Do you have questions about certificate lifecycle automation in your environment? I’m happy to help you validate your approach and address any challenges you’re encountering. Fill out the form below, and I’ll provide you with more information.

Additional Information

Let’s Encrypt Issues First Six-Day Certificate

DirectAccess IP-HTTPS and Let’s Encrypt 6-Day TLS Certificates

The Case for Short-Lived Certificates in the Enterprise

2 Comments
by Richard M. Hicks on May 4, 2026  •  Permalink
Posted in Always On VPN, Certificate-Based Authentication, Cryptography, DirectAccess, Microsoft Intune, PKI, PowerShell, TLS, Windows Server
Tagged , , , , , , ,

Posted by Richard M. Hicks on May 4, 2026

https://directaccess.richardhicks.com/2026/05/04/the-case-for-6-day-public-tls-certificates/

DirectAccess IPHTTPS and Let’s Encrypt 6-Day Certificates

I’ve written extensively about how public TLS certificate lifetimes will drop to just 47 days by March 2029. Before then, we’ll see certificate lifetimes gradually drop from the current 398 days to 200 days on March 15, 2026, and then to 100 days on March 15, 2027. In preparation for this, I’ve been working with many customers to deploy automated certificate enrollment and renewal solutions to eliminate the need for manual intervention. Interestingly, Let’s Encrypt now offers extremely short-lived certificates that are good for just 6 days! While they work just fine for Always On VPN, I discovered they will not work for DirectAccess.

6-Day Certificate

After successfully enrolling for a 6-day TLS certificate from Let’s Encrypt (I used CertKit, BTW!), I encountered an error when trying to assign the short-lived certificate to the IP-HTTPS listener in the DirectAccess configuration. Specifically, when running the Set-RemoteAccess PowerShell command, I received the following error.

Set-RemoteAccess: The parameter is incorrect.

Further investigation showed that I could install other public TLS certificates just fine. For some reason, though, DirectAccess did not like this new 6-day certificate.

Missing Subject Name

After digging a bit deeper, I realized the Subject field of the new 6-day Let’s Encrypt certificate was empty.

Subject vs. SAN in Modern TLS

Modern TLS clients rely entirely on the Subject Alternative Name (SAN) field for identity validation, and the older practice of matching against the certificate’s Subject field has been phased out for many years. Many certificate authorities, including Let’s Encrypt, now leave the Subject field empty because it no longer serves a functional purpose in current TLS implementations. DirectAccess still expects this field to contain data and does not properly fall back to SAN‑only validation. As a result, any certificate with an empty Subject field, such as the new 6‑day certificates from Let’s Encrypt, will fail when applied to the DirectAccess IP‑HTTPS listener.

Workaround

Admittedly, using 6-Day public TLS certificates for DirectAccess is extreme and likely overkill for this workload. The good news is that DirectAccess still works perfectly with 90-day Let’s Encrypt certificates, so the lack of 6-day certificate support should not be impactful.

CertKit

Have you heard about CertKit? CertKit, an online service for automating Let’s Encrypt certificate enrollment and renewal, has added support for Always On VPN and DirectAccess. Find details on leveraging it for public TLS certificates for these solutions here.

Additional Information

Always On VPN SSTP with Let’s Encrypt Certificates

Always On VPN and 47-Day Public TLS Certificates

The Case for Short-Lived Certificates in Enterprise Environments

CertKit Agent Support for Always On VPN SSTP and DirectAccess IP-HTTPS TLS Certificates

Leave a comment
by Richard M. Hicks on March 16, 2026  •  Permalink
Posted in Always On VPN, Cryptography, DirectAccess, IPv6, PKI, PowerShell, TLS, Windows Server
Tagged , , , , , ,

Posted by Richard M. Hicks on March 16, 2026

https://directaccess.richardhicks.com/2026/03/16/directaccess-iphttps-and-lets-encrypt-6-day-certificates/

CertKit Agent Support for Always On VPN SSTP and DirectAccess IP-HTTPS TLS Certificates

With public TLS certificate lifetimes set to drop to 200 days soon (next week!), Always On VPN and DirectAccess administrators face an increased risk of service disruption if certificates aren’t renewed on time. These shorter certificate lifetimes require more frequent renewals, substantially increasing management overhead. Although 200 days equate to roughly a twice-a-year renewal, lifetimes will decrease further to 100 days next year and eventually to just 47 days in 2029. SSTP and IP-HTTPS are TLS-based tunneling protocols used by Always On VPN and DirectAccess, respectively, tying their certificate health directly to remote access availability. Now is the time to automate the enrollment and renewal of Always On VPN SSTP and DirectAccess IP-HTTPS/TLS certificates to ensure reliable operation in the future.

Always On VPN

Previously, I wrote about using CertKit.io to automate the enrollment and renewal of public TLS certificates for Always On VPN. CertKit is an online service that administrators can use to delegate the task of enrolling for short-lived certificates from Let’s Encrypt. In that post, I shared some sample code to retrieve the certificate from CertKit and assign it to the SSTP listener for the Routing and Remote Access Service (RRAS). However, CertKit added new features to its solution, eliminating the need for additional code.

CertKit Agents

Recently, CertKit introduced CertKit Agents. These lightweight software agents are installed on Windows Servers (other operating systems are supported as well) to automate the process of downloading CertKit certificates and installing them in the local computer certificate store. Importantly, they now specifically support both the Always On VPN (SSTP) and DirectAccess (IP-HTTPS) workloads natively.

Always On VPN

The CertKit agent automatically detects the Routing and Remote Access (RRAS) workload and updates the certificate binding for the SSTP listener accordingly. Since this process requires a service restart, which terminates all current VPN connections, CertKit allows you to select an outage window for certificate updates.

Here, administrators can define the day(s) and time window during which the agent is authorized to restart the RemoteAccess service when updating the TLS certificate for SSTP. The day and time are based on the server’s configured time zone settings.

DirectAccess

Beginning with CertKit agent v1.6.2, the agent automatically detects whether DirectAccess is configured, enabling IP-HTTPS TLS certificates to be automatically enrolled and renewed. However, additional configuration is required. The following changes must be made to support CertKit for DirectAccess.

  • Service Account – Administrators must configure a service account in Active Directory for the CertKit agent. A Group Managed Service Account (gMSA) is preferred, but a standard domain service account is also supported.
  • GPO Delegation – CertKit service account must be delegated the ‘Edit settings, delete, and modify security’ permission on the DirectAccess server and client settings GPOs.
  • Log On as a Service – When using a domain service account, administrators must grant the CertKit service the ‘Log on as a service’ right on the DirectAccess server. However, when using gMSA, the ‘Log on as a service’ right is not required.
  • Local Administrator – Administrators must also add the CertKit agent service account to the Local Administrators group on the server.

Configuration Script

I have published a PowerShell script to simplify configuring the CertKit agent on DirectAccess servers. The script automatically performs all required tasks for the CertKit agent to work with DirectAccess. You will find the Enable-DACertKit.ps1 PowerShell script on GitHub. Alternatively, you can install the script directly from the PowerShell Gallery.

Install-Script -Name Enable-DACertKit -Scope CurrentUser

After installing the CertKit agent, run the PowerShell script to complete the configuration. Next, authorize the agent in the CertKit management portal and assign a certificate. Once complete, CertKit can fully manage the IP-HTTPS TLS certificate for DirectAccess.

Note: Like Always On VPN, changes to the DirectAccess IP-HTTPS certificate require a service restart, which is disruptive. Be sure to define a maintenance window (as shown previously) to ensure the change is made during non-peak times.

Summary

As TLS certificate lifecycles continue to shrink, automating certificate enrollment and renewal has become essential for both Always On VPN and DirectAccess environments. CertKit agents streamline this process by automatically retrieving, installing, and binding certificates for SSTP and IP-HTTPS, all while supporting scheduled outage windows to minimize disruption. With these new capabilities, administrators can significantly reduce operational overhead and ensure consistent, reliable remote access services without manual intervention. Visit CertKit.io to get started today.

More Information

If you would like to learn more about CertKit or see a demonstration with Always On VPN or DirectAccess, fill out the form below, and I’ll provide you with more details.

Additional Information

Always On VPN SSTP Certificate Automation with CertKit

CertKit Agents

Enable-DACertKit.ps1 on GitHub

Enable Group Managed Service Accounts

Leave a comment
by Richard M. Hicks on March 10, 2026  •  Permalink
Posted in Always On VPN, Cryptography, DirectAccess, IPv6, Microsoft Intune, PKI, PowerShell, TLS, Windows Server
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on March 10, 2026

https://directaccess.richardhicks.com/2026/03/10/certkit-agent-support-for-always-on-vpn-sstp-and-directaccess-ip-https-tls-certificates/

Always On VPN Security Updates July 2025

Patch Tuesday has arrived, and, unlike last month, it’s a busy month for Always On VPN administrators. The June 2025 Microsoft security updates address a whopping 16 (!) vulnerabilities in the Windows Routing and Remote Access Service (RRAS). Notably, DirectAccess administrators are once again impacted by a critical vulnerability in the Windows KDC Proxy Service (KPSSVC) this month.

RRAS

As stated previously, this month’s update addresses 16 unique CVEs in Windows Server RRAS. All are memory-related buffer overflows and out-of-bounds reads, indicating that a security researcher was recently probing for vulnerabilities in RRAS.

While all the above CVEs are Remote Code Execution (RCE) and Information Disclosure vulnerabilities, none are rated as Critical; all are rated as Important. This means exploitation is unlikely, but administrators are encouraged to update as soon as possible.

KDC Proxy

This month’s security update includes another Critical RCE in the Windows KDC Proxy Service (KPSSVC).

The KDC Proxy is enabled by default when DirectAccess is configured. By design, this means the service is exposed to the public Internet, posing a significant risk to organizations using DirectAccess for secure remote access. Administrators are urged to update their systems immediately to avoid compromise.

Additional Information

Microsoft July 2025 Security Updates

Leave a comment
by Richard M. Hicks on July 8, 2025  •  Permalink
Posted in Always On VPN, Authentication and MFA, DirectAccess, Security Updates, Windows Server
Tagged , , , , , ,

Posted by Richard M. Hicks on July 8, 2025

https://directaccess.richardhicks.com/2025/07/08/always-on-vpn-security-updates-july-2025/

November 2024 Microsoft Security Updates and DirectAccess

With the November 2024 security updates, Microsoft disclosed a vulnerability (CVE-2024-43639) in the Windows Server KDC Proxy service. This is a Remote Code Execution (RCE) vulnerability with a max severity rating of Critical. If you still use Microsoft DirectAccess for remote access, you’ll want to pay close attention to this bulletin.

KDC Proxy and DirectAccess

When DirectAccess is installed and configured, the KDC Proxy Service is enabled automatically and by default. By design, DirectAccess servers are exposed to the Internet, which significantly increases the risk of this vulnerability. Organizations that have deployed DirectAccess are encouraged to update their systems immediately.

Workaround

There is no known workaround available at this time. Apply the latest security updates to mitigate this risk.

Additional Information

Windows KDC Proxy Remote Code Execution Vulnerability

Microsoft DirectAccess Formally Deprecated

Leave a comment
by Richard M. Hicks on November 14, 2024  •  Permalink
Posted in Authentication and MFA, DirectAccess, Security Updates, Windows Server
Tagged , , , , ,

Posted by Richard M. Hicks on November 14, 2024

https://directaccess.richardhicks.com/2024/11/14/november-2024-microsoft-security-updates-and-directaccess/

DirectAccess Fails on Windows 11 24H2

Microsoft recently released Windows 11 24H2. Not long after the release there have been numerous reports of DirectAccess failing after performing an in-place upgrade from previous versions of Windows 11. New installations of Windows 11 24H2 experience the same problem.

Update 10/28/2024: This issue is resolved with KB5044384.

Testing

After downloading and configuring a Windows 11 24H2 test client I was able to quickly reproduce the issue. While previous versions of Windows 11 can connect to my test DirectAccess server without issue, the Windows 11 24H2 client fails.

Troubleshooting

Looking at the DirectAccess status indicator in the UI the DirectAccess connection remains ‘Connecting’ perpetually. Further investigation indicates an IP-HTTPS interface error. Running the command netsh.exe interface httpstunnel show interface reveals an error code 0x57 (invalid parameter) with the following error message.

Failed to connect to the IPHTTPS server. Waiting to reconnect.

Workaround

Currently there is no known root cause for this issue and there is no available workaround. Administrators should delay upgrading to Windows 11 24H2 if DirectAccess is deployed in the organization. I will continue to investigate and post additional information as I learn more. Stay tuned!

Additional Information

Troubleshooting DirectAccess IP-HTTPS Error Code 0x800b0109

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

Troubleshooting DirectAccess IP-HTTPS Error 0x2af9

Microsoft DirectAccess Now Formally Deprecated

7 Comments
by Richard M. Hicks on October 7, 2024  •  Permalink
Posted in DirectAccess, IPv6, TLS, Training and Events
Tagged , , , , ,

Posted by Richard M. Hicks on October 7, 2024

https://directaccess.richardhicks.com/2024/10/07/directaccess-fails-on-windows-11-24h2/

DirectAccess and CVE-2024-38063

With the August 2024 Windows security updates, Microsoft released a fix to address a Remote Code Execution vulnerability in the Windows TCP/IP stack (CVE-2024-38063). Critically, this vulnerability affects IPv6 only and does not require authentication or user interaction to exploit. An attacker would only need to send specially crafted IPv6 packets to a Windows host, which could allow them to run arbitrary code on the server. This vulnerability presents some unique challenges for organizations that have deployed DirectAccess.

Exposure

DirectAccess servers are deployed to provide secure remote access and are, necessarily, exposed to the public Internet. Sometimes, this is a direct connection (not recommended) or behind an edge firewall or load balancer. In either case, anyone can establish a TCP connection from the Internet to the DirectAccess server by default. If the DirectAccess server has a global unicast IPv6 address assigned to its external interface, that presents a worst-case scenario for exposure. Administrators should update their DirectAccess servers immediately. There are some other mitigation options, though. See below for more details.

IPv6 Transition

DirectAccess servers are usually reachable on the public Internet via IPv4 only. The lack of direct IPv6 connectivity significantly reduces the attack vector for this vulnerability. However, DirectAccess servers use various IPv6 transition technologies that could present additional risks.

Tunnel Establishment

Clients on the Internet can establish an IPv6 transition tunnel to the DirectAccess server without authentication. Once the tunnel is established, the client will receive a router advertisement (RA) and establish an IPv6 address on link. However, communication over the link requires IPsec. Although an attacker can obtain an IPv6 address, they require authentication to send TCP and UDP traffic inside the tunnel.

ICMP

It’s important to know that ICMP traffic inside the DirectAccess IPv6 transition tunnel is exempt from IPsec policy processing, by default. It is unclear whether the “specially crafted packets” an attacker must send to exploit this vulnerability can be ICMP packets. If that’s the case, this introduces significant risks and increases exposure exponentially. I will update this post if I learn anything more about this specifically.

Mitigation

The best and most obvious way to mitigate this attack is to immediately apply the Microsoft security updates. However, some additional controls can be effective in mitigating this risk.

Authentication

As mentioned, DirectAccess allows IPv6 transition tunnels to be established by default without authentication. However, it is possible to update the DirectAccess configuration to support authentication, as described here.

https://directaccess.richardhicks.com/2016/06/13/directaccess-ip-https-preauthentication/

Note: Updating the DirectAccess configuration can be impactful for remote users. Be sure to test this change in a lab environment before implementing in production.

Load Balancers

If the DirectAccess server is behind a load balancer, it can be configured to require authentication for DirectAccess IPv6 transition tunnels. Below is published guidance for configuring popular load balancers to support this.

F5 BIG-IP

Citrix ADC (formerly NetScaler)

Additional Information

Microsoft Windows TCP/IP Remote Code Execution Vulnerability

DirectAccess IP-HTTPS Preauthentication

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP

DirectAccess IP-HTTPS Preauthentication using Citrix ADC (formerly NetScaler)

3 Comments
by Richard M. Hicks on August 15, 2024  •  Permalink
Posted in Always On VPN, DirectAccess, IPv6, Load Balancing, Security Updates, TLS, Windows Server
Tagged , , ,

Posted by Richard M. Hicks on August 15, 2024

https://directaccess.richardhicks.com/2024/08/15/directaccess-and-cve-2024-38063/

« Older Posts