Disclaimer: All postings are provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.
Hey all, Rob here again. I thought I would expand upon my last blog describing Certificate Enrollment Web Services by covering some of the different configurations that are possible.
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: HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\PolicyServers\<GUID>
Use CEP configuration is located here: HKEY_CURRENT_USER\Software\Microsoft\Cryptography\PolicyServers\<GUID>
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
for example:
CertUtil –config “fab-rt-ca1.fabrikam.com\Fabrikam Root CA1” –enrollmentServerURL
Output:
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
> The web application pool identities must be the same for CEP and CES when both services are running on the same computer
actually this is not correct statement, because there is no difference if CEP and CES uses the same service account or different. By default CEP runs under AppPoolAccount, but it is recommended to run CES under NetworkService or domain user account. This is because there is no way to configure delegation settings for built-in account. Therefore this will common scenario when CEP and CES uses _different_ application pool identities.
Hey Vadims -
You're right, in this particular scenario. The requirement for CEP and CES to run under the same account on the same server only applies if both are using Kerberos for authentication. In this scenario, we're using Username\Password for authentication, so the restriction does not apply. I've corrected the blog post.
Here's what the Windows Server 2008 R2 Certificate Enrollment Web Services whitepaper has to say:
"Known issue: If other Kerberos authenticated http/https services are running on the same host as an enrollment or policy web service configured for Kerberos authentication, enrollment failures may occur because of an SPN collision. The workaround is to configure all of the services to run as the same user account."
So if you have both CEP and CES (or any other web service, for that matter) running on the same server, and they are both configured for Kerberos authentication, then all the application pools should be run under the same identity. This is the identity under which you'd register the HTTP service principal name.
Thanks for the catch.
Jonathan Stephens
> So if you have both CEP and CES (or any other web service, for that matter) running on the same server, and they are both configured for Kerberos authentication, then all the application pools should be run under the same identity
I'm not sure if this is true. I have performed several CEP/CES installations with the following scheme: CEP/CES are installed on the same server and are configured with Kerberos authentication. Back-end CA server is hosted on the different server.
In that scenario we need to configure delegation settings for CES service account, therefore I use NetworkService account for CES service and AppPoolIdentity for CEP service and this work in all my installations.
another question about mentioned whitepaper:
have you tried to specify managed service account during CES installation? Whitepaper states that you need to specify account name in DOMAIN\ServiceAccountName$ format and leave password field as blank. Since managed service accounts don't have managed password, you will unable to specify this account during role installation, because of password requirement.
For example it is possible (somehow) to specify managed service account for CES service. How we can configure delegation settings for this account? dsa.msc and other GUI tools don't show 'Delegation' tab for these accounts even if 'Advanced Features' are enabled.
It is true, Vadims, and the reason why can be illustrated by your example.
The example you described has two web services configured to run under different Built-In accounts, Network Service and AppPoolIdentity. The special thing about these two accounts, or in fact any Built-In account, is that they are all associated with the computer's account in Active Directory. That is, when requesting a Kerberos ticket to a service running under a Built-In account, you are actually requesting a ticket to the computer. As such, the necessary Service Principal Names (SPN) are registered under the computer account in Active Directory. From the OUTSIDE, your two web services are using the same account -- the computer account -- as their identity. Any differentiation between the explicit Built-In accounts is strictly internal to the server and has no meaning externally. For this reaon, the configuration you describe is valid.
Contrast this with running CES as Network Service and CEP under a service account -- DOM\CEPSvc. In this scenario, from the perspective of a user attempting to get a Kerberos ticket for one or the other of these services, the services are running under two different accounts: CES is running the server's computer account and CEP is running under the manually created service account. In order for this to work, you'd have to register the HTTP/<computerName> SPNs under both accounts, which is illegal. The same Service Principal Name cannot be registered under multiple accounts in the same forest, and attempting to do so will just cause the KDC service on your domain controller(s) to start recording KDC Error event 11 -- Duplicate SPN.
It is this second scenario we're encouraging you to avoid.