Preview of SAN URI for Certificate Strong Mapping for KB5014754

Hello, this is Matthew Palko, senior product management lead in Enterprise & Security, and today I have some information to share about the new changes to strong mapping in Active Directory.

Preview of SAN URI for Strong Mapping for KB5014754

KB5014754, released in May 2022, introduced changes to Active Directory Kerberos Key Distribution (KDC) behavior on 2008 and later when validating certificates during -based . These changes were made to address elevation of privilege related vulnerabilities leveraging certificate spoofing.

The KDC changes require certificates for a user or computer object to be strongly mapped to Active Directory. The KB describes multiple mapping options, including manual mapping options and automatic mapping that will populate an OID extension with a device or user SID for online certificate templates from Active Directory Certificate Services (AD CS).  

We are announcing the preview of a new strong mapping format that will work with KDCs running Preview Build 25246 and later. This mapping uses the user SID and can be used for manual mapping and offline certificate requests. This new mapping is a Subject Alternative Name (SAN) tag-based URI which uses the following format:,2022-09-14:sid:

In this SAN URI, “” and “2022-09-14” are hard-coded values which should not be modified. The only value that needs to be provided when using the SAN URI is the user or device SID which will replace the field. 

Below is an example of a certificate that has been issued with this SAN URI. Under the Subject Alternative Name field, the tag is listed in the Value section populated with a user's SID. 


Existing strong mappings that are described in KB5014754 are not being modified and this new mapping is an additional option to provide more flexibility in issuing certificates that meet the strong mapping requirement.

Strong mapping is currently not enabled by default. If you are attempting to implement strong mapping using the SAN URI and want to test it is working properly, you can use the audit events described in KB5014754 to check to see if the mapping is working correctly.

Considerations for Schannel

Schannel-based servers with KB5014754 will by default attempt to map client certificates. This will require a query by the server to the to confirm the mapping. If a server is not running in a domain environment and does not need certificate mapping, mapping can be disabled by setting the SCH_CRED_NO_SYSTEM_MAPPER flag in SCH_CREDENTIALS on the server. If a server is a part of a domain environment, disabling certificate mapping for SChannel will disable protections against the escalation of privilege vulnerabilities KB5014754 is meant to address which will leave your environment at risk to those attacks.

Example Certificate INF

This is an example inf file for a smart card certificate request that includes the new SAN URI field:


Signature=$Windows NT$


; list of Keys / Values can be found here:

subject=”CN=USER DN”

; put the FQDN of the server or name of the user after CN=

; if you need a blank subject field use Subject=”CN=”







KeySpec = AT_NONE

; KeySpec can only be set to one value, and NOT Multiple values.

; If set to 1 AT_EXCHANGE, used for Exchange (Encryption/RSA). This is used with Cryptographic Service Providers (CSP).

; If set to 2 AT_SIGNATURE, used for Signature (think Diffe-Helman, but can use RSA signing too).  This is used with Cryptographic Service Providers (CSP).

; If set to 0 AT_NONE, used with Key Providers (KSP) typically.

KeyLength = 2048

; Can be 1024, 2048, 4096, 8192, or 16384, default is 1024










; NOTE: All true/false should be in all lowercase letters!



; true – means that you can export the private key.

; false – means you cannot export the private key. This is Default

; If this is being used with a Smartcard may want to set it to False.


; true – means that the cerficate is for a machine and not the logged on user.

; false – Means the certificate is for the User.


;Hash Algorithm to be used for this request (CSR).

; Sha256, sha384, sha512, sha1, md5, md4, md2

SMIME = False 

; If this parameter is set to true, an extension with the object identifier value 1.2.840.113549.1.9.15 is added to the request. 

; The number of object identifiers depends on the on the operating system version installed and CSP capability, 

; which refer to symmetric encryption algorithms that may be used by Secure Multipurpose Internet Mail Extensions (S/MIME) applications such as Outlook.

PrivateKeyArchive = false 

; true – means that the private key will be archived on the CA.

; false – Means the private key will only reside on the requesting machine.  This is Default.

; If you do archive the private key, then you MUST use a RequestType of CMC

UseExistingKeySet = false 

;  Used to specify that an existing key pair should be used in building a certificate request. 

If this key is set to true, you must also specify a value for the RenewalCert key or the KeyContainer name. 

You must not set the Exportable key because you cannot change the properties of an existing key. In this case, no key material is generated when the certificate request is built.

ProviderName=”Microsoft Software Key Provider”

; ProviderType=1

; ProviderType setting NOT NEEDED for Key Providers.

; use Certutil -csplist to get the list of Provider names with its Provider Number.


; Values are:  CMC, PKCS10, PKCS10-, PKCS7.  Default is PKCS10


; list of Extensions can be found here:


_continue_ = %szOID_PKIX_KP_CLIENT_AUTH%”

%szOID_SUBJECT_ALT_NAME% = “{text}

_continue_ =

_continue_ =,2022-09-14:sid:”

; list of options for SAN can be found here:

; should be replaced with the user's actual SID from AD


This article was originally published by Microsoft's Directory Services Team. You can find the original article here.