---
title: "Mitigation for CBA before Full Enforcement Mode is Enabled (KB5014754)"
slug: "mitigation-cba-before-full-enforcement-mode"
updated: 2025-04-03T18:52:39Z
published: 2025-04-03T18:52:39Z
canonical: "docs.axiad.com/mitigation-cba-before-full-enforcement-mode"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.axiad.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/v1/docs/info-ms-kb-5014754)), 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:

![](https://cdn.document360.io/eaa8d9cb-3eef-4690-8447-5bcaa4f4afb2/Images/Documentation/image-1743541991618.png)

### 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"`

> [!TIP]
> Reference
> 
> Get more information from Microsoft [here](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16), under **Manually Map Certificates**

Then import it into the user attribute via PowerShell script:

```powershell
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:

![](https://cdn.document360.io/eaa8d9cb-3eef-4690-8447-5bcaa4f4afb2/Images/Documentation/image(21).png)

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

![](https://cdn.document360.io/eaa8d9cb-3eef-4690-8447-5bcaa4f4afb2/Images/Documentation/image(16).png)

### ObjectSid Not Pushed and altSecurityIdentities Updated

![](https://cdn.document360.io/eaa8d9cb-3eef-4690-8447-5bcaa4f4afb2/Images/Documentation/image(17).png)

### ObjectSid Pushed and altSecurityIdentities Not Updated

![](https://cdn.document360.io/eaa8d9cb-3eef-4690-8447-5bcaa4f4afb2/Images/Documentation/image(18).png)

![](https://cdn.document360.io/eaa8d9cb-3eef-4690-8447-5bcaa4f4afb2/Images/Documentation/image(20).png)

### ObjectSid Pushed and altSecurityIdentities Updated

![](https://cdn.document360.io/eaa8d9cb-3eef-4690-8447-5bcaa4f4afb2/Images/Documentation/image(19).png)