Active Directory Groups
Now that we have got our both the AD environments ready to start the migration and installed all the required tools, let’s start moving the objects over. To ensure that we have the proper security structure in place before users are migrated to target domain, we’ll be dealing with Active Directory groups before migrating any of the user objects.
So, what is an AD group? How is the security structure controlled by these groups? Why are they important part of an AD schema?
Active Directory Groups are basically a collection unit of user accounts, computer accounts, and other groups to make it more manageable. Working with groups instead of with individual users helps simplify network maintenance and administration. Think of an environment where users are added/modified/removed multiple times in a week. With each user comes a list of resources that they need (controlled) access to. Managing the access permissions to a long list of resources (fileshares, printers, servers etc) for hundreds and hundreds of users would be a nightmare without security groups.
There are two types of groups in Active Directory:
- Distribution groups Used to create email distribution lists. These groups can be used only with email applications (such as Exchange Server) to send email to collections of users. Distribution groups are not security enabled, which means that they cannot be listed in discretionary access control lists (DACLs).
- Security groups Used to assign
permissions to shared resources.
- Security groups also support mail-enabled capability that enables you to use a security group as a distribution group as well. Although this adds a bit of confusion and complexity, it can be helpful in some scenarios and reduces the number of groups.
Using security groups, you can:
- Assign user rights to security groups in Active Directory.
- Assign permissions to security groups for resources.
Like distribution groups, security groups can be used as an email entity. Sending an email message to the group sends the message to all the members of the group.
Group scope
Groups are characterized by a scope that identifies the extent to which the group is applied in the domain tree or forest. The scope of the group defines where the group can be granted permissions. The following three group scopes are defined by Active Directory:
- Universal
- Global
- Domain Local
Note: In addition to these three scopes, the default groups in the Builtin container have a group scope of Builtin Local. This group scope and group type cannot be changed.
The following table lists the three group scopes and more information about each scope for a security group.
| Scope | Possible Members | Scope Conversion | Can Grant Permissions | Possible Member of |
| Universal | Accounts from any domain in the same forest Global groups from any domain in the same forest Other Universal groups from any domain in the same forest | Can be converted to Domain Local scope Can be converted to Global scope if the group does not contain any other Universal groups | On any domain in the same forest or trusting forests | Other Universal groups in the same forest Domain Local groups in the same forest or trusting forests Local groups on computers in the same forest or trusting forests |
| Global | Accounts from the same domain Other Global groups from the same domain | Can be converted to Universal scope if the group is not a member of any other global group | On any domain in the same forest, or trusting domains or forests | Universal groups from any domain in the same forest Other Global groups from the same domain Domain Local groups from any domain in the same forest, or from any trusting domain |
| Domain Local | Accounts from any domain or any trusted domain Global groups from any domain or any trusted domain Universal groups from any domain in the same forest Other Domain Local groups from the same domain Accounts, Global groups, and Universal groups from other forests and from external domains | Can be converted to Universal scope if the group does not contain any other Domain Local groups | Within the same domain | Other Domain Local groups from the same domain Local groups on computers in the same domain, excluding built-in groups that have well-known SIDs |
For more information about Active Directory groups:
AD Group Account Migration
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. All the universal and global groups are migrated first followed by domain local groups.
The User accounts gets added to the relevant groups (if already present) in the target domain when the user account migration is performed.
ADMT migrates security groups with some restrictions:
- Two groups cannot exist within the same domain with the same name.
- Built-in groups such as Domain Admins or Domain Users cannot be migrated.
- For (on-prem) distribution groups, you can consider converting the groups into cloud only (O365) groups. This gives the capability of adding users from both the source and target domain.
- A mail
enabled security group can only exist once, as they must be unique and are copied
to Office 365. And this can present a
challenge in terms of migration timing. To address this, when all the
production users are migrated, email capabilities from existing mail-enabled
security groups and distribution groups will be disabled in Source domain and
enabled on corresponding groups in Target domain.
- With a big bang migration, where all users are migrated at the same time, the mail enabled security groups can be enabled in the new domain at the same time the users are migrated.
- With a phased migration, where users are migrated in smaller groups, migrated users will not be able to receive the emails sent to the security group until the capability is enabled in the new domain.
Migration flow:
- Log on by using the ADMT migration account onto ADMT Server.
- Use the Group Account Migration Wizard and perform the steps in the following table.
| Source to target domain | Action |
| Domain Selection | Under Source, in the Domain drop-down list, select or type source domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller. Under Target, in the Domain drop-down list, select or type target domain. In the Domain controller drop-down list, type or select the name of the domain controller, or select Any domain controller, and then click Next. |
| Group Selection | Click Select groups from the domain, and then click Next. On the Group Selection page, click Add to select the groups in the source domain to migrate, click OK, and then click Next. |
| Organizational Unit Selection | Find the container in the target domain to move the global groups into, and then click OK. |
| Group Options | Click Migrate Group SIDs to the target domain. Make sure that all other options are not selected. |
| User Account | Type the user name, password, and domain of an administrative account (ADMT account) in the source domain. |
| Conflict Management | Click Do not migrate source object if a conflict is detected in the target domain. (this is done to make sure the migrating group from source domain doesn’t impact any group with the same name in target domain.) However, it’s useful not to select this option during a phased approach which allows you to copy any changes that might have been made to the groups permissions before each phase. |
- When the wizard has finished running, click View Log, and review the migration log for any errors.
- Open the Active Directory Users and Computers snap-in, and then locate the target OU. Verify that the groups exist in the target domain OU.
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