AD Tiering – Design and Conception of CAs and Templates

[mstraessner]

This project enables me to further develop PKIs in the area of security and to make vulnerabilities in existing environments visible.

Several years ago, I configured enrollment for duplicated certificate templates based on group permissions. With increasing security requirements and the introduction of AD Tiering, Locksmith now frequently reports ESC1, ESC4, ESC5, and ESC7.

So far, I haven’t found a clear answer regarding the correct implementation of AD Tiering – particularly with respect to permissions for Public Key Services, computer objects, and rights within the Certification Authority. It also remains unclear whether, and why, the use of AD security groups in certificate templates for enrollment is considered a bad practice or critical.
My goal is to process and remediate the Locksmith output in a consistent and transparent way.

Open questions:

What does a correct AD Tiering configuration look like with regard to ESC5 and ESC7?

Why should AD security groups not be used for enrollment in certificate templates?

[jakehildreth]

Hi Mathias! Locksmith has no understanding of tiering and will trigger on any principals outside of the following:

RID	Group
-512	Domain Admins group
-519	Enterprise Admins group
-544	Administrators group
-18	SYSTEM
-517	Cert Publishers
-500	Built-in Administrator
-516	Domain Controllers
-521	Read-Only Domain Controllers
-9	Enterprise Domain Controllers
-498	Enterprise Read-Only Domain Controllers
-526	Key Admins
-527	Enterprise Key Admins
S-1-5-10	SELF

What does a correct AD Tiering configuration look like with regard to ESC5 and ESC7?

If you have created specific groups (and user accounts) to manage your AD CS environment and you protect those groups (and their members) with the same level of security as your Tier 0 admins, you're doing it right!

Why should AD security groups not be used for enrollment in certificate templates?

When Locksmith determines risk, it assumes the groups in use are not properly tiered. Groups (usually) contain more principals as members. More principals = more risk. Make sense?

If you'd like additional assistance interpreting your results, run Locksmith in Mode 3 and send your results to jake@dotdot.horse. I'm happy to take a look.

BTW: Locksmith 2 will allow you to enter the name of your PKI admin groups and consider those safe.

[mstraessner]

Hello Jake,

thank you for your quick response and the detailed answers.

When Locksmith determines risk, it assumes the groups in use are not properly tiered. Groups (usually) contain more principals as members. More principals = more risk. Make sense?

Sure, but many of my customers have a large number of systems that require, for example, web server certificates. Adding every computer account directly to a template quickly becomes unmanageable, and I haven’t yet found a good solution. At the moment, I’m reading about and testing the TameMyCerts project by Uwe Gradenegger to minimize this risk.

If you'd like additional assistance interpreting your results, run Locksmith in Mode 3 and send your results to jake@dotdot.horse. I'm happy to take a look.

I’ll send you the output after configuring PKI AD Tiering in my test lab so we can discuss possible improvements.

Good to know about Locksmith 2 – I’ll test that as well.

Best regards,
Mathias

[jakehildreth]

Sure, but many of my customers have a large number of systems that require, for example, web server certificates. Adding every computer account directly to a template quickly becomes unmanageable, and I haven’t yet found a good solution. At the moment, I’m reading about and testing the TameMyCerts project by Uwe Gradenegger to minimize this risk.

TameMyCerts is a perfect solution for this case. I've begun suggesting it for pretty much every AD CS deployment. @Sleepw4lker can you comment?

[Sleepw4lker]

With TameMyCerts, you can exactly define which fields in certificates are allowed to get requested and issued, and you can define the allowed content of the fields with regular expressions and CIDR masks.
Everything that is not explicitly allowed is automatically getting denied. Means when you define a policy for a web server certificate (usually commonName and maybe other fields in the DN, and a dNSName in the SAN), no one will be able to request a userPrincipalName in such a certificate.
Of course the circle of allowed entities still remains the one that is defined in the template's ACL, but still, attack surface is reduces by 99%.