de-DEen-US
Language
Search
× Search
Tuesday, March 19, 2024

Active Directory to UCS Migration

Learn how to use CopyRight2 to migrate Active Directory users, groups, contacts and OUs from a Windows® domain controller to Univention Corporate Server (UCS).

Active Directory to UCS Migration

This video shows an Active Directory migration from a Windows 2019 domain to Univention Corporate Server (UCS) using CopyRight2. In this video we show how to setup a UCS Active Directory-compatible Domain Controller and then configure a CopyRight2 copy job to migrate the Active Directory objects from the source to the target domain.

You can download the UCS images from the following URL: https://www.univention.com/downloads/download-ucs/

Opposed to Microsoft's ADMT, CopyRight2 does not require a trust between the two domains, neither any agents that have to be installed, nor does it require a SQL server instance. As it supports sidHistory-less migrations, there is no security risks attached to it and none of the requirements of ADMT have to be fulfilled.

For simplicity, in this video, the account used to run the migration has the same password in both domains (a.k.a. pass-through authentication), otherwise the GUI would prompt for authentication.

Video

Environment

The source server "WIN2K19" is a domain controller of the "DomainE.Com" domain. The target system "UCS-6999" is a domain controller of the "Acme.Com. The two domains are in two different forests. CopyRight2 was previously installed on the source system, to push the accounts to the target. There is no trust defined between the two domains.

There are 3 OUs called "Support", "Marketing" and "Sales" in the source Active Directory. Those three OUs and any users, groups, contacts, distribution lists and OUs they contain, shall get migrated into 3 OUs having the same names, located directly below the root of the target Active Directory.

If the source domain was running on a different Windows versions the same settings could be used.

Settings

Job Type
User and Group Migration

Name and Description Page
Name: Active Directory Migration

Source and Destination Page
Source computer: WIN2K19
Destination computer: UCS-6999

User and Group Migration Page
Specific accounts: The OUs of the "Support", "Marketing" and "Sales" departments, including any users, groups, contacts and distribution lists contained.

Filter Page
User accounts: Enabled (Add/Update)
Local groups: Enabled (Add/Update)
Global groups: Enabled (Add/Update)
Contacts: Enabled (Add/Update)

Settings Page
Migrate user passwords: Disabled
Local group memberships: Enabled (Add/Remove)
Global group memberships: Enabled (Add/Remove)
Local group members: Enabled (Add/Remove)
Global group members: Enabled (Add/Remove)
Do not migrate any accounts indirectly that are not selected: Enabled

Active Directory Options Page
Migrate OU & container structure: LDAP://DC=Acme,DC=Com
Local group memberships: Enabled (Add/Remove)
Global group memberships: Enabled (Add/Remove)

Notes

CopyRight2 fully supports sidHistory style migrations, where the target accounts (users or groups) get additional old SIDs added to grant access to resources referencing those SIDs the accounts had in the source domain. Using the sidHistory feature allows you to separate the account from the resource migration at the expense of higher complexity. After the user and group accounts have been migrated, you would have to perform a sidHistory cleanup, replacing the old SIDs the accounts had in the source domain, with the SIDs the accounts got in the target domain. Once all SIDs have been replaced, usually in NTFS and share level permissions, the sidHistory Active Directory field can be cleared and the migration is completed. There are several requirements to meet if you want to perform a sidHistory migration. Please check the CopyRight2 user's manual for more information on those requirements.

This example does not make use of sidHistory, to simplify the process. You can either run a subsequent data migration, automatically replacing the SIDs on-the-fly while the data and permissions are copied to the target, or in case the data should not get moved, you can use a "Security & Attributes" type of job to perform a search & replace operation for the accounts. This method has no additional requirements and much less complexity than a migration using sidHistory.

This example shows an interforest migration. CopyRight2 supports intraforest (source and target domain in the same forest) migrations as well. This case requires sidHistory to be used. In this scenario, the accounts get moved between the two domains and not copied. After the account was moved, it automatically gets the SID of the original source account added to its sidHistory field allowing access to the resource originally accessible.In case of an intraforest migration, it is not possible to copy the account using the original samAccountName, because the samAccountName has to be unique within the forest.

Terms Of UsePrivacy StatementCopyright © Sys-Manage, 1998-2024. All Rights Reserved.
Back To Top