AD CS is composed of several role services that
perform several tasks. One or more of these role services can be
installed on a server as required. These role services are as follows:
- Certification Authority— This role service installs the core CA component, which allows a server to issue, revoke, and manage certificates for clients. This role can be installed on multiple servers within the same root CA chain.
- Certification Authority Web Enrollment— This role service handles the web-based distribution of certificates to clients. It requires Internet Information Services (IIS) to be installed on the server.
- Online Responder— The role service responds to individual client requests regarding information about the validity of specific certificates. It is used for complex or large networks, when the network needs to handle large peaks of revocation activity, or when large certificate revocation lists (CRLs) need to be downloaded.
- Certificate Enrollment Web Service— This new service enables users and computers to enroll for certificates remotely or from non-domain systems via HTTP.
- Certificate Enrollment Web Policy Service— This service works with the related Certificate Enrollment Web Service but simply provides policy information rather than certificates.
- Network Device Enrollment Service— This role service streamlines the way that network devices such as routers receive certificates.
Public Key Infrastructure must be deployed in
hierarchical order to securely deliver certificates to clients,
application and servers. The best way to achieve this is to deploy a
Standalone Offline Root CA and Online Enterprise Subordinate CA. Offline
Root CA meaning you have to shut down the CA once you obtain the CRL
chain for subordinate CA. Subordinate stays powered on and joined to the
domain. Offline Root CA works in a workgroup not a domain member.
Standalone offline Root CA:Benefits:
- Principal component of PKI infrastructure
- Provide CRL sign off capacity for subordinate authority
- Provide Web Enrolment for Sub-ordinate Certificate Authority
- Maintain CAPolicy.inf to record OID and certificate authority validity period
Benefits:
- Subordinate Component of PKI infrastructure
- Present and issue Certificates to clients
- Sign off Web Certificates for application
- Management point of Certificate Infrastructure
- Maintain CAPolicy.inf to record OID and certificate authority validity period
- Analyze and plan necessity of Active Directory Certificates or public key infrastructure (PKI) in your organization before deploying certification authorities (CAs)
- Place database and transaction log files on separate hard drives possibly SAN
- Keep the root certification authority offline and secure its signing key by hardware and keep it in a vault to minimize potential for key compromise
- When changing security permissions for the certification authority (CA), always use the Certification Authority snap-in
- Do not issue certificates to users or computers directly from the root certification authority
- Always point client to subordinate certificate any certificates
- Back up the CA database, the CA certificate, and the CA keys
- Ensure that key lifetimes are long enough to avoid renewal issues
- Review the concepts of security permissions and access control, since enterprise certification authorities issue certificates based on the security permissions of the certificate requester
- Use Secure Sockets Layer (SSL) when using Web-based certificate enrollment
You have to select RSA#Microsoft Software Key Storage Provider” with sha1 if there is any Windows XP Client otherwise select RSA#Microsoft Software Key Storage Provider” with sha256 as certificate provider.
Cryptographic Key Length
Use 2048 bit cryptographic length for both offline Root CA and Subordinate CA.
Templates
- Plan certificate templates before deployment
- Only Publish templates that are necessary
- Duplicate new templates from existing templates closest in function to the intended template
- Do not exceed the certificate lifetime of the issuing certification authority
- Do not delete the Certificate Publishers security group
- Offline Standalone Root CA- 10 Years
- Online Enterprise Subordinate CA- 10 Years
The following sections summarize how certificate revocation checking works.
- Basic chain and certificate validation
- Validating revocation information
- Network retrieval and caching
- Leave the default revocation checking behavior instead of using CRLs for revocation checking
- Instead of creating long listings of URLs for OCSP and CRL retrieval, consider limiting the lists to a single OCSP and a single CRL URL
- Use CryptoAPI 2.0 Diagnostics to Troubleshoot Revocation Settings
- Use Group Policy to Define Revocation Behavior
Select the following Audit Policy for both Certificate Authority
- Backup and restore the CA database
- Change CA configuration
- Change CA security settings
- Issue and manage certificate request
- Revoke certificates and publish CRL
- Backup Public Key
- Backup CA database
- Retention: Daily increment/Monthly Full
The following table summarize certificate security permission in AD CS.
| Domain Computers | Auto-Enroll | Read Only |
| Domain Users | Auto-Enroll | Read Only |
| Wintel Administrator | Full Control | Full Control |
You must create role separation in Active Directory Certificate Services to provide greater control on Certificate Authority. To enable Role separation, Open Elevated command prompt and type certutil -setreg caRoleSeparationEnabled 1. The following table describe role separation for AD CS.
| CA Administrator | Full Permission |
| Certificate Manager | Issue and Manage Certificates |
| Auditor | Manage auditing and security logLocal Security Settings/ Security Settings/Local Policies/User Rights Assignments |
| Backup Operator | Back up file and directories Local Security Settings/ Security Settings/Local Policies/User Rights Assignments |
| Enrollees | Authenticated Users |
- Do not install Certificate Authority on any Domain Controller or server with other roles unless you are a small business and you have only one or two servers in your organization. In this case, you don’t have any choice.
- Do not install both certificate authority in two different operating systems such as Windows Server 2003 and Windows Server 2008.
- Do not keep CAs in different patch and update level.
- Do not use 1024 bit encryption length.
http.araihan.com
Published By
S.G.Godwin Dinesh.MCA
Sr.System Administrator
No comments:
Post a Comment