Introduction

In his blog post, I will be introducing Microsoft certificate web enrollment services, and how it can help you enroll certificates using a friendly http protocol. Before certificate web enrollment was introduced [on Windows server 2008 R2], certificated enrollment was performed using one of the following methods:

1. Using the Web Enrollment Pages.
2. Requesting certificate by utilizing the certificate authority DCOM calls (RPC).
3. Third party tool that will proxy enrollment requests like FIM CM 2010. 

It is obvious that every method mentioned above has its own limitation. Web Enrollment Pages, simply would replace the client. The client will initiate HTTP request to the web enrollment pages, and the enrollment page will query Active Directory for all lists of templates and converting the client’s HTTP request into DCOM request that can be sent to the CA. So the client doesn’t have direct access to the CA. This way of enrollment is completely manual process and doesn’t support auto enrollment. Third Party tool like Forefront Identity Management – Certificate Management [FIM CM] is great tool for issuing smart cards and user certificate. It doesn’t support issuing computer certificates or auto enrollment.

Requesting certificates using DCOM

Requesting certificates using DCOM to the CA. In his method, clients need LDAP access to a domain controller to determine the certificate templates available and which CA servers are publishing them. Actually the client will perform the following LDAP queries to the AD:

• Queries for a list of pKICertificateTemplate objects (certificate templates) within the forest.
• Queries for a list of pKIEnrollmentService objects (enterprise CA’s) within the forest.
• Queries for a list of msPKI-Enterprise-Oid objects within the forest.

Once all of objects are returned to the client, it determines what enterprise CA’s are available, and what certificate templates can be issued by each one of them. The client then determines the certificate templates for which it has permissions to enroll or auto enroll. Once the client selects the certificate template for which to enroll, a DCOM connection is made to the CA. DCOM connects to the CertSrv Request DCOM interface to enroll for the certificate. The certificate is then handed back to the client.

It is not practical to expose DCOM access to the CA server itself, and this doesn’t work if you want to enroll external clients without connectivity to corporate network. On the other hand , this will not work for clients not joined to the corporate domain.

Certificate web enrollment services

 Benefits

Certificate web enrollment services came with the release of Windows Sever 2008, to handle those limitations and to enable clients to enroll for certificates by utilizing web services. The main advantages are:

1. Non-domain joined workstations. They are unable to authenticate to a DC and perform the initial LDAP queries, and thus will never make it to step 2 – the RPC/ DCOM call.
2. Internet based clients that need to enroll for a certificate or renew a certificate.
3. No need to expose DCOM interface for the certificate service. This is very important if there is a requirement that client computers should not be able to access the CA directly over the network, or there is a firewall between  CA and client computers.

The new services that support the new web enrollment services included in Windows Server 2008 R2 are:

1. Certificate Enrollment Policy
2. Certificate Enrollment Services

Step 1. Client connects to the CEP web service over HTTPS.

Computer is configured to enroll for certificates against a CEP server [specified via GPO or by specifying the CEP server manually via certificates snap in].

Step 2. CEP web service queries LDAP.

The CEP service will send an LDAP query to a domain controller to get the pKICertificateTemplate objects (certificate templates), pKIEnrollmentService objects (enterprise CA’s), and msPKI-Enterprise-Oid objects within the forest.

Once all the objects are collected and sent back to the client computer, the client computer determines the types of certificate for which it can enroll and which enterprise CAs can issue those certificates.

There is a new attribute on the CA’s pKIEnrollmentService object that tells the client computer what the URI’s are for the CES servers in the environment. The attribute name is msPKI-Enrollment-Servers. The attribute is a multi-valued string, so there can be multiple URI’s defined if you need to support different authentication methods.

Step 3. Client connects to the CES web service over HTTPS.

The client then connects to the CES web service that answers for the certification authority that is configured to issue the certificate. The actual CES URI is defined in the msPKI-Enrollment-Servers attribute on the pKIEnrollmentService object for that CA.

CES web service impersonates the client security context to request a certificate via DCOM, and then hands the certificate back to the client.

Authentication Methods

Certificate web enrollment Services support the following authentication methods to authenticate clients requesting a certificate

• Integrated Authentication:  useful if clients who need to enroll certificates are joined to the domain and connected to the corporate network. It uses Kerberos and it the recommended method because it is the most secure and seamless method.

• Client Certificate Authentication: this requires that machines are already provisioned with computer certificates before.

• User name and password: this is used when enrolling to external clients or machines not member of the domain.

Load Balancing

Certificate web enrollment load balancing is built in the product. Rather than relying on network load balancing (NLB) technologies, the policy and enrollment service client components have load balancing and fault tolerance logic built in.  For example, the clients will automatically randomize the list of endpoints they’re provided with, and will attempt to iterate through the list if the first endpoint is unresponsive.  Thus, as long as multiple URIs are published, basic load balancing and fault tolerance is built in.

Internal deployment with integrated authentication

The following are some consideration to keep in mind when deploying certificate web enrollment sevices [CES and CEP] internally and using Kerberos:

1. It is recommended not to install CES and CEP on the CA server itself.
2. If both CES and CEP are using Kerberos (Integrating authentication), then they cannot be installed on the same server, as simply there will be SPN collision (both using same IIS application pool, and same protocol). That is why we recommend installing them on separate machines.
3. You cannot install multiple CEP instances on the same machine
4. It is possible to install multiple instances of the CES on the same machine if they use different authentication protocol (one instant uses integrated authentication while the other uses client certificates).
5. It is recommended to run the application pool of the CES service using custom account.
6. Since Kerberos is used on the CES server and it will enroll certificates on behalf of the user, then the following two steps must be done :
   1. Service principle name for the CES application pool account
   2. Account delegation (those services “Kerberos only”) for the CES application pool account. Delegation should be made for the CA server for (HOST and RPCSS)
7. CES application pool account should be :
   1. Member of the local IIS_USRS group
   2. Have Request Certificate permission on the CA server.
8. The account that is used to install the services should be Enterprise Admin.

Blog Post Notification

Be the first to get notification when key blog post articles are released. No marketing material.

SUBSCRIBE!

You have Successfully Subscribed!