Windows Server 2008 : Administering Security in an Enterprise-Level Infrastructure

6/7/2011 5:22:36 PM

1. Enterprise Security Concerns

When you're dealing at the enterprise level, two of the primary concerns are implementing a secure public key infrastructure (PKI) and ensuring this infrastructure has secure policies to back it up. Microsoft recommends that before your enterprise implements an infrastructure of any sort, it should have the following three documents easily available to users:

Security policy
Certification policy
Certification practice statement

1.1. Security Policy

A general security policy is a document that outlines the company's security practices and best policies. This typically covers all the computers and other technological assets that the company holds, and it identifies which assets it considers particularly valuable. It also usually contains information on what is considered acceptable use and what is considered a violation of security or a serious security threat.

Without a security policy, the old saying "I didn't know" can become a valid excuse. For example, what if security concerns mandate that a certain folder on the infrastructure server can never have its name changed? If a user doesn't know this, they can always use the "I didn't know" excuse after the folder's integrity has already been compromised.

1.2. Certification Policy

Although not used by all organization, a good practice when implementing a complicated certificate structure is to implement a certification policy that outlines the processes and measures taken to ensure both the validity of a user and the validity of the certificate they are using. This may be something as simple as an email to a higher certificate authority requesting permission for a certificate or as complex as an intensive background check. Either way, outlining this policy can ease some of the burden of informing users how to attain and manage certificates.

1.3. Certification Practice Statement

The last document recommended by the Microsoft best practices for a public key infrastructure is a certificate practice statement (CPS). According to Microsoft, a CPS essentially outlines how a certificate authority manages its security and certificates.

2. Using Windows Server 2008 PKI Additions in a Legacy Environment

Although you are most likely familiar with all of these technologies from your previous study of Windows certificate services for your 70-640, 70-642, and 70-643 exams, it's important to note that in order to support Windows Server 2008, you must update the schema master to support the new Windows Server 2008 features of the public key infrastructure, including the following:

Version 3 certificate template support
Online responders
Network device enrollment
Qualified certificates

For more information on how to update your organization's schema operations master, see Windows Server 2008 Active Directory Configuration by William Panek (Sybex, 2008).

3. Designing a Certificate Authority Hierarchy

The underlying fabric of any public key infrastructure is the design of the underlying certificate authorities. This includes the number of certificate authorities (CAs), as well as what type of certificates they will use and how the certificate authorities will be used, implemented, and so forth.

3.1. Choosing a Tier Model

The first step in creating a CA hierarchy is to choose an effective tier-design model. Therefore, the best way to start a certificate services design is to decide how many servers are going to be operating as certificate authorities and how the process of accessing certificates from these CAs will proceed.

According to Microsoft best practices, certificate authorities can exist in single-, two-, three-, or even four-tiered models, each of which has its own advantages and reason for implementation. In the following sections, I will briefly touch on each of these models and highlight the strengths and weaknesses of each.

3.1.1. Single-Tier CA Structure

For our purposes, the discussion of this level of structure is relatively moot. This is because a single-tiered CA hierarchy is usually used only in small organizations, typically with fewer than 300 user accounts. The focus of the enterprise-level exam is organizations that have more than 5,000 employees.

Regardless, in a single-tier CA infrastructure, the CA is a member server of the domain that exists as the only enterprise root-level certificate authority. Obviously, the advantages of this design are that it is both easy to design and easy to implement. However, it is limited. For example, there is absolutely no available backup. If the main root authority fails, then the entire structure fails. Furthermore, without additional tiers to rely upon, a single member server issuing certificates can (and most likely will) become overburdened in a large organization.

3.1.2. Two-Tier CA Structure

In a two-tiered CA structure, multiple levels of certificate servers perform different roles. Best practices dictate that at the top of the tree the root-level enterprise authority is stand-alone. That is, it exists apart from the network for the sake of security. Then, below that root-level authority, other member servers exist to issue certificates, as shown in Figure 1.

In this figure, the root certificate authority exists independently from the rest of the network, and the extending second-tier computers can either issue certificates or exist as policy issuance certificate authorities. Policy issuance CAs are similar to certificate authorities, except they define the way certificates can be issued but often do not issue certificates themselves.

The advantage of this design is that it allocates a single level of infrastructure for each of the roles being played in the process of dispersing certificates. Furthermore, it adds more physical security because it creates barriers of separation between the root CA, the policy CA(s), and the issuing CAs.

Figure 1. Two-tier CA hierarchy

Figure 2. Three-tier CA hierarchy

3.1.3. Four-Tiered Structure

A four-tiered CA structure is often used in organizations that have to issue many certificates and require an infrastructure that can support that need. Using a fourth tier, the issuing CAs that existed in the previous three-tier structure expand into a new layer of certificate authorities that build on the previous third tier and create a new tree structure that sort of resembles a "multitiered" third tier. This is pictured in Figure 3.

Figure 3. Four-tiered structure

4. Modeling Your Structure

When choosing how to design your CA hierarchy, one of the first decisions to make—before you make any other crucial decision—is to pick the model that your entire PKI follows. What this means is that you need to answer the following question: Will the CA architecture follow the administrative structure, or will it follow its own independent structure?

4.1. Following the Administrative Structure

One of the most commonly practiced methods of working with a PKI is to model it to mirror your organization. You can model the CA structure the same way. If the organization has multiple branch offices, you can model them with certificate authorities that represent each branch office. If there are multiple departments, you can implement multiple servers that follow the model of each department.

The advantage of this method is that it is simple and creates uniformity in your infrastructure. Both Active Directory and certificate services will follow the same architecture, making it easy for administrators at all levels to understand

4.2. Following an Independent Structure

A case can be made that it is best to have a CA follow a structure that is independent of the standardized methods established by your Active Directory structure. For one thing, there may be organizational or legal standards that require your CA to be placed in a manner set apart from the Active Directory structure. This plays an especially important role in compliance with government standards and industry regulations. Some organizations, such as the FBI or CIA, might require that sensitive security data be laid out in a fashion that may seem strange at first but is ultimately the most secure method.

5. Design Factors

As I discussed earlier in this book, these are some of the major factors that play into your design decision:

Organizational requirements
Software requirements
User requirements
Business requirements

Only you, the administrator, can make these decisions (or perhaps you and several other people tasked with the duty). But the point is that all of these factors have to go into making the decision, and it can't be taken lightly. Usually, the decision of how to implement a CA structure is labored over for several weeks. Think about it. In the modern day, even jump drives can be issued certificates. Just think about how many keys there can be floating around if there are 10,000 of those devices in your enterprise!

6. X.509

An X.509 digital certificate is the most common form of certificate used in modern infrastructures. It contains information regarding the owner of the certificate, the public key of that certificate, and certain other fields:

Version number
Serial number
Algorithm identifier
Issuer name
Validity
Subject name
Subject public key information
Issuer unique identifier
Subject unique identifier
Key identifier

X.509 certificates can be used in almost every area of security, including just about any form of communication or application. The main function of a certificate, as you know from your study at the MCTS level, is to link a user with certain identifiers that label them as an individual (or entity) that your infrastructure can recognize and authenticate in a process called verification.

NOTE

There are three versions of X.509:

X.509 version 1
X.509 version 2
X.509 version 3

You do not need to understand the intricate differences among these three versions to become a capable administrator.

7. Using Certificate-Monitoring Tools

For the certification exam, you need to be familiar with two important and useful certificate-monitoring tools that come with Windows Server 2008:

pkiview.msc

The pkiview.msc command launches the PKI Health tool, which allows you to monitor the activity and health of your currently existing public key infrastructure. Additionally, it monitors Authority Information Access (AIA) and CRL distribution (CDP) extensions to ensure that the line of communication for the distribution of authority for certificates is properly monitored.

certutil.exe

The certification utility (certutil.exe) command allows you to determine the validity of issued certificates through the use of two switches:

-verify -urlfetch
-viewstore

Using the –verify –urlfetch FileName switch allows you to see the output of the URL for each certificate. If it succeeds, it will display a "verified" output. If it fails, it will display an "error" output.

The –viewstore output allows you to see the contents of a specific Active Directory Domain Services store or object, which lets you choose to view all certificates in that store.

8. Reasons for a PKI

Whenever an organization uses technologies such as smart cards, IPsec, SSL, digital signatures, EFS, or other technologies that rely upon levels of encryption, the organization needs to create a public system of encryption and identification. But the most common reason for using a system of certificates is Secure Sockets Layer (SSL), which verifies a user's identity and securely transmits data. Without a system of certificates, this would be almost impossible.

Therefore, in most companies, because of the need for the Web, there have been numerous examples of simple PKIs just to support a website on IIS. Without a PKI and certificates, you can't even use HTTPS!

9. Components of the Public Key Infrastructure

The PKI (the technology that your infrastructure uses to validate the identity of user or entities) is composed of many different components, but at the MCITP level you are primarily concerned with the following:

Certificates
Certificate authorities (CAs)
Certificate revocation lists (CRLs)
Certificate templates
The Online Certificate Status Protocol

Some of the material you may read here will seem like review—and some of it may be. But remember, on the Enterprise Administrator certification exam the strongest concentration of material is not necessarily on any one new technology but on a mix of all technologies available to you within a modern infrastructure and your ability to apply those technologies in complex situations.

9.1. Certificate Authority

A certificate authority is part of the PKI that is responsible for validating certificates, issuing certificates, and revoking certificates. At a minimum, an enterprise using Active Directory Certificate Services (AD CS) must have at least one CA that issues and revokes certificates. Normally, there's more than one CA deployed in an organization. Additionally, CAs can be either internal or external and can exist at several different levels, acting as a root CA or an issuance-only CA, for example.

9.2. Certificate Revocation Lists

When certificates are revoked before their period of expiration, they are added into a list called a certificate revocation list. Within Windows Server 2008, there are two types of CRLs: base CRLs and delta CRLs.

Base CRLs are complete lists of certificates revoked by a CA; this list also contains the reason for their revocation. A delta CRL, on the other hand, contains only the serial numbers and revocation reasons for a revoked certificate that has been revoked since the original incarnation of the base CRL. It's sort of like a differential backup, because it lists only what has changed since the original list was added.

9.3. Certificate Templates

Certificate templates are categories of certificates that allow AD CS to store certificates within Active Directory and categorize them according to how they are used and what they contain. They are still relatively new and can be used with either Windows Server 2003 or Windows Server 2008. In effect, what a certificate template does is issue a set of rules that can be applied to certificates, such as where certificates can come from and how they can be created.

7.10. Certificate Authority Roles

Within the enterprise, the PKI is usually comprised of multiple certificate authorities, each of which contains one of several roles. These range from the most fundamental of all roles—the root CA role—to a simple CA issuing certificates, all of which fit somewhere within the CA hierarchy.

10.1. Root CA Role

The root CA in an organization is the first installed and most important CA in the entire infrastructure. Ultimately, the root CA contains the authority to sign certificates as well as authorize other subordinate CAs throughout the organization. And authorizing subordinate CAs is the activity that most root CAs spend the majority of their time undertaking.

Logically, what happens with a root CA is that whenever a client or subordinate receives a certificate, the client will validate that the certificate is trusted by the root CA. Thus, because of this vital role, most root CAs are kept offline, protected from the outside world and stored in a secure location for fear of being compromised.

10.2. Intermediate CA Role

An intermediate CA is any certificate authority that exists outside the role of the root CA and issues certificates to other CAs somewhere in the CA hierarchy. Normally, this intermediate CA exists in a state between the root CA (which is offline) and the issuing CAs, which are online. This way, issuing CAs have a method of contacting the root CA while ultimately exposing the root CA's private key the minimum number of times.

10.3. Policy CA Role

The policy CA is technically a subcategory of intermediate CA, but it has a special category in and of itself because of the vital part it plays within a Windows Server 2008 infrastructure. Within that infrastructure, a policy CA contains the policies and procedures an organization uses to secure and validate both the CA and the certificate holder identity. Normally, policy CAs communicate only with other CAs.

10.4. Issuing CAs

By far, the most common and lowest-level certificate authority is the CA that is responsible for actually distributing certificates to users and devices within the infrastructure—the issuing CA. Typically, the issuing CA receives policies from a higher-level policy CA and responds to requests for certificates and other information. However, an issuing CA is capable of holding its own policies and making its own policy decisions in a smaller architecture, such as a one- or two-tiered hierarchy .

10.5. Enterprise and Stand-Alone CAs

It's most likely that you have encountered an explanation of enterprise and stand-alone CAs in your previous study, but in case you have forgotten, an enterprise CA is a CA that takes advantage of Active Directory to control the enrollment process. Thus, because it involves the use of Active Directory, it can logically be further controlled and refined through the use of Group Policy.

Stand-alone CAs do not take advantage of Active Directory and cannot be managed by Group Policy. Furthermore, stand-alone CAs are limited to either web-based or command-line deployment.

11. Using the Online Certificate Status Protocol

One of the drawbacks of using certificates is that as the number of certificates grows, expires, or ultimately become revoked, the number of revoked certificates in the CRL becomes very large and cumbersome to send back and forth. Using the Online Certificate Status Protocol (OCSP), administrators are able to implement a system that, instead of sending the complete list of revoked certificates, is able to respond to a request about a single certificate within the organization. This greatly reduces the amount of data traffic and optimizes the infrastructure for other tasks.

11.1. Online Responders

Any computer that is currently running the Online Responder service can function in the online responder role. The responsibility of the Online Responder service is to communicate responses upon requests for OCSP responses, along with the use of CRLs. Normally, in the enterprise architecture the online responder is an individual machine that is responsible only for the online responder role.

According to Microsoft, online responders can respond to requests much more quickly stances involving the following:

External clients connected via low-speed WAN connections
Overloaded networks
An organization with numerous certificates
An organization that does not want all expired certificate data to be exposed

In Windows Server 2008, Microsoft encourages the use of the OCSP with its responder system over the use of traditional CRLs to increase the network efficiency of your infrastructure capabilities.

NOTE

Responses from online responders are digitally signed and indicate the status of only the certificate to which they have been requested to respond.

The online responder server should be set up and running the Online Responder service before any client certificates are issued. This server must be running Windows Server 2008, but the data can come from a published CRL, which can exist on either Windows Server 2008, Windows Server 2003, or even a non-Microsoft CA.

However, in order to install the Online Responder service, the following prerequisites must be met:

IIS installed and operating
OCSP response signing certificate template must be configured on the CA with autoenrollment
URL placed in the AIA extension of certificates by the CA

Other -----------------

- Windows Server 2008 : Designing a Windows Update Strategy for the Enterprise - WSUS Options

- SQL Server 2008 : Monitoring Your Memory (part 2) - Memory with SQL Server Counters & Memory with DMVs and DBCC Commands

- SQL Server 2008 : Monitoring Your Memory (part 1) - Counters to Watch & Memory with Windows Counters

- Windows Server 2008 : Designing a Windows Update Strategy for the Enterprise - Planning and Implementing Windows Software Update Services (WSUS)

- Windows Server 2008 : Designing a Windows Update Strategy for the Enterprise - System and Environment Health Models

- Windows Server 2003 : Troubleshooting TCP/IP Routing

- Windows Server 2003 : Securing Remote Access

- Windows Server 2003 : Static and Dynamic Routing

- Microsoft Exchange Server 2003 Security : Protecting Against Computer Viruses

- Microsoft Exchange Server 2003 Security : Managing Connectivity Across Firewalls