The Azure VPN gateway has been an option for supporting Microsoft Always On VPN client connections for organizations moving resources to the cloud. Today, Azure VPN gateway supports Internet Key Exchange version 2 (IKEv2), OpenVPN, and Secure Socket Tunneling Protocol (SSTP), although SSTP support has long been limited in scope and scalability. However, Microsoft recently indicated that some important changes are coming soon that will affect VPN protocol support on the Azure VPN gateway.
SSTP and Azure VPN Gateway
Microsoft has announced plans to deprecate and eventually remove support for SSTP on the Azure VPN gateway.
Key Dates
Here is Microsoft’s timeline for retiring SSTP for VPN connections.
March 31, 2026 – SSTP can no longer be enabled on new or existing gateways
March 31, 2027 – Existing SSTP connections will stop functioning
SSTP: Second Class Citizen
The retirement of SSTP for Azure VPN gateway should not have a significant impact on Always On VPN deployments. Support for SSTP on Azure VPN gateway has always been limited, making it a less viable option for most Always On VPN deployments. SSTP connections are capped at 128 concurrent connections (256 in active-active mode), regardless of gateway SKU. Additionally, Azure VPN gateway does not support simultaneous user and device tunnels, further limiting its usefulness in modern Always On VPN designs.
Plan Migration Now
If you are using Azure VPN gateway to support Always On VPN client connections, now is the time to begin planning a migration to IKEv2, which offers better scalability and native Always On VPN support. Alternatively, consider Windows Server RRAS in Azure, a third-party VPN solution, or Entra Private Access if Azure VPN gateway no longer meets your requirements.
More Information
For official guidance, see SSTP Protocol Retirement and Connections Migration. If you’re unsure how this change affects your Always On VPN deployment, or you would like help planning a migration, this is a good time to review your design and roadmap. Fill out the form below, and I’ll provide you with more information.
When deploying Microsoft Entra Private Access, administrators must install at least one Entra Private Network Connector to facilitate communication between Global Secure Access clients and on-premises resources. The Entra Private Network connector is a software agent that communicates outbound only. It requires no inbound connectivity, reducing public network exposure and minimizing the organization’s attack surface.
Entra Private Network Connector
The Entra Private Network connector is essentially the old Azure Application Proxy, updated to support all TCP and UDP-based communication. You can download the connector by opening the Entra admin center, navigating to Global Secure Access > Connect > Connectors, and clicking the Download connector service link.
Cloud Appliances
To enable access to cloud-hosted resources, the Entra Private Network connector can be installed on a VM in those environments. However, the Entra Private Network connector is also available as an appliance in public preview for the following cloud providers.
Minimum 4 CPU cores and 8GB RAM. Monitor resource utilization during migration. Provision additional CPU and/or memory when utilization consistently exceeds 70% during peak times. Scaling out (adding servers) is preferred over scaling up (adding CPU and RAM).
Domain Join. Domain join is optional but recommended. Domain join is required to support single sign-on (SSO).
Connector Groups
A Connector Group is a logical grouping of Entra Private Network connectors. A Connector Group functions as a single unit for high availability and load balancing. Connectors are deployed in the same region as the tenant by default.
Default Group
When you install the Entra Private Network connector, it is placed into the Default connector group. However, this may not always be desirable. For example, the organization may have multiple data centers in different geographies. They may also have resources hosted in different Active Directory forests or perhaps located in isolated network locations. Using a common connector group may be suboptimal or not work at all.
Custom Groups
Administrators can define custom connector groups as needed. Custom connector groups ensure that connectors always have access to the resources nearest to them. They can be deployed in different locations and assigned to other Azure regions to ensure optimal traffic routing and reduced latency. Today, administrators can create connector groups in the North America, Europe, Australia, Asia, and Japan regions.
Create a Connector Group
Open the Microsoft Entra admin center and perform the following steps to create a new Entra Private Network connector group.
Navigate to Global Secure Access > Connect > Connectors and Sensors.
Click on New Connector Group.
In the Name field, enter a descriptive name for the connector group.
From the Connectors drop-down list, select one or more Entra Private Network connectors to assign to the group. Optionally, you can leave this field blank and assign connectors later.
To assign a new connector group to the Quick Access application, open the Entra admin console, navigate to Global Secure Access > Applications > Quick Access, and select the Network access properties tab. Select the new connector group from the Connector Group drop-down list.
Enterprise Applications
To assign a new connector group to an individual Enterprise application, navigate to Global Secure Access > Applications > Enterprise applications. Select an application, then select Network access properties. Select the new connector group from the Connector Group drop-down list.
Deployment Strategy
The following are best practices for deploying the Entra Private Network connector.
Redundancy
Always deploy at least two Entra Private Network connectors to ensure high availability and eliminate single points of failure.
Location
Install the Entra Private Network connector on servers closest to the applications they serve. Deploy connectors in all locations where applications are accessed, including on-premises networks and Infrastructure-as-a-Service (IaaS) resources.
Default Connector Group
Avoid using the default connector group for application assignment. Always use custom connector groups for application access. This ensures that new connectors do not process production traffic immediately after installation, which can cause unexpected behavior if the connector is not optimally deployed for the published resource or is not connected to the back-end application.
Deleting Connectors
Entra Private Network connectors cannot be removed from the management console. If you uninstall a connector, its status will show as inactive. After 10 days of inactivity, it will be automatically removed.
Reassigning Connectors
Administrators can reassign connectors to different connector groups at any time. However, existing connections on that connector server from the prior group assignment will remain until they age out. Administrators can restart the connector service or reboot the server to address this issue.
Restart-Service -Name WAPCSvc -PassThru
Connector Updates
The Entra Private Network connector will automatically install major updates when they become available. However, not all updates are applied automatically. Don’t be alarmed if you see discrepancies between release versions across multiple connector servers in the admin console. Administrators can always perform software updates manually to ensure uniform connector versions in their environment, if desired.
Diagnostics
Beginning with Entra Private Network connector v1.5.4287.0, the agent installation also includes the diagnostic utility ConnectorDiagnosticsTool.exe, which is in the C:\Program Files\Microsoft Entra Private Network Connector\ folder on the connector server. Running the tool initiates a series of tests to perform a health check of the connector service, including certificate status, connectivity, enabled TLS versions, service status, and more.
Note: Entra Private Network connector v1.5.4522.0 and later includes a graphical output, as shown above. Previous versions featured text-based output only.
Summary
Microsoft Entra Private Network Connectors are lightweight, outbound-only agents that enable secure access to on-premises and cloud resources through Entra Private Access. Best practices emphasize deploying at least two connectors per location for redundancy, placing them close to target applications, using custom connector groups for high availability, load balancing, and optimal routing, and assigning them to Quick Access or enterprise applications while avoiding the default group. Ensure that VMs are appropriately sized for the expected connector traffic, and consider using marketplace appliances for Azure, AWS, and GCP. If you’ve previously deployed the Entra Private Network connector, ensure that it is running the latest release to take advantage of new diagnostics for troubleshooting.
The Certificate Connector for Microsoft Intune is a vital component that allows administrators to issue and manage enterprise PKI certificates to endpoints managed by Microsoft Intune. The connector is installed on a Windows server with access to the on-premises Certificate Authority (CA). It is registered with Intune and can be used by any PKCS or SCEP device configuration profiles defined by Intune administrators.
Agent Certificate
When you install the Certificate Connector for Intune, a certificate issued by the Microsoft Intune ImportPFX Connector CA is automatically enrolled into the local computer certificate store of the server where the connector is installed. This certificate authenticates the connector to Intune and is valid for one year from the date of issuance. This certificate is automatically renewed in most cases. However, some configurations prevent this from happening.
Failed To Renew
Administrators may find event log errors with event ID 2 from the CertificateConnectors source in the Microsoft-Intune-CertificateConnectors operational event log with the following information.
Pki Create Service:
Failed to renew agent certificate
System.Security.Cryptography.CryptographicException: Access is denied.
Root Cause
Agent certificate renewal fails when the Certificate Connector for Intune is running under a service account that is not a member of the local administrators security group. You will not encounter this error if the connector services are running in the SYSTEM context, however.
Resolution
There are a few different ways to resolve this issue. Here are some options to consider.
Grant Admin Rights
Adding the service account under which the connector service runs will allow the agent certificate to renew automatically. However, this may not be desirable from a security perspective. To address this, administrators may temporarily grant local administrative access to renew the agent certificate, then revoke this permission once the certificate has been successfully renewed. However, this is a manual process that doesn’t scale well and requires annual administrative intervention.
Reinstall
Uninstalling and reinstalling the Certificate Connector for Intune will force a new certificate enrollment during the registration process. You can delete the old certificate after completing the installation.
Switch to SYSTEM
Changing from a service account to SYSTEM will also resolve this issue. However, it is not recommended to make these changes directly on the services themselves. Instead, administrators should remove and reinstall the Certificate Connector for Intune, selecting the SYSTEM option rather than the service account method.
Note: Using the SYSTEM account for the Certificate Connector for Intune should be avoided when using PKCS. Details here.
Summary
The Certificate Connector for Intune agent certificate renewal fails when the service is configured to run as a service account without local administrative rights. The best way to resolve this is to add the service account to the local administrators group on the server where the connector is installed. However, this isn’t always ideal. Although running the connector in the SYSTEM context is acceptable when using SCEP, it should be avoided when using PKCS. Administrators will have to accept the risk of the service account having local administrative rights or accept that they’ll have to reinstall the connector annually.
Recently, the CA/Browser Forum, which is a voluntary consortium made up of public CAs, browser vendors, and other industry stakeholders, introduced new requirements for S/MIME certificates issued by public certification authorities (CAs). For organizations using Microsoft Intune SCEP device configuration profiles to enroll for these certificates, administrators must update Intune settings to ensure uninterrupted enrollment once the changes take effect.
Subject Name Changes
Beginning July 16, 2025, all publicCAs will enforce these new S/MIME Baseline Requirements, mandating “Given Name” and “Surname” attributes in the Subject Name field of S/MIME certificates. By default, Intune user certificate profiles include only the “UserName” attribute in the Subject Name field.
Intune Support
Intune recently completed the rollout of these new attributes in SCEP profiles. Administrators can now update their SCEP profiles for third-party public CAs to include these new attributes for S/MIME certificates using the following supported variables.
G={{GivenName}} SN={{SurName}}
To align with current public CA standards, include these two fields along with any other information required in the Subject name format field. Multiple values must be separated by commas without spaces, as shown in the example below.
Private CAs
Private CAs, like Active Directory Certificate Services (AD CS) or Intune Cloud PKI, are unaffected. If you are enrolling for S/MIME certificates using these services, no changes are required.
Reenrollment
It’s important to note that modifying an existing Intune SCEP profile will trigger certificate reissuance for all users and devices within the policy’s scope, which could yield unexpected results. When making changes to Intune certificate policies, it is best to create a new policy to supersede the old one, allowing administrators to pilot the new policy before its broad deployment.
I’m excited to announce that I will be delivering another edition of the Mastering Certificates with Microsoft Intune course, hosted by ViaMonstra Online Academy. This is a three-day live online training course that takes place August 26-28, 2025. This course dives deep into issuing and managing certificates using Microsoft Intune, covering both on-premises and cloud-based solutions.
Course Overview
This interactive training equips IT professionals with the skills to provision and manage enterprise PKI certificates using Microsoft Intune. It explores Active Directory Certificate Services (AD CS), Microsoft Cloud PKI for Intune, and non-Microsoft solutions, with live demonstrations featuring real-world scenarios.
Key Learning Objectives
Those taking the online training course will learn the following.
Certificate Basics: Understand certificate roles and enterprise use cases.
Deployment Options: Master Intune certificate deployment (Intune policies, revocation, security) and Microsoft Cloud PKI (licensing, benefits, limitations, BYOCA).
Intune Deployment: Learn PKCS and SCEP deployment, security best practices, and troubleshooting.
High Availability: Explore strategies for reliable certificate management.
Course Highlights
Here are some key highlights for attendees of the training.
Expert-Led: Learn from a veteran IT professional, a Microsoft MVP, with deep PKI and Intune expertise.
Interactive Demonstrations: The course includes numerous practical exercises in real-world scenarios.
Resources: Access to security best practices and sample scripts for automated configuration.
Community: Join a private Facebook group for peer collaboration.
Live Q&A: Engage directly with the instructor for a clearer understanding.
Who Should Attend?
This training event is ideal for IT administrators, security professionals, and systems engineers working with Intune, AD CS, or Microsoft Cloud PKI for Intune.
Prerequisites
Those attending the online training course should be familiar with the following.
Basic networking knowledge (TCP/IP, DNS).
Familiarity with Active Directory, Windows OS, and Intune.
Access to an AD CS setup and an Azure subscription with Intune Suite licenses.
Why It Matters
Certificates are vital for secure authentication and communication. This course bridges theory and practice, equipping you to deploy and manage digital certificates effectively in cloud-native environments.
Details
Here is some additional information about the training event.
When: August 26-28, 2025 (sessions begin at 9:00 AM CDT).
I’m very excited to announce that I will be attending the annual Techmentor Conference at the Microsoft HQ campus in Redmond, Washington, this year. The event takes place August 11-15, 2025. The Techmentor Conference is one of my favorite IT pro conferences because it offers unparalleled access to experts worldwide. I will deliver two presentations at this year’s event. I hope you’ll join me!
Entra Private Access
On Tuesday, August 12, 2025, I will be presenting a session on Zero Trust Network Access with Microsoft Entra Private Access. ZTNA is the future of remote access and provides many security and operational benefits over traditional client-based VPN technologies.
On Wednesday, August 13, 2025, I’ll discuss Simplified Certificate Management with Microsoft Cloud PKI for Intune. As organizations integrate cloud-native devices in their environments, administrators must solve the problem of issuing and managing certificates for users and devices that are not domain-joined. Cloud PKI for Intune is an excellent solution that provides deployment flexibility to address these unique and specific requirements.
Registration for the event is open now. Use the promo code HICKS and receive $500.00 off the price of admission. Don’t miss this excellent opportunity to learn from the best. Register today!
Recently, I wrote about Microsoft Always On VPN and Entra Conditional Access and how conditional access improves your organization’s security posture by making policy-based access decisions based on various signals such as user identity, location, device compliance, platform, sign-in risk, and more. In this post, I’ll provide step-by-step instructions for integrating Entra Conditional Access with existing Always On VPN deployments.
Requirements
To use Microsoft Entra Conditional Access with Always On VPN you must have Entra ID P1 at a minimum. To use advanced features such as risk-based policy assessment, you must have Entra ID P2. In addition, all endpoints must be under Intune management; either native Entra ID joined, or hybrid Entra ID joined.
Enable VPN Support
To begin, open the Microsoft Entra admin center (https://entra.microsoft.com/), navigate to Identity > Protection > Conditional Access, and perform the following steps.
Click VPN Connectivity.
Click New certificate.
From the Select duration drop-down list, choose an appropriate certificate validity period.
Click Create.
Once complete, click Download certificate and copy the certificate file to a domain-joined system on-premises.
Publish Certificate
Next, administrators must publish the Entra VPN root certificate in Active Directory to support domain authentication. Open an elevated PowerShell or command window and run the following commands.
certutil.exe -dspublish -f <path to certificate file> RootCA
certutil.exe -dspublish -f <path to certificate file> NtAuthCA
Note: You must be a domain administrator to perform this task.
Conditional Access Policy
Navigate to Identity > Protection > Conditional Access and click Policies, then perform the following steps to create a conditional access policy for VPN access.
Click New Policy.
Enter a descriptive name for the new policy.
Click the link in the Target resources section.
From the Select what this policy applies to drop-down list, select Resources (formerly cloud apps).
In the Include section, choose Select resources.
Click the link in the Select section.
Enter VPN in the search field.
Check the box next to VPN Server.
Click Select.
Click the link in the Grant section.
Select Grant access.
Check the box next to Require device to be marked as compliant.
Click Select.
On the Enable policy slider, select On.
Click Create.
NPS
Changes to Network Policy Server (NPS) policy and configuration are required to support Always On VPN with Entra Conditional Access.
NPS Policy
To update the Always On VPN network policy to support Entra Conditional Access, open the NPS management console (nps.msc), expand Policies, then select Network Policies and perform the following steps.
Right-click on the Always On VPN policy and choose Properties.
Select the Settings tab.
Select Vendor Specific in the RADIUS Attributes section.
Click Add.
Select the Allowed-Certificate-OID attribute.
Click Add.
Click Add.
Enter 1.3.6.1.4.1.311.87 in the Attribute value field.
Click Ok.
Click Ok.
Click Close.
Click Ok.
Important Note: This change will block new Always On VPN user tunnel connections until you update the client configuration. When integrating an existing Always On VPN implementation with Entra Conditional Access, consider creating a new NPS policy and corresponding security group to migrate users to conditional access seamlessly.
NPS Configuration
By default, NPS will perform revocation checks for certificates used for domain authentication. However, Entra Conditional Access uses short-lived certificates (one-hour lifetime) that do not include CRL Distribution Point (CDP) information. Therefore, administrators must change the NPS server configuration to disable revocation checking for certificates lacking this information.
To do this, open the registry editor (regedit.exe) and create a new registry key with the following settings.
Once complete, the server must be rebooted for the change to take effect.
Client Configuration
After making all required changes to the supporting infrastructure, you must also update the Always On VPN client configuration to leverage Entra Conditional Access. Changes to client configuration vary depending on the method used to deploy and manage Always On VPN client configuration settings.
Intune
When using Microsoft Intune and the native VPN policy type to deploy and manage Always On VPN client configuration settings, perform the following steps to update the VPN configuration to include Entra Conditional Access support.
Click Enable next to Conditional access for this VPN connection.
Click Enable next to Single sign-on (SSO) with alternate certificate.
Enter Client Authentication in the Name field.
Enter 1.3.6.1.5.5.7.3.2 in the Object Identifier field.
Enter the organization’s root certification authority (CA) certificate thumbprint in the Issuer hash field.
XML
When using a custom XML configuration file for Always On VPN client configuration settings deployed using Intune or PowerShell, edit the XML file, remove the existing <TLSExtensions></TLSExtensions> section, and replace it with the following.
In addition, add the following code between the <VPNProfile></VPNProfile> tags after <TrustedNetworkDetection>.
Note: You will find a sample XML configuration file you can copy and paste from on GitHub here.
DPC
When using Always On VPN Dynamic Profile Configurator (DPC) for managing Always On VPN client configuration settings, open the DPC group policy and navigate to Computer Configuration > Policies > Administrative Templates > DPC Client > User Tunnel Settings > Advanced and perform the following steps.
Following the guidance in this post to integrate Entra Conditional Access with Always On VPN can significantly improve your organization’s security posture. In the example above, the conditional access policy is a basic one. Yet, it dramatically reduces the attack surface for your remote access infrastructure by ensuring only compliant devices can establish a VPN connection.
Administrators can use advanced conditional access policy settings to strengthen the VPN’s security further by performing additional checks, such as requiring strong, phishing-resistant credentials and requesting multifactor authentication (MFA) for risky sign-ins.
I’m excited to announce that I’ll be speaking at the Arizona Systems Management User Group (AZSMUG) at their next user group meeting on Friday, March 7, at 9:00 AM MST. I am presenting on the topic of Certificate Deployment Strategies with Microsoft Intune.
Intune and Certificates
My session at AZSMUG will provide an overview of issuing and managing certificates with Microsoft Intune. We’ll begin by examining common scenarios for certificate authentication and explore various delivery methods, including PKCS and SCEP. Additionally, we’ll discuss supporting technologies such as the Network Device Enrollment Service (NDES) and review deployment strategies and high availability options for the Intune Certificate Connector. The session will also cover Cloud PKI for Intune, integration with on-premises Active Directory, and best practices for securing certificate lifecycles and key management in enterprise environments.
Register Now
If you are in the Phoenix area and would like to attend the user group meeting on Friday, March 7, you will find the registration link here. Hope to see you there!
Microsoft recently introduced Entra Private Access, an identity-centric Zero Trust Network Access (ZTNA) solution to provide secure remote access to on-premises resources. With Entra Private Access, administrators can leverage Entra Conditional Access to enforce policy-based access control for network access. However, Entra Private Access isn’t for everyone. It does not provide full feature parity with Always On VPN, and there are also licensing considerations. However, for those organizations using Always On VPN, the good news is that you can integrate Entra Conditional Access with Always On VPN today to gain some of the security benefits it provides.
Conditional Access
Microsoft Entra Conditional Access is a security feature that enables administrators to create and enforce policies that specify how users can access resources. In the specific case of Always On VPN, conditional access is critical to ensuring legitimate access to authenticated users on authorized devices.
Signals
Conditional access policies use a wide variety of signals for policy enforcement, such as:
User Identity: Who is making this access request?
User Properties: Is this user a member of a specific group?
Location: Where is this access request originating?
Device Management: Is this device joined to Entra ID?
Device State: Is this device compliant with security policies?
Device Platform: Is this a Windows device?
Risk Level: Is this login considered risky?
Access Control
Based on these signals, administrators can design a conditional access policy to enforce granular access control, such as:
Enforce specific authentication types (e.g., phishing-resistant credentials)
Allow access only from specific device platforms (e.g., Windows only)
Require Entra hybrid-joined device
Block access when a device is not compliant with security policies
Always On VPN
Entra Conditional Access works with Always On VPN by issuing a special, short-lived user authentication certificate once the user has been authorized. The Always On VPN infrastructure can be configured to use this certificate to grant access to the VPN. Integrating conditional access with Always On VPN can significantly improve the security posture of organizations using this feature.
Are you ready? In just a few short weeks(!) Microsoft will release the February 2025 security updates. This is a critical update because Microsoft plans to enable full enforcement of strong certificate mapping on Active Directory Domain Controllers (DCs) with this release. Administrators unprepared for this may incur outages for workloads using certificate-based authentication such as Always On VPN, Wi-Fi, and others.
Microsoft introduced strong certificate mapping with the May 2022 update KB5014754 to address vulnerabilities identified with certificate-based authentication. The update makes changes to Active Directory Certificate Services (AD CS) certification authorities (CAs) to embed the principal’s Security Identifier (SID) on issued certificates with a new certificate extension. The update also changes domain controller behavior to monitor and optionally enforce strong certificate mapping for authentication.
Enforcement Mode
When first introduced, the update is configured in compatibility mode. If a certificate that isn’t strongly mapped is presented for authentication, an event is recorded in the event log indicating that. Microsoft has been planning for years to enable full enforcement. After many delays, that time is now upon us. Specifically, full enforcement for strong certificate mapping will be enabled by default on DCs after applying the February 2025 security updates.
Note: Administrators can switch back to compatibility mode for now. See below for more details.
Limitations
Initially, the strong certificate mapping update was applied only to online certificate templates. Specifically, those templates are configured to build the subject name from Active Directory information. However, offline templates, where the subject name is supplied in the request, do not include this information by default. Crucially, any certificate issued with Microsoft Intune with PKCS or SCEP uses offline templates and is not strongly mapped. The lack of strong certificate mapping options for Intune-issued certificates forced Microsoft to delay its full enforcement deadline until these limitations were resolved.
Updates
In October 2024, Microsoft Intune announced support for strong certificate mapping for PKCS and SCEP certificates. Administrators can now configure these certificates to include strong certificate mapping. However, administrators must take action to affect this change.
PKCS
To enable strong certificate mapping for PKCS certificates, administrators must ensure that the certificate connector is running at least version 6.2406.0.1001. In addition, the following registry key must be configured on the connector server.
The Intune Certificate Connector server must be restarted for this change to take effect. No changes are required on the PKCS certificate policy in Intune.
SCEP
To enable strong certificate mapping for SCEP certificates, administrators must add the following attribute/value pair to the Subject alternative name settings on their existing Intune SCEP certificate policy.
Attribute: URI Value: {{OnPremisesSecurityIdentifier}}
Preparation
Administrators using certificate-based authentication against on-premises Active Directory should ensure all user and device authentication certificates include embedded SID information. For certificates issued on-premises, with Intune using PKCS or certificates issued by Entra Conditional Access, the certificate should now have the extension 1.3.6.1.4.1.311.25.2, including the principal’s SID.
SCEP certificates issued using Intune will include the following information in the Subject Alternative Name field.
URL=tag:microsoft.com,2022-09-24:sid:<sid>
Note: This applies to certificates issued using Cloud PKI for Microsoft Intune as those certificates are deployed using a SCEP device configuration policy.
Opt-Out
With the February 2025 security update, all domain controllers will be switched to full enforcement mode. Authentication requests using certificates without strong mapping will be denied in this configuration.
If your organization is not prepared to move to full enforcement mode, the February 2025 update allows administrators to opt out and switch back to compatibility mode by enabling the following registry key on all domain controllers.
Administrators are strongly encouraged to update all user and device authentication certificates before September 2025. With the September 2025 security update, Microsoft will no longer honor the opt-out registry settings and strictly enforce strong certificate mapping for all certificate-based authentication requests.
Troubleshooting
Certificate authentication is commonly used for Always On VPN and Wi-Fi authentication. If full enforcement mode is enabled on domain controllers and a certificate is presented for authentication that is not strongly mapped, administrators may see the following event log information recorded on the Network Policy Server (NPS).
Network Policy Server denied access to a user.
The details of the event include the following.
Reason Code: 16 Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.
Obviously, the user does not enter their password when using certificates for authentication. However, the indication of a credential mismatch can be caused by missing strong certificate mapping information when the DC is in full enforcement mode.
Note: There are other causes for reason code 16 failures on NPS. Further investigation may be required to determine the root cause.
