All posts tagged SID

Strong Certificate Mapping for Intune PKCS and SCEP Certificates

Always On VPN LockDown Mode

With the October 2024 Intune update, Microsoft introduced support for strong certificate mapping for certificates issued by Intune via the Intune Certificate Connector. Enabling strong certificate mapping support in Intune is an important change for those organizations using Microsoft Intune to issue and manage certificates for their users and devices, as it resolves a critical implementation blocker.

Note: This post was updated to clarify that adding the {{OnPremisesSecurityIdentifier}} for PKCS certificates is not required. This variable is only used for SCEP certificates.

Background

In May 2022, Microsoft released security update KB5014754, which added functionality to domain controllers and enterprise issuing certification authority (CA) servers, allowing the Kerberos Key Distribution Center (KDC) to enforce strong certificate mapping. Specifically, with KB5014754 installed, issuing CAs now add the requesting principal’s Security Identifier (SID) to the certificate in a new certificate extension. Domain controllers can be configured to reject authentication requests using certificates that do not include this information.

Today, DCs with KB5014754 installed will still allow authentication without strong certificate mapping. However, Microsoft has stated they will begin enforcing strong certificate mapping in February 2025, with an option to disable it via the registry. Starting in September 2025, full enforcement will be mandatory.

Reference: https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16

Limitation

The initial changes in KB5014754 applied only to online certificate templates, meaning those that build the subject name from Active Directory. However, deploying certificates with Intune using either PKCS or SCEP requires using an offline certificate template that allows the requestor to supply the subject name in the request. When using offline templates, a certificate is issued but does not embed the SID in the certificate. Using offline templates presents unique challenges to organizations moving to modern management with Intune and Entra ID.

Intune Changes

The October 2024 Intune update addresses this limitation by providing a method to include SID information in certificates using either SCEP or PKCS.

SCEP

To include the SID information in SCEP certificates, create or edit an existing SCEP device configuration policy and define a URI Subject Alternative Name (SAN) attribute with the value {{OnPremisesSecurityIdentifier}} as shown here.

PKCS

To include SID information in PKCS certificates, administrators must ensure the Intune Certificate Connector is updated to at least version 6.2406.0.1001. In addition, a registry setting must be enabled on the Intune Certificate Connector server.

On the server where the Intune Certificate Connector is installed, open the registry editor, navigate to HKLM\Software\Microsoft\MicrosoftIntune\PFXCertificateConnector, and change the value of EnableSidSecurityExtension to 1.

Optionally, administrators can update this setting at the command line by running the following PowerShell command.

Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft\MicrosoftIntune\PFXCertificateConnector’ -Name EnableSidSecurityExtension -Value 1 -Force

Once complete, restart the Intune Certificate Connector server for the changes to take effect.

Certificates

SID information is added to certificates differently depending on which Intune device configuration policy type is used.

PCKS

PKCS certificates have the SID embedded in the certificate extension 1.3.6.1.4.1.311.25.2, as shown here.

SCEP

SCEP certificates have the SID embedded in the Subject Alternative Name (SAN) field in the format “tag:microsoft.com,2022-09-14:sid:<SID>” as shown here.

Migration

When making these changes to embed the SID in Intune-issued certificates in an existing Intune PKCS or SCEP configuration policy, the change will only affect certificates issued after the change is made. To update all certificate holders, you must create and deploy a new device configuration policy to targeted users or devices. Deleting the old profile (or ensuring it no longer applies) will remove the old certificate from the endpoint. If you’ve configured your Intune Certificate Connector to support revocation, the old certificate will also be revoked.

Entra Conditional Access

Entra Conditional Access certificates have included SID information since July 2023. More details here.

Intune Cloud PKI

The changes above will also work with certificates issued by Cloud PKI for Intune.

Other Cloud PKI Providers

Many other Cloud PKI providers, such as SCEPman and KEYTOS, already include the embedded SID in their certificates. Other cloud PKI providers may also include embedded SID. Consult your provider to confirm.

Additional Information

Microsoft Intune October 2024 Strong Certificate Mapping Update

Microsoft Intune Certificate Connector Strong Certificate Mapping Update for PKCS

Entra ID Conditional Access Certificates with SID Information Now Available

Implementing Strong Certificate Mapping in Microsoft Intune PKCS and SCEP Certificates

Certificate-Based Authentication Changes and Always On VPN

10 Comments
by Richard M. Hicks on November 4, 2024  •  Permalink
Posted in Active Directory, Active Directory Certificate Services, AD CS, ADCS, administration, Always On VPN, AOVPN, authentication, Azure, Azure Active Directory, Azure AD, Azure Conditional Access, Certificate Authentication, Certificate Authority, Certificate Connector for Intune, Certificate Services, Certificate-Based Authentication, certificates, cloud, Cloud PKI, Cloud Service, Conditional Access, Device Management, Endpoint Manager, Enterprise, enterprise mobility, Entra, Entra Conditional Access, Entra ID, Hybrid Entra ID Join, Hybrid Entra Join, Infrastructure, InTune, Intune Certificate Connector, Intune PFX Connector, MDM, MEM, Microsoft, Microsoft Endpoint Manager, Microsoft Entra, Microsoft Entra ID, Microsoft Intune, Mobile Device Management, Mobility, NDES, Network Device Enrollment Service, Network Device Enrollment Services, Operational Support, PFX Connector, PKCS, PKI, public cloud, public key infrastructure, SCEP, Security, Security Update, Simple Certificate Enrollment Protocol, Update, Windows 10, Windows 11
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on November 4, 2024

https://directaccess.richardhicks.com/2024/11/04/strong-certificate-mapping-for-intune-pkcs-and-scep-certificates/

Azure Conditional Access Certificates with SID Information Now Available

I recently wrote about changes to certificate-based authentication affecting Always On VPN implementations. These changes were introduced by Microsoft’s security update KB5014754. When the update is installed on domain controllers and enterprise Certification Authorities (CAs), administrators can perform strong user mapping for certificates used for Active Directory authentication. However, when first introduced, the update came with some serious limitations that prevented administrators from enabling full enforcement mode for certificate mapping.

Limitations

When KB5014754 is installed on an enterprise issuing CA, a new certificate extension (1.3.6.1.4.1.311.25.2) is added to the issued certificate that includes the principal’s (user or device) Security Identifier (SID). However, this only occurs when an online template is used. An online template is one with the subject name built from Active Directory information. The SID is not embedded in certificates issued using an offline template. Offline templates are templates where the subject name is supplied in the request. There are two scenarios where this causes problems for Always On VPN.

Microsoft Intune

Certificates delivered with Microsoft Intune via the Intune Certificate Connector use an offline template. This applies to certificates using PKCS or SCEP. Today, the SID is not embedded by issuing CAs using offline templates.

Azure Conditional Access

The short-lived certificate issued by Azure when Conditional Access is configured for Always On VPN did not include the SID. However, that recently changed.

Recent Updates

Today we can scratch Azure Conditional Access off the list of limitations for Always On VPN. Microsoft recently introduced support for the new SID extension in Azure Conditional Access certificates, as shown here.

Now when an Azure Conditional Access certificate is issued to an on-premises user or device account that is synced with Azure Active Directory, Azure Conditional Access will include the SID information in the issued short-lived certificate.

Intune

Unfortunately, we’re still waiting for Microsoft to address the limitation with certificates delivered using Microsoft Intune. Hopefully we’ll see an update for that later this year.  

Additional Information

Certificate-Based Authentication Changes and Always On VPN

Microsoft KB5014754

Digital Certificates and TPM

Microsoft Intune Certificate Connector Service Account and PKCS

4 Comments
by Richard M. Hicks on July 11, 2023  •  Permalink
Posted in AADJ, Active Directory, administration, Always On VPN, AOVPN, authentication, Azure, Azure Active Directory, Azure AD, Azure AD Join, Azure Conditional Access, Azure MFA, Azure VPN, Certificate Connector for Intune, certificates, cloud, Conditional Access, Deployment, Device Management, Endpoint Manager, Enterprise, enterprise mobility, HAADJ, Hybrid Azure AD Join, Infrastructure, InTune, Intune Certificate Connector, Intune PFX Connector, MDM, MEM, MEMCM, MFA, Microsoft, Microsoft Endpoint Manager, Microsoft Intune, Mobile Device Management, Mobility, Multifactor Authentiction, NDES, Network Device Enrollment Service, Network Device Enrollment Services, NPS, Operational Support, PFX Connector, PKCS, PKI, public cloud, public key infrastructure, Remote Access, SCEP, Security, Simple Certificate Enrollment Protocol, systems management, Update, user tunnel, VPN, Windows 10, Windows 11
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on July 11, 2023

https://directaccess.richardhicks.com/2023/07/11/azure-conditional-access-certificates-with-sid-information-now-available/

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

6 Comments
by Richard M. Hicks on March 27, 2023  •  Permalink
Posted in administration, Always On VPN, AOVPN, AovpnDPC, Deployment, DPC, Dynamic Profile Configurator, Endpoint Manager, Enterprise, enterprise mobility, GitHub, InTune, MDM, MEM, MEMCM, Microsoft, Microsoft Endpoint Manager, Microsoft Intune, Mobile Device Management, Mobility, OMA-DM, Operational Support, PowerShell, ProfileXML, Remote Access, user tunnel, VPN, Windows 10, Windows 11
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on March 27, 2023

https://directaccess.richardhicks.com/2023/03/27/always-on-vpn-and-device-sharing/

« Older Posts