Certificate enrollment before windows server 2008 R2 was performed using one of the following methods:
- Using the Web Enrollment Pages
- Requesting certificate by utilizing the certificate authority DCOM calls (RPC).
- 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 pages will query ADD 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.
- 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.
The limitation here is 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.
3. Third Party tool like FIM CM 2010 is great tool for issuing smart cards and user certificate. It doesn’t support issuing computer certificates or auto enrollment.
Certificate Web Enrollment Services
Windows Sever 2008 R2 came with many enhancements and it extend the methods clients can enroll for certificates by utilizing web services. The main advantages are:
- 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.
- Internet based clients that need to enroll for a certificate or renew a certificate.
- 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 the CA and client computer and your clients are Windows7 /2008R2.
Who does it work
The new services that support the new web enrollment services included in Windows Server 2008 R2 are:
- Certificate Enrollment Policy
- Certificate Enrollment Services
Step 1. Client connects to the CEP web service over HTTPS.
The Windows 7 / Windows Server 2008R2 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 it 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.
Step 4. CES web service impersonates the client security context to request a certificate via DCOM, and then hands the certificate back to the client.
- 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.
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 and 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.
The following are some consideration to keep in mind when deploying CES and CEP internally and using Kerberos:
- It is recommended not to install CES and CEP on the CA server itself.
- 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.
- You cannot install multiple CEP instances on the same machine
- 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).
- It is recommended to run the application pool of the CES service using custom account.
- 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 :
- Service principle name for the CES application pool account
- Account delegation ( those services “Kerberos only”) for the CES application pool account .Delegation should be made for the CA server for (HOST and RPCSS)
- CES application pool account should be :
- Member of the local IIS_USRS group
- Have Request Certificate permission on the CA server.
- The account that is used to install the services should be Enterprise Admin.