Actually. Before I go.
I was about to leave Suzie Q's session after the file-encryption thing. The note was on her desktop. She wasn't going to see it until Monday. Everything I came for was done.
Then I noticed something on her account.
I always take one more look before I leave a session. Habit. You never know what's sitting on someone's account that they don't even know is there. And Suzie Q's account has something interesting.
She's not a template admin. But she's in a group that is. Sort of.
A group called PKI-Delegates. Twelve members. Created three years ago. Suzie's in it because a project three years ago needed her to submit certificate requests for some application she was working on. When the project ended, the group didn't. She never asked to be removed. Nobody in your admin team ever cleaned it up. Standard.
PKI-Delegates has Write permissions on a certificate template. The User Signing one. Twelve people, one template, Write.
When the group was created three years ago, there was probably a ticket. Something like "Suzie's team needs to specify subject names in their certificate requests for the internal signing app." The admin who read that ticket saw the phrase "write to a certificate" and did what looked like the obvious thing. They granted PKI-Delegates Write on the User Signing template.
Which was the wrong Write.
There are two things called Write on a certificate template. One is the AD permission on the template object itself, the ACL that says who's allowed to modify the template's properties. The other is a template setting called Supply in the request, which lets whoever enrolls from the template specify their own subject in the CSR. They sound similar. They are not the same.
The admin thought they were letting Suzie write her subject. What they actually did was let Suzie rewrite the template.
So I open the template. From Suzie's account, because Suzie has Write. Every audit trail says PKI-Delegates modified a certificate template. Which is exactly what PKI-Delegates has permission to do. Nothing about the log looks out of place.
I add Client Authentication to the EKU list.
I enable Supply in the request for the Subject Name.
I add Authenticated Users to the Enroll permissions.
Save.
The template is now the same shape as the User template I attacked earlier tonight, except this time I made it that way instead of finding it that way. The vulnerability I needed didn't exist five minutes ago. Now it does. And in fifteen minutes I'll turn it back off, so by the time anyone reviews the template, it looks like it always did.
I enroll. Standard request. SAN=upn=Administrator@your.domain in the attributes. The template says Supply in the request is enabled, because I just enabled it. The CA signs. I have a certificate that says I'm Administrator.
PKINIT. Kerberos ticket. Domain Admin.
Six minutes. Easier this time, honestly. I didn't have to find anything. I just had to change one thing.
Hiro out.
If you're a defender, here's what just happened, from the other side of the desk.
Somewhere in your AD, a certificate template has Write permissions granted to a group that shouldn't have it. Not because someone was careless. Because someone was helpful.
Someone put in a ticket saying they needed to specify subject names in certificate requests for their application. The admin who read that ticket saw "write to templates" and granted the requesting group Write on the template's ACL. Problem solved from the admin's perspective. Ticket closed. Everyone moves on.
Except the admin solved the wrong problem. The requester didn't need to modify the template. They needed to be able to specify the subject at enrollment time. That's a template property called Supply in the request on the Subject Name tab. It's a radio button. Toggle it, save, done. No ACL changes needed.
The confusion is understandable. Both things are called some form of "write." Both sound like they'd let a user put their subject name into a certificate request. Both live in the template properties dialog. Only one of them lets the user rewrite the template itself.
What to check this week
On every certificate template published in your environment, look at the Security tab. Any account or group with Write, WriteOwner, WriteDacl, or FullControl on a template should be a very short list. Enterprise PKI admins. Nobody else.
If you find groups with Write that shouldn't have it, remove them. If you don't know why a group was granted Write, treat that as evidence someone confused the two Writes and fix it accordingly.
For every user who genuinely needed to specify subjects in their requests, the actual fix is inside the template: Properties → Subject Name → Supply in the request. That gives them what they needed. It does not give them the ability to modify the template.
There's a second thing worth doing while you're in there. For every template you touch, check whether the current template properties match the last time they were reviewed. Modifications leave traces in AD replication metadata (whenChanged, objectVersion), but if you're not looking, you won't see them. Any template that's been modified recently by anyone other than a known admin is worth a closer look.
Two doors, still
The Locked Door article was about who's allowed to enroll for a certificate. This article is about who's allowed to modify the template that decides what enrollment looks like.
Enroll access to a template is the ability to walk through a door. Write access to a template is the ability to change what the door leads to.
The Locked Door was about who has keys. This one is about who gets to change what the keys open.
Hiro is fluent in both.