{"id":1108,"date":"2024-11-18T19:34:57","date_gmt":"2024-11-18T18:34:57","guid":{"rendered":"https:\/\/blog.chrisse.se\/?p=1108"},"modified":"2024-12-03T22:06:17","modified_gmt":"2024-12-03T21:06:17","slug":"when-your-enterprise-pki-becomes-one-of-your-enemies-part-1","status":"publish","type":"post","link":"https:\/\/blog.chrisse.se\/?p=1108","title":{"rendered":"When your Enterprise PKI becomes one of your enemies (Part 1)"},"content":{"rendered":"\n

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.
<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n


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)<\/p>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

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

\"\"<\/figure>\n\n\n\n

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<\/sup><\/sub>)<\/p>\n\n\n\n

Active Directory<\/strong>
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<\/strong>
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.<\/p>\n\n\n\n

Group Policy Autoenrollment Client Side Extension (CSE)<\/strong>
Supposed to cache the content from AD to the Registry on each domain joined machine within the forest (Including DCs).<\/p>\n\n\n\n

So who is validating that the CA is trusted in NTAuth?<\/p>\n\n\n\n