Preview of SAN URI for Certificate Strong Mapping for KB5014754
Published Apr 06 2023 08:33 PM 25.6K Views

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 certificate mapping in Active Directory.


Preview of SAN URI for Certificate Strong Mapping for KB5014754 

KB5014754, released in May 2022, introduced changes to Active Directory Kerberos Key Distribution (KDC) behavior on Windows Server 2008 and later when validating certificates during certificate-based authentication. 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 Windows Server 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:<value> 

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 <value> 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 Domain Controller 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 Storage 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 Storage Provider" 

; ProviderType=1 

; ProviderType setting NOT NEEDED for Key Storage 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:<value>" 

; list of options for SAN can be found here: 

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

Copper Contributor

As always... Great write-up Ryan!


This does simplify the KDC side of issue for strong mapping.


Wondering if this certificate request option works only with the "Supply in the request" option in the certificate template or can be set to be auto-populated with the option "Build from Active Directory". 

I understand that the former would be ideal for the devices requesting certificates via SCEP/MDM, however, for users and machines leveraging auto-enrollment, the latter would be a suitable option.


This issuance of certificates with the SID still remains a big task for the PKI admins.

Is there something also in pipeline to introduce new certificate template options to cater this requirement?

Somewhat like adding an additional item in the SAN list as in below screenshot, may be an item called SID that auto-populates from objectsid attribute of the requesting user?






Hi :)

If you're using "Build from this Active Directory information" (online template) option, it will get the SID and put it on the field (OID), this is the strong mapping. No need to add,2022-09-14:sid:<value> 


This alternative, described in the article, is for offline templates (Supply in the request option is selected), since there was no method to add that OID with user's SID value in the past. So if you're using Online templates, no need to worry about this new SAN because CA will populate SID automatically under OID


Regards :)


Copper Contributor

Great to see some progress on this, as someone with a lot of clients utilising SCEP - it eases some of the associated anxiety. 


Do you guys have an ETA as to when this will go into production? I’m mindful that the full enforcement is coming in November ‘23.


Also, in terms of deployment - will there be guidance on the best way to deploy for those with SCEP NDES environments?

The only way I can see currently is setting the renewal threshold insanely high (99%) on the Intune certificate policy to force the client to request and pick up a new certificate. 


As certificates are leveraged for quite a few things, it would be great to get some clarification.




Copper Contributor

Awesome to see work on this! I second Chrispyyy's comment as we are also using SCEP for deploying user certificates used by Windows Hello for Business Certificate Trust on our AADJ Intune managed devices and are cognizant of the November 2023 deadline for full enforcement as it will either involve us implementing the above solution and/or migrating users to Cloud Trust prior to this deadline.


I see you've mentioned this is in preview under Windows Server Preview Build 25246 and later, is this likely to be backported and released to in-support Windows Server versions once it goes GA via a Quality Update or would we need to upgrade our KDCs to Server 2022 to have this functionality?


Thanks, Tyler

Copper Contributor

I will implement this in the next release of the (freely available) TameMyCerts policy module for AD CS ( to properly support this new mapping type for "offline" ("supply in the certificate request") certificate templates on the server-side (the module can re-map requested certificate content to the corresponding AD object).

The current version already supports building the proprietary SID certificate extension introduced with the May 2022 update. It is also already capable of restricting offline certificate requests for the uniformResourceIdentifier SAN extension type.

Copper Contributor

Just if anyone is interested: I've developed a custom AD CS "SID Policy Module" that adds support for new proprietary extension in offline templates. That is, if request comes from trusted requester (e.g. Intune/NDES service account) and includes target identity information (via UPN or SAN DNS), the module will automatically include new SID extension in issued certificate. This change doesn't require any changes from Intune/NDES side. You have a great level of control on when SID value is passed to issued certificate.


Since subject names are not validated in offline requests, default approach opens a door for account spoofing via unvalidated offline requests. To protect CA, SID Policy Module provides functionality to handle cases when incoming request contains potentially spoofed SID information and sent from untrusted source. This includes original Microsoft proprietary extension and new SAN URL option. You can explore and try my policy module (open-source and free for use) in GitHub: PKISolutions/ADCS-SID-Extension-Policy-Module (

Iron Contributor

first, why the heck are people still using SCEP with Intune? surely thats just for the manky third party services obsessed with sticking with the 20th century that can't do PFX requests?

secondly, to echo the important part - when can we expect this so that Intune connector can issue strong mapping compatible certs for users and devices through PFX/PKCS?

Copper Contributor

Hi geulate,

we found one important thing in our ADCS environment. Certificate created from offline template(supply in the Request) also showing newly introduced OID attribute and user/account's SID is incorporated in the certificate. How this is possible or I am missing something. 

Note: in the M/S article , it was mentioned that "Enterprise Certificate Authorities (CA) will start adding a new non-critical extension with Object Identifier (OID) ( by default in all the certificates issued against online templates after you install the May 10, 2022 Windows update. "



or this statement is not relevant at all. OID attribute has been incorporated with all type certificate templates in ADCS.  Also one doubt is  whether this KB article/ vulnerability is true for those certificates which has been issued from any third party CA for any organization where there is no link to get user/computer SID info to the third party CA for that requested user/computer account. 

Please help us to clarify the points.


anyone can answer on my questions/doubts. 


Copper Contributor

In a scenario where a single user certificate is used across multiple domains, can a certificate be issued with multiple SAN URI entries? How is this handled by the KDC if so? Will it succeed authentication if at least one SAN:URI SID entry matches the user/device SID?


Here is an example of what I mean by multiple SAN URI entries.






Brass Contributor

Hi @Ryan Ries 


We too use SCEP and AD CS to deploy certificates to Intune managed devices with a certificate template that has Supply in the request selected.


Is it intended that we manually create the strong mapping or is it planned that a future update / release will see the mapping created automatically when the certificate is issued?


We are seeing certificate authentication warnings as per the KB, which will become errors once full enforcement mode is enabled.


Any guidance or information you can provide would be much appreciated.



Copper Contributor

This SAN tag solution looks like a great, simple fix for third-party certificate products, like ours. Thank you for doing this!  However...


Is support for the URL,... going to be backported to Windows Server 2012 and later? Your post says this tag is supported by AD KDC run Windows Server Preview Build 25246 and later. Most of our customers need a solution to the KB that 1) happens long before the Feb 2025 deadline in the KB, and 2) doesn't require them to upgrade all there AD servers to some unreleased version of Windows Server.






Copper Contributor

Anyone heard anything regarding the Intune Certificate Connector supporting this?



Copper Contributor

You can add SID extension or URI to Intune certificates and thus use strong mapping by using a policy module on the CA:


Documentation here:

Copper Contributor

@UweGradenegger ,

Unfortunately our regulatory body won't allow us to use your policy module. :cry:
That is why I'm hoping MS comes up with a native solution.



Iron Contributor

Is anything more known?



Copper Contributor

Had anybody solved the problem with GC replication latency and certificate autoenrollment in combination with the new SAN extenstion?
Consider the following scenario:
a) you have a complex AD forest structure with multiple subdomains and GCs located in all domains.

b) your Enterprise CA is located in the root domain, so it uses GCs from this domain to get information needed for certificated issuance.
c) you have configured certificate autoenrollment via GPO (or other method) for your domain joined workstations
d) you install your workstations (joined into several subdomains of your forest) with a temporary name and rename them in a final deployment step

The reboot after renaming the computer triggers a new certificate auto-enrollent request. 
If this is a new workstation name, the CA will issue a cert once it can resolve the computer via it's GC queries. Here you have only a certain delay until you receive a valid and matching cert on your workstation.
If the computer name was already in use previously the old computer object in AD must be deleted before your can rename the computer to it's final name.
If you delete the object in the subdomain and rename the computer just a few seconds later (which is very likely in automated deployments), the new cert requests will be successful immediately  - BUT - the cert will have a SID from the previous computer object in its SAN attribute, because the new AD information is not yet replicated back to the GCs in the root domain!
Now you have an only "partly valid" cert on your workstation!

Once you force stronger cert validation methods your device account will no longer be validated successfully!

e.g. during 802.1x certificate based authentication the device will no longer be authenticated and network access is denied!


Version history
Last update:
‎May 16 2023 12:46 PM
Updated by: