Mitigation for CBA before Full Enforcement Mode is Enabled (KB5014754)

Before you run your Domain Controllers (DCs) in full enforcement mode (in response to KB5014754), you must ensure Certificate Based Authentication (CBA) will still work. In the article below, we present the Axiad recommended approach to mitigate the risk for existing users as well as new ones.

Mitigation Mechanism for KB5014754

There are two recommended approaches to remediate issues presented by KB5014754 (Certified) and be compliant:

• Add the end-user objectSid in a new attribute in the certificate (long-term solution)

• Map the user active certificate to their altSecurityIdentities attribute in AD (temporary solution)

Add objectSID to Certificate

The end-user objectSid is unique within a domain and looks like the following (in its humane readable format):
S-1-5-21-2928084608-851073606-3971736007-1617

The remediation for Certified is to automatically add this value to a new Object Identifier (OID) added to an authentication certificate. This is done by pulling the attribute and loading it onto Axiad Conductor’s internal database so that each certificate issued to this user will have it added.

OID - 1.3.6.1.4.1.311.25.2

In the resulting certificate, it will be displayed as such:

Map Certificate to altSecurityIdentities Attribute

If it is not possible to issue a new compliant certificate before the deadline to the user, then the alternative is to modify the user object in AD by adding certificate information (issuer and serial number) to the altSecurityIdentities attribute.

The information must be specifically formatted:

• Issuer: CN=KoMPrivateIssuingUsersCA,DC=hills,DC=lab

• Serial number: 3d0000000000a3

Result should be formatted as such: "X509:<I>DC=lab,DC=hills,CN=KoMPrivateIssuingUsersCA<SR>A300000000003D"

Reference

Get more information from Microsoft here, under Manually Map Certificates

Then import it into the user attribute via PowerShell script:

PS C:\Users\Administrator> Get-ADUser -Identity "acalliet" -Properties "AltSecurityIdentities"

AltSecurityIdentities : {X509:<I>DC=lab,DC=hills,CN=KoMPrivateIssuingUsersCA<SR>3d0000000000a3}
DistinguishedName     : CN=Agathe Calliet,OU=MFA,DC=hills,DC=lab
Enabled               : True
GivenName             : Agathe
Name                  : Agathe Calliet
ObjectClass           : user
ObjectGUID            : 3e36b6ce-2c75-4fe3-8779-a38475b2cd00
SamAccountName        : acalliet
SID                   : S-1-5-21-2928084608-851073606-3971736007-1617
Surname               : Calliet
UserPrincipalName     : acalliet@hills.lab

Certificate-based Authentication Outcome

As mentioned above, the mitigation revolves around two parameters we can play with:

• objectSid being pushed to Axiad Conductor via LDAP or SCIM (or not)

• altSecurityIdentities being updated for the user with the correct and formatted information (or not)

Each one is either activated or not, which means there are four (4) possible scenarios to study:

1. ObjectSid not pushed and altSecurityIdentities not updated,

2. ObjectSid not pushed and altSecurityIdentities updated,

3. ObjectSid pushed and altSecurityIdentities not updated,

4. ObjectSid pushed and altSecurityIdentities updated.

An end-user authenticating to Windows will face three possible outcomes. The first one is a failure to authenticate whereas the other two are either a success with warning or a full success. See below for more details on that:

Let’s go through the possible scenarios and see how successful the user is depending on the timeline and the enforcement level (DC).

ObjectSid Not Pushed and altSecurityIdentities Not Updated

ObjectSid Not Pushed and altSecurityIdentities Updated

ObjectSid Pushed and altSecurityIdentities Not Updated

ObjectSid Pushed and altSecurityIdentities Updated