Configuring source and target domains
In the previous post of this series I discussed about the tasks involved in migrating a user from a domain to another in a hybrid exchange environment. Now let’s get down to the nitty-witty of migration.
Before getting into moving the users across to target domain, there are few things that need to be installed and configured in both source and target domain. Let’s start by looking at the configuration steps for source and target domains.
On a high level, below tasks need to be carried out:
- Ensure both the domains can resolve each other using domain name. To achieve this, conditional forwarders were setup in both the domains
- For the users to be able to access the resources from either domain, a domain trust between source and target domain needs to be setup
- Once forwarders have been setup, it’s good idea to add the source/target domains suffix to the suffix search list as well so that names resolution can be simpler.
- Setup the desired OU structure in target domain
- SID filtering configuration to be able to migrate SID history
- Add accepted domains for internal relay. This is done so that users can continue using the sub-domains from source forest as email alias until source domain is decommissioned.
Configuring DNS forwarders
To create a conditional forwarder in windows server 2008:
- Open the DNS Management console.
- Right-click Conditional Forwarders in the left pane and select New Conditional Forwarder.
- Type the name of the domain for which the forwarder is being created in the DNS Domain field.
- Type the fully qualified domain names (FQDNs) or IP addresses of the servers to which queries should be sent in the IP addresses of the master servers’ field.
- If desired, select the Store this conditional forwarder in Active Directory, and replicate it as follows checkbox, then select a replication scheme from the dropdown list.
Setting up the Domain Trust
A 2-way trust will be setup between the source and target domains.
- Open Active Directory Domains and Trusts.
- In the console tree, right-click the domain node for the forest root domain, and then click Properties.
- On the Trust tab, click New Trust, and then click Next.
- On the Trust Name page, type the DNS name (or NetBIOS name) of another forest, and then click Next.
- On the Trust Type page, click Forest trust, and then click Next (to setup a forest trust both domains will need to be at a 2003 Forest Functional level or higher.)
- On the Direction of Trust page, do one of the following (for our purpose, a “two-way” trust option had to be chosen):
- To create a two-way, forest trust, click Two-way. Users in this forest and users in the specified forest can access resources in either forest.
- To create a one-way, incoming forest trust, click One-way: Incoming. Users in the specified forest will not be able to access any resources in this forest.
- To create a one-way, outgoing forest trust, click One-way: outgoing. Users in this forest will not be able to access any resources in the specified forest.
- To be able to setup both sides of the trust from target domain, other domain administrator credentials will be required.
- Select Domain-wide authentication option to enable users to be authenticated to use all of the resources in local domain
- Confirm both the incoming and outgoing trusts
Configuring DNS Suffix Search List
- Now the clients from both the domains should be able to resolve FQDNs from the other. This will be achieved by setting up a new GPO and set DNS Suffix search List for clients.
- On a domain controller in target domain, click Start, Administrative Tools, then click Group Policy Management.
- Create new GPO.
- Right click on the Policy, then click Edit.
- In Group Policy Management Editor, go to Computer Configuration\Policies\Administrative Templates\Network\DNS Client. Right click DNS Suffix Search List, and then click Edit.
- On the DNS Suffix Search List Properties page, select Enabled. In the DNS Suffixes box, type the target domain and then source domain, then click OK.
- Close all, open Command prompt and run GPUPDATE /force command.
- On the domain controller in source domain, click Start, Administrative Tools, then click Group Policy Management.
- Create new GPO.
- Right click on the Policy, then click Edit.
- In Group Policy Object Editor, go to Computer Configuration\Administrative Templates\Network\DNS Client. Right click DNS Suffix Search List, and then click Properties.
- On the DNS Suffix Search List Properties page, select Enabled. In the DNS Suffixes box, type the source domain and then target domain, then click OK.
- Close all, open Command prompt and run GPUPDATE /force command.
- Group policy configuration should have been updated on the clients and can be tested by opening Command prompt and run IPCONFIG /ALL command.
Configuration of target OU for migration
Active Directory is built on a hierarchy of objects known as Organisation Units (OUs) that are arranged to meet the needs of an organisation. The OUs contain the user and group accounts that will be migrated. When migrating, the target OU of the user or group object that is migrating must be specified.
Depending on your business case and requirements, this step might vary. In my case, to ensure consistency and interoperability of existing AD structure and configuration, I had to export the current source OU structure and imported it into the target domain under a separate new OU.
“LDIFDE” tool will be utilised to achieve the above migration of OU Structure. Syntax for the command is as below:
| LDIFDE | Command Syntax |
| Export function | ldifde -f c:OUs.ldf -r “(objectClass=organizationalUnit)” -l objectClass,description |
| Import function | ldifde -i -f c:OUs.ldf |
It’s a good idea to script the commands for all the OUs to be created and then run the script from command prompt.
SID filtering configuration
SID history is needed to maintain user access to resources in source domain while the migration is underway. It’s very rare, sply in large environments that all the resources like fileshares etc are migrated at the same time as user. So, there will be a time duration in which after migration users in target domain still need access to resources in source domain that have not been migrated yet.
When an object is migrated to another domain, it is assigned a new SID. And this can result in the user losing access to that resource unless all the permissions are re-assigned. ADMT provides an option using which SIDs from source domain can be migrated with user as SID history so that the access to resources can be retained.
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 that are running Windows 2000 Service Pack 4 (SP4) or later.
If you choose migrate SID history along with the user using ADMT, you will need to disable SID filtering (the default setting in a forest trust.) If this step is not performed, SID history migration will not be successful. The ADMT tool will configure the disabling SID filtering when this option is selected.
Run Netdom as a domain administrator from the target domain.
Forest trust: netdom trust trustingDomain /domain:trustedDomain /enableSIDhistory:yes /usero:domainadministratorAcct /passwordo:domainadminpwd
For external trust, the command is slightly different.
Another requirement for ADMT to migrate SIDHistory is the “Audit Account Management” and “Audit directory service access” setting on both source and target domains.
Enable auditing of account management in the source and target domains. Furthermore, enable auditing for directory service access to migrate users with SID history between forests.:
- Log on as an administrator to domain controller in the source domain.
- Click Start, point to All Programs, point to Administrative Tools, and then click Group Policy Management.
- Navigate to the following node:
- Forest | Domains | Domain | Domain Controllers | Default Domain Controllers Policy
- Right-click Default Domain Controllers Policy and click Edit.
- In Group Policy Management Editor, in the console tree, navigate to the following node:
- Computer Configuration | Policies | Windows Settings | Security Settings | Local Policies | Audit Policy
- In the details pane, right-click Audit account management, and then click Properties.
- Click Define these policy settings, and then click Success and Failure.
- Click Apply, and then click OK.
- In the details pane, right-click Audit directory service access and then click Properties.
- Click Define these policy settings and then click Success.
- Click Apply, and then click OK.
- If the changes need to be immediately reflected on the domain controller, open an elevated command prompt and type gpupdate /force.
- Repeat steps above in target domain
In the source domain, create a local group called SourceDomain$$$, where SourceDomain is the NetBIOS name of your source domain. Do NOT add members to this group; if you do, SIDHistory migration will fail.
- On source domain DC, open Active Directory Users and Computers console, right click on Users container, select New then click Group.
Enable TCP/IP client support on the source domain primary domain controller (PDC) emulator.
- On the domain controller in the source domain that holds the PDC emulator operations master (also known as flexible single master operations or FSMO) role, click Start, and then click Run.
- In Open, type regedit, and then click OK.
- In Registry Editor, navigate to the following registry subkey:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
- Modify the registry entry TcpipClientSupport, of data type REG_DWORD, by setting the value to 1.
Note: If you are migrating from a domain with domain controllers that run Windows Server 2003 or later to another domain with domain controllers that run Windows Server 2003 or later, the TcpipClientSupport registry entry does not have to be modified.
Internal relay accepted-domains
If the users still want to use their email addresses from source domain as an alias, add those sub-domains from source domain as internal relay accepted domains in target domain.
New-AcceptedDomain -Name xxx.com -DomainName xxx.com -DomainType InternalRelay
Once this is done, the user can be assigned xxx.com from the source domain as an alias.
Series:
Part 1. Introduction and high-level migration approach
Part 2. Configuring source and target domains for SID history and accepted-domains
Part 3. Installation and configuration of ADMT tool and Password Export Server
Part 4. Groups Migration
Part 5. Users Migration
Part 6. Security Translation Wizard – Local Profiles and things to consider for end user experience