Enabling CEP and CES for enrolling non-domain joined computers for certificates

Enabling CEP and CES for enrolling non-domain joined computers for certificates

  • Comments 23
  • Likes

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.

NetworkDiagram

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.

Installing CEP and CES Role Services

First you need to install the CEP and CES roles on the member server Win2K8R2-MEM1.

  1. Launch Server Manager.
  2. Click on Roles in the tree view.
  3. In the right hand pane click on “Add Roles”.
  4. Click the Next button.
  5. Check the box “Active Directory Certificate Services”.
  6. Click Next button twice.
  7. Uncheck “Certification Authority”.
  8. Check “Certificate Enrollment Web Service”.
  9. When you check the role, another dialog box will come up as shown below. Click the “Add Required Role Services” button.

    Figure 1 - Additional required role services 
  10. Check “Certificate Enrollment Policy Web Service”.

    Figure 2 - Adding CEP and CES Role Services 
  11. Click the Next button.
  12. Click the Browse button and select the CA to which this CES server will send certificate requests.

    Figure 3 - Select the certification authority 
  13. Click the Next button.
  14. Select “Username and password” as the Authentication Type. We are choosing this method because these are non-domain joined computers and do not have a domain-based account to pass to the web service.

    Figure 4 - Select Authentication Type 
  15. Click the Next button.
  16. Select “Use the built-in application pool identity”.

    NOTE: I know that the setting default is Specify service account (recommended). If you want to specify an account see the advanced configuration section at the end of the blog.

    Figure 5 - CES Application pool identity 
  17. Click the Next button twice.
  18. You will be given a screen listing IIS components. Do not make any changes; just click the Next button.
  19. Click the Install button.

Configuring SSL certificate for the websites

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.

  1. Open Internet Information Services (IIS) Manager.
  2. Select the server node in the tree view.
  3. In the right hand pane double click on Server Certificates.

    Figure 6 - Server certificates 
  4. Click on Create Domain Certificate.

    Figure 7 - Create domain certificate 
  5. The Create Certificate dialog box will be presented. Fill out the fields; the “Common name” field MUST be the DNS name that the clients will use to connect to the CEP / CES services on the Internet. In figure 8 you will be using “cert-enroll.fabrikam.com” as the Internet DNS name. If you need to request a certificate that has multiple DNS names associated with it then you can create the certificate using the Custom Certificate requests within the Certificates snap-in.

    Figure 8 - Create Certificate wizard 
  6. Once you have filled in the fields, click the Next button.
  7. Select the online certification authority.NOTE: If an enterprise certification authority is not listed, then look to make sure that the Root CA certificate is in the Trusted Root Certification Authority machine store. Also, the Create Certificate Wizard will attempt to enroll for a certificate based on the default Web Server template. If that template is not available then enrollment will fail.
  8. Type in a friendly name for the certificate.
  9. Click the Finish button.
  10. Back in the IIS Manager Tree view, expand to select Default Web Site node.
  11. In the right hand pane select SSL Settings.
  12. Click on Bindings for the action.

    Figure 9 - SSL Bindings
  13. Select the HTTPS binding, and click the Edit button.
  14. Select the certificate created in step 9 for the SSL certificate field.
  15. Click the OK button.
  16. Click the Close button.
  17. Select each web service virtual directory one at a time and do the following.
    1. Double click on SSL Settings.
    2. Verify Require SSL is checked.
    3. Lastly, you will want to give a friendly name to the CEP service. This friendly name shows up on all client computers when they manually request certificates.
    4. Expand Default Web Site.
    5. Select the virtual directory ADPolicyProvider_CEP_UsernamePassword.
    6. Double click on Application Settings.
    7. Double click on the group name FriendlyName.
    8. In the value field, enter a name that uniquely identifies your organization. See figure 10 for an example.

      Figure 10 - Adding FriendlyName value

Modification of msPKI-Enrollment-Servers attribute

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.

  1. Run ADSIEdit.msc.
  2. Expand ADSIEdit to: cn=Enrollment Services,cn=Public Key Services,cn=Services,cn=Configuration, DC=yourforestrootdomain,dc=com.
  3. In the right hand pane select the CA for which you are configuring CEP/CES.
  4. Right click and select Properties.
  5. Double click on the attribute msPKI-Enrollment-Servers. See Figure 11.

    Figure 11 - CA Enrollment Services object properties
  6. You need to modify the URL address here to match the Internet based URL that the client computers will be using. You can use the Remove button, and modify the URI and then click the Add button to get the changed URI added back to the attribute.
  7. So in my setup here is what I changed:

    Original URI: 140https://win2k8r2-mem1.fabrikam.com/fabrikam%20Root%20CA1_CES_UsernamePassword/service.svc/CES

    Changed URI: 140https://cert-enroll.fabrikam.com/fabrikam%20Root%20CA1_CES_UsernamePassword/service.svc/CES
  8. Click the OK button.
  9. Exit ADSIEdit.msc.

Configuring the client computers

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.

Adding the Root certificate to the Trusted Root Store
  1. Logon as a local computer administrator account.
  2. You can add the Root CA certificate to the computers Trusted Root Certification Authorities store via the MMC:
    1. Open the Run command and type MMC.
      1. Select File then Add/Remove Snap-in
      2. Select Certificates, and click the Add > button.
      3. Select Computer Account, and click the Next button.
      4. Click the Finish button.
      5. Click OK
    2. Expand Certificates (Local Computer).
    3. Expand Trusted Root Certification Authorities.
    4. Right click on Certificates, and select All Tasks, and then select Import
      1. Certificate Import Wizard comes up.
      2. Click the Next button.
      3. Click the Browse… button and navigate to the CER file.
      4. Click the Next button.
      5. Leave the defaults, and click the Next button.
      6. Click the Finish button.
  3. Or you can run an elevated command prompt (Run as Administrator) and type the below command:

    CertUtil –AddStore Root <Root CA Public Certificate file name>

    For example:
    CertUtil –AddStore ROOT c:\fab-root-ca1.cer
Configuring the CEP web address in the client

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.

Configuring user certificate enrollment

  1. Run CertMgr.msc.
  2. Expand Certificates, then Current User.
  3. Expand Personal.
  4. Right click on Personal, and select All Tasks, then Advanced Operations, then Manage Enrollment Policies
  5. On the Manage Enrollment Policies dialog click the Add… button. See Figure 12

    Figure 12 - Enrollment Policies dialog box
  6. Type in the URI for the CEP service in the field. This will be in the format of:

    https://<Internet FQDN>/ADPolicyProvider_CEP_UsernamePassword/service.svc/CEP

    In my example this would be:

    https://cert-enroll.fabrikam.com/ADPolicyProvider_CEP_UsernamePassword/service.svc/CEP

    NOTE: the only thing that will be unique to your environment is the Internet FQDN of the URI.
  7. In the Authentication type drop down select: Username/password
  8. Click the Validate button.
  9. Once the Validate button is pressed, you will be prompted to type in a domain user name and password. Supply these credentials.
  10. If everything goes correctly you should see that the validation test passed in the lower section of the dialog box see Figure 13.

    Figure 13 - Validation of Enrollment Policy Server configuration

    NOTE: You can see in Figure 13 that the only difference is the DNS portion of this URI. If you scroll down further in the validation output, you will see the friendly name you added under the website configuration being displayed also.
  11. Click the Add button.
  12. Uncheck Enable for automatic enrollment and renewal.

    NOTE: Failure to do so could cause users to be prompted for user name and password each time they logon to the computer. This occurs because Windows Autoenrollment runs immediately after the user has logged on. If the enrollment policy is configured for automatic enrollment and renewal, Windows Autoenrollment will attempt to contact the configured CEP server when it starts in order to determine if new certificates have been assigned. Since this will result in the users being prompted for credentials every time they log on your users may be annoyed.
  13. Click the OK button.NOTE: Follow the same procedures to configure the Enrollment Policy server for the computer personal store if you need to enroll for computer certificates.

Testing the configuration

With the users certificate store MMC still open do the following:

  1. Right click on Personal, select All Tasks, and select Request New Certificate…
  2. Certificate Enrollment wizard is displayed.
    1. Click Next.
    2. You will see that our new CEP configuration is being displayed.

      Figure 14 - Certificate Enrollment CEP server 
    3. Click the Next button.
    4. You will be prompted for a domain user name and password. Type in a valid domain user name and password combination. Keep in mind that the account used here will determine what certificate templates that are displayed to you next. You can check the box “Remember my credentials”, however if the account password changes you will have to change the credentials through the credentials vault.
    5. Select a certificate template to issue. I always like to use Basic EFS during testing.
    6. Click the Enroll button.
    7. You will be prompted for User name and Password. Type in a valid domain user name and password combination.
    8. You have now successfully enrolled for a certificate against the certification authority.

      NOTE: The same procedures can be used to test computer certificates. The templates that are available must be configured for “Supplied in the request” on the Subject Name tab for the template. Also, the user account used to authenticate to the CEP and CES service must be configured on the templates Security tab with Enroll permissions.

How to deploy the Certificate Enrollment Policy URL to clients:

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>

Advanced Configurations

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.

Multiple CES servers or multiple authentication methods:

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:

Figure 15 - 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.

Domain account running the application pool

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.

  1. Open Internet Information Services (IIS) Manager snapin.
  2. Highlight the Application Pools tree node.
  3. On the right hand pane, you will see some application pool accounts. You are interested in WSEnrollmentPolicyServer and WSEnrollmentServer.
  4. Do the following for each application pool.
    1. Right click on the application pool, and select Advanced Settings.
    2. Select Identity under Process Model node, and click on the button. See figure 16.

      Figure 16 - Application Pool Identity
    3. Radio button select Custom account:
    4. Click on the Set… button.
    5. Type in the Application Pool account in the form of domain\user name.
    6. Type in the password twice.
    7. Click the OK button three times.
  5. Open up computer management (Compmgmt.msc).
  6. Add the group to the local computer IIS_IUSRS group.
  7. Open an elevated command prompt, and type IISRESET

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.

    Jonathan Stephens