Setting permissions on ADCS Certificate Templates
As you probably can imagine, right after we are done installing the Enterprise Certification Authority there are still a lot of configurations to be done, and as the title says, in this article we are going to take a look at one of these configurations and that is setting up the certificate templates permissions. This is one of the many important options in a certificate template because if we set the wrong permissions, then the wrong people might get their hands on a certificate that is not met for them, and off course, a security breach happens.
The permissions are not to be set just for users, but for computers also. Imagine having auto-enroll configured for computers and you set the template with the wrong permissions. Those computers either don’t get a certificate, they get the wrong one, or they either get to many.
All of the security configurations are done in the certificate templates store which can be opened from the Certification Authority console, by right-clicking the Certificates Templates folder and choosing Manage.
Right of the bat, we are presented with a bunch of certificates that we can use for our clients, and if we open one of the templates and go to the Security tab, we can see the default permissions on that template.
Another tab that we should take a look at, besides the Security one, is the Subject Name tab. Here we can see for whom the certificate is going to be used, a computer/device or a user. As you will see later on, this is very important since we will not be able to issue a user certificate for a machine and vice-versa, even if we set the right permissions on the template. Another thing about this, is that even when we create/duplicate our own custom templates, this option will be inherited to our custom ones.
Now let’s see what those security permissions mean so we can set the proper ones when we get into some practice later on.
- Full Control permission, as the name imply, allows a user to modify the template permissions, settings and ownership. By default, this permission is given to those part of the Domain Administrators security group (Administrator, Domain Admins, Enterprise Admins).
- Read permission allows the template to be seen by the users and/or computers. By default, the Authenticated Users security group -which are all computers and all users in the domain/forest- have the read permission.
- Write permission allows a user to modify the certificate template settings.
- Enroll permission will actually let users and computers enroll for certificates. This goes hand-in-hand with the Read permission.
In order for the user/computer to be able to enroll for a certificate, first it needs the Read permission so it can actually “see” the certificate template. Most of the times the Read permission is taken care of by the Authenticated Users group (if it was not removed from the template ACL).
- Autoenroll permission is set on a template when we want our users and/or computers to automatically enroll for a certificate based on the template. This goes hand-in-hand with the Read and Enroll permissions, which means that if we want a group of users to auto-enroll for certificates, we also need to tick the Enroll box. As before, the Read permission is taken care of by the Authenticated Users group -if it was not removed-.
As a best practice, here are some of the things I thought of:
- Use security groups when setting up the permissions on templates instead of just putting individual accounts in the ACL. This gives us better control and also it’s easier when we have to enroll users/computer for certificates, because all we have to do is add them to that specific security group.
- Never give to Authenticated Users the Enroll or Autoenroll permissions. As you can imagine, every device and user in the Active Directory forest will be able to enroll and auto-enroll for certificates. This will also give us less control on who can and cannot get a certificate. If it is a requirement for all users or computers to enroll or auto-enroll, it is better to use the Domain Users and Domain Computers groups.
- As much as possible try not remove the Authenticated Users group from a template, so users and computers from the domain can read the template. This includes the Enterprise CA servers also.
1. Setting-up permissions for enrollment
Now let’s say we have a certificate template and we want only a few users to be able to get it/enroll, manually. Since it is a best practice, let’s make these users part of a security group then add the group to the certificate template ACL.
There will be certificate templates with a default permission of Enroll for the Domain Users group, which as you can imagine will allow all users in the domain/forest to enroll for a certificate using this template. If that’s the case, remove this security group and add the custom one in order to filter/strengthen the security on the template.
Once the users were added to the security group, open the Certificate Templates console, then right-click a certificate template and choose Properties. From the Security tab, hit the Add button and add the security group that we just created.
As far as permissions goes on the certificate template, as you guest it, all we have to tick is the Enroll box. This is because the Read part on the certificate template is done by the Authenticated Users group, which are all users and computers in the AD forest. So we have Read and Enroll, and this is exactly what we need in order for our users to be able to enroll for a certificate using this template.
Now let’s log in on a client computer with an account that is part of the security group we created above and open the User Certificates Store (certmgr.msc). Enrolling for a certificate should work without any issues whatsoever.
Because we are using the User Certificates Store, the authentication is done using the user account, and since the user has Read and Enroll permissions on the certificate template, he can see the template and request a certificate based on it.
On the same user session, if we open the Computer Certificates Store (certlm.msc) the certificate is not even displayed. This is to be expected since the template was constructed for user subjects. Even if we add the computer account to the certificate template ACL, we should still not be able to see it in the Computer Certificates Store. The only way to fix this is to duplicate/create a certificate template that was constructed for a computer subject.
As I’ve said at the begging of the article, we can only issue certificates to the subject that is intended for. In this case, this is a user type certificate, and only a user account can see it no matter the permissions. The same applies for a computer template when trying to enroll from the User Certificates Store. These rules also apply when we check the Autoenroll box to automatically deploy certificates using Group Policy.
2. Setting-up permissions for managing certificate templates
As in any environment that is growing, we have to delegate part of our work to different administrators and in this case, the certificate templates.
Right of the bat, if the administrator installs the Certificate Authority console on his workstation -using Remote Server Administration Tools (RSAT)– and tries to take a peak, his access will be denied, even if he has proper permissions on the certificate template.
Before he can even access the console, he needs to have Read permissions on the Certificate Services service. For that, open the Certification Authority -on the CA server-, right-click the CA name and choose Properties.
On the Security tab, add the group that contains the administrators, then on the Permissions section tick the Read box and hit OK. Now the administrators the are/will be part of this security group will be able to access the Certificate Services service console, but they will not be able do anything else.
If they try to change some of the settings in the CA or certificate templates they will be denied access when saving the changes.
In order to give them the proper rights to manage our certificate templates, right-click the Certificate Templates folder from the CA console and choose Manage.
This will open up the Certificate Templates console. From the list of templates, choose the one you want to delegate control and open its properties. On the Security tab add the group that contains your administrators which will manage this template.
I usually add the same security group that also has the Read permissions on the CA itself. This way, when adding a new user into the group it will automatically have Read on the CA and Write on the templates.
Once the security group was added to the template ACL, tick the Write box then hit OK.
Now when the administrators open the Certification Authority console on their side, they will be able to manage only the certificate templates they were give access to and nothing else.
In this article we looked at how to apply and delegate permissions on our certificate templates. This is an important part since applying the right permissions in an environment, especially on a service that handles security between clients and servers it’s no joke. This is why public CAs take this certificates security part very seriously in that you need authorizations and fingerprints devices to access part of their infrastructure.
Make sure you allow only the right people to manage this service and if you have the infrastructure or budget, dump the Certification Authority logs into a log collector for auditing.
Want content like this delivered right to your