This article describes how Quest NDS Migrator determines a match between NDS and AD (Active Directory) Objects.
A match results when a mapping is created between an NDS object and a pre-existing AD object. The NDS path and the corresponding AD path are provided
in the mapping.
Mapping can be created through these three methods:
1. Selecting objects - select NDS object and AD container
2. Manual mapping - map NDS or Bindery object to existing AD users or groups
3. Import a Mapping File - import a CSV (comma separated variables), a Quest NDS Migrator project file (NPF), or an MSDSS file.
A matching will occur from methods 2 and 3 by intent. Method 1, selecting objects, will only result in a match if a 'matching' rule is applied during the 'Detect NDS to AD Collisions' action. Collisions are determined during the NDS to AD Collision Detection process (ran after the objects are selected but before the objects are migrated) by comparing the source NDS CN (common name) to the following three attributes of AD Objects:
If The NDS CN matches any of these attributes there is a collision. A rule must be selected and applied if a collision occurs. One of these rules is to establish a match between the colliding NDS and AD Object. If a match is established the NDS object will not be re-created. The option to migrate the
object attributes from the NDS object to the AD object can also be selected. After a match has been made, if files are migrated to which the NDS object has permissions, the AD object will have the equivalent permissions to the migrated NTFS files.