As a refresher, Certificate Enrollment Policy and Certificate Enrollment Services abstracts certificate Policy and certificate Enrollment from a specific Active Directory forest allowing clients in a different forest -- or no forest -- to request and obtain certificates.
So here is a simple network diagram of what I am setting up in this blog post.
A non-domain joined computer on the Internet needs to be able to enroll for certificates from a Microsoft Enterprise Certification Authority. We are configuring the CEP/CES web services to interact with the Internet-based computer and this computer has no network connectivity to domain controllers or certification authorities behind the firewall. You could also further isolate the domain controllers and certification authorities by placing the CEP/CES server(s) in a perimeter network with another firewall between CEP/CES and the internal network.
First you need to install the CEP and CES roles on the member server Win2K8R2-MEM1.
For those of you well versed in getting certificates issued through IIS and how to setup the websites to require SSL you can skip this section.
Now that you have the services installed and the IIS configuration completed, you need to focus on the URI sent to the client computer to which it will send the enrollment request.
Alright, you are almost done with the setup now. The last thing you have to do is configure the clients to use the CEP/CES services.
Before clients will enroll for certificates against a certification authority hierarchy, they must have the public Root CA certificate in the computer’s trusted root store. This part of the configuration is probably the most difficult since these are not domain computers and you will have to rely on the user to follow the steps. There are two ways to do this – through the snap-in, or with a command-line that you could give to the user as a batch script.
Before I go into the steps it is important to understand that this configuration is based on the security context. You have a CEP configuration for the user, and you have another configuration for the computer. Depending on what certificates you plan on issuing (user or computer certificates) you may only require one of these to be configured.
With the users certificate store MMC still open do the following:
Now you may be asking “how can I get this configuration deployed to users?” And you may be thinking “these steps are way too complicated for them to follow.” Well, you can export the configuration from the registry and have the users import the settings.
Computer CEP configuration is located here:
Use CEP configuration is located here:
Alright, so you got your non-domain joined client computers requesting and getting certificates over the Internet. Great job! There are two different topics to be discussed for advanced configurations:
1. You have multiple CES servers or multiple authentication methods (Kerberos, Username Password, or Certificate) in your environment.
2. You want to use the CEP and CES services on the same computer, and use a domain or managed service account for the web application pool.
If you have multiple CES servers that host different authentication methods or one CES server that hosts multiple authentication type web services, you need to be concerned with the priority of the authentication methods you specify. If you recall from the section “Modification of msPKI-Enrollment-Servers attribute”, those changes assume that this is the only CES server and authentication method you are implementing in your environment. If you need to support multiple authentication methods then the CES URI needs to be added in a different way to assign different priorities to each authentication method.
The first thing to understand is that the lower the priority number the more preferred the CES URI is. So a priority of 100 is more preferred then that of 200. If you want to find out the different CES authentication types assigned to a certain CA and the priority you can type the following CertUtil command: certUtil –config “ <CA Computer Name>\<CA Name> ” -enrollmentServerURL
CertUtil –config “fab-rt-ca1.fabrikam.com\Fabrikam Root CA1” –enrollmentServerURL
As you can see from the output in Figure 15 there are two authentication methods assigned to the Fabrikam Root CA1. You have Kerberos at a Priority of 100, and UsernamePassword at a priority of 200. You can also see that the URL addresses are different. External clients would not resolve the win2k8r2.fabrikam.com DNS name, and internal clients would prefer Kerberos authentication over the UserNamePassword method because the priority for Kerberos is lower. Failure to set the priorities correctly could cause domain joined client computers to prefer UsernamePassword authentication method over Kerberos, and you will get a lot of calls to the help desk asking why the computer is constantly asking for credentials.
Alright, if you are reading this section, you must be really serious about security, and using domain based service accounts to run application pools. As stated earlier, during the installation phase if the CEP and CES web services are running on the same server then the application pool accounts for both of these services must be using the same account.
So in a nutshell, that’s pretty much how you can configure CEP/CES to allow users on non-domain joined clients to enroll for certificates against an internal Enterprise CA. Stay tuned in the future when we’ll cover some other scenarios featuring CEP/CES in Windows Server 2008 R2.
I hope that you have enjoyed learning how to use CEP and CES to extend certificate issuance to your users and customers.
Rob “Unjoined” Greene
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.