From 389 Directory Server
Auto Enrollment - Architecture
Automatic Certificate Enrollment is a feature built into Windows 2000, XP, and 2003. It is available to windows systems which are members of a Windows domain. Each member of a domain can query its domain controller to find services available to it, and use credentials issued to it from the domain controller to request those services.
The Auto Enroll Proxy should be run on a dedicated machine, in a secure environment. Users with login access to the administrator account on the machine will be able to request for certificates for the domain, thereby impersonating entities in the domain, so limit access only to trusted administrators.
The proxy receives enrollment requests over DCOM, and forwards them to the Red Hat Certificate System CA, as shown in the following diagram:
During installation , the proxy will be set up as an NT service, with registry entries created such that it responds to the ICertRequestD DCOM CLSID. The RPC service (RPCSS) on the machine will perform authentication/authorization checks to make sure that the enrollee is authorized to access the proxy.
Other machines in the domain expect to find information about certificate enrollment services in Active Directory. This information can be populated into active directory by the AEP configuration panel. Once this is done, other members of the domain will be able to query Active Directory for the hostname of the machine running the proxy, as shown here:
The enrollee can be one of several processes:
- A user-driven enrollment with Microsoft's Management Console, running the 'Certificates' snap-in
- A user-driven enrollment with Microsoft's commandline tool 'certutil.exe'
- An automated enrollment, perhaps initiated with group policy
- An enrollment initiated with the IIS (Web Server) MMC Snap-in
Whichever process is used, the enrollee will check that the enrollment service supports the type of certificate that it is interested in (e.g. Domain Controller, Web Server, etc.), and that the Certificate Authority is trusted. If it meets the requirements, it will post a PKCS#10 certificate request to the proxy.
The proxy will then parse the request. It will pull out some information from the request, and reformat it appropriately for the Red Hat CA. It may also, (depending on the type of certificate requested) assemble other information which is needed to go into the certificate (e.g. domain controller GUID).
Finally, the proxy submits the Certificate Request to the CA, over an SSL-Client Authenticated HTTP connection. The CA issues the certificate, returns it to the proxy, which then returns it to the enrollee.
Windows IS architecture considerations
You will want to consider how AEP fits into your windows architecture before installing. A single AEP proxy installed in your enterprise can fulfill the enrollment needs for any enrollee , if the proxy can authenticate the origin of the request. In practice, this means that the enrollee must be in the same forest.
The following 3 deployment scenarios may be common
 | This image illustrates the simplest configuration... the proxy is installed on the same machine as the domain controller. |
 | This image illustrates a single windows domain, but the proxy is installed on a dedicated machine in the domain. |
 | This image illustrates multiple domains in a forest. The domains can be completely separated, or child domains. The proxy is installed into only one of the domains, but is visible from machines in other domains. Setting up a domain in this manner is quite challenging, but once done correctly, certificate enrollment via AEP as expected. |
