Integrating the Active Directory Infrastructure

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Your CA infrastructure is independent of the domain structure of your Windows environment. For example, one CA can service requests from multiple domains, or multiple CAs can serve a single domain. CA hierarchies with stand-alone CAs can even span multiple Active Directory forests.

If possible, take your PKI requirements into account when you design your Active Directory infrastructure. Active Directory and PKI technology impact each other in the following ways:

  • Enterprise CAs are bound to the forest. As a result, enterprise CAs can only issue certificates to computers and users in the forest. In addition, you cannot change the name of the CA or the computer after it is deployed. Moreover, the computer cannot be removed from the domain or forest. Because much of the security of an organization is established at the forest level, the security of an enterprise CA is connected to the forest in which it is located. For this reason, each forest requires its own enterprise CAs.

    Note

    • If certificates from stand-alone CAs are published to Active Directory, these stand-alone CAs cannot be renamed or removed from the forest without their certificates becoming invalid. However, you can rename stand-alone CAs that belong to workgroups without impacting the status of their certificates.

  • Certificate storage affects the size of your directory. If you store certificates in user objects, the size of the directory increases and replication time might increase. Because the userCertificate attribute contains data about all the user certificates, the addition of a certificate to that multivalued attribute causes Active Directory to replicate attribute data for all certificates.

  • Complications such as failure to recognize the user or the certificate can occur. This happens if you do not apply a consistent naming structure for both your distinguished names (also known as DNs) and your user principal names (UPNs).

  • Enterprise CAs rely on the existence of an Active Directory schema. If your schema is based on Windows 2000 Active Directory, you might need to extend it to support Windows Server 2003 Certificate Services functionality, such as version 2 certificate templates. For more information about version 2 templates, see "Selecting Certificate Templates" later in this chapter.

For certificates with a long life, the availability of the CA services themselves is much less important than the availability of the directory that holds the certificates and the certificate revocation lists. If you integrate your CAs with Active Directory, your certificates and CRLs are automatically published to the directory and replicated throughout the forest as part of the global catalog.

Note

  • If you use Active Directory to publish and replicate information about CRLs throughout your organization, be sure to review Active Directory replication schedules and policies in order to ensure that this data is distributed in a timely manner.

Windows Server 2003 Certificate Services functions whether Active Directory in your organization is based on Windows 2000 or Windows Server 2003. It also functions if your organization is operating in mixed mode.

Configuring Public Key Group Policy

If you have an Active Directory environment, Group Policy allows you to link certificate services to groups of users or computers based on their domains or organizational unit membership. You must configure public key Group Policy in order to perform the following tasks:

  • Add trusted root certificates for groups of computers. You can define the following:

    • Which root CAs users can trust when verifying certificates.

    • Whether users are allowed to trust additional CAs of their own choosing.

    • The purposes for which certificates issued by each CA can be used.

    Enterprise root CAs within your domain forest are automatically added to these policies.

  • Distribute certificate trust lists for computers and users. For more information about certificate trust lists, see "Evaluating Factors That Affect Extended Trusts" later in this chapter.

  • Enable autoenrollment. For more information about autoenrollment, see "Selecting a Certificate Enrollment and Renewal Method" later in this chapter.

  • Designate EFS recovery agent accounts. You can define an EFS recovery policy within the scope of the policy object. If a recovery policy is defined, it is populated with the certificates of the recovery agents.

In many organizations, users and computers are already organized into domains and organizational units that are based on the organization structure, location, and job function. If your organization has not already created an Active Directory domain structure, the best way for you to take advantage of Public Key Group Policy is to define the groups of users and computers that will use your Certificate Services and communicate this information to the Active Directory and Group Policy administrators, so that they can address your public key requirements in their planning.

For more information about how to plan for the use of Group Policy, see "Designing a Resource Authorization Strategy" in this book.