The Sysadmins

Tips and tricks from the Sysadmins

Category: Active Directory (page 2 of 4)

ADMT Series – 9. Merging Users with a Different sAMAccountName

Is the last post we looked at a vanilla user account migration, assuming a clean target domain.

There may be a situation where the users have already been created in the target domain with a different sAMAccountName. For example, the user Branch Warren might have the sAMAccountName of bwarren in the source domain but branch.warren in the target.

Source

Target

To get around this you can use an include file to map these different sAMAccountNames together when migrating. The include file is in the following format, and if we use the example above would look like this:

Sourcename,TargetSAM,TargetUPN
bwarren,branch.warren,branch.warren@target.local

Creating the Include File

To generate this list you can use CSVDE to pull out the required information from the two forests. The final include file will require a bit of manual preparation to get into the correct format.

From the source domain:

csvde -d "OU=source,DC=source,DC=local" -f sourceinclude.csv -l "sAMAccountName"

From the target domain:

csvde -d "OU=target,DC=target,DC=local" -f targetinclude.csv -l "sAMAccountName, userPrincipalName"

Create the include CSV file in the same format as the example above, I’ve created three users which I need to migrate and merge with an include file.

Sourcename,TargetSAM,TargetUPN
jjackson,Johnnie.Jackson,Johnnie.Jackson@target.local
jcutler,jay.cutler,jay.cutler@target.local
bwarren,branch.warren,branch.warren@target.local

Once you have this in place, the migration process is very similar to the method outlined in the last blog post. When you are asked to select users, choose Read objects from an include file, specify the Include file you created above.


Continue reading

ADMT Series – 8. User Account Migration Wizard

In this post we’ll run through the User Account Migration Wizard to migrate users from the source to target domain. This guide will cover migrating users that do not exist in the target domain, if they do, please wait for the next article which will cover merging user accounts with an include file and/or migrating only the siDHistory attribute (with no other attributes).

I have created 9 test users in the source domain, which are members of the global security group we migrated in the last series post.

Migrating Users

From the ADMT machine, run ADMT and select User Account Security Wizard.

Select the source and target domain, you can also select which specific domain controller to use.

Select users from the domain or use an include file (the include file will be explained in the next ADMT Series post).
Continue reading

ADMT Series – 7. Group Account Migration Wizard

Universal, global and domain local groups can be migrated with the ADMT tool. Each group type has different rules for membership, and each group type serves a different purpose. This affects the order that the groups are migrated from the source to the target domains.

 

Universal groups
Universal groups can contain members from any domain in the forest, and they can replicate group membership to the global catalog. Therefore, you can use them for administrative groups. When you restructure domains, migrate universal groups first

Global groups
Global groups can include only members from the domain to which they belong. Create global groups to organize users. Global groups should be migrated second.

Domain local groups
Domain local groups can contain users from any domain. They are used to assign permissions to resources. When you restructure domains, you must migrate domain local groups when you migrate the resources to which they provide access, or you must change the group type to universal group. This minimizes the disruption in user access to resources. Migrate Domain Local groups last.

In this example we will migrate a global security group and a domain local security group which is the member of the global group.

Migrating Global Groups

From the ADMT machine, run ADMT and select Group Account Security Wizard.

Select the source and target domain, you can also select which specific domain controller to use.
Continue reading

ADMT Series – 6. Service Account Migration Wizard

The Service Account Migration Wizard will identify, migrate and update services that run in the context of a domain user account. ADMT does not migrate services running under the Local System account as they are migrated automatically when the computer is migrated. The Local Service and Network Service accounts are not migrated, because they are well-known accounts that always exist in domains.

When you run the Migrate Service Account Wizard, you are asked to select the computers you wish to scan for service account flagging. You can either search for computers on the domain, or provide an include file (text file with new computer objects separated by a line break). The wizard will then deploy the ADMT agent to the selected computers and scan for services running in the context of a domain user account. After the scan is complete, you will be presented with a list of services and service accounts.

The Service Account Migration Wizard doesn’t migrate any service accounts, nor does it make any changes to the services running under the computers you choose. It’s simply to flag the service accounts in the ADMT database.

To migrate the service account and update the service with the migrated user (in the target domain), you need to run the User Migration Wizard and select the Service Accounts highlighted in the process above. This doesn’t need to be done straight away and can be part of the User Migration Process. For this demo I will carry out the complete process so you can see what happens to the services.

This step isn’t mandatory, and you would typically only run this against your servers (see the security concerns at the bottom of this post). You may find if you have a small number of servers you would want to do this manually with a re-jig of your service accounts. Or perhaps the target domain has a different policy for service accounts, be that a naming scheme or how they are used.

Identifying Service Accounts

On XP1.source.local I’ve changed two of the services to run under domain user accounts.

From the ADMT machine, run ADMT and select Service Account Migration Wizard.

Select the source and target domain, you can also select which specific domain controller to use.

Continue reading

ADMT Series – 5. Machine Preparation

This post will look at preparing your workstations and servers to work with ADMT and to make sure you give ADMT the correct permissions and connectivity.

Local Administrators Group

The ADMT Migration Account that you use to migrate workstations and member servers must have local administrator rights in the the source domain. If you don’t the ADMT agent cannot be deployed which will result in errors such as:

ERR2:7006 Failed to install agent on \\xp1.source.local, rc=5 Access is denied.

ERR2:7674 Unable to determine the local path for ADMIN share on the machine 'xp1.source.local'. rc=-2147024891

We’ll look at two ways to achieve this with group policy.

Method 1. Restricted Groups

Create a Domain Local Security Group in the Source Domain, add the ADMT Service Account (ADMTUser in my case) to the group. You may decide to simply add the domain admins group from the target domain, as this includes the ADMTUser account. Also the Domain Admins group will get automatically added when the computers are migrated. The end result is the same though.

Create a new GPO and link it to the OU with the computer objects in.

Give it a name.

Continue reading

ADMT Series – 4. Password Export Server

During the User account migration you will have the option to migrate passwords from the source domain user accounts to the target domain. If you choose to use this feature there are a few steps you need to carry out. This feature is very useful, and removes the requirement to communicate new passwords to end users.

 

Migrating Password Prerequisites

Before you can migrate passwords, you will need to install the password export server onto a domain controller in the source domain.

Download the tool here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=10370 https://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=53422

Before you go ahead and install PES onto a DC in the source domain you need to create an encryption key from the machine running ADMT in the target domain. In our case this is ADMT.target.local. From the command prompt run:

admt key /option:create /sourcedomain:source.local /keyfile:"c:\PES Key\PES.pes" /keypassword:*

Now head over to a DC in the source domain (AD01.source.local) and download and run the PES installer. When prompted choose the .key file you created on the ADMT machine.

Provide the password you used when creating the key.

Continue reading

ADMT Series – 3. SID History

In the first post we setup the trust and prepared Active directory for the migration. One of the last messages provided when creating the trust states:

To improve the security of this external trust, security identifier (SID) filtering is enabled. However, if users have been migrated to the trusted domain and their SID histories have been preserved, you may choose to turn off this feature.

What is SID History

SID history helps you to maintain user access to resources during the process of restructuring Active Directory domains. When you migrate an object to another domain, the object is assigned a new SID. Because you assign permissions to objects based on SIDs, when the SID changes, the user loses access to that resource until you can reassign permissions. When you migrate users into the target domain you will have the option to migrate the users SID to the target domain. This becomes the sIDHistory attribute under the new user object.

Resources within the source and target domains resolve their access control lists (ACLs) to SIDs and then check for matches between their ACLs and the access token when granting or denying access. If the SID or the SID history matches, access to the resource is granted or denied, according to the access specified in the ACL.

SID history can be used for roaming user profile access, certification authority access, software installation access and resource access.

To visualise this I’ve created a user called Ronnie Coleman in the source domain and run dsquery to display the user’s SID.

dsquery * -filter "&(objectcategory=user)(samaccountname=ronnie.coleman)" -attr objectsid

Here is Ronnie Coleman’s SID in the Source Domain:

If we use ADMT to migrate Ronnie Coleman to the target domain and migrate his SID from the source domain you will see both the new SID, and the sIDHistory from the source domain.

The actual process of migrating the sIDHistory will be shown in the Migrating Users part of the series, this post is simply to explain what SID History is and why you would use it in your migration.

Continue reading

Older posts Newer posts