SID filtering does not allow for the use of SIDs from outside the forest to enable access to any resource within the forest. You can enable the SID of a user in a different forest to access a resource within a forest that has SID filtering enabled by translating security on the resource to include the user SID in the permission list. Because SID filtering does not apply to authentication within a domain, it is also possible to allow access to resources by means of SID history, if the resource and the account are in the same domain.
To allow users or groups to access a resource by using SID history, the forest in which the resource is located must trust the forest in which the account is located. SID filtering is applied by default when a forest trust is established between two forest root domains.
Also, SID filtering is enabled by default when external trusts are established between
domain controllers running Windows Server 2003 or Windows 2000 SP4 or later. This prevents potential security attacks by an administrator in a different forest.
For more information about SID history–based attacks and SID filtering, see Configuring SID Filtering Settings (http://go.microsoft.com/fwlink/?LinkId=73446).
Assigning Object Locations and Roles
Create an object assignment table that lists the roles and locations for all of the objects that you are migrating. Create one table for account objects, such as users, groups, and service accounts, and one table for resource objects, such as workstations, profiles, and domain controllers. In your tables, list the source and target locations for all objects to be migrated.
Before you create your account object assignment table, determine whether the domain organizational unit (OU) structures for the source and target domains are the same. If they are not the same, you must identify the source and target OU in your object assignment tables.
For a worksheet to assist you in creating an account object assignment table, see "User and Group Object Assignment Table" (DSSREER_1.doc) in the
Job_Aids_Designing_and_Deploying_Directory_and_Security_Services download of the Job Aids for Windows Server 2003 Deployment Kit
(http://go.microsoft.com/fwlink?LinkId=14384).
The following figure shows an example of an object assignment table for users and groups.
To create a resource object assignment table, identify the source and target OU for each object and note the physical location and role in the target domain. For a worksheet to assist you in creating a resource object assignment table, see "Resource Object Assignment Table" (DSSREER_2.doc) in the
Job_Aids_Designing_and_Deploying_Directory_and_Security_Services download of the Job Aids for Windows Server 2003 Deployment Kit
(http://go.microsoft.com/fwlink?LinkId=14384).
The following figure shows an example of a resource object assignment table.
Developing a Test Plan for Your Migration
ADMT v3 does not include a test migration option which was available in previous versions of ADMT. Develop a test plan to assist you in systematically testing each object after it is migrated to the new environment, and identifying and correcting any problems that might occur. Testing to verify that your migration is successful helps ensure that users who are migrated from the source to the target domain are able to log on, to access resources based on group membership, and to access resources based on user credentials. Testing also helps ensure that users are able to access the resources that you migrate.
After your testing is complete, you can proceed with migrating small pilot groups and then gradually increase the size of each batch of migration objects in your production environment.
Use the following process to test the migration of your account object and resource objects:
1. Create a test user in the source domain. Include this test user with your migrations.
2. Join that user to the appropriate global groups to enable resource access.
3. Log on to the source domain as the test user, and verify that you can access resources as appropriate.
4. After you migrate the user account, translate the user profile, and migrate the workstation of the user, log on to the target domain as the test user, and verify that the user has retained all necessary access and functionality. For example, you might test to verify that:
• The user can log on successfully.
• The user has access to all appropriate resources, such as file and print shares;
access to services such as messaging; and access to line-of-business applications. It is especially important to test access to internally developed applications that access database servers.
• The user profile was successfully translated, and the user retains desktop settings, desktop appearance, shortcuts, and access to the My Documents folder. Also, verify that applications appear in and start from the Start menu.
You cannot migrate every user property when you migrate user accounts. For more information about user properties that cannot be migrated, see Migrate User Accounts, later in this guide.
After you migrate resources, log on as the test user in the target domain, and verify that you can access resources as appropriate.
If any steps in the test process fail, identify the source of the problem, and determine whether you can correct the problem before the object needs to be accessible in the target domain. If you cannot correct the problem before access to the object is required, roll back to your original configuration to ensure access to the user or resource object.
For more information about creating a rollback plan, see Creating a Rollback Plan, later in this guide.
As part of your test plan, create a migration test matrix. Complete a test matrix for each step that you complete in the migration process. For example, if you migrate 10 batches of users, complete the test matrix 10 times, once for each batch that you migrate. If you migrate 10 member servers, complete the test matrix for each of the 10 servers.
For a worksheet to assist you in creating a test matrix, see Migration Test Matrix (DSSREER_3.doc) in the
Job_Aids_Designing_and_Deploying_Directory_and_Security_Services download of the Job Aids for Windows Server 2003 Deployment Kit
(http://go.microsoft.com/fwlink?LinkId=14384).
The following figure shows an example of a completed migration test matrix.
Creating a Rollback Plan
Reduce the risk of disrupting end users in your organization by establishing a rollback plan. In general, it is possible to isolate and resolve any problems that occur during each phase of the migration. However, it is important to analyze potential risks and identify the levels of user impact and downtime that might necessitate rolling back the migration. You might be required to roll back your migration if any of the following occur:
• Users cannot log on to their accounts after migration.
• Users cannot access resources after migration.
• User migration is incomplete; for example, passwords did not migrate.
• User migration was successful, but user workstation migration or local profile translation failed.
If user impact or downtime reaches a level that you have defined as unacceptable in your organization, you can implement your rollback plan and continue to operate in your premigration environment. Because the source domain remains intact during the restructure, you can restore the original environment by completing a few key steps.
To roll back to the premigration environment after migrating account objects:
1. Enable the user accounts in the source domain (if you disabled the accounts during the migration process).
2. Notify the users to log off from the target domain.
3. Notify the users to log on to the source domain.
4. Verify that users are able to access resources.
5. Verify that the logon scripts and user profiles for users work as configured in the source domain.
The rollback process for resource objects is similar to that for account objects. To roll back to the premigration environment after migrating resource objects:
1. Change the domain membership for the server or workstation to the source domain.
2. Restart the server or workstation.
3. Log on as a user and verify that you can access the resource.
Note
If you need to modify objects such as member servers or domain controllers in order to migrate them to the target domain, back up all the data before making the modifications and performing the migration.