Design Considerations before Building a Two Tier PKI Infrastructure - Windows PKI blo...

Page 1 of 4

Design Considerations before Building a Two Tier PKI Infrastructure

amerk-PFE 19 Jun 2010 6:45 AM 2

Environmental Dependencies:
€1- Determine if the Active Directory Forest has Windows 2000 Domain Controllers. This is important because of
modifications to the CertPublishers group scope, and permissions related to the AdminSDHolder role. These
permissions can be added by using the Dsacls command.

2- Determine if the Active Directory Schema was upgraded to at least Windows 2003 (version 30) or Windows
2003 R2 (versions 31). This item needs to be checked at the Forest Root and the child domains if they exist. Active
Directory Certificate Services require Windows 2003 schema updates. Windows 2008 or Windows 2008 R2 schema
updates would work too. The Schema should have been extended if there is at least one Windows 2008/R2
domain controller installed in the environment.

3- Determine if there are any Exchange Mangled Attributes and fix them before the implementation. In some
cases, when the Active Directory Schema is expanded, it can cause mangled attributes. Incorrect modification of
the LDAP display names occurs in the following scenarios:

a. When you install Exchange Server 2000 or Exchange Server 2003 before you install Windows Server 2003
schema updates.

b. When you install Exchange Server 2000 or Exchange Server 2003 before you apply the inetOrgPerson kit.

c. When you install Windows Server 2003 schema updates before replication of the modifications to the
LDAP display names is complete.

€The following table describes the attributes:

Attribute Original LDAP Display Name Modified LDAP Display Name

Ms-Exch-Assistant-Name€€€€€€€ € Secretary msExchAssistantName

Ms-Exch-LabeledURI labeledURI msExchLabeledURI

Ms-Exch-House-Identifier houseIdentifier msExchHouseIdentifier

If these attributes were mangled, they will change to something like DUP-secretaryc5a1240d-70c0-455c-9906-
a4070602f85f. This can be fixed by following the steps outlined in http://support.microsoft.com/kb/314649/en-us

€4- An Enterprise Admin account is required for the install. An Online CA can't be installed without it. The other
option would be delegating permissions at the CA containers in the Active Directory Configuration partition, which
can be complicated in some environments.

5- The following OS versions are required before the install:

a. Root CA: Windows 2003/2003 R2/2008/2008 R2 Server Standard/Enterprise Edition, member of a

workgroup.

b. All Issuing CAs: Windows 2003 Server Enterprise Edition or Windows 2008 R2 Standard edition to allow V2
templates, and should be a member of the domain, preferably the child domain to follow the security model.

c. If V3 templates are required, then all Issuing CAs should be installed on Windows 2008 or 2008 R2
Enterprise or Standard Editions.

d. If Key Archival is required, then all Issuing CAs should be installed on the Enterprise Edition of the OS.

http://blogs.technet.com/b/pki/archive/2010/06/19/design-considerations-before-building-... 08/11/2010
Design Considerations before Building a Two Tier PKI Infrastructure - Windows PKI blo... Page 2 of 4

e. If you are not sure about the requirements, then it is preferred to install the Issuing CAs on the Windows
2008 or Windows 2008 R2 Enterprise Edition.

€6- If there are any HSM device(s), then they should be present and functional before the install.

a. Review the documents provided by the vendor for their recommendations of the install. In most cases, this
will require installing the HSM software and management tools on each CA server communicating with the
HSM.

b. Determine if all CAs are going to share the same Security World, or having separate Security Worlds for
each installed CA (more secure).

€7- <Optional> Determine if the PKI infrastructure is installed on physical servers or virtual servers. Virtual servers
should be secured in the same manner as physical servers due to the criticality of the infrastructure.

8- Make sure to have a thorough understanding of Microsoft's support boundaries regarding VMs as described in
Microsoft Virtual Server and Support Policy for Non-Microsoft Hardware Virtualization.

 Certification Authority Planning: 

€1- Understand the CRL and AIA locations fully, and determine the following before proceeding with the install

a. Root CA: Should be a member of a workgroup, and offline when the setup is completed. It is needed
anytime a new sub CA is created, and anytime a new Root Base CRL is needed.

b. Root CA: Determine the appropriate Key Length of the CA, 1024, 2048, 4096, etc.... This has to be
determined based on the applications using the CA. If in doubt, the vendor of the application should be
contacted contact the vendors. As an example, if the organization is planning to use SAP Portal access certs.
The key length has to be determined before hand, so the certs can chain up to the Root CA.

c. Root CA: The root should only have a base CRL, because it is offline. Ensure the following is also planned:

i. Frequency of Base CRL generation, 3 months, 6 months, a year, etc....

ii. Remember to bring the CA online before the expiration of the Base CRL and issue certutiul -CRL
command. Copy the new CRL file to the CDP, and publish it to Active Directory depending on the
locations of the AIA and CDP (mentioned below).

iii. Patch and backup the offline Root every time before and after the processes mentioned above.
Patching should only be for major releases

iv. For the tasks mentioned above, add a team calendar reminder to ensure operations are not disrupted

d. Root CA: Determine if the CRL and AIA are published in Active Directory or a web site that can be accessed
internally and externally. It can be either option, or both, but each have caveats such as:

i. Active Directory Only: This type of setup is only recommended if certificates are used internally. Any
certificate used outside of the internal network might fail such as SCCM Internet Based Client
Management Pack, or Direct Access. The CRL needs to be published to AD on regular intervals
depending on the time set for the CA to issue a Base CRL.

ii. Web Site: This option has to take into consideration that the web site is accessed internally and
externally especially if certificates are used outside the internal network. Like Active Directory, the web
server distribution point should be updated with CRL files based on their generation frequency.

iii. Active Directory and Web Server: Combination of both notes above.

€e. Issuing CA: Should be a member of any domain in the forest. ADCS is a forest wide resource and can
publish certificates to any member client in any domain

f. Issuing CA: If there is one Issuing CA only for a multi domain forest, then the Issuing CAs computer account
needs to be added to the Certpublishers group of each domain.

g. Issuing CA: Determine how many issuing CAs are needed. The design can be set such as having a CA per
geography, per function (user, or computer certs).

i. Certification Authorities are not Active Directory site aware, and will not abide by site boundaries. The
control of certificate enrollment is done by the permissions set at the Certificate templates, with the
right to enroll, autoenroll and read.

ii. Determine if the Issuing CA needs to issue user certs and computer certs, or having a designated CA
for each type of cert.

http://blogs.technet.com/b/pki/archive/2010/06/19/design-considerations-before-building-... 08/11/2010
Design Considerations before Building a Two Tier PKI Infrastructure - Windows PKI blo... Page 3 of 4

iii. If CA high availability is required, then the CA can be clustered in Windows 2008 and 2008 R2
Enterprise Editions of the OS. Refer to Configuring and Troubleshooting Certification Authority
Clustering in Windows Server 2008 for more information.

h. Determine the generation frequency of the Base and Delta CRL files for each CA. This step is critical to
ensure appropriate revocation is taking place. Any organization should evaluate the process of terminating
users, and adjust the frequency accordingly.

i. There should be a process in place to revoke user and computer certificates before hand, and train the
helpdesk or the person(s) handling termination how to revoke certificates.

ii. If real-time revocation checking is required, then you should consider implementing an Online
Responder. Refer to Online Responder Installation, Configuration, and Troubleshooting Guide for more
information.

i. Determine the AIA and CDP distribution points for each CA. This step is very critical because these locations
are hard coded in each certificate issued by the CA, and will not get updated unless the certificate is renewed.
The locations can be:

i. AD, internal CA web server and file: This condition is good when using certs internally only. The AD,
internal CA web server and file locations will have the CRL and CRT files published automatically. The file
location is used by the CA to generate the CRL files and also has the CRT file. This location is typically
under %windir%\system32\Certsrv\Certenroll

€ii. AD, Web server access internally and externally and file: This condition is ideal for most
implementation, and can be used with certificates used externally. A process needs to be in place to
copy the Base and Delta CRL file to the Web server which is accessible internally only, or internally and
externally. The AD location will be updated automatically. The file location is similar to point above.

iii. Web Server, and file: Same as above, but this configuration allows you to use external certificates or
in environments where certificates will be used by applications or operating systems which are not
Active Directory aware. A process needs to be in place to copy the Base and Delta CRL file to the Web
server which is accessible internally only, or internally and externally. The file location is similar to the
points above.

j. Issuing CA: Determine the appropriate Key Length of the CA, 1024, 2048, 4096, etc.... .... This has to be
determined based on the applications using the CA. If in doubt, the vendor of the application should be
contacted.

k. Ensure there is a process to backup the CA on a daily basis, or at least backup the System State. Root CA
backups should be carried out anytime the CA is brought online. Refer to Disaster Recovery Procedures for
Active Directory Certificate Services for mote information.

Certificate Templates:
1- Determine the type of Certificate Templates used from the moment of standing up the issuing CA, and remove
any unneeded templates.

2- Discuss the certificate template design with application vendors and subject matter experts

3- Design and document each template created, including the issuance requirements, and which Active Directory
groups are allowed to enroll for that template

a. Determine which CAs issue the templates designed, as an example, a CA in Europe may issue templates
that don't exist in the US, and vice versa. This can be controlled by using certificate template permissions, and
issuing the templates at the CA issuing the cert.

4- Determine the scope of users, and computers auto enrolling for certificates

a. Auto enrollment can only occur for user certificates for users running on Windows XP or higher

b. Autoenrollment can only occur for computer certificates running on Windows XP or higher

c. Automatic Computer Request Services can be used for computers running Windows 2000 and above. This
only applies to computer certificates only, using V1 templates

d. Version 3 templates can only be used with Windows Vista and above. These new templates utilize Crypto
Next Generation algorithms. You should contact the application vendor to make sure the certificate
generated by these templates, specifically the algorithm used is compatible with the application.

http://blogs.technet.com/b/pki/archive/2010/06/19/design-considerations-before-building-... 08/11/2010
Design Considerations before Building a Two Tier PKI Infrastructure - Windows PKI blo... Page 4 of 4

Security Concerns: 
1- Consider using Role Sepearation for the day to day administration tasks of the CA. Review
http://technet2.microsoft.com/WindowsServer/en/library/3ef594f5-758f-43d1-81c4-108a82017fa11033.mspx?
mfr=true for more information

2- Enable Object Access Auditing for Success and Failure in the local security policy of each CA server, or through
a group policy. Once that is set, run the Certutil -setreg CA\Auditfilter 127 at the command line and restart
certificate services.

Amer Kamal

Senior Premier Field Engineer

Comments

Brian 21 Jun 2010 11:15 AM

Questions:

1. Can you clarify what permissions you are referencing in #1 - "and permissions related to the
AdminSDHolder role. These permissions can be added by using the Dsacls command."

amerk-PFE 22 Jun 2010 4:27 PM

The Cert Publishers needs read and write permissions to the userCertificate attribute of user objects.
Certificates published to these. If the environment has a single forest/domain then you can ignore this
step, however, if the environment has multiple domains and the CA is intalled only in one domain and
needs to issue certificates to other domains then you need to make sure the CertPublishers group has the
name of the CA, in addition to that group having read and write permissions to the userCertificate
attriute of the user object.

The CertPublishers group in Windows 2000is a global group (This was changed in Windows 2003 – new
installs only) This means that only user accounts, computer accounts, and global groups from the same
domain can have membership in the Cert Publishers group. To modify permissions to allow enterprise
CAs from other domains to publish information to the userCertificate attribute, use the following
strategy:

Change the scope of the CertPublishers Group from Global Group to Local Group

Assign each domain’s Cert Publishers group the Read userCertificate permission in every domain in the
forest.

Assign each domain’s Cert Publishers group the Write userCertificate permission in every domain in the
forest.

Assign each domain’s Cert Publishers group the Read userCertificate permission at the
CN=adminsdholder,CN=system,DomainName container in every domain in the forest.

Assign each domain’s Cert Publishers group the Write userCertificate permission at the
CN=adminsdholder,CN=system,DomainName container in every domain in the forest.

http://blogs.technet.com/b/pki/archive/2010/06/19/design-considerations-before-building-... 08/11/2010