All posts tagged Mobility

Always On VPN Discord Channel

I’m excited to announce the launch of a brand-new Discord channel dedicated to administrators working with Always On VPN! Whether you’re a seasoned pro or just getting started, this community is designed to be your go-to hub for collaboration, troubleshooting, and staying up to date on all things Always On VPN. The channel was established by my good friend Leo D’Arcy, the creator of the popular Always On VPN Dynamic Profile Generator (DPC) software.

Why Discord?

Always On VPN is a powerful solution for secure, seamless remote connectivity, but managing it comes with its own set of challenges. From configuration quirks to deployment strategies, administrators often need a space to share insights, ask questions, and learn from one another in real time. That’s where our new Discord channel comes in.

Community Forum

Discord offers a dynamic, user-friendly platform for instant communication and community building. Unlike forums or email threads, it’s a place where you can start a conversation, jump into live discussions, share resources, ask questions, share important insights or experiences, and much more.

Channels

Today, the Always On VPN Discord channel is part of the Microsoft Remote Access User Group Discord Server. It consists of multiple channels divided into the following topics.

General – This is a great place to introduce yourself and say hello to everyone!

DPC-Development – Here, you can ask questions about DPC, provide feedback, and suggest new features and functionality.

DPC-Chat – This channel is for administrators to discuss all things DPC, including deployment strategies, operation, support, and more.

Aovpn-Chat – If you’ve deployed Always On VPN but aren’t using DPC, this is your channel! Although DPC is fantastic, not everyone is using it. In this channel, you can submit questions and share general information about Always On VPN.

Gsa-Chat – We’ve also included a Microsoft Entra Global Secure Access channel for the new Microsoft Security Service Edge (SSE) solution, which includes Entra Private Access. This channel is pretty quiet right now. Hopefully, it will grow in the future!

DirectAccess-Chat – Yes, we realize some of you are still running DirectAccess, so there’s also a channel for you! Feel free to drop in and ask questions here, hopefully about migrating soon. 😉

Who Is This For?

This channel is open to anyone managing Microsoft secure remote access products. Whether you’re an IT administrator in a small business, an enterprise network engineer, or a consultant helping clients stay connected. If you’re working with Microsoft remote access technologies, this is the place to be!

Why Not Reddit?

Funny story: I tried to create an Always On VPN subreddit a few years ago. It lasted one day before it was banned! No reason was given, and I couldn’t get anyone from Reddit to respond. I answer questions ad hoc on Reddit all the time, but there’s no dedicated space for Always On VPN or Microsoft remote access in general.

How To Join

Joining our Discord channel is easy.

Click this link.
Set up your Discord account if you don’t already have one. It’s free and only takes a minute!
Optionally, you can download the Discord app here.
Say hello and introduce yourself in the #general channel.
Explore the other channels, ask questions, give feedback, and share your expertise!

See You There!

Leo and I, along with many other experienced Always On VPN administrators, are on the forums daily. We encourage you to share your expertise, ask questions, and help others along the way. The more we contribute, the stronger this resource becomes for everyone. Join us today!

Additional Information

Always On VPN Discord Channel

Always On VPN Dynamic Profile Configurator (DPC)

DPC on GitHub

Always On VPN and SQL Target Principal Name Incorrect

Microsoft Always On VPN provides seamless and transparent remote access to corporate applications and data. In most cases, accessing resources over the VPN works the same as on-premises. However, a few folks have asked recently about an issue they found when using the SQL Server Management Studio (SMSS) to connect to a remote SQL server over Always On VPN.

Principal Name Incorrect

Administrators may encounter the following error message when using SMSS to connect to Microsoft SQL servers over an Always On VPN connection.

“The target principal name is incorrect. Cannot generate SSPI context. (Microsoft SQL Server)”

Resolution

There are a few different ways to resolve this issue. Choose the option that works best in your environment.

VPN Configuration

For Always On VPN deployments with Windows 11 24H2 and later clients, add the following setting to your XML configuration file.

<UseRasCredentials>false</UseRasCredentials>

For clients older than Windows 11 24H2, you must edit the rasphone.pbk file setting as follows.

UseRasCredentials=0

Group Policy

Optionally, a Group Policy Object (GPO) can be created and applied to target endpoints. For testing, you can enable this setting using the local group policy editor (gpedit.msc). Using either method, enable the following group policy setting.

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network access: Do not allow storage of passwords and credentials for network authentication = Enabled

Registry Editor

This method can be used for local testing. Open the Windows Registry Editor (regedit.exe) on a test client and create the following entry.

Key = HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Name = DisableDomainCreds
Type = DWORD
Value = 1

PowerShell

The following PowerShell command will also create the required registry entry. Administrators can run the command interactively or deploy it via automation.

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Lsa’ -Name DisableDomainCreds -Value 1

Additional Information

Always On VPN Short Name Access Failure

1 Comment

by Richard M. Hicks on February 13, 2025 • Permalink

Tagged administration, Always On VPN, AOVPN, authentication, error, kerberos, Microsoft, Mobility, remote administration, security, SMSS, SQL, SQL server, SQL Server Management Studio, VPN, warning, Windows

Posted by Richard M. Hicks on February 13, 2025

https://directaccess.richardhicks.com/2025/02/13/always-on-vpn-and-sql-target-principal-name-incorrect/

Always On VPN and Cloud PKI for Intune Error 853

Microsoft Cloud PKI for Intune is a PKI-as-a-Service offering that allows organizations to issue and manage digital certificates without on-premises infrastructure. Certificates are excellent phishing-resistant credentials that are well-suited for applications requiring strong authentication, such as secure remote access with Always On VPN. However, administrators may encounter errors when attempting to authenticate users or devices using certificates issued by Cloud PKI for Intune.

Error 853

After publishing certificates with Cloud PKI for Intune and configuring the on-premises Always On VPN infrastructure to support this, administrators will find that the Always On VPN connection fails to connect. Attempts to manually start the connection result in the following error message.

“The remote access connection completed, but authentication failed because the certificate that authenticates the client to the server is not valid. Ensure the certificate used for authentication is valid.”

In the event log on the Windows client, you’ll find an event ID 20227 from the RasClient source that includes the following error message.

“The user <domain>\<user> dialed a connection named <VPN connection name> which has failed. The error code returned on failure is 853.”

Error 853 (ERROR_EAP_USER_CERT_INVALID) indicates the user certificate is invalid.

Certificate

Upon further investigation, the certificate shows no issues, is valid, is trusted, and has a private key.

NPS

Looking at the event log on the Network Policy Server (NPS), you’ll find a corresponding event ID 6273 from the Microsoft Windows security auditing source that includes the following error message.

“Network Policy Server denied access to a user.”

Looking at the authentication details section of this event log entry yields the following important clue.

Reason Code: 258
Reason: The revocation function was unable to check revocation for the certificate.

Failed Revocation Check

Since the NPS server indicates that it rejected the authentication request because it could not perform a revocation check, let’s bring the user authentication certificate to the NPS server and perform some tests.

Export Certificate

Open the user certificate store (certmgr.msc) on the client and expand Personal > Certificates. Right-click on the certificate in question and choose All Tasks > Export. Export the certificate only (not the private key) and copy the file to the NPS server.

Verify Certificate

Open a PowerShell or command window on the NPS server and run the following command to validate the certificate.

certutil.exe -verify -urlfetch <path to exported certificate>

For example.

certutil.exe -verify -urlfecth .\rdeckard.cer

The command generates a lot of output, but if you look at the very end of the data stream, you’ll see two interesting items.

Revocation check skipped – no revocation information available
Leaf certificate revocation check passed

Based on this information the user certificate (the leaf certificate) passed a revocation check. However, it would appear that another certificate in the chain does not include revocation information. Since there is only a root and issuing CA in the chain, and root certificates don’t include revocation information because they are the self-signed root of trust, it would appear that revocation information is missing from the issuing CA certificate.

We can confirm this by scrolling up in the previous command’s output to where the verification of the issuing CA certificate takes place. Here, you’ll see that the issuing CA certificate is missing CDP (CRL Distribution Point) information.

When NPS attempts to validate the certificate and the certificate chain, it expects to find CDP information, which it will use to check if the issuing CA certificate has been revoked. The revocation check fails without this information, and the authentication request is rejected.

Design Error?

Missing CDP information is not unusual for end-entity (leaf) certificates when they are short-lived. An example is Entra ID conditional access certificates, which do not include CDP information by design. However, I expect this information to be listed on an issuing CA certificate. Why it’s not there, I’m not sure. I’ll investigate this in more depth and report on anything I learn that’s new.

Workaround

To move forward using Cloud PKI for Intune certificates with Always On VPN, administrators must implement the following registry setting on all NPS servers handling authentication requests for Always On VPN servers.

Key = HKLM\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13
Name = IgnoreNoRevocationCheck
Type = DWORD
Value = 1

To implement this change using PowerShell, open an elevated PowerShell command window and run the following command.

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13\’ -Name IgnoreNoRevocationCheck -PropertyType DWORD -Value 1 -Force

Once complete, restart the NPS server for the changes to take effect.

Additional Information

Cloud PKI for Microsoft Intune

Cloud PKI for Microsoft Intune and Active Directory

Cloud PKI for Microsoft Intune and Certificate Templates

Strong Certificate Mapping for Microsoft Intune PKCS and SCEP Certificates

Troubleshooting Intune Failed PKCS Request

Cloud PKI for Microsoft Intune SCEP URL

Delete A Cloud PKI for Microsoft Intune Certificate Authority

Cloud PKI for Microsoft Intune on RunAs Radio Podcast

Mastering Certificates with Microsoft Intune Online Training

Richard M. Hicks Consulting, Inc.

Awards

Consulting

Pluralsight

Newsletter

All posts tagged Mobility

Always On VPN Discord Channel