Reorganizing Active Directory - Page 2

By Brien M. Posey | Posted Nov 2, 2000
Page 2 of 2   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

I should also point out that when moving objects within a domain, it's possible to move multiple objects simultaneously. This feature can save you a lot of time during a major reorganization in which dozens or even hundreds of objects are being moved.

The process of actually moving an object to its new location is quite simple:

  1. Open the Active Directory Users and Computers snap-in for Microsoft Management Console.

  2. Within this snap-in, select the object(s) you want to move.

  3. Select the Action|Move command to open the Move dialog box.

  4. In this dialog box, select the new location and click OK. The object will be instantly moved to the location you've specified.

Moving Objects Between Domains

Unlike moving objects within a domain, moving objects between domains is more of a science than a simple procedure.

SIDHistory

SIDHistory is unique to Windows 2000 and is active only when Windows 2000 is running in native Active Directory mode. The SIDHistory attribute maintains a list of all the SID numbers the object has ever been assigned. To see how SIDHistory really works, consider a situation in which you're moving a user account from one domain to another. During the process of the move, the user account retains its original Globally Unique Identifier (GUID) but takes on a new fully qualified domain name and SID. The account's original SID is recorded in the account's SIDHistory attribute. The next time the user logs on the new SID is active.

Normally, the user wouldn't be able to access his old files and other resources, because the account's new SID isn't registered as having access to those resources. However, during the login process, Windows 2000 looks at the SIDHistory. When Windows 2000 creates the access token, it bases the access token on the current SID and on all previous SIDs. It's almost as if it's possible for a user account to be registered to multiple SIDs. Because the resources to which the user previously had access recognize the old SID from the SIDHistory, the user will still be able to access his resources as if nothing happened.

This process involves using a utility called MOVETREE. MOVETREE is included with Windows 2000, but it must be installed manually. I'll explain how to install MOVETREE in Part 2 of this series. For now, you should know that you must follow a very strict set of rules when moving objects between domains. Some objects can be moved easily, whereas other objects simply can't be moved at all. Still other types of objects can be moved with some manipulation, but Microsoft doesn't officially support those procedures.

In spite of all the complicated procedures, the basic premise of moving objects between domains isn't that different from moving objects within a domain. Whether you're moving a leaf object or a root object, the idea is to move the object from its current location into a pre-existing parent object elsewhere in the forest. When you complete such a move, the object's fully qualified domain name will automatically change to reflect its new position within the Active Directory hierarchy. Even with the new fully qualified domain name, the object still retains its original Globally Unique Identifier (GUID).

Although the object's GUID remains the same after it has moved, the object takes on a new SID. As you may recall, in Windows NT (and to some extent in Windows 2000), the SID is used to create an object's access token. In Windows NT, changing a user's SID will render the account useless, because it will no longer be associated with any security information. To get around this problem, MOVETREE takes advantage of an object attribute called SIDHistory (see sidebar).

CrossLinks

Now that you know how the MOVETREE utility works, it's time to get into the rules that you must follow when using MOVETREE. I'll cover these rules along with the MOVETREE installation procedure in Part 2 ( previous ). //

Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it's impossible for him to respond to every message, although he does read them all.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter