Partilhar via

Design Considerations before Building a Two Tier PKI Infrastructure

  • Artigo

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 https://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.

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.

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.

Security Concerns: 

1- Consider using Role Sepearation for the day to day administration tasks of the CA. Review https://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

  • Anonymous
    January 01, 2003
    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.

  • Anonymous
    January 01, 2003
    Perfect Amer, the Cert Publisher group think got me, glad to see the steps to do it here.

  • Anonymous
    June 21, 2010
    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."

  • Anonymous
    December 15, 2010
    "Windows Server 2008 - PKI and Certificate Security" states it may be a good idea not to have CRLs published from a root CA (page 102 - Example CAPolicy.inf). Since publishing intervals (also stated in the blog above) typically are expressed in months there can indeed be a doubt about the usefullness of such CRLs when thinking of the time that could elapse between the compromise of a CA (for which a root CA has issued a certificate) and the detection through a CRL of that fact by a client. Despite that fact, are there any particular reasons that make it worthwhile anyway to have root CA CRLs (and thus having to bring them online every few months or so)?

  • Anonymous
    March 01, 2011
    The comment has been removed

  • Anonymous
    July 26, 2011
    Hi, Good, Thanks for taking the time to put in writing this article, Great articles as usual......It consists of a framework of processes, supplemented by various publications and a periodically updated library of best practices that are available on the website of the ASL Foundation, which also provides a platform for application management organizations.

  • Anonymous
    May 27, 2015
    The comment has been removed