Introducing Active Directory Certificate Services
Introducing the Public Key Infrastructure
Installing Active Directory Certificate Services
Configuring Certificate Revocation
Configuring Certificate Templates
Managing Certificate Enrollments
Configuring CA Server Settings
Sherbimet e certifikatave jane pjese e zgjidhjes se Microsoft per Identity Lifecycle Management.
Introducing Active Directory Certificate Services
THE BOTTOM LINE
The new Active Directory Certificate Services (AD CS) role in Windows Server 2008 is a component within Microsoft's larger Identity Lifecycle Management (ILM) strategy.
ILM enables network administrators and owners to configure access rights for users during the users' entire lifecycle within an organization. This includes providing a user account, modifying access rights as a user's role changes within an organization, and finally deprovisioning a user account when die user's relationship with an organization is ended.The role of AD CS in ILM is to provide services for managing public key certificates that can be used by any security system that relies on a PKI for authentication or authorization.
Introducing the Public Key Infrastructure
Before you can deploy AD CS, it is important to understand how a public key infrastructure (PKI) works, because the AD CS role in Windows Server 2008 allows you to deploy and manage your own PKI as well as interoperate with PKI deployments in other environments. The ultimate purpose of a PKI is to provide assurances that, when you are communicating with an external entity (a reputable online retailer, for example), you can confirm that you are actually dealing with the entity that you think you are dealing with, rather than someone pretending to be diat entity (such as a hacker pretending to be a reputable online retailer to steal credit card information). Although a full discussion of the mathematics and architecture of PKI is beyond the scope of this book,this lesson provides a high-level understanding of how PKI works as well as the terminology that you need to know.
In brief, a public key infrastructure (PKI) consists of a number of elements that allow two parties to communicate securely, without any previous communication, through the use of a mathematical algorithm called public key cryptography. Public key cryptography, as the name implies, stores a piece of information called a public key for each user, computer, and so on that is participating in a PKI. Each user, computer, and so on also possesses a private key, a piece of information that is known only to the individual user or computer. By combining the well-known and easily obtainable public key with the hidden and well-secured private key, one entity (you, for example) can communicate with another entity (a secured
Web site, for example) in a secure fashion without exchanging any sort of shared secret key beforehand. A shared secret key is a secret piece of information that is shared between two parties prior to being able to communicate securely. Although securing communications using a shared secret can often be more efficient due to the simpler mathematical algorithms involved, it is far less flexible and scalable to deploy than a PKI. Imagine, for example, if everyone on the Internet needed to create and exchange one of these secret keys when they wanted to buy something from a secured Web site; e-commerce as we know it would scarcely be as prolific as it has become over the past decade. When working with a PKI, you will encounter the following terms:
• Certification authority (CA). A CA is an entity, such as a Windows Server 2008 server running the AD CS server role, that issues and manages digital certificates for use in a PKI. CAs are hierarchical, which means that many subordinate CAs within an organization can chain upwards to a single root CA that is authoritative for all Certificate Services within a given network. Many organizations use a three-tier hierarchy, where a single root CA issues certificates to a number of intermediate CAs, allowing the intermediate CAs to issue certificates to users or computers.
• Digital certificate. Sometimes just called a certificate, this digital document contains identifying information about a particular user, computer, service, and so on. The digital certificate contains the certificate holder's name and public key, the digital signature of the Certificate Authority that issued the certificate, as well as the certificate's expiration date.
• Digital signature. This electronic signature (created by a mathematical equation) proves the identity of the entity that has signed a particular document. Like a personal signature on a paper document, when an entity signs a document electronically it certifies that the document originated from the person or entity in question. In cases where a digital signature is used to sign something like an email message, a digital signature also indicates that the message is authentic and has not been tampered with since it left the sender's Outbox.
• Certificate Practice Statement (CPS). The CPS provides a detailed explanation of how a particular CA manages certificates and keys.
• Certificate Revocation List (CRL). This list identifies certificates that have been revoked or terminated, as well as the corresponding user, computer, or service. Services that utilize PKI should reference the CRL to confirm that a particular certificate has not been revoked prior to its expiration date.
• Certificate templates. These are templates used by a CA to simplify the administration and issuance of digital certificates. This is similar to how templates can be used in other applications, such as office productivity suites, or when creating objects within Active Directory.
• Smart cards. These small physical devices, usually the size of a credit card or keychain fob, have a digital certificate installed on them. By using a smart card reader, a physical device attached to a workstation, users can use a smart card to authenticate to an Active Directory domain, access a Web site, or authenticate to other secured resources, typically by entering a numeric personal identification number (PIN) instead of a password. By using smart cards for authentication, you can implement two-factor authentication; that is, basing authentication on something that the user knows (in this case, a password or PIN number) in combination with a physical token that the user possesses (in this case,the smart card).
• Smart card enrollment stations. These are workstations (typically dedicated to this task) that are used by administrators to preconfigure smart cards for use by local or remote network users.
• Self-enrollment. As the name suggests, this feature enables users to request their own PKI certificates, typically through a Web browser.
• Enrollment agents. These are used to request certificates on behalf of a user, computer,or service if self-enrollment is not practical or is otherwise an undesirable solution for reasons of security, auditing, and so on. An enrollment agent typically consists of a dedicated workstation that is used to install certificates onto smart cards, thus preconfiguring a smart card for each person's use. Certificate Services in Windows Server 2008 allows you to configure one or more restricted enrollment agents to limit the permissions required for an enrollment agent to configure smart cards on behalf of other users. This is designed to enable larger companies to adhere to the principle of least privilege, a security best practice that dictates that users should receive only the minimum amount of privileges needed to perform a particular task, even in cases where these companies need to install enrollment agents in remote locations. You can configure a restricted enrollment agent so that they can only request certificates on behalf of certain users, computers, or groups of users or computers.
• Autoenrollment. This PKI feature supported by Windows Server 2003 and later allows users and computers to automatically enroll for certificates based on one or more certificate templates, as well as using Group Policy settings in Active Directory. Because this feature is only supported in Windows Server 2003 or later, certificate templates that are based on Windows 2000 will not allow autoenrollment to maintain backwards compatibility.
• Recovery agents. These agents are configured within a CA to allow one or more users (typically administrators) to recover private keys for users, computers, or services if their keys are lost. For example, if a user's hard drive crashes and the user has not backed up the private key, any information that the user has encrypted using the certificate will be inaccessible until a recovery agent retrieves the user's private key.
• Key archival. This is die process by which private keys are maintained by the CA for retrieval by a recovery agent, if at all. Most commercial CAs do not allow key archival; if a customer loses a private key and has not taken a backup, the user needs to purchase a new certificate. In a Windows PKI implementation, users' private keys can be stored within Active Directory to simplify and automate both the enrollment and retrieval processes.
Within Windows Server 2008, the Active Directory Certificate Services server role consists of the following services and features:
• CAs, as mentioned previously, issue and manage PKI certificates to users, computers, and services on a network. CAs can exist in a hierarchical structure consisting of a root CA and one or more subordinate CAs beneath the root.
• Web enrollment. This feature enables users to connect to a Windows Server 2008 CA through a Web browser to request certificates and obtain an up-to-date Certificate Revocation List.
• Online Responder. This service responds to requests from clients concerning the revocation status of a particular certificate, returning a digitally signed response indicating the certificate's current status. The Online Responder is used in situations where a traditional CRL is not an optimal solution. Instead, the Online Responder uses the Online Certificate Status Protocol (OCSP) to return certificate status information to the requester; as the name suggests, this protocol is used to respond to queries from clients who requested data about the status of a PKI certificate that has been issued by a particular CA. OCSP transactions must be digitally signed, which can be enabled by using an OCSP Response Signing certificate template on any CA that will be used as an Online Responder. You can configure a single Online Responder to service certificate status requests or you can deploy Responder arrays, multiple Online Responders that are linked together to process status requests.
• Network Device Enrollment Service (NDES). This service allows devices such as hardware-based routers and other network devices and appliances to enroll for certificates within a Windows Server 2008 PKI that might not otherwise be able to do so. This service enrolls these devices for PKI certificates using the Simple Certificate Enrollment Protocol (SCEP), a network protocol that allows network devices to enroll for PKI certificates.
When deploying a Windows-based PKI, two different types of CAs can be deployed:
• A standalone CA is not integrated with Active Directory. It requires administrator intervention to respond to certificate requests. You can use a standalone CA as both a root and a subordinate CA in any PKI infrastructure.
• An enterprise CA integrates with an Active Directory domain. It can use certificate templates to allow autoenrollment of digital certificates, as well as store the certificates themselves within the Active Directory database. You can use an enterprise CA as both a root and a subordinate CA in any PKI infrastructure.