Cryptography is the practice of hiding information, commonly used in security scenarios such as ATM cards and passwords. Two cryptographic functions are supported:

Encryption is the process of transforming information (referred to as plain text) using an algorithm (a cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key. The result of the process is encrypted information (referred to as cipher text in cryptography). In many contexts, the word encryption also implicitly refers to the reverse process, decryption (such that “encryption software” will also perform decryption), that is, to make the encrypted information readable again by making it unencrypted.

Symmetrical encryption uses a single key for encryption, which both the sender and receiver will leverage to decrypt the transmissions. When data is encrypted with a symmetric algorithm, the sender generates a random symmetric key. The algorithm and the application determine the bit-length of the key. Figure 11.1 illustrates the symmetrical encryption process.

Figure 11.1. The symmetrical encryption process

Asymmetric encryption uses a key pair. The keys that make up the key pair are mathematically related and referred to as the public and private keys. Public keys are distributed freely. You can publish them to Active Directory (AD) and install them via auto-enrollment. The “Deploying Certificates” section of this chapter covers auto-enrollment. The use of this key pair ensures that only the recipient has access to the necessary private key to decrypt the data. Figure 11.2 illustrates the asymmetrical encryption process.

Figure 11.2. The asymmetrical encryption process

The following points define the process illustrated in Figure 11.2:

Two inputs are required when encrypting data:

The algorithm defines how to convert the data to the cipher text, and the key is used to input the data into the algorithm. Figure 11.3 illustrates the asymmetrical signing process.

Figure 11.3. The asymmetrical signing process

The following steps demonstrate how in Figure 11.3 you can validate the sender’s identity and that the data was not altered:

This encryption process protects the data, or payload, from being intercepted and read, viewed, or altered. If it were intercepted, the decryption process would fail, thus letting the recipient know there was a breach.

Digital signing is used to prove the source and integrity of the data. Using a hash algorithm, digitally signed data can be trusted to be the original content. Hash algorithms such as MD5 (Message Digest 5) and SHA1 (Secure Hash Algorithm 1) apply a mathematical formula to an object, resulting in output known as a hash value, message digest, or just digest. Hashes cannot be reversed, making them very useful in verifying data integrity.

Refer to Chapter 6, “Architecture Design Planning,” for specific detail on how ConfigMgr utilizes certificate services.

Both SSL (Secure Sockets Layer) and TLS (Transport Layer Security), which is replacing SSL, are cryptographic protocols providing security and data integrity for communications over TCP/IP (Transmission Control Protocol/Internet Protocol). SSL encrypts the segments of the Transport layer protocol, which is Layer 4 of the Open Systems Interconnection (OSI) model. An SSL client and server negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection’s security:

The client may contact the server that issued the certificate (the trusted CA, as before) and confirm the certificate is authentic before proceeding:

This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes. If any one of the preceding processes fails, the SSL handshake fails and the connection is not created.

TLS and SSL have a variety of security measures:

Microsoft provides native support for PKI in Windows Server 2003 and 2008 Active Directory. If you are running Windows 2000 Active Directory, special considerations are necessary because you must upgrade the schema to the Windows Server 2003 schema. This requires Windows 2000 domain controllers to be on SP 3 at a minimum. If you are running Windows 2000 Active Directory, refer to http://support.microsoft.com/kb/325379 and http://support.microsoft.com/kb/314649 for steps and precautions before upgrading the schema or Active Directory to the 2003 version.

With Microsoft Windows 2003 or 2008 Active Directory, the only configuration required for an Enterprise CA is if you have an Active Directory forest with multiple domains. In this scenario, you must add the CA’s computer account to each domain’s built-in Cert Publishers local group.

Certificate templates do just what you would expect: They let the CA issue certificates preconfigured with specific settings or information. Windows Server 2003 supports version 1 and 2 certificate templates. Windows Server 2008 supports version 3, although ConfigMgr does not currently support this version. Certificates templates are stored in the configuration naming context in the following location:

Version 1 certificate templates are only capable of having their permissions modified. Version 2 certificate templates allow you to create new templates by duplicating existing version 1 or 2 templates.

ConfigMgr requires the use of the following certificate templates:

Detailed requirements for the certificate templates and the data the templates must contain can be found at http://technet.microsoft.com/en-us/library/bb680733.aspx, in the “Certificate Requirements for Native Mode” section.

Certificate validation guarantees that the information contained in the certificate is authentic, what the certificate is to be used for, and that the certificate is trusted. When you enable Certificate Revocation List checking, the Windows OS using the certificate validates each certificate in the chain until it reaches the CA.

CRL checking is the process of searching for revoked certificates on a server. The default setting for ConfigMgr in native mode is that the clients validate their certificate against the CRL. Although disabling CRL checking is not a best practice, some technologies offer scenarios where CRL checking may not be necessary or ideal. As an example, Windows mobile devices cannot perform CRL checking. You can disable CRL checking using one of two methods:

Certificate validation also includes certificate discovery and path validation:

These checks include verifying Authenticode signatures, determining if the issuing CA certificate is already in the certificate store, and checking for policy object identifiers.

Once the PKI is built and the certificate templates are in place, ConfigMgr administrators can begin issuing certificates to sites, site systems, and clients. There are a number of ways to deploy the certificates to each.

Here are some good reference materials for certificates and PKI:

Network Policy Server is Microsoft’s replacement technology in Windows Server 2008 for Internet Authentication Service (IAS) in Windows Server 2003. IAS only provided a subset of NPS’s capabilities. Both IAS and NPS allow administrators to route traffic authentication against AD for remote access and enforcement of network access. Both technologies offer these capabilities:

NPS now lets administrators centrally configure and manage network policies with the following three features: RADIUS (Remote Authentication Dial-In User Service) server, RADIUS proxy, and NAP policy server. NPS also allows centralized connection authentication, authorization, and accounting for many types of network access, including wireless and virtual private network (VPN) connections.

NPS’s full suite on functionality and capabilities includes the following:

NPS is available on all Windows Server 2008 editions except Microsoft’s Web Server 2008.

NAP policies in ConfigMgr evaluate clients and verify if they have the required updates. ConfigMgr then sends the NPS the SoH from the client and a list of remediation servers. NPS then determines whether the client will be granted full network access or restricted network access, and whether the computer can be remediated if found to be out of compliance. NPS supports the following policies for NAP clients:

NAP in ConfigMgr 2007 builds on the capabilities and automation routines offered natively in NPS. The integration of NPS in ConfigMgr creates some very sophisticated possibilities for administrators to secure their network environment. The value of NAP increases exponentially as the number of mobile systems in an environment increase.

ConfigMgr NAP is a feature that allows administrators the ability to enforce compliance of software updates, or restrict access, on client computers to help protect the integrity of the network. NAP is managed via policies that the clients download. Administrators define their requirements for connectivity to the environment. The client checks its configuration against that which is defined, and generates a client Statement of Health. This SoH is sent to the SHV, a ConfigMgr role. The SHV evaluates what is required if the client is out of compliance and offers options defined by the administrator for remediation. The remediation process may be user interactive or completely silent, depending on the administrative desires for the specific deviation from compliance. If the client does not have current NAP policies, the agent will kick off a machine policy refresh, which includes the latest NAP policies, and then reevaluate its health and send a more current SoH.

NAP’s success hinges on software update management (SUM). If SUM is not working correctly, clients can be accidently quarantined without the capability of remediation. Do not NAP-enforce software updates without approving and distributing those updates, because clients will otherwise be unable to remediate. An exception to this is for those highly critical patches, where the risk of infection is greater than network access by the non-compliant user or system.

ConfigMgr clients generate an SoH when the NAP agent requests it from the ConfigMgr client. The ConfigMgr client sends the SoH to the ConfigMgr SHV for verification. The SHV then sends a Statement of Health Response (SoHR) containing the client health state to the NPS. The NPS then sends the client heath state back to the client as an SoHR. The SoH always contains the following items:

All NAP-capable clients generate an SoH with a compliant status, even when the site is not NAP enabled. Once NAP is enabled on the site, clients will evaluate their SoH against the NAP policies defined on the NPS.

The SHV will accept a cached statement of health from clients if it is within the configured validity period and it does not conflict with the optional Date setting specified on the General tab of System Health Validator Point Component Properties. SoH messages may also contain failures when a client cannot determine its own health status. Figure 11.4 illustrates the System Health Validator Point Component configuration within the ConfigMgr console.

Figure 11.4. SHV component properties

When clients generate an unknown response state failure, the NPS may not be able to auto-remediate the client. ConfigMgr clients may return a compliant SoH when they actually are noncompliant, and the SHV will send a noncompliant SoH to the NPS. This can occur when the client has not downloaded the new policies for compliance and is sending a cached SoH. When a client’s SoH is sent to the SHV/NPS with a noncompliant status and it is remediated, the client will generate another SoH and re-send it, with a list of the client’s MP, DP, and SUP, to the SHV, where it will be reevaluated and eventually granted access to the network.

In the New PC scenario, there is no data backup. The system boots from PXE, CD/DVD, USB, or a locally installed bootable operating system such as WinPE. Once booted, the system then has the hard disk overwritten entirely with an image written to the drive. This scenario is sometimes referred to as “bare metal.”

Several conditions may warrant the use of the New PC scenario:

In the Refresh PC scenario, the PC has an existing user and it needs reimaging. This is sometimes called an in-place migration. The scenario requires backing up the user’s state using some automated process, such as the User State Migration Tool (USMT). The USMT allows the backup and storage of the user’s state to a network location or locally on a part of the hard drive. By default, OSD will use the state migration point (SMP) to store user state during an OS migration. The Refresh PC scenario can use the SMP, a folder on the hard drive, or a network share to store data from the OS the user was initially running. WinPE is copied to this same hard drive location, which the PC boots into and downloads the image into. It then applies the image to the disk, reboots again, and finally in the destination OS performs the necessary deployment tasks. In short, the Refresh PC scenario is the New PC scenario, but with a user state backup in front and no possibility of doing a disk wipe because of the minint folder.

Several conditions may call for the use of the Refresh PC scenario:

The Replace PC scenario is the most complicated because it is similar to the Refresh PC scenario, but the user state backup occurs on the user’s old PC and the rest of the deployment occurs on the new PC. This may also be referred to as a side-by-side migration. The Replace PC scenario is used in the following situations:

Table 11.1 reflects the high-level phases of the three primary types of imaging scenarios. This does not reflect task sequences or all scenarios, but rather to clarifies how the scenarios differ.

Microsoft’s Windows imaging utility, ImageX.exe, is a file-based imaging technology that is hardware independent and highly compressed. ImageX, introduced in Windows Automated Installation Kit (WAIK) 0.9, allows for the capturing, maintenance, and deploying of Windows Imaging Format (WIM) images. Unlike sector-based imaging technologies, which make images of the 1’s and 0’s on the drive, ImageX copies all the files into its image, a WIM file. Because ImageX is file based, it has the ability to make only a copy of a file one time, no matter how many instances of that same file exist. This intelligence, along with file exclusion, allows WIM images to be substantially smaller than other sector-based imaging or cloning tools. It is not uncommon for ImageX WIM images to be one-third to one-half the size of other utilities’ images.

WIM images have the ability to hold multiple WIM images inside a single WIM image. For instance, the Windows Vista WIM has seven different versions or SKUs of Windows Vista in it. You can mount WIM images on an NTFS file system and customize them. This means there is no need to redo an image when most administrative types of changes need to occur. After you mount a WIM image, the following items can be modified within the image:

Here’s the ImageX capture syntax:

Here’s the ImageX append syntax:

Here’s the ImageX apply syntax:

And, finally, here’s the ImageX info syntax:

Here’s the process in which WIM images are edited offline:

Sector-based imaging has many issues that are time consuming and costly to work around. Sector-based technologies have a number of stipulations:

Although several sector-based imaging technologies allow you to edit an image after creating it, there are very few tasks that the administrator is capable of performing, and the file-deletion capability deletes the files without reclaiming the space. The significance of this last point means that a laptop image made from a reference PC with 4GB of RAM will most likely have a several GB page file and a 4GB hibernation file. That is approximately 6GB going into an image that is unnecessary, because it will be re-created on the first boot. The deletion of these files will not reclaim the space, but leaves the administrator with lots of room to add other items that usually are not needed in this volume. ImageX excels in this area, because it ignores the hibernation and page files during the capture phase.

Because sector-based imaging technologies image the disk at the “1’s and 0’s” level, a file such as winword.exe, which may be located on the system numerous times, is copied into the image as many times as it is present. ImageX, on the other hand, will only copy winword.exe once per version and place pointers for the other instances it finds. This single-instance file imaging allows for even greater efficiencies during the capture and apply phases, and produces smaller images in general. Because ImageX works at the file level, it provides the following capabilities:

ConfigMgr uses WinPE as its boot device for clients undergoing an OS deployment. The WinPE image is stored on the ConfigMgr server as a WIM file. It’s approximately 120MB in size and is named boot.wim. The ConfigMgr administrator provides these WIM files; they are not created by performing captures. In both the New PC and Replace PC scenarios, boot.wim is downloaded to the client PC from PXE, USB, or a CD/DVD. In the Refresh PC scenario, the client has boot.wim downloaded to the minint folder, and boot.ini is redirected to point at this location. This allows the reboot occurring after the user state capture to boot the system into WinPE, and for the OS deployment to commence the replacement.

ConfigMgr provides two default boot.wim images: one for x86 and one for x64. As with any other package, you must deploy these boot images to distribution points for clients to be able to download and use them. The boot.wim files that come with ConfigMgr will require customization to support the network drivers and storage controller drivers utilized throughout the deployments.

Updating the boot images is a fairly simple process. Perform the following steps to update any boot image:

Another approach would include the following:

Alternatively, simply select the driver to add and drag it to the boot image under the Boot Images node.

ConfigMgr can maintain a driver catalog. This catalog keeps drivers external to the images and enables a centralized, easily administered location to store drivers. The driver catalog allows storing multiple versions of the same device driver to support systems that may still require older versions for support. The driver catalog is broken up into drivers and driver packages. A driver is an INF file, as well as several other files, that defines how an operating system is supposed to use a specific piece of hardware. The operating system matches the driver to the hardware by the Plug and Play ID (PnPID). The driver package is merely a grouping of drivers for a specific purpose that later can be deployed to distribution points.

As images are being built without drivers installed locally, the OS deployment process will have to provide the drivers to the target PC at the appropriate time. This occurs through the task sequencer by leveraging the WinPE Auto Apply Drivers task sequence step. This step automatically detects and installs all applicable Plug and Play device drivers it can locate in the driver catalog. For ConfigMgr to search in the driver catalog for the new device drivers, you should add the Auto Apply Drivers task sequence step to an existing task sequence. Auto Apply Drivers contains the following options:

Capturing an image is the first of three steps required to deploy an operating system. The second task is to create the task sequence, and the third task is the advertising of the task sequence to a collection. There are two possible methods for capturing an image:

Many find the manual build method to be the easiest and least prone to errors from a capturing perspective, but it allows human error to occur on the build of the reference PC. Capturing a PC image using media requires the following steps:

The other method of capturing an image is to create a task sequence to build and capture an operating system image. You can use a task sequence to build an operating system from scratch in an unattended format. This ensures consistency as the build is updated over time and removes the human error factor, because all tasks that occur to configure the OS are placed in the task sequencer as tasks. To create a new build-and-capture task sequence, perform the following steps:

Because ConfigMgr uses WinPE as the boot media to deploy an operating system, in theory you can use any type of image with the ConfigMgr deployment process. In addition, task sequences are the actual ConfigMgr objects advertised to a collection, which allows an infinite number of possibilities to be deployed to clients.