Intune Certificate Connector Configuration Failed

Troubleshooting Always On VPN Error 691 and 812 – Part 2

The Microsoft Intune Certificate Connector must be deployed on-premises to provision and manage enterprise PKI certificates using Intune. The Intune Certificate Connector supports the deployment of SCEP, PKCS, PKCS imported certificates, or any combination of these. The connector can be configured to run under the SYSTEM account or optionally (and recommended) a domain service account. When using a service account, the service account must have permission to log on as a service on the server where the Intune Certificate Connector server.

Access is Denied

Even when all prerequisites are met, administrators may still find the installation of the Intune Certificate Connector fails with the following error message.

“Configuring Microsoft Intune Certificate Connector failed. No changes were made to Feature or Proxy settings. Please try again.”

“Unexpected Failure. Error: System.lnvalidOperationException: Cannot open PFXCertificateConnectorSvc service on computer ‘.’ System.ComponentModel.Win32Exception: Access is denied”

Workaround

After the connector installation fails, open the file explore and navigate to C:\Program Files\Microsoft Intune\PFXCertificateConnector\ConnectorUI. Right-click PFXCertificateConnectorUI.exe and choose ‘Run as administrator’.

Run through the connector installation wizard again, and it should install without issue.

To avoid this problem for future Intune Certificate Connector deployments, administrators can right-click the Intune Certificate Connector installer (IntuneCertificateConnector.exe) and choose ‘Run as administrator’.

Additional Information

Microsoft Intune Certificate Connector Configuration Failure (Part 1)

Microsoft Intune Certificate Connector Service Account and PKCS

Microsoft Intune Learning Resources for Always On VPN Admins

Microsoft Intune Certificate Connector Overview

Always On VPN April 2023 Security Updates

Heads up, Always On VPN administrators! This month’s patch Tuesday includes fixes for critical security vulnerabilities affecting Windows Server Routing and Remote Access Service (RRAS). Crucially there are remote code execution (RCE) vulnerabilities in the Point-to-Point Tunneling Protocol (PPTP) (CVE-2023-28232), the Layer Two Tunneling Protocol (L2TP) (CVE-2023-28219, CVE-2023-28220), the Point-to-Point over Ethernet (PPPoE) protocol (CVE-2023-28224), and the Internet Key Exchange (IKE) protocol (CVE-2023-28238). The vulnerabilities in PPTP and L2TP are especially urgent as they allow an unauthenticated attacker to exploit them. There is also a denial-of-service (DoS) vulnerability (CVE-2023-28234) in the Secure Socket Tunneling Protocol (SSTP) protocol.

Exposure and Risk

The RCEs in PPTP, L2TP, and PPPoE should present limited risk as these protocols aren’t commonly used for Always On VPN (PPPoE and PPTP aren’t supported for Always On VPN, in fact). However, organizations may be using these protocols for other purposes. In addition, improperly configured edge firewalls could allow these connections even though administrators may not be actively using them. An attacker could also exploit these vulnerabilities with access to the RRAS server from the internal network.

Attack Surface Reduction

Always On VPN administrators are advised to ensure that only protocols and ports for VPN protocols in use are allowed through the edge firewall. Also, administrators should disable any unused protocols and services in RRAS to reduce the attack surface on their RRAS servers. To do this, open an elevated PowerShell command window on the RRAS server and run the following commands to disable support for the PPTP, L2TP, and PPPoE protocols.

netsh.exe ras set wanports device = “WAN Miniport (L2TP)” rasinonly = disabled ddinout = disabled ddoutonly = disabled maxports = 0

netsh.exe ras set wanports device = “WAN Miniport (PPTP)” rasinonly = disabled ddinout = disabled ddoutonly = disabled maxports = 1

netsh.exe ras set wanports device = “WAN Miniport (PPPOE)” ddoutonly = disabled

Restart-Service RemoteAccess -PassThru

Additional Vulnerabilities

This month’s update also includes fixes for other vulnerabilities that may impact Always On VPN deployments. Specifically, there are RCEs in Windows Network Address Translation (NAT) (CVE-2023-28217) and Windows Network Load Balancing (NLB) (CVE-2023-28240), and a DoS vulnerability in Windows Transport Layer Security (TLS) (CVE-2023-28234).

Update Now

Administrators should patch their RRAS servers as soon as possible to avoid potential compromise of the RRAS server in their environments.

Additional Information

Always On VPN SSTP Security Configuration

Always On VPN and Device Sharing

Always On VPN client configuration settings are typically deployed in the user’s context. However, this presents a unique challenge when sharing a single device with multiple users who have an Always On VPN profile assigned to them. By design, Windows designates only a single user profile on a shared device to be “always on”. When multiple users with assigned Always On VPN profiles share the same machine, it could yield unexpected results.

Auto Trigger Profile

When an Always On VPN profile is provisioned to a user, Windows records information about this profile in the registry. Specifically, the Always On VPN profile’s name and GUID are recorded, as well as the user’s Security Identifier (SID) and the path to the rasphone.pbk file that contains the Always On VPN profile.

Multiple Users

When a new user logs on to a shared device and receives their Always On VPN profile, Windows overwrites this existing data in the registry with the current user’s information. Each time this user logs on, their Always On VPN connection will establish automatically. Any other users with Always On VPN profiles configured on the same shared device will no longer connect automatically after this. The most recently deployed Always On VPN profile will be designated the “always on” profile.

Connect Automatically

In the above scenario, any user with an assigned Always On VPN profile on the shared device can take over the “always on” designation by opening the VPN connection properties and checking the “Connect automatically” check box.

When this happens, this user will now own the “always on” profile, and other users on the shared device will no longer connect automatically.

Workarounds

If multiple users share a single device requiring Always On VPN connectivity, you have a few options.

Intune

If you are deploying Always On VPN client configuration settings using Intune, you must use the Custom device configuration profile template. Specifically, as shown here, you must deploy your XML configuration file using the ./Device/Vendor/MSFT/VPNv2/ OMA-DM URI.

Unfortunately, the native Intune VPN template does not support deploying Always On VPN profiles in the “all users” context.

PowerShell

When using PowerShell, either natively or with SCCM or another software deployment tool, administrators can use my Always On VPN deployment PowerShell script with the -AllUserConnection parameter.

PowerON DPC

When using PowerON Platforms’ Dynamic Profile Configurator (DPC) to deploy Always On VPN client configuration settings using on-premises Active Directory or via Intune, no changes are required. DPC deploys Always On VPN user profiles in the “all users” context by default.

Additional Information

New-AovpnConnection.ps1 PowerShell Script on GitHub

PowerON Platforms’ Dynamic Profile Configurator (DPC)

Always On VPN DPC with PowerON Platforms’ DPC

%d bloggers like this: