Cloning Security Principals (ClonePrincipal) (ST)

ClonePrincipal is not really a utility or command, but a set of scripts that allows administrators to perform inter-forest migration, primarily to incrementally migrate (copy) accounts from an existing Windows NT 4.0-based domain to a new Active Directory domain (based on domain controllers running Windows 2000 or Windows .NET). (In contrast to MoveTree, ClonePrincipal does not affect the source objects.) ClonePrincipal can also be used for reorganizing AD-based forests. This tool and its GUI counterpart — the Active Directory Migration Tool (ADMT) — are the only facilities used for upgrading existing Windows NT 4.0-based domains in cases when users can preserve continuous access to network shared resources and administrators can fulfill fallback in case of an emergency.

Note 

ADMT is a more powerful and user-friendly tool than ClonePrincipal. ADMT has many additional features, for example, it also supports intra-forest operations, and can migrate user profiles, computers, and trusts. ClonePrincipal and ADMT have quite a few similar features. However, they differ internally, and Microsoft does not recommend that you mix these tools for migration operations. If you learn ClonePrincipal's basics (especially the environmental requirements and mechanism of SID migration), you will be able to master ADMT without any problems.

Well-Known SIDs and RIDs

Let us first clarify some terms used below.

A unique Security Identifier (SID) of a security principal (i.e., user, computer, or group account) is used to grant access rights to shared network resources to a principal. The SID is composed of two parts: a unique "domain part", which is the same for all principals within the domain where they reside, and a Relative Identifier (RID), which uniquely identifies the principal in the domain.

Note 

Windows .NET domains offer a new security principle — class inetOrgPerson. You can use objects of that class in the same way as the user objects and assign them permissions on shared resources and directory objects.

An account with a well-known RID has an SID composed of an RID that is identical in every domain, and a "domain part" that is unique for each domain. Such an account can only be cloned onto an account with the same RID. Here are accounts with well-known RIDs:

• Administrator

• Domain Admins

• Domain Guests

• Domain Users

• Guest

An account with a well-known SID cannot be cloned, since its SID is identical in every domain. (Therefore, it doesn't make sense to copy an account whose SID already exists in the target domain.) Here are accounts with well-known SIDs:

• Account Operators

• Administrators

• Backup Operators

• Guests

• Power Users

• Print Operators

• Replicator

• Server Operators

• Users

Supported Object Types

With ClonePrincipal, you can clone the following objects:

• User accounts

• Security group accounts:

  • Local groups (from Windows NT 4.0 or Windows 2000 mixed mode domains)

  • Global groups

  • Domain local groups (from at least Windows 2000 native mode Active Directory domains)

  • Universal groups (from at least Windows 2000 native mode Active Directory domains)

ClonePrincipal does not support the following objects:

• Computer accounts (workstations or domain controllers)

• Inter-domain trusts

• Accounts with well-known SIDs (for example, Administrators or Users local groups)

ClonePrincipal Components

ClonePrincipal consists of the following files:

• Clonepr.dll—a COM server that implements all functions.

• Clonepr.vbs—the script that clones a single security principal (user account; global, universal, or domain local group), creating the target principal if necessary.

• Clonelg.vbs—the script that clones all local (except built-in) or domain local groups in a domain.

• Clonegg.vbs—the script that clones all global and universal groups in a domain.

• Cloneggu.vbs—this script clones all users and global groups (user, global group, and universal group accounts) in a domain, including well-known global groups such as Domain Admins, Domain Users, and Domain Guests.

• SIDHist.vbs—the script that copies (adds) the value of the objectSID attribute of a source principal to the sIDHistory attribute of a target principal.

Use of these scripts is discussed in the following sections.

Configuring Migration Environment

One of the most important requirements for ClonePrincipal (as well as for ADMT) to work well is the proper configuration of both source and target domains. If you are also planning to use ADMT, see also the additional requirements below. ClonePrincipal will fail if any of the requirements have not been met.

Here are some general considerations:

• If ClonePrincipal was installed separately from the Support Tools, make sure that the Clonepr.dll has been registered on the target DC.

• All ClonePrincipal scripts must be run on the PDC Emulator (the FSMO role master) of the target domain.

• You must log on to the DC as a member of the Domain Admins group of the target domain.

Registry Settings (TcpipClientSupport)

In the source domain running Windows NT 4.0 (with Service Pack 4 or later) or Windows 2000/.NET, create the registry REG_DWORD:0x1 value named TcpipClientSupport on the PDC (or the PDC Emulator) under the following subkey:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa 

Reboot the PDC.

This setting is not necessary if you use ADMT for intra-forest migration.

Audit Settings

It is necessary to set auditing, both in the source and target domains. Use the procedure described below.

For Windows 2000 and Windows .NET domains (both the source and target):

1. Open the Group Policy Object (GPO) for the Domain Controller OU. (Use either the Domain Controller Security Policy or the Active Directory Users and Computers snap-in.)

2. Open the Security Settings | Local Policies | Audit Policy node.

3. Double-click the Audit account management policy and check both the Success and Failure boxes. Click OK. A sample screen is shown in Fig. 13.3. Refresh the computer policy or wait for the updates to take place.

   
   Fig. 13.3: Setting audit on the Windows 2000-based domain controllers

For a Windows NT 4.0-based source domain:

1. In User Manager for Domains, click Audit in the Policies menu.

2. Select Audit These Events and check the Success and Failure boxes for User and Group Management (Fig. 13.4).

   
   Fig. 13.4: Setting audit on a Windows NT 4.0-based domain controller

Creating the Audit Group

In either a Windows NT 4.0- or AD-based source domain, you must create a special domain local group that is used for auditing cloning operations. The name of the group is composed of the source domain NetBIOS (pre-Windows 2000) name appended with three dollar signs, for example, NT4DOM$$$. The group must be empty. Without this group, you will not be able to transfer SIDs between forests and update the sIDHistory attribute of target objects.

This group is not required if you use ADMT for intra-forest migration.

Trusts

Establish a bidirectional trust between the source and target domains (i.e., the source domain must trust the target domain, and vice versa). (For details, see "Establishing Trusts" in Chapter 5, "Installing Active Directory.") Before that, make sure that name resolving is working properly in your configuration. You must be able to successfully ping the target DC from the source DC bi the NetBIOS (pre-Windows 2000) name, and vice versa.

Configuring Groups

To run ClonePrincipal successfully, you must have the appropriate administrative privileges: add the Domain Admins global group from the target domain to the Administrators local group in the source domain.

Additional Requirements for ADMT

In addition to the considerations and necessary procedures described above, you must carry oet the following operations:

• Add the Domain Admins global group from the source domain to the Administrators local group in the target domain.

• Add the Domain Admins global group from the source domain to each migrated computer's Administrators local group. The same is applicable to each computer on which security will be translated.

• Make sure that administrative shares exist on the target DC as well as on each computer you migrate.

Cloning Users

Even if the source domain is AD-based, ClonePrincipal does not address Active Directory's user properties. (ADMT 2.0 is free of that disadvantage.) Only the following Windows NT 4.0 propertiec are copied from the source object to the target object:

• General properties:

  • Full name

  • Description

  • Account flags (such as Account Expires, Logon Hours, Logon To, and others)

• Profile properties:

  • User profile (Profile path and Logon script)

  • Home directory (Local path, Connect drive and location)

• Dial-in properties

• File and Print for NetWare properties

• Terminal Server Properties

  The following flags are set for the existing or cloned (newly created) user account:

• User must change password at next logon

• Account is disabled

The following flags will be cleared:

• User cannot change password

• Password never expires

The user password is set to empty (null).

By default, the cloned user becomes a member of the Domain Users group. The user's group memberships are retained in the target domain if the target global and/or universal groups are clones of the source groups in which the source user is a member. That is, if both user and global (universal) group accounts are copied (Cloneggu.vbs is used), the groups can retain all their members (if all of them are cloned).

Cloning Groups

When cloning global groups, you must consider the fact that the Cloneggu.vbs and Clonegg.vbs scripts copy accounts with well-known RIDs, and will fail if you specify a target container (the /dstOU parameter) different from the default Users containerwhere these accounts reside. For example, you cannot perform such a command without a fatal error:

    cloneggu /srcDC:nt4dc5 /srcDom:nt4dom      /dstDC:netdc1 /dstDom: net.dom /dstOU:OU=Staff, DC=net, DC=dom 

In this case, you have the three following options:

1. Specify the Users container as the target OU, for example, /dstOU:CN=Users, DC=net, DC=dom.

2. In the destination domain, move (temporally) all accounts with well-known RIDs (Administrator, Guest, Domain Admins, etc.) to the target OU.

3. Do not clone (i.e., ignore) the accounts with well-known RIDs. Open the Cloneggu.vbs or Clonegg.vbs script in a text editor, find the code shown below, and uncomment the specified statements:

       'To Stop Cloning Well Known Sids[1] Uncomment 4 lines below    ' if HasWellKnownRid(sidString) then    ' ShouldCloneObject = False    ' exit function    ' end if 

In this case, the target "well-known" accounts will lose access to those network resources which contain the source "well-known" accounts in their ACLs (since the sIDHistory attribute of these target accounts will not be updated). You may manually update the ACLs of the appropriate shared resources, or copy the SIDs from the source accounts to the target ones by using SIDHist.vbs.

ClonePrincipal Samples

Let us now consider some examples of how to use ClonePrincipal. Each parameter of every ClonePrincipal script is mandatory. You can view the parameter list for each script by entering the script name and a question mark at the command prompt.

Note 

You might wish to set the "command-line" mode of Windows Script Host (WSH), since by default, it outputs all messages in pop-up windows, which is not convenient when you are working with ClonePrincipal scripts. Enter cscript //H:CScript at the command prompt.

Cloning SID (SIDHist.vbs)

Usually, the SIDHist.vbs is executed by other ClonePrincipal scripts. However, you might want to run it manually to accomplish some specific tasks (for example, if you have disabled cloning groups with well-known RIDs). You may want to, for example, grant the Domain Admins group in the target domain the right to access network resources available to the same group from the source domain.

Note 

You can monitor all changes of the sIDHistory attribute with Ldp.exe. (Use the same version of Ldp on both domains!) AdsVw.exe allows you to view the objectSid attribute (in hexadecimal byte format) on the source Windows NT-based DC. To see this attribute in the same format on the destination DC, you can also use the ADSI Edit snap-in.

The following script adds the objectSid attribute of the Mark-W2K user object from the w-2000 domain to the sIDHistory attribute of the Mark-NET user object located in the net.dom domain:

    C:\>sidhist /srcDC:w2kdc3 /srcDom:w2000 /srcSAM:Mark-W2K      /dstDC:netdc1 /dstDom:net.dom /dstSAM:Mark-NET 

As a result, the Mark-NET user will have the same resource access rights as the Mark-W2K user.

You can perform this operation only for one selected account in the target domain. Otherwise, the script will fail with the following error:

    Connected    Error 0x8007215B occurred.    Error Description: Failed to add the source SID to the destination object's SID history. The error was: "The source object's SID already exists in destination forest."    Error HelpContext: 0    Error HelpFile :    Error Source : DSUtils.ClonePrincipal.1 

If the operation is successful, the resulting output is very simple:

    C:\>sidhist /srcDC:w2kdc3 /srcDom:w2000 /srcSAM:Mark-W2K      /dstDC:netdc1 /dstDom:net.dom /dstSAM:Mark-NET    Connected    Success 

After the above-mentioned command has been executed, the following message appears in the Security Log on the destination DC:

    Event Type: Success Audit    Event Source: Security    Event Category: Account Management    Event ID: 669    ...    User: NET\Administrator    Computer: NETDC1    Description:    Add SID History:       Source Account Name: w2000.dom\Mark-W2K       Source Account ID: NET\Mark-NET       Target Account Name: Mark-nET       Target Domain: NET       Target Account ID: NET\Mark-NET       Caller User Name: Administrator       Caller Domain: NET       Caller Logon ID: (0x0, 0x115EB)       Privileges: - 

Cloning a User (ClonePr.vbs)

The following script clones a user from a Windows 2000 domain to a Windows .NET domain, where the user is `laced into a specified organizational unit. This container must exist before the script is executed. (Note that the user can already exist on the target DC.)

    C:\>clonepr /srcDC:w2kdc3 /srcDom:w2000 /srcSAM:Mark      /dstDC:netdc1 /dstDom:net.dom /dstSAM:Mark      /dstDN:CN=Mark, OU=Migrated, DC=net, DC=dom    ...    Connected to source and destination domain controllers    Bound to source User Mark    Destination object Mark not found (by SAM name) path used: WinNT://net.dom/netdc1/Mark    Destination object CN=Mark,OU=Migrated,DC=net,DC=dom not found (by DN) path used: LDAP://netdc1/CN=Mark,OU=Migrated,DC=n et, DC=dom    Creating CN=Mark,OU=Migrated,DC=net,DC=dom    Created CN=Mark,OU=Migrated,DC=net,DC=dom    Setting properties for target User CN=Mark    Downlevel properties set.    Fixing group memberships for User CN=Mark      Found global group WinNT://w2000/w2kdc3/Domain Users      Skipping WinNT://w2000/w2kdc3/Domain Users -- not cloned yet    User's Group memberships restored.    User changes commited.    Adding SID for source User Mark to SID history of target User CN=Mark    SID history set successfully.    Mark cloned successfully. 

Two events will be registered in the Security log on the target DC: Event ID 624 (User Account Created) and Event ID 669 (Add SID History). Thus, you can trace all clone operations performed in the domain.

Note 

When a user object is cloned, the source account remains active, and the new account will be disabled.

Finding Groups of a Specific Type

When cloning groups, you may need to view the list of already copied groups and monitor the process of migration. There is a trick described below that allows you to find only the groups of a specific type located in any container in the object tree.

You need to use a LDAP search operation and the LDAP_MATCHING_RULE_BIT_AND (1.2.840.113556.1.4.803) matching rule control in the search filter. (For details, search for the "query filter" string in the ADSI SDK.) For example, the following command displays the ADsPath property of all universal groups that exist in the domain:

    C:\>search "LDAP://DC=net, DC=dom"      /C:"groupType:1.2.840.113556.1.4.803:=2147483656" /S:subtree 

With the DsQuery utility, the command is even shorter:

    C:\>dsquery * -filter groupType:1.2.840.113556.1.4.803:=2147483656 

This search filter can also be used in other tools, such as Ldp.exe (specify it in the Filter field). The filter's values for various group types are listed in the table below. (Only the decimal values can be used. Notice also the minus sign in the last row of the table.)

Group type	Hexadecimal value	Decimal filter value
Built-in and Domain local	0x80000004	2147483652
Global	0x80000002	2147483650
Universal	0x80000008	2147483656
Built-in only	0x7FFFFFFB	−2147483643

^[1]This is a typo in the scripts; should be "RIDs".