This example describes a specific migration task that can be implemented
using the Move cross domain script action in User Management Resource
Administrator.
The implementation is straightforward but a number of restrictions apply.
This document describes these restrictions and the UMRA example project.
In this project, user accounts are moved to another domain, but other
Active Directory objects can be moved as well with UMRA.
Restrictions and Requirements
Both the source and destination domain must be
in native mode. The move operation will fail if one of the domains is
in mixed mode.
The domains must belong to the same forest of
domains. The domains can be child domains in a domain tree, but this is
not a requirement. As long as the domains are part of the same domain
forest, the move operation is possible.
The target user account to be moved must not be
a member of any global group in the source domain. By default, a user
account is made a member of the Domain Users global group and this group
is set as the primary group for the user account. You cannot remove the
group membership of a group configured as the primary group. Therefore,
the user must become a member of a universal group and the universal group
must be configured as the primary group.
The source account must be accessed through the
RID-master of the source domain.
The account running the UMRA application must
have sufficient access rights to remove the target user account from the
source domain and add the account to the destination domain. In a domain
tree, an account that is a member of the Enterprise Admins group of the
root domain, will have permissions to add and remove user accounts in
child domains.
Environment
For the example project, the following environment is used:
User accounts from the source domain are to be moved to
the destination domain. Source domain is: Accounting.TheFirm.com. The
user accounts are located in an Organizational Unit called USA.
The destination domain is: Marketing.TheFirm.com. The domain
controller of the destination domain is goudvis. The user accounts must
be moved to the organizational unit Europe in the destination domain.
All 3 domains run in native mode, Windows 2000, Service
Pack 4. A special universal group is created in domain Accounting, container
Users: PrimaryUniGroup. The UMRA project script configures this group
as the primary group of the user account that must be moved.
Move cross domain project
Goal of the project is to move the user account from an
OU in one domain to an OU in another domain. The script of the project
is described below in detail. The project is implemented as an UMRA mass
project, and the accounts to be moved are loaded directly from the network
bar. The UMRA Console application is ran from a domain controller in the
root domain, logged on as Administrator of the root domain. In principle,
the project can run on any domain controller as long as the logged on
user is an administrator of both the source and destination domains.
The overall UMRA Console application looks like this:
The source accounts are listed in the mass project window,
and the bottom of the mass project windows shows the script. The 4th column
of the project window is assigned to variable %LdapName% that is used
throughout the script. The %LdapName% represents the user account that
must be moved.
Move cross domain - Script
This section describes the script of the UMRA project. The
actual move operation is done in the last line of the script. All the
other script actions are used to setup the right primary group membership
of the account to move.
Get user (AD) - UMRA binds to the user
account in order to obtain the SAM account name. The SAM account name
is used to setup the new primary group membership.
The LDAP name property is used as the input of the script
action. The domain controller specified is a domain controller of the
source domain of the user accounts.
Important: The Username
property is used to export the %SamAccountName% variable.
This variable %SamAccountName% is used in subsequent script
actions.
Set primary group (non AD)
The action configures an universal group as the primary
group of the user account. This action is required in order to be able
to remove the group membership of the current primary group which is usually
the global group Domain Users.
The property Domain controller is used to access the child
domain that contains the user account. When running Windows 2000 (in native
mode), the domain controller must be specified using DNS. The script action
might fail if the name of the domain controller is specified using a NETBIOS
name.
The Account name property specified as %SamAccountName%
is the result from the previous script action. The Group name property
is the name of a universal group that becomes the primary group of the
user account.
Delete
a specific variable
The user object information regarding the primary group
needs to be refreshed internally. In order to do this, the application
must release the user account object and rebind to the account. Therefore,
the variable that holds the user account object %UserObject%
must be deleted.
If this action is not included, the Domain users group membership
cannot be removed successfully.
Get
user (AD)
This action is identical to the first Get user (AD) action.
Now, the UMRA Console application binds to the same user account with
an updated primary group account.
When the account succeeds, the %UserObject% variable holds
a data structure representing the user account to be moved. Before the
actual move operation, the global group memberships of the user account
are now removed.
Remove
user group memberships (AD)
The global groups can now be removed successfully. Note
that other non-global group memberships can be maintained, depending on
other requirements of the move operation.
Since the primary group is no longer a domain global group,
the Domain users global group
membership is now removed. Note that the group membership of the primary
group cannot be removed. If the property Remove
from universal group was set to Yes,
the action would not generate an error, but the user account was not removed
from the universal primary group.
Move
cross domain
This is the main action of the script and requires accurate
specification of the properties.
The Source object
property is the LDAP name of the object to be moved in the original location
(before the move).
Important: In case the
source domain has multiple domain controller, the domain controller with
the role of RID master must be used to access the source account.
Access to the source account is controlled by specifying
a binding string as part of the LDAP name:
To find the RID master of a domain, start Active
Directory Users and Computers, right click the domain and select
Operations Masters
In this example project, an user account is moved but the
same action can be used to move other types of accounts as well.
The Target container
property is used to specify the full LDAP name of the destination of the
object. The container can be an organizational
unit, domain or general container (e.g. Users). The container must be
specified using a server binding string in DNS format: goudvis.marketing.TheFirm.com.
This type of specification enforces the move operation to use Kerberos
authentication instead of NTLM.
Since the (common) name of the user account is not changed
in this example, the New name
property is not specified.
Move cross domain - Project execution
When executing the project, the moved user account becomes
a member of the Domain users global group of the new domain. The universal
group membership of the old primary group is automatically removed (this
is also possible with no problems!). The section below shows the log file
generated by the UMRA Console application when the project is executed
for a single user account:
Starting User Management
Resource Administrator session, build 1190 at 11:22:03 09/19/2005
11:22:03 09/19/2005 Finding
AD user using LDAP name: 'LDAP://CN=Actano Tece,OU=USA,DC=Accounting,DC=TheFirm,DC=com'.
Binding info 'AIRBUS-B' ignored, using property specification instead.
11:22:03 09/19/2005 User
account 'LDAP://Airbus-B.Accounting.TheFirm.com/CN=Actano Tece,OU=USA,DC=Accounting,DC=TheFirm,DC=com'
successfully found in Active Directory.
11:22:03 09/19/2005 Setting
primary group of account 'tecea' maintained on domain controller 'Airbus-B.Accounting.TheFirm.com'
to 'PrimaryUniGroup'.
11:22:03 09/19/2005 Primary
group successfully updated.
11:22:03 09/19/2005 Finding
AD user using LDAP name: 'LDAP://CN=Actano Tece,OU=USA,DC=Accounting,DC=TheFirm,DC=com'.
Binding info 'AIRBUS-B' ignored, using property specification instead.
11:22:03 09/19/2005 User
account 'LDAP://Airbus-B.Accounting.TheFirm.com/CN=Actano Tece,OU=USA,DC=Accounting,DC=TheFirm,DC=com'
successfully found in Active Directory.
11:22:03 09/19/2005 Removing
user account 'LDAP://Airbus-B.Accounting.TheFirm.com/CN=Actano Tece,OU=USA,DC=Accounting,DC=TheFirm,DC=com'
from the following groups: 'local, global, security, distribution'.
11:22:03 09/19/2005 User
'LDAP://Airbus-B.Accounting.TheFirm.com/CN=Actano Tece,OU=USA,DC=Accounting,DC=TheFirm,DC=com'
removed from group 'LDAP://Airbus-B.Accounting.TheFirm.com/CN=Domain Users,CN=Users,DC=Accounting,DC=TheFirm,DC=com'
(Global - security group).
11:22:03 09/19/2005 Moving
AD object 'LDAP://AIRBUS-B/CN=Actano Tece,OU=USA,DC=Accounting,DC=TheFirm,DC=com'
to 'LDAP://goudvis.marketing.TheFirm.com/OU=Europe,DC=Marketing,DC=TheFirm,DC=com'.
11:22:04 09/19/2005 Total
number of script action execution errors: 0.
End of session
Move cross domain - Possible errors
In case the project fails, check the following:
Source and target domain must be in
native mode.
The removal of the global group memberships
of Domain users fails. Therefore, the user cannot be moved since the account
is still a member of the global group. To check if this is the case, create
a universal group and add the account to the group. Set the group as primary
group and remove the membership.
The binding to the source account to
be moved is not correct. In case multiple domain controllers exist in
the source domain, the RID master must be used to bind to the source account.
The binding to the target container
of the move operation is not correct. User server binding with DNS notation:
server_a.mydomain.com (results in LDAP://server_a.mydomain.com/OU=&ldots;)
