Windows 2000 Network Infrastructure Exam Cram 2 (Exam 70-216)
Authors: Huggins D.
Published year: 2005
Need to Know More?
Search the online version of TechNet and the Windows 2000 Server Resource Kit using keywords such as ICS and NAT .
Minasi, Mark, Christa Anderson, Brian Smith, and Doug Toombs. Mastering Windows 2000 . Sybex Press, Alameda, CA. ISBN: 0782140432.
Microsoft Corporation. Microsoft Windows 2000 Server Resource Kit . Microsoft Press. ISBN: 1572318058. This book provides in-depth information about all aspects of Windows 2000 server, including Network Address Translation.
Chapter 9. Certificate Services
Terms you'll need to understand:
Techniques you'll need to master:
As security becomes more important in today's network environments, there needs to be a secure method of passing information between hosts . One of the most common ways of doing this is through the use of digital certificates.
Organizations have the option of using a commercial company to issue digital certificates. They can also use Certificate Services, included with Windows 2000. Certificate Services enables the creation of a Public Key Infrastructure (PKI), which allows data to be encrypted, and computers and users to be verified and authenticated. Certificate Services establishes a system of trust.
This chapter covers the fundamentals behind certificates, including how to install, configure, and manage Certificate Services.
Understanding Certificate Authorities
When implementing certificates for security purposes, organizations can opt to use a commercial certificate provider or it can use a tool called Certificate Services , which is included with Windows 2000. In either case, before implementing any certificate infrastructure, it is important to understand certificates and certificate authorities.
A certificate is a digital statement from a trusted authority used for verification purposes. The certificate is used to validate the entity bound to a public key . In other words, the certificate confirms that the holder of the key is who he claims to be. The entity issued a certificate can be a person, computer, organization, or a device, such as a router.
PKI and Public/Private Keys
A Public Key Infrastructure (PKI) is a system that employs the use of digital certificates, public and private keys, and certificate authorities to secure communications. The digital certificates provide a way of verifying an individual's identity. The public and private keys are used to secure data that is exchanged. The certificate authorities are responsible for generating the key pair and issuing the digital certificates.
Public and private keys ensure data being sent between parties is secure. They also ensure that the entity sending the data is who they claim to be. Once a key pair is generated, the private key is given to the individual who made the request. The public key is made available to others as part of the digital certificate. When a message is encrypted using a public key, only the individual holding the corresponding public key can decrypt it. For example, if Sean wants to send Doug a secure message, he can locate Doug's public key and use it to encrypt the message (remember the public keys are made available to other parties, not the private keys). Once the message is encrypted, only Doug can decrypt it using his private key. Likewise, if Sean wanted to authenticate himself to Doug, he could encrypt a digital certificate using his own private key. Doug can then use Sean's public key to decrypt it.
For an entity to be part of a PKI , it must have a public and private key as well as a certificate. Before a certificate can be issued, a key pair must be generated. The key pair is usually generated by the Cryptographic Service Provider (CSP). The CSP provides the encryption and signature algorithms and determines the algorithms and key lengths used with a certificate. Once the key pair is generated, a request can be submitted to a Certificate Authority (CA). Depending on how CAs are implemented, this request may be sent to a third-party certificate service or to a CA on the internal network (CAs are discussed in the following section). The request for a certificate includes the public key of the requestor as well as any other required information, such as name and email address. If the certificate is issued it will include the following information:
Some of the reasons for implementing certificates include:
A Certificate Authority (CA) is an entity that has been assigned to issue certificates to users, computers, and organizations. There are two options when using CAs. You can use a third-party CA, such as VeriSign (www.verisign.com), or you can create your own CA using Certificate Services.
Certificate requests are submitted to a CA to verify the requestor. In other words, the CA verifies that the person requesting a digital certificate is indeed who they claim to be. This verification is an important step in the information security process. By having a trusted third party, such as VeriSign, identify and legitimize the requestor, entities wanting to transfer data to the requestor can rest assured that they are dealing with a trustworthy and secure party.
Not only is the CA responsible for issuing digital certificates, it is also responsible for revoking them. The CAs publish a list of all revoked certificates to identify which entities no longer have the trusted credentials given by the CA (revoking certificates is discussed later in this chapter).
Because a CA is responsible for sensitive information, it's important that security measures are in place to protect it. First of all, the CA should be physically protected, meaning it should be placed in a secure location accessible only by administrators. Because the CA's private key is the basis for trust in the certification process, this too must be secured.
The CA's private key is used to sign all issued certificates. For example, if Mike receives a digitally signed message from Dana, he can verify her identity by using the CA's public key to decrypt the signature (that was signed using a private key). If the CAs signature is valid, and the information contained within the certificate is valid, Mike can be assured that the message is in fact from Dana.
The cryptographic hardware module can provide tamper-resistant key storage and protect the CA's private key. Finally, you must also consider the possibility of losing a CA. This can obviously cause a number of problems. Certificate Services supports backing up the certificate instance so it can be restored in the event of failure.
Certificate Authority Hierarchies
CAs are organized into hierarchies, similar to the way in which Windows 2000 domains are organized. The top level of the hierarchy consists of a root CA, or root authority, which is responsible for issuing certificates to other CAs. All other CAs then branch off the root, thus creating a parent-child relationship. These CAs are also referred to as subordinate, or child, CAs. Child CAs are certified by their parent CA. A CA hierarchy essentially creates a model of trust. Each child CA trusts its parent CA with the trust path leading back to the root authority.
There are a number of benefits to creating a hierarchy of certificate authorities. Multiple CAs enable you to designate specific CAs to be responsible for issuing specific types of certificates. Depending on the structure of the organization, it can allow each department or geographical location the ability to maintain its own CA. It also offers another level of security because users and computers are not in contact with the root CA to get their certificates. Instead they are issued a certificate by one of the subordinate CAs. Additionally, it gives administrators the ability of taking the root CA offline.
Certificate Authority Classes
Windows 2000 supports two classes of Certificate Authorities: Enterprise CAs and Standalone CAs . The type of CA you implement depends on to whom you are issuing certificates. For example, a standalone CA would be implemented to issue certificates to entities such as partners or clients outside of your organization. An Enterprise CA would be implemented to issue certificates to entities within the organization. The differences between the two types are outlined in the following sections.
Enterprise Certificate Authorities
An Enterprise CA provides certificates to users and computers within an organization. An Enterprise CA is automatically registered in Active Directory and trusted by all computers in that AD domain.
Enterprise CAs have the following features:
Standalone Certificate Authorities
In an environment without Active Directory, you can implement Certificate Services using a Standalone CA. Standalone CAs are also implemented if certificates are being issued to entities outside the organization, for example, to business partners or vendors . Standalone CAs have the following characteristics:
Certificate Authority Types
Now that you are familiar with the two general classes of CAs, let's take a look at the different CAs that can exist within a certificate hierarchy. The four types of CAs supported by Windows 2000 are as follows :
The following sections help you become more familiar with each of these CA types.
Enterprise Root CAs
At the top level of an enterprise certificate authority hierarchy is the Enterprise Root CA. Once the CA is configured, it is automatically registered within Active Directory and trusted by all computers within the domain.
In a CA hierarchy, the Enterprise Root CA is usually responsible for issuing certificates to subordinate CAs, which then issue the certificates to users and computers on the network. The Enterprise Root CA can also issue certificates directly to users and computers if required.
Enterprise CAs have the following requirements:
Enterprise Subordinate CAs
In a certificate hierarchy, an Enterprise Subordinate CA exists under an Enterprise CA. Enterprise Subordinate CAs are usually created for a specific purpose, such as issuing certificates to a particular part of an organization. To configure an Enterprise Subordinate CA, an Enterprise Root CA must be present. This can be an Enterprise Root CA on the local network or a third-party root CA.
Standalone Root CAs
If Active Directory is not installed, a Standalone CA is the only type of CA that can be configured. It requires only administrative privileges on the local computer. If your organization needs to issue certificates to entities outside of the organization, a Standalone CA should be implemented All certificate requests are then held as pending until an administrator approves them.
Standalone Subordinate CAs
A Standalone Subordinate CA is very similar to an Enterprise Standalone CA, except it does not require Active Directory. To successfully install a Standalone Subordinate CA, there must already be a root CA in place. Again, this can be a root CA within the organization or from a third party. Also, keep in mind the administrative privileges requirement on the local server.
Windows 2000 Network Infrastructure Exam Cram 2 (Exam 70-216)
Authors: Huggins D.
Published year: 2005