Blog Post

Ask the Directory Services Team

5 MIN READ

Preview of SAN URI for Certificate Strong Mapping for KB5014754

Microsoft

Apr 07, 2023

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:

URL=tag:microsoft.com,2022-09-14:sid:<value>

In this SAN URI, “microsoft.com” 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:

[Version]

Signature=$Windows NT$

[NewRequest]

; list of Keys / Values can be found here: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1#newrequest

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="

[Strings]

szOID_SUBJECT_ALT_NAME = 2.5.29.17

szOID_ENHANCED_KEY_USAGE = 2.5.29.37

szOID_PKIX_KP_SERVER_AUTH = 1.3.6.1.5.5.7.3.1

szOID_PKIX_KP_CLIENT_AUTH = 1.3.6.1.5.5.7.3.2

szOID_KP_SMARTCARD_LOGON = 1.3.6.1.4.1.311.20.2.2

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

KeyUsage= "CERT_DIGITAL_SIGNATURE_KEY_USAGE | CERT_NON_REPUDIATION_KEY_USAGE | CERT_KEY_ENCIPHERMENT_KEY_USAGE"

; CERT_DIGITAL_SIGNATURE_KEY_USAGE -- 80 (128)

; CERT_NON_REPUDIATION_KEY_USAGE -- 40 (64)

; CERT_KEY_ENCIPHERMENT_KEY_USAGE -- 20 (32)

; CERT_DATA_ENCIPHERMENT_KEY_USAGE -- 10 (16)

; CERT_KEY_AGREEMENT_KEY_USAGE -- 8

; CERT_ENCIPHER_ONLY_KEY_USAGE -- 1

; CERT_DECIPHER_ONLY_KEY_USAGE -- 8000 (32768)

;

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

;

Exportable=false

; 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.

MachineKeySet=false

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

; false - Means the certificate is for the User.

HashAlgorithm=Sha256

;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.

RequestType=CMC

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

[Extensions]

; list of Extensions can be found here: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1#extensions

%szOID_ENHANCED_KEY_USAGE%="{text}%szOID_KP_SMARTCARD_LOGON%,

_continue_ = %szOID_PKIX_KP_CLIENT_AUTH%"

%szOID_SUBJECT_ALT_NAME% = "{text}UPN=user@contoso.com&

_continue_ = EMail=user@contoso.com&

_continue_ = URL=tag:microsoft.com,2022-09-14:sid:<value>"

; list of options for SAN can be found here: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1#extensions

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

Updated May 16, 2023

Version 2.0

RyanRiesMSFT

Microsoft

Joined April 16, 2018

View Profile

Ask the Directory Services Team

Follow this blog board to get notified when there's new activity

32 Comments

skykam87
Copper Contributor
Sep 14, 2023
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.

Thanks,
TJ
debbasu
Copper Contributor
Jun 29, 2023
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 https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_kdcregkey&articleFooterSupportBridge=communityBridge , it was mentioned that "https://social.technet.microsoft.com/wiki/contents/articles/53249.active-directory-certificate-services-enterprise-ca-architecture.aspx (CA) will start adding a new non-critical extension with Object Identifier (OID) (1.3.6.1.4.1.311.25.2) 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.
Peter Holland
Iron Contributor
Apr 20, 2023
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?
- AndrewMcN_SFRS
  Brass Contributor
  Feb 24, 2025
  Don't know if you've found out or not by now... You have to use SCEP if you want your certificate to be hardware bound, i.e. generated by a device's TPM and optionally with Key Attestation. I'm afraid this is the 21st century way of doing things but Microsoft hasn't done a great job in setting us up for this by default. Most people have to completely replace all issuer certs to achieve Key Attestation.
  PKCS is technically a poor option because the private key will be generated by the Intune Certificate Connector server, not the device, and then transmitted through the air to the target device. Security best practice would say this is not a great thing to do. You are reliant on the transmission encryption not being broken before such a certificate expires. With SCEP, the private key is generated on the device and is never transmitted beyond it. Intune Certificate Connector secures the NDES service using a policy module.
  For ultimate security, your device certificates should be generated by the TPM and then Key Attested. A good security solution would validate the key attestation, e.g. Cisco ISE does this.
  Microsoft binds PRT's to the TPM and I think more and more things are beginning to take advantage of this now that more and more hacks are happening against tokens and such like that are not hardware bound.
Crypt32
Copper Contributor
Apr 17, 2023
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: https://github.com/PKISolutions/ADCS-SID-Extension-Policy-Module
UweGradenegger
Copper Contributor
Apr 12, 2023
I will implement this in the next release of the (freely available) TameMyCerts policy module for AD CS (https://github.com/Sleepw4lker/TameMyCerts) 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.
itstylerreilly
Brass Contributor
Apr 11, 2023
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
Chrispyyy
Copper Contributor
Apr 11, 2023
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.

Thanks,
Chris
geulate
Microsoft
Apr 11, 2023
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 1.3.6.1.4.1.311.25.2 (OID), this is the strong mapping. No need to add URL=tag:microsoft.com,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 1.3.6.1.4.1.311.25.2.

Regards 🙂
wiki_admin
Copper Contributor
Apr 10, 2023
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?