Chapter 1: Security

Article
12/09/2009

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.

Introduction

Security is very relevant to domain migration.

Migration, when you use the term in its restructuring sense, involves copying or moving security principals such as users or security groups from one domain to another. In-place upgrade does not move users. In the Microsoft Windows NT security model, these security principals are identified by security identifiers (SIDs). Access to resources in Windows NT is granted or denied on the basis of these SIDs. Because SIDs are domain specific, they must be changed as a result of migration.

This chapter explains security as it relates to domain migration. It covers the following:

Authentication and authorization. Taking a high-level look at the Windows NT authentication and authorization model will help you understand the relevance of SIDs.
SIDHistory. Microsoft Windows 2000 security principals in Active Directory have an attribute that preserves old SIDs in cross-domain moves and makes migration much simpler.

Authentication and Authorization

Security Identifiers

The Windows NT security model identifies account objects such as users, groups, machines, and domain trusts by SIDs. SIDs are domain-unique values, built when the user or group is created, or when the machine or trust is registered with the domain.

The components of a SID follow a hierarchical convention: A SID contains parts that identify the revision number, the authoritysuch as the domainthat issued the SID, and a variable number of subauthority or relative identifier (RID) values that uniquely identify the security principal relative to the issuing authority.

Although there are well-known SIDs that identify generic groups and users across all systems, the majority of security principals that you will focus on are identified in the context of a domain, and thus they cannot be moved between domains without their SIDs changing.

Authentication and Access Tokens

An essential component of the Windows NT security model is authentication, where a user is identified to the domain by presentation of credentials, usually in the form of a user name and password. Assuming these credentials are acceptable, the system creates an access token for the user containing the SID of the user (the primary SID), and the SIDs of all the domain groups the user is a member of. Every process the user creates, for example by running an application, carries the user's access token.

The system uses this access token to determine whether to grant the user access to system resources.

Authorization and Security Descriptors

The counterpart of the user's access token is the security descriptor attached to resources such as files or printers. A security descriptor contains a discretionary access control list (DACL), which consists of a list of access control entries (ACEs). Each ACE consists of a SID, together with an indicator that the security principal that the SID identifies is granted or denied some sort of access to the resource.

As a result, the effect of upgrade or restructure on SIDs is of crucial importance.

Authorization and Upgrade

Domain upgrade is the process of upgrading the software on the primary domain controller (PDC) of a domain, and upgrading some or all of the backup domain controllers (BDCs), from Windows NT to Windows 2000 Server.

In an upgrade, security principals remain in the same domain they were created in, and so the SIDs identifying them remain unchanged. As a result, upgrade does not affect resource access.

A subsequent chapter will explain upgrade in detail.

Authorization and Restructure

Domain restructure is a process that allows you to redesign your Windows 2000 forest according to the needs of your organization. Although restructure can result in any number of different outcomes, typically the result is some rationalization of the current structure, and perhaps a move to fewer larger domains.

Changing structure implies copying or moving objects from one domain (the source domain) to another (the target domain). Because of the domain relative nature of SIDs, copying or moving objects implies that the new object in the target domain will have a new SID relative to that domain.

A number of third-party directory management tools have long provided domain-restructuring support for Windows NT 4.0. These tools have handled the SID change issue by providing components to search out all references to the security principal's former SID in ACLs all over the enterprise, and either replace it with the new SID or add a reference to the new SID. This is one approach to the problem, and in some instances it may still be necessary, but in many instances Windows 2000 makes repermissioning unnecessary by virtue of an Active Directory attribute called sIDHistory.

SIDHistory

In Windows 2000, the domain restructuring is made considerably easier as a result of a new attribute on Windows 2000 Active Directory security principles called sIDHistory.

SIDHistory is used to store the former SIDs of moved objects such as users and security groups.

When a user or group is moved using new Microsoft Win32 application programming interfaces (APIs), or tools and support utilities provided by Microsoft or independent software vendors and built on top of them, the sIDHistory attribute of the object representing it in Active Directory is updated with its former SID as part of the operation. When the user then logs on to the system, not only the new SID but also the old SID retrieved from the sIDHistory attribute are added to the user's access token and used to determine the user's group memberships. The SIDs of the groups in which the user is a member through either the new SID or the old SID then also are added to the access token, together with any sIDHistory those groups might have.

Because groups can be moved, they can also have sIDHistory, and the system also retrieves the sIDHistory attributes of all the groups the user is a member of and adds these to the user's access token.

These sIDHistory entries in the token look to the system like normal group memberships during authorization checks, so they can grant appropriate access even on down-level systems that know nothing about Windows 2000 or Active Directory.

Note: The sIDHistory attribute can only be updated in native mode Windows 2000 domains, which has the effect of requiring all migration operations relying on sIDHistory to have a native mode target for restructure.

Figure 1.1: Resource access granted through sIDHistory

Security Implications of SIDHistory

The ability to take a SID from one security principal and add it to the sIDHistory of another is sensitive from a security perspective. As a result, the ability to manipulate sIDHistory is constrained in a number of ways. The principal one requires the SID to be unique in a Windows 2000 forestthat is, it can only exist once in the target forest whether that is as a primary SID or in the sIDHistory of any object.

As a result, sIDHistory is available in two migration scenarios:

Moving security principals between domains in the same forest. In this case, moving the object, destroying the source object, and adding it to the sIDHistory of the target object ensures SID uniqueness. This is referred to as an "intra-forest migration" because it occurs between domains in the same forest.
"Cloning" security principals between domains in different forests. In this instance, because the source object still exists, the operation can only take place between separate forests. This is referred to as an "inter-forest migration." Because Windows NT domains cannot be part of a Windows 2000 forest, this type of migration is available to down-level source domains as well as Windows 2000 ones.