The need for certificates it’s expending beyond our domain joined Windows computers to those that are running in a Workgroup environment also. As you probably know, deploying and configuring certificates to computers that are part of an Active Directory domain its easy since we can make use of the auto-enrollment feature. The problem arises when those domain joined computers leave the premises and certificates need to be (re)issued or when you want your Workgroup Windows machines to benefit the same treatment like those part of the domain.
To overcome this barrier, starting with Windows Server 2008 R2, Microsoft developed a new certificate enrollment protocol based on WS-Trust which brought two new Certificate Authority role services with it:
- Certificate Enrollment Policy Web Service (CEP – the policy service)
- Certificate Enrollment Web Service (CES – the enrollment service)
Compared to the Certificate Web Enrollment where we have a portal so users can request a new certificate for their needs, CEP and CES services are focused on automated requests and provisioning using the built-in certificate management client.
These two new role services have the advantage of working over the HTTPS protocol, making the enrollment secure and not needing more than one port opened in the firewall from the outside world. On the inside network however, the policy service (CEP) requires the standard LDAP ports 389 and 636 and Kerberos 464 and 440 for communicating with Active Directory/domain controllers. The enrollment service (CES) in order to communicate with our internal Certification Authority service needs a range of ports opened since it is using DCOM. This one applies only if we deploy CES on a separate server than our Certification Authority one.
Before moving forward, an Enterprise Issuing CA needs to already be running in the environment, even if it is a multi tier PKI or a just a single Issuing CA. What it’s important, is the issuing CA which needs to be an Enterprise one, meaning being part of an Active Directory domain. It cannot be a stand-alone CA.
The CES and CEP role services can each be deployed on separate servers, on the same server, or on the Certificate Authority server. Here, it all depends on how large is the environment and how many resources does the company has since every deployed Windows server needs a license. So for small businesses, deploying the two roles services on the CA server will fit better in terms of costs. For this article however, we are going to deploy the two CA role services on the same box separate from our Enterprise Issuing CA server. By going with this type of deployment, a service account it’s recommended to be used for the CES service, so let’s create one.
1. Creating and configuring a Service Account for CES
As you will see later on, during the Enrollment Web Service configuration wizard we will have the option to use a service account for CES or use the built-in IIS application pool as the authentication mechanism. This decision needs to be taken into account if CEP and CES are running on the same machine, or if CES is deployed on a separate machine than the Enterprise CA server or if Kerberos is used as the authentication protocol, or if we are using multiple authentication methods. Either way, having a service account for the Enrollment Web Service it is the recommended way to go and we have a few stuff to do in order to configure it.
First, we have to create a user account in our Active Directory (AD) database which we are going to use as a service account during the CES configuration wizard. Creating the account can be accomplished very easily with the Active Directory Users and Computers (ADUC) console or with PowerShell.
Once we have the service account created, we need to set up a Service Principal Name (SPN) for it. This is only needed if the Certificate Enrollment Web Service is configured for Kerberos authentication or if it is deployed on a different computer than the Certificate Authority role service -like in our case-.
To set up the SNP for our service account, all we need to do is use the bellow command line by replacing the <server FQDN> with the name of your machine where CEP and CES are going to be deployed later on.
setspn -s http:/<server FQDN> <domain name><account name>
The third thing that we need to do on the service account is to configure it for constrained delegation. And again, this operation is only needed if the Certificate Enrollment Web Service is installed on a different computer than the Certification Authority one, and if new certificates are to be issued by the Certificate Enrollment Web Service.
Sign in to one of the domain controllers and open the properties of the service account we just created. On the Delegation tab select Trust this user for delegation to specified services only. Once we select this option, another two sub-options will be available to us. If you are going to configure CES for Kerberos authentication then select Use Kerberos only, but since we are going with the Username and Password authentication type for this article, select Use any authentication protocol then hit the Add button.
In the Add Services window that opens up, click Users and Computers and search for the Enterprise Issuing Certification Authority server. Click OK when done.
A list of the available services running on the CA server will be displayed, but from the entire list we only need two of them. Select from the list HOST and rpcss services then click OK.
The two services should now be present in the Delegation section of our service account. Save the changes by clicking OK.
If CES is deployed on a separate server than the CA one -like in this lab-, the service account needs to be added to the local IIS_IUSRS local group on that server. To do this, just open Computer Management, expand Local Users and Groups and in the Groups folder we can find the group that we need. Double click IIS_IUSRS and hit the Add button.
Search for the service account we just created and add it to the list. Click OK when done.
2. Deploying CEP and CES
2.1. Installing CEP and CES
As I have mentioned at the begging of the article, CEP and CES can be deployed separately, on the same server or on the CA server. In this example however we will be installing them together but on a different server than the CA one. For this to work correctly, we need section one of this article to be completed or we will get the bellow error message during the two roles services configuration. If you don’t have a Certification Authority present in your environment and starting from scratch, make sure you first install and configure the CA, then come back and read further on how to install and configure CEP and CES.
The account is not a member of the local machine’s IIS_IUSRS group. The specified user account is not a member of the specified group account. 0x80070529 (WIN32: 1321 ERROR_MEMBER_NOT_IN_GROUP)
Now that we have all the prerequisite in order, let’s log in on the server where we want the two role services installed and fire up the Add Roles and Features Wizard. Once we reach the Server Roles page of the wizard, tick the box next to Active Directory Certificate Services then click Next.
In the Role Services screen tick Certificate Enrollment Policy Web Service and Certificate Enrollment Web Services boxes. By default the Certification Authority role service will be enable which is not good in this case since we already have a CA server in the environment. Remove the selection from this box then continue the wizard.
In the Confirmation screen just hit Install to begin the CA role services installation.
The process will not take long, and once it is done we get the option to launch the AD CS Configuration wizard for the two role services that we just installed by clicking the Configure Active Directory Certificate Services on the destination server link.
2.2. Configuring CEP and CES
In the first screen of the AD CS Configuration wizard we need to put in the account used by the wizard to set up the two CA role services. The account needs to be part of the Enterprise Admins group in order for everything to succeed.
Select the two CA role services that we want the wizard to configure then click Next.
Here we need to select our Enterprise Issuing CA by clicking the Select button. Once this is done we can continue the wizard.
This is where we select the authentication type for CES. Since our clients are in a Workgroup environment and have no computer object created in Active Directory, the only way to make it work is by going with the User name and password option. If you have domain joined clients that go off the internal network, then the other two options will work better, but that’s another story for another time.
On the next screen of the wizard we need to provide the service account we created and configured in the first section of the article. We can simplify things and go with the second option Use the built-in application pool identity, but it is recommended to use a service account since it provides better security.
In the Authentication type for CEP screen we need to select the type of authentication we want to use for the policy service. Like in the CES example, select User name and password then continue the wizard.
Key-based renewal its a CEP’s feature introduced starting with Windows Server 2012 which allows certificates to be auto-renew with the same key or a different one -depending on how the certificate templates are configured-. Since our Workgroup clients don’t even have a certificate right now, there is nothing to renew, so we will skip this for now. If you want more information about key-based renewal, you can read it right here.
This is the part of the wizard where we can specify the security certificate to encrypt the connection between CES/CEP and clients. If no certificate is present on the machine, select the second option to skip this and install a certificate later on as shown in the next section.
In the Confirmation screen, all we have to do after reviewing the configurations is to click the Configure button.
Setting up the two CA role services will take just a few seconds, and if everything was successful we will get those nice green check boxes.
2.3. Issuing and installing the security certificate for CEP and CES
If no certificate was installed for CEP and CES during the AD CS Configuration wizard, we will have to do it afterwards. This way the connection between the services and the clients will get encrypted and validated. Plus, if no certificate is installed, clients will not even be able to access the enrollment service.
On the same server where we deployed CEP and CES, open the Internet Information Services (IIS) Manager, select the server name then double-click Server Certificates.
From the Actions pane, click the Create Domain Certificate link in order to open the Create Certificate wizard.
Complete the fields with the information that suits your company then issues the certificate. In the Common name field we need to provide an external FQDN so that our Workgroup clients can reach the CA services trough the internet, if the services are published beyond our internal network.
Once we have the certificate issued, expand the Sites folder and click the Default Web Site. From the Action pane click Bindings.
Select the second binding in the list –https– then hit Edit.
From the SSL certificate drop-down box select the security certificate we just issued and installed in the system. Click OK then Close.
2.4. Verifying the SSL requirement for CEP and CES virtual directories
Now that we have installed the certificate on our Default Web Site, the next thing in further securing the communication between clients and the service is to always require SSL for the connection. By default this is usually enabled, but it does not hurt to verify it.
Still in the IIS Manager, click on the first virtual directory then double click SSL Settings in the Features View.
We need to make sure Require SSL is enabled. If not, tick the box and hit Apply.
Moving on the second virtual directory, the Require SSL setting needs to be the same, enabled.
2.5. Configuring the CEP friendly name
The last configuration we need to do in IIS is to provide a friendly name for our policy service, or we will get the bellow message during the clients enrollment configuration. Also, without a friendly name configured, clients will see an ID instead of a nice self-explanatory name when they request a new certificate.
“https://<FQDN>/ADPolicyProvider_CEP_UsernamePassword/service.svc/CEP” was validated succesfully but there was no friendly name returned by the remote machine.
Select the CEP virtual directory –ADPolicyProvider_CEP_UsernamePassword– then double-click Application Settings. Here we can see in the Name column a FriendlyName entry. Right-click it and choose Edit.
In the Value filed, provide a name that identifies your organization. This name will be displayed to users in the Enrollment Policy -shown in the client configuration section-.
2.6. Configure Enrollment Servers URI
By default, the Uniform Resource Identifier (URI) is set by the installation wizard to the name of the server where CES it’s installed. This is not a bad thing for internal computers, but since we are publishing this service for outside users also, the URI needs to mach the Common Name in the certificate which is a public one. This is so the enrollment server can send the proper address to the client computer to which it will send the enrollment request.
To fix the URI with the proper one, we need to open ADSIEdit console on one of our domain controllers and connect to the Configuration Naming Context.
Once the console is loaded, expand Configuration <domain name> > CN=Services > CN=Public Key Services > CN=Enrollment Services then right-click the CA name from the right hand pane and choose Properties.
Scroll down the list until you find the msPKI-Enrollment-Servers attribute. Select it then click the Edit button.
As you can see, inside the attribute is the URI for the enrollment and in the first part of the URI is the server name where we deployed our two CA role services. In order for our external users to be able to enroll, we need to edit this with our external FQDN.
Click Remove so the entire URI will be positioned in the edit field then replace the server name with the Common Name that you put in the certificate –see section 2.3.-. Once done, click Add then OK twice.
3. Configuring client computers
3.1. Importing the Root CA certificate
For the Workgroup client computers to be able to enroll without any issues, we need to find a way to install the Root CA certificate(s) into the computer Trusted Root Store or they will get the bellow error message during the enrollment configuration. As you can probably guess, this happens because the client computer cannot built the certificate trust since it is missing the Root CA certificate. In case of multi-level CAs, the same rule applies, and if one of the Root certificates is missing from the trust chain, the Enrollment Policy Server configuration will trow the same error message.
An error occurred while obtaining certificate enrollment policy. Url: https://<FQDN>/ADPolicyProvider_CEP_UsernamePassword/service.svc/CEP
Error: The certificate authority is invalid or incorrect 0x80072f0d (WinHttp: 12045 ERROR_WINHTTP_SECURE_INVALID_CA)
The easiest way to install a certificate into a client certificate store is by using the certutil command or PowerShell then move the client out on the internet. If you have clients already out of the internal network, then you need to send them a package that contains the Root CA certificate and the script for the import.
certutil -addstore Root <path to Root CA certificate>
After running the command line, the Root CA certificate should be present in the Trusted Root Certification Authorities store on the client computer.
3.2. Configuring Enrollment Polices
Configuring the Enrollment Policies on the client side is done in the certificates store, and to access it just type certlm.msc in a Run command. Once the console opens right-click Personal > All Tasks > Advanced Operations > Manage Enrollment Policies.
In the Manage Enrollment Policies window that pops-up click the Add button to start configuring the enrollment settings.
And here is the part where we tell our clients where to connect in order to get a certificate. In the URI field, type the address in the bellow format by replacing the FQDN with your own then select Username/password from the Authentication type drop-down box. Click Validate Server.
The FQDN in the URI needs to match the Common Name or SAN name in the certificate we issued and installed in IIS in section 2.3.
https:// <Internet FQDN> /ADPolicyProvider_CEP_UsernamePassword/service.svc/CEP
As a tip, instead of memorizing the entire URI, all we have to do is log in on the CES/CEP server, open the IIS console then click the CEP virtual directory. From the right-hand side double click Application Settings. And here we can see the URI, but take note that it is with the internal FQDN.
Once the validation was initiated, an authentication window will pop-up to provide the credentials of a domain user account.
The validation process will take just a few seconds and if everything connects and gets validated, we will have a successful message in the Certificate enrollment policy properties box.
Click OK on the Manage Enrollment Policies window to save the configuration but do not close the certificates store console yet because we need it for the next section.
Follow the same procedures in this section to configure the Enrollment Policy server for the user personal store (certmgr.msc) if you need to enroll for user certificates.
3.3. Requesting certificates from the Workgroup computers
And finally we are at the stage of requesting our first certificate from a Workgroup client over the internet. Just as note here, is that port 443 needs to be opened and forwarded in the firewall to our enrollment server in order for internet clients to be able to reach it.
Once everything is in place, right-click the Personal folder from the certificates store console and choose All Tasks > Request New Certificate.
In the first screen of the Certificate Enrollment wizard we can see the friendly name we set up earlier for the CEP service.
On the next screen we get the certificate templates that the user has access to on our internal CA. This is the cached username that we provided during the Certificate enrollment policy server configuration.
By clicking the Enroll button of the wizard we are prompted to authenticate again. One option will be to remember the credentials, but every now and then we will be asked again to re-authenticate.
And as expected, the certificate is issued over the internet to our Workgroup client.
4. Tips and troubleshooting
4.1. Importing enrollment policies configurations on clients
As you can probably figure it out by now, manually configuring Workgroup clients is not going to be any fun in the long run. It is a repetitive task and takes a lot of remote sessions. Creating and sending a document to users will reduce the workload, but sometimes the users get unknown messages and they will still call you. The easiest and faster way is for the admin to export the enrollment policy from an already configured client and send the file to the user who will make this work with a double-click.
Log in on an already configured client, open the registry editor (regedit.exe) and expand HKEY_LOCAL_MACHINE > Software > Microsoft > Cryptography > PolicyServers > <GUID>. Right-click the GUID and choose export. Save the .reg file and send it to your remote users for importing the enrollment configuration.
4.2. Clear the client cache
By default, there is an eight hours client cache interval and if we publish a new certificate template in this interval, clients will not see it. The same applies if we do some changes on the existing certificate templates. In order for the clients to see the updated version of our certificate templates, we need to clear this cache, and we do this using the command line.
certutil -f -policyserver * -policycache delete
Now on the CES/CEP server restart the IIS service.
I don’t know about you, but this is a nice feature to have in the company for those non-domain joined computers. Now if a certificate needs to be renew, the user will be asked to authenticate to the CEP service and the rest happens behind the scene. No more sending a new certificate and installing it on the client(s) because the old one expired. I really encourage you to test it and let me know in the comments area your opinion.
Want content like this delivered right to your