Always On VPN with PEAP Fails in Windows 11 26H1

Always On VPN RasMan Errors in Windows 10 1903

There appears to be a bug in the latest Windows 11 26H1 (no, that’s not a typo – 26H1) build affecting Protected Extensible Authentication Protocol (PEAP). In my testing, all VPN connection attempts (Always On VPN and manual/ad-hoc) failed when PEAP was used for authentication.

Windows 11 26H1

Recently, while reviewing downloads and product keys in Visual Studio, I noticed a new Windows 11 release listed: Windows 11 26H1 (business and consumer editions). I initially thought 26H1 would be ARM-only, but the download is available for x64 as well.

I’m not sure whether this is intended as a general release, because Microsoft describes it as an Insider Experimental Preview Build (28200.1873). I also don’t recall seeing Insider builds offered through Visual Studio downloads, so I’m not sure what to make of it. Either way, if you’re evaluating this build, the notes below document a VPN issue I was able to reproduce.

Troubleshooting

After preparing a Windows 11 26H1 test client, I found that the Always On VPN user tunnel would not connect. The same configuration worked on earlier Windows 11 versions. In the event log, I observed the following errors.

Error 619

When using SSTP, the event log records error code 619 (event ID 20227) from the RasClient event source, with the following error message.

The user [domain\user] dialed a connection named [connection name] which has failed. The error code returned on failure is 619.

Error 691

When using IKEv2, the event log records error code 691 (event ID 20227) from the RasClient event source, with the following error message.

The user [domain\user] dialed a connection named [connection name] which has failed. The error code returned on failure is 691.

Workaround

At the time of writing, the only workaround I’ve found to restore Always On VPN connectivity is to switch authentication from PEAP to EAP-TLS. This may not be a drop-in change for every environment, so evaluate the security and operational impact before rolling it out broadly. You’ll need to enable EAP-TLS on both the client and the NPS/RADIUS server.

Summary

I’m not convinced Windows 11 26H1 will be widely deployed soon, since it appears to be an experimental/Insider build rather than a general release. If you decide to evaluate it, plan to use the workaround above to maintain Always On VPN connectivity.

Feedback

Have you tested Always On VPN with Windows 11 26H1? If so, do you see the same behavior? Share your findings in the comments.

Additional Information

Windows 11 Insider Experimental (26H1) Preview Build 28200.1873

Entra Private Access and Bring Your Own Device (BYOD)

Microsoft Entra Private Access is a Zero Trust Network Access (ZTNA) solution that provides secure access to private enterprise resources. With the release of Global Secure Access (GSA) client version 2.26.108, Microsoft has addressed a crucial functionality gap by adding support for Bring Your Own Device (BYOD), enabling secure access from non-managed endpoints.

BYOD Support in Global Secure Access

Microsoft introduced BYOD support for Entra Private Access with the release of the GSA client version 2.26.108. This update allows the GSA client to be installed on Microsoft Entra-registered devices that are not domain-joined or managed by the organization, enabling secure access to private resources from personal or unmanaged endpoints.

Use Cases

BYOD support in GSA and Entra Private Access enables several common scenarios where network access from managed devices is impractical or unavailable, including:

  • Vendor or contractor access
  • IT incident response from unmanaged endpoints
  • Temporary or seasonal staffing
  • Collaboration with external partners

Replacing Legacy VPN for Ad Hoc Access

Historically, legacy VPN solutions were the primary option for providing ad hoc access to private resources from unmanaged devices. With the introduction of BYOD support in the GSA client, organizations can now extend Entra Private Access to these scenarios without deploying or maintaining a separate VPN infrastructure.

Additional Changes

In addition to adding BYOD support, GSA client v2.26.108 includes the following new enhancements.

  • Improved Intelligent Local Access (ILA) detection
  • Join Type displayed in the client interface
  • GSA traceroute enhancements, including a 50M MB speed test between the client and edge service.

Summary

BYOD support removes a key barrier to adopting Microsoft Entra Private Access. Organizations can now securely provide access to private resources using Zero Trust policies, even when users connect from unmanaged or personal devices, and without relying on legacy VPN solutions.

Additional Information

Microsoft Entra Private Access Bring Your Own Device (BYOD)

Microsoft Global Secure Access Client for Windows v2.26.108

Microsoft Entra Private Access Intelligent Local Access

Always On VPN vs. Entra Private Access

The Myth of the Publish Certificate in Active Directory Setting

Certificate templates in Microsoft Active Directory Certificate Services (AD CS) provide powerful, preconfigured settings that enable administrators to issue certificates tailored for specific purposes. For example, a certificate template could allow a user to authenticate to a Wi-Fi network or VPN gateway. Another template might control policies for enrolling for web server certificates in the enterprise. Templates define settings such as cryptographic parameters (key algorithm and length), validity period, application policies, enrollment requirements, and more. While there are myriad settings to choose from, one in particular is often enabled unnecessarily. And while it works without issue, there can be some hidden downsides to enabling this setting.

Publish Certificate in Active Directory

When creating a certificate template, there’s an option on the General tab called Publish certificate in Active Directory. From experience, this is one of the most misunderstood settings for certificate templates.

Intuitively, it would make sense to check this box on all published certificate templates. After all, I want the users or devices targeted by this certificate template to find them in Active Directory (AD) so they can enroll. Many administrators believe that enabling this setting is required to ‘see’ the published certificate template on the endpoint, as shown here.

However, enabling the Publish certificate in Active Directory option is not required for enrollment. To ‘see’ certificates available for enrollment, the user or device must only have the Enroll permission on the template.

What Is It For?

So, what does the Publish certificate in Active Directory setting do? When this option is enabled, the issuing CA adds the certificate to the requesting principal’s Active Directory account. There are two common scenarios where this is required.

S/MIME

Adding a user’s certificate to their AD account makes the public key centrally discoverable, allowing Outlook and other S/MIME-enabled clients to automatically find recipients’ certificates for secure email encryption and signature validation. Without the certificate published in AD, users must manually exchange certificates, breaking seamless S/MIME encryption in most enterprise environments.

Encrypting File System (EFS)

Publishing a user’s EFS certificate to their Active Directory account allows Windows to locate the correct public key automatically when encrypting files. It ensures recovery agents and key archival processes function properly. Without the certificate in AD, EFS can fail to encrypt data consistently across machines or prevent access to encrypted files when users roam or recover profiles.

Drawbacks

There are very few scenarios outside of S/MIME and EFS that require the Publish certificate in Active Directory option to be enabled. However, enabling it doesn’t necessarily break anything, and this setting is often enabled by default (or carried over from the source template when duplicating), so administrators may miss this option. Issuing certificates in this way introduces some potential problems.

AD Database Bloat

Adding a certificate to each principal’s AD object increases the size of each object, thereby increasing the total size of the AD database. For organizations with large directories with hundreds of thousands or even millions of accounts, adding unnecessary data to each account can be very expensive in terms of database size, replication traffic, backup storage, and overall domain performance. Making matters worse, certificates published to AD live perpetually. They are not removed automatically when certificates are revoked or expire.

Service Accounts

Service accounts used for certificate enrollment, such as the Microsoft Intune Certificate connector, can be especially challenging. Here, if the Publish certificate in Active Directory setting is enabled on the Intune certificate template, the CA will add a certificate to the service account for every certificate it issues. While you can have many certificates associated with a single account, there is an upper limit, approximately 1250, based on my testing. After that, certificates will continue to be issued, but adding them to AD will fail.

Remediation

The following recommendations can help administrators correct this misconfiguration and limit its impact in their environment.

Disable Unnecessary Certificate Publishing

Administrators should clear the Publish certificate in Active Directory setting on all certificate templates that do not explicitly require it, such as those used for S/MIME or Encrypting File System (EFS). This prevents new certificates from being written to user or computer objects and does not require certificates to be reissued.

Remove Published Certificates

Administrators can remove unnecessary certificates from user, computer, and service account objects in AD to reduce object and overall AD database sizes. Perform the following steps to remove unneeded certificates.

  1. Open the Active Directory Users and Computers management console (dsa.msc) and double-click the target principal.
  2. Select the Published Certificates tab.
  3. Select a certificate (or all certificates) and click Remove.

Important Note: Use extreme caution when deleting certificates! Do not delete any certificates unless you are certain they are not required.

Managed Service Accounts

Managed Service Accounts in AD do not have a Published Certificates tab. Administrators can use the Attribute Editor to remove individual certificates from the userCertificate attribute on the account.

Managed Service Account Attribute Editor

Managed Service Account userCertificate Entries

Unfortunately, there is no option to view the certificate in the UI for Managed Service Accounts. To view detailed certificate information, see the PowerShell section below.

Existing Certificates Are Not Removed Automatically

Disabling the Publish certificate in Active Directory setting only stops future certificates from being published in AD. Certificates already written to Active Directory are never removed automatically, even after they expire or are revoked. In environments where this setting has been enabled for an extended period, large numbers of stale certificates often accumulate and continue to increase the AD database size.

Intune Certificate Connector Considerations

This issue is especially problematic for high-volume enrollment scenarios that use service accounts, such as the Microsoft Intune Certificate Connector. When publishing is enabled for Intune certificate templates, certificates issued on behalf of users are added to the service account, quickly leading to excessive certificate accumulation and potential attribute limits.

ADPrincipalCertificate PowerShell Module

Manually performing this cleanup at scale is impractical. To assist administrators with cleaning up unnecessarily published certificates, I’ve created the ADPrincipalCertificate PowerShell module. This module includes functions to enumerate AD accounts that include certificates, show and optionally export certificates for AD accounts, and remove published certificates. The module also includes a function to enumerate published certificate templates that include the Publish certificate in Active Directory option enabled. You can install the ADPrincipalCertificate PowerShell module from the PowerShell gallery by running the following command.

Install-Module -Name ADPrincipalCertificate -Scope CurrentUser

See the ADPrincipalCertificate GitHub repository for detailed usage information.

Summary

While the Publish certificate in Active Directory option is helpful for S/MIME and EFS deployments, it is unnecessary for most other scenarios and is often enabled when it isn’t needed. This results in the unnecessary addition of certificates to AD accounts, causing individual objects and the entire AD database to grow without benefit. Sadly, many vendor guides indicate that this setting is required when it often isn’t, so many environments suffer from this misconfiguration. Administrators should review the certificate template configuration and disable this setting when it isn’t needed. Additionally, use the ADPrincipalCertificate PowerShell module to perform cleanup, if required.

Additional Information

ADPrincipalCertificate PowerShell Module on GitHub

ADPrincipalCertificate PowerShell Module in the PowerShell Gallery