Export (0) Print
Expand All
Expand Minimize

Chapter 5: Mature Windows 2000 Domains

Section 1:
Migration Concepts

The example companies, organizations, products, people, and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.

On This Page

Introduction
Protected Storage (PStore)
Encrypting File System
Group Policy

Introduction

Up to now, the focus of this guide has been on migration from Microsoft Windows NT 4.0; in some scenarios, the source domain will be part of a mature Microsoft Windows 2000 forest. While strictly speaking, this is not a migration scenariothe source environment has already migratedsome enterprises will want to carry out such an operation to incorporate an extensive pilot migration into the final production Windows 2000 forest.

In such scenarios, the source domain could have fully implemented new features such as Group Policy and the Encrypting File System (EFS).

This chapter recognizes this possibility and addresses some of the issues involved when dealing with mature Windows 2000 source domains.

The chapter will cover:

  • Protected Storage (PStore). PStore was available in Windows NT 4.0 and is significant in this context because of the effects of migration on security identifiers (SIDs) and the way in which PStore protects its contents.

  • EFS. EFS, which became available in Windows 2000, uses PStore to store the user's private key. As the previous paragraph implies, migration has implications for PStore.

  • Group Policy. Windows 2000 introduces many new policy-based administration features. Many of these features are applied based on user and group SIDs, which raises issues during migration.

Protected Storage (PStore)

Secure Storage for Data

PStore provides applications with a place to store per-user data such as private keys, which must be kept secret or free from modification. Access to data in PStore is regulated by a user-defined security style, which specifies what kind of interactive confirmation is required for the application to access the datafor instance, whether a password is required.

PStore is actually implemented as an opaque portion of the user's profile. As previously seen, Microsoft Active Directory Migration Tool (ADMT) will migrate user profiles. It does this by creating a new ProfileList entry using the string representation of the migrated user's new SID as the key. ADMT then copies the contents of the key stored under the user's old SID, including the pointer to the user's old profile data file. This results in the old and new users sharing the same profile file. This is not a problem because the users are the same person, just represented by different SIDs.

Since PStore is a part of the profile data, PStore is preserved in the profile. However, as seen earlier, PStore is opaque and is protected by encryption. Unfortunately, the keys used to encrypt and decrypt PStore are not available to the migrated user.

Preserving PStore Contents

Microsoft is looking at ways to migrate the contents of PStore for a future release of Windows 2000. In the meantime, if you have made extensive use of PStore and need to preserve the contents and make them available to the migrated user, you could write a simple utility and use it as part of your migration to:

  • Use CryptoAPI to export the contents of PStore prior to migration under the security context of the user to be migrated.

  • Store the exported keys securely during migration.

  • Use CryptoAPI to reimport the exported keys into the migrated user's PStore under the security context of the migrated user.

Because very few applications have made use of PStore in Windows NT 4.0, this aspect of migration is unlikely to cause problems for many customers. However, as companies deploy Windows 2000 and more applications use PStore functionality, this will become more of a migration consideration.

Note: The system preserves the old PStore data apart from any new data the migrated user might add. Because of this, the old data will be recoverable at any time after migration either using the proposed Microsoft functionality or using a utility such as described above. The only requirement is that the original profile data file is preserved.

Encrypting File System

A Secure Encryption Method

Windows 2000 provides EFS to enable users to securely encrypt data in files. EFS is implemented on top of NTFS file system and provides users with the ability to transparently use encryption capabilities while storing their sensitive files in NTFS.

EFS enhances the ability of the underlying file system to enforce read-and-write access control. It does not change the access control model, which is focused on restricting access to files to authorized individuals, as checked via system logon.

Protected Storage and Encrypting File System

EFS has taken advantage of PStore to protect its core secrets, such as keys and key management information.

As seen in the previous section, migration currently results in the migrated user losing access to their premigration PStore unless steps are taken to export the keys prior to migration. Because EFS uses PStore, migration also has implications from an EFS perspective, although this is unlikely to have a major impact initially because it affects only Windows 2000.

If you have deployed Windows 2000 and made extensive use of EFS and need to migrate users, you should take the following steps:

  • Consider deploying a utility to export keys from PStore prior to migration and reimport them after migration as described above.

  • Recommend that users decrypt their EFS-encrypted files prior to migration, and reencrypt them after migration.

Group Policy

Defining the Rules

Windows 2000 derives many benefits from its policy-based administration. Policies express business rules. Commonly used policies in distributed systems define how resources in the network are accessed, configured, and used. For example, when users log on, policies determine what applications they see on their desktops.

Policy selection is the mechanism that determines what policies should be applied to a given operation. Specifically, policy selection is the process used to choose the policies that must be evaluated for a given subject, object, and operation.

Each of these policies applies to particular subjects and objects, in the context of particular operations. Evaluating all policies for all operations is expensive in terms of time and is very inefficienta given policy usually applies to a fairly narrow set of circumstances and is meaningless outside of that set. For example, the user desktop policies never apply to router configurations.

Selecting Policies

The policy selection mechanism must "know" how to choose the correct policies to be evaluated. Policy selection is distinct from policy enforcement. Selection occurs at a policy decision point. Software at the decision point "knows" the subject, the object, and the operation, and uses this information to select candidate policies to evaluate.

Subjects are security principals, which have objects in the directory. The objects are stored in organizational unit (OU) containers. OUs in turn are stored in domains. A given computer is located in a discrete part of the network, represented in the directory by a site object. The site, domain, and OU containers can reference a list of policies that apply to security principals in those containers. At a decision point such as user logon, the policies referred to by the user's OU hierarchy, domain, and site are selected as candidates and evaluated. This approach keeps the number of candidate policies both small and focused, and is easy to administer: Placing a given principal in a container will automatically apply the policies in that container and its parents.

The application of policy as such depends on factors such as location, in the sense of a particular domain, OU, or security group, and identity. Migration by definition affects both of these.

Currently, there is no way to migrate policy with objects. This is likely to have little impact initially because Group Policy as described only applies to Windows 2000 domains. In order to safely migrate objects from such domains where policy has been deployed, the safe course is to ensure that such objects have no policy applied to them prior to migration. Microsoft is working on documenting steps to ensure this, and future versions of this chapter will document these.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft