Preparing To Migrate Existing Users And Groups

This section describes how to prepare your environment for migration and computer access, including how to create and configure the initial zones. This chapter also describes how to import existing account information into Active Directory, set up provisioning for new users and groups, and configure role-based access controls.

Collecting And Analyzing Users and Groups

Before you create any zones, you should collect and analyze information about existing users and groups in the target set of computers. After you have investigated user and group attributes and identified invalid accounts and conflicting attributes, you can draft a basic zone design that addresses the needs of that user population. The goal of the initial zone design is to provide access to those users who currently have access, so they can transition to Active Directory with no disruption to their work. Later, you can refine access to computers through role assignments, filtering, and other options, if needed.

Collecting Information from Other Departments in Your Organization

Before you look at the content of identity stores you want to migrate, you should consider other sources of information that will help you identify a definitive set of legitimate users. For example, it can be useful to contact people in other departments who have reliable knowledge about the current organization or historical knowledge about how the organization has evolved. Individuals with information about a segment of the user population can help you identify accounts that are obsolete or were created for testing, or belong to users who have left the company or moved to another department.

As a starting point for collecting information about existing users and groups, consider doing the following:

Contact HR to get an up-to-date list of current active-duty employees, contractors, and consultants. You can use this information to compare personnel records to the UNIX accounts to be migrated. After you identify which accounts correspond to people in the organization, you can create a spreadsheet to record the UNIX user names, UIDs, and other useful fields for those accounts.
Contact enterprise security administrators or department-level UNIX administrators to determine whether all of the accounts defined for a computer still need access to that computer. For example, you should determine if any users validated as current employees have changed departments or job functions. If a user no longer needs access to some computers, you may not need to add a profile for that user.
Identify any conventions used in defining the namespace. For example, is there a standard format for the contents of the GECOS field? How do the conventions used for UNIX, Linux, or Mac OS X accounts compare to the conventions used in Active Directory? For example, is the convention used for the UNIX login name the same as the convention used for the user’s sAMAcountName in Active Directory? Does the GECOS field follow the same conventions as the user’s displayName in Active Directory?
Identify which user attribute fields that can be used as primary keys for identifying a unique user. Depending on the conventions you use for creating new accounts, the user name, user identifier (UID), or the GECOS field may be a reliable field for identifying real users and mapping them to Active Directory accounts. If you use a standard provisioning convention across platforms for an attribute such as the GECOS field or user name, the convention makes it much easier to identify unique users and map user profiles to Active Directory accounts.

Using a Script to Retrieve User and Group Profiles for Each Computer

Alternatively, you can write a script to retrieve all of the /etc/passwd and /etc/group files in the target set of computers. For example, to create a hostname.passwd and hostname.group file for each computer in a target set of computers, you might use code similar to the following:

for name in cat hostname.txt; \
do scp $name:/etc/passwd $name.passwd; \
scp $name:/etc/group $name.group; \
done

This sample script includes the computer host name in the file name, so that you can determine which user and group definitions came from which computer. If you use a script to collect user and group information, copy all of the files generated by the script to a common location for analysis.

Collecting Data from NIS Domains

If you’re migrating users and groups from a NIS domain, you can use ypcat or niscat to generate a copy of the NIS passwd and group maps once for each NIS domain. For example, run commands similar to the following:

ypcat passwd > domainname.passwd
ypcat group > domainname.group

If you are collecting user and group information from NIS maps, copy all of the files generated by these commands to a common location for analysis.

Identifying Accounts that Should Not Be Migrated

After you have collected information about the existing users and groups in the target set of computers, examine each of the passwd and group files and NIS domain maps to create a list of users and groups that you do not plan to migrate into Active Directory. For example, in most cases, there’s no compelling business reason to migrate default system accounts, such as nfsnobdy or games, that will not map to Active Directory users. You should also eliminate accounts for people who have left your organization, and accounts that are locked or obviously invalid.

Eliminate Default System Accounts

In most cases, you can ignore all UNIX users with a UID less than 99 because those are the default operating system accounts. You may also want to skip migration for some or all UNIX service accounts unless you explicitly want to manage those service accounts, and any privileged commands they run, through Active Directory and zones.

You can manage the passwords for UNIX service accounts using Access Manager without having those accounts defined in zones or in Active Directory. Therefore, you may want to leave most or all of the service accounts as locally defined accounts.

In general, the only reasons to migrate default system or service accounts to Active Directory are:

If you want to use Active Directory password policies for the account.
If the service account itself owns one or more privileged commands that you want to manage through Centrify role definitions rather than locally in the sudoers file.

Typically, only service accounts that own special permissions, such the oracle user account, are migrated to Active Directory.

Remove Other Invalid Accounts

You should also skip migration for users who have left the organization and profiles that contain invalid data. Scan the data set for user accounts and groups that are locked or indicate they were created for testing. You should also check for profiles that contain obvious errors or legacy information no longer used.

In some cases, you may need to contact workstation or application owners directly to determine whether a profile should be skipped for migration. For example, assume the /etc/group file contains an entry for clowns with krusty, bozo, and tadams as members and there are valid user profiles for those three users. You may suspect the clowns group was created for some local testing, and therefore, not a candidate for migration. However, there’s no definitive indication that the clowns group should be skipped without more information.

Create a List of the Users and Groups to Ignore

Add all of the accounts that should not be migrated to a text file. For example, create a text file named user.ignore and include all of the user accounts you don’t want to migrate into Active Directory. For default system and service accounts that have known UIDs, you can create the text file programmatically using code similar to the following:

cat *.passwd ZZ_BAR_ZZ \egrep "x?:[0-9]:[0-9].ZZ_BAR_ZZx?:[0-9][0-9]:[0-9].ZZ_BAR_ZZx?:60[0-9][0-9][0-9]:[0-9]ZZ_BAR_ZZx?:65[0-9][0-9][0-9]:[0-9]" ZZ_BAR_ZZ \
cut -d ":" -f 1 | \
sort | \
uniq | \
sed 's/^/\^/' > user.ignore

Other accounts you have identified as invalid can be added manually or using code if they share some common attribute, such as LOCKED in the password field.

Analyze User Profiles for Conflicting Attributes

After the initial analysis to remove profiles that should not be migrated, you have a candidate data set of users and groups to import. The next step is to analyze the attributes in user profiles to identify any potential problems that you will need to address when you move the profiles into zones. IBM Security Professional Services offers scripts that assist in this process. If you are analyzing the files manually or writing your own scripts, here are the common issues you need to check for:

Determine whether any user name has more than one UID in the target set of computers. The UID is the primary way of determining file ownership and file permissions. On a single UNIX system, a user can only have one UID. However, across all of the computers in the target set, the same user name might have more than one UID.
Determine whether any UIDs are associated with more than one user name.
Determine whether any users have other profile conflicts, such as more than one primary GID, home directory, or shell on the computers in the target set.

In doing your preliminary analysis, keep in mind that you need to know which user profiles are associated with which people in your organization. For example, do the user names ldavis and davle refer to the same person (Len Davis) or to different people (Len Davis and Leslie Davidson).

This analysis of existing user profiles will help you identify the requirements of your initial zone design. The zone design allows you to use conflicting attributes as-is, without modifying any of the legacy data. You need to be aware of where there are conflicts so you can address them, but you do not need to change values for any attributes.

Analyze Group Profiles for Conflicting Attributes

You need to perform a similar analysis across the groups in the target set of computers. IBM Security Professional Services offers scripts that assist in this process. If you are analyzing the files manually or writing your own scripts, here are the common issues you need to check for:

Determine whether any group name has more than one GID in the target set of computers. Like the UID, the GID affects file ownership and file permissions. On a single UNIX computer, a group name can only have one GID. However, across all of the computers in the target set, the same group name might have more than one GID.
Determine whether any GIDs are associated with more than one group name.
Determine whether any group has a different set of members on any computers in the target set. Group membership is particularly important for zone design. The members of a group must be consistent across all of the computers in a zone.

As with the user analysis, this analysis of existing group profiles will help you identify the requirements of your initial zone design. The zone design allows you to use conflicting attributes as-is, without modifying any of the legacy data. You need to be aware of where there are conflicts so you can address them, but you do not need to change values for any attributes.

Create a Working Set of User and Group Profiles

After you have identified profiles that should not be migrated and noted any conflicting attributes you need to address, you have a known set of user and group profiles that you plan to migrate into Active Directory. The next step is to remove the users who should be ignored from list of users to import, and to remove the groups that should be ignored from the list of groups to import. You can do this manually or write a script that removes the profiles defined in the user.ignore and group.ignore files and outputs the results to a new file. For example, you might use code similar to the following to remove ignored users and generate a working set of user profiles:

mkdir output; \
for name in cat hostname.txt; \
do egrep -v -f user.ignore $name.passwd > \output/$name.passwd; \
done

How Migration Affects the Zone Design

As discussed in Why use zones?, identity management is one of the primary benefits of using zones. Identity management is important because most organizations have an existing user population where users can have multiple UIDs or other attributes, such as different default shells, on different computers and groups with the same name can have different members. Each user has one Active Directory user object but may have multiple UNIX profiles, some with attributes in common and some with different settings. Zones allow you to migrate the profile information as it is defined, setting overrides where necessary, so that you can manage and report on the accounts without rationalizing the user namespace.

For all of the computers in a zone, a user or group has one profile definition, but the user or group could have different profile attributes on the computers in a different zone. Hierarchical zones make the zone design even more flexible. Hierarchical zones allow you to define one or more profile attributes in a parent zone and use those profile attributes in all child zones. In practice, this enables you to define a dominant set of attributes in a parent zone, and inherit the common attributes in one or more child zones. You can also override any attribute at any point in the zone hierarchy down to an individual computer.

For example, if a UNIX administrator has a consistent profile across all of the UNIX computers, but a customized home directory on two Mac OS X computers, you could define the default profile for the user in a parent zone, then create a child zone for the Mac OS X computers and inherit all of the profile attributes except the home directory setting.

In planning the migration, you identify the attributes that are the same across the target set of computers and where there are differences. If you use hierarchical zones, the primary task is identify one or more potential parent zones. For example, if you are migrating two NIS domains, you might create two parent zones because the UID space is unique in each domain but there would be conflicting attributes if the domains were combined into a single parent zone. The computers in each of the parent zones would inherit the UID and other profile attributes from each distinct NIS domain.

After you have identified one or more parent zones, you can plan how you will use child zones and overrides to manage profile attributes, implement access controls, and delegate administrative duties.

Creating the First Zone

It is recommended that you plan to use hierarchical zones and create at least one top-level parent zone. A single top-level zone for your organization is also useful for long-term management of UNIX profiles. You can have more than one top-level parent zone. For example, if your organization has subsidiaries that are run independently or distinct geographical locations managed by different teams, you may want to create separate parent zones for those lines of business or locations.

Having a single top-level parent zone enables you to create an administrative group of super-users who can log on to every UNIX computer in your organization. It also allows to define some common rights and roles that can be inherited by child zones and the computers in those zones. Having a global or master zone for the entire organization also simplifies setting up provisioning for new accounts. However, there’s no restriction on the number of parent or child zones you create. If you have a distributed environment and delegate administrative authority to separate teams, you can create as many parent zones as you find useful.

This guide describes how to set up the migration environment using one top-level parent zone. If you create more than one parent zone, you may need to repeat steps or extrapolate additional steps from the information presented here.

Create a Top-level Parent Zone

Before you migrate users and groups or add computers to the domain, you must have at least one zone. It is recommended that you create one top-level parent for your organization, which is similar to having a single forest root domain.

To create the top-level parent zone

Log on to the Windows computer where Authentication & Privilege is installed and open Access Manager.

If you are not currently connected to the appropriate forest, specify the domain controller to which you want to connect.
In the console tree, select Zones and right-click, then click Create New Zone.
Type the zone name and, optionally, a longer description of the zone.

In most cases, you should use the default parent container and container type that you created when you configured the Active Directory forest, and the default zone type, which creates the new zone as a hierarchical zone, then click Next.

The only reasons for changing the default settings would be if you want to:
- Create a zone in a new location to separate administrative activity for different groups of administrators.
- Create zones as organizational units because you want to assign group policy objects to zones.
- Create a classic zone for backwards compatibility or are using the Microsoft Services for UNIX (SFU) schema.
  
  For additional details about any of the zone fields, press F1 to view context-sensitive help.
Review the information about the zone you are creating, then click Finish.

Add Provisioning Groups to the Parent Zone

The next step in configuring the top-level parent zone is to create two Active Directory groups that will enable automated provisioning and de-provisioning of users and groups in the toplevel parent zone. By creating these provisioning groups in the parent zone, you can integrate the provisioning of UNIX users and groups with your existing processes for provisioning Active Directory users.

The provisioning groups are not required for migration, but a recommended configuration for the top-level parent zone you are creating as the first zone in the environment.

It is recommended you follow the naming conventions suggested for these groups. If you use a different naming convention, you should be sure it is well documented in your internal process documentation.

To add the provisioning groups for user and group profiles to the parent zone

Start Active Directory Users and Computers.
Expand the forest domain and the top-level UNIX organizational unit you created in Selecting a location for the top-level OU.
Select Provisioning Groups, right-click, then select New > Group.
Type the group name using the format ZoneName_Zone_Groups. For example, if the zone name is arcadeGlobal, type arcadeGlobal_Zone_Groups, then click OK.

The Zone Provisioning Agent will use this group when processing the business rules for adding or removing group profiles in the parent zone.
Select Provisioning Groups, right-click, then select New > Group.
Type the group name using the format ZoneName_Zone_Users. For example, if the zone name is arcadeGlobal, type arcadeGlobal_Zone_Users, then click OK.

The Zone Provisioning Agent will use this group when processing the business rules for adding or removing user profiles in the parent zone.

To prevent problems in UIDs and GIDs for existing users and groups, you should import existing user and group profiles before defining the business rules for automated provisioning of new accounts. After you complete the migration of the existing user population, you will define the business rules for the ZoneName_Zone_Groups and ZoneName_Zone_Users groups you just created.

Create Groups for the Default Roles in fhe Parent Zone

The next step in configuring the top-level parent zone is to create two Active Directory groups for the default listed and UNIX Login roles that are predefined in hierarchical zones.

If you have a single top-level parent zone, users with a listed role can be recognized as having a valid profile on every UNIX computer in the organization. However, users in the listed role are not allowed to log on to any of those computers.
If you have a single top-level parent zone, users with a UNIX Login role can log on to every UNIX computer in the organization.

For the toplevel parent zone, the UNIX Login role is intended for enterprise-level systems administrators who need to be able to log on to any UNIX computer in the organization. Because these are powerful roles in the parent zone, only a limited number of users would ever be assigned to these roles. However, the listed and UNIX Login roles are key components of migration when you create one or more child zones. If no users in the organization will be assigned these roles in the parent zone, you can skip the creation of the Active Directory groups for roles in the parent zone.

To create the groups for listed and UNIX Login roles in the parent zone

Start Active Directory Users and Computers.
Expand the forest domain and the top-level UNIX organizational unit you created in Selecting a location for the top-level OU.
Select the User Roles organizational unit, right-click, then select New > Group.
Type the group name using the format ZoneName_Role_RoleName. For example, if the zone name is arcadeGlobal, type arcadeGlobal_Role_Listed, then click OK.
Select the User Roles organizational unit, right-click, then select New > Group.
Type the group name using the format ZoneName_Role_RoleName. For example, if the zone name is arcadeGlobal, type arcadeGlobal_Role_Login, then click OK.

Delegate Administrative Tasks on the Parent Zone

The next step in configuring the top-level parent zone is to delegate administrative authority to the Zone Administrators group and to delegate specific permissions to the service account for the Zone Provisioning Agent to enable automated provisioning of user and group profiles in the parent zone.

To delegate administrative tasks on the top-level parent zone

Start Access Manager.
In the console tree, expand the Zones node.
Select the top-level parent zone, right-click, then click Delegate Zone Control.
Click Add.
Change the Find list from User to Group, type z, then click Find Now.
Select Zone Administrators in the results, then click OK.
Click Next.
Select All to enable members of the Zone Administrators group to perform all administrative tasks on the top-level parent zone, then click Next.
If you are delegating the task of joining computers to a zone, you can specify the scope of computers you can join to the zone; you pick a container in Active Directory to grant access to.

If you leave the scope blank, the scope is the domain root. Be aware that the postalAddress field is used for information about joining computers to a zone; if you lookup the permissions for people you've delegated the task of joining computers to a zone, they'll have permissions to the postalAddress field for the affected computers.
Review your selections, then click Finish.
Right-click, then click Delegate Zone Control.
Click Add.
Type all or part of the service account name for the Zone Provisioning Agent that you created in About Zone Provisioning Agent and its requirements, click Find Now, then select the service account in the results and click OK.
Click Next.
Select the following delegation rights for the Zone Provisioning Agent service account, then click Next:
- Change zone properties
- Add users
- Add groups
- Remove users
- Remove groups
Review your selections, then click Finish to save the changes and close the dialog.

Link a Role Group to a Role Assignment in the Parent Zone

The next step in configuring the top-level parent zone is to link the Active Directory role groups created in Create groups for the default roles in the parent zone with the listed and UNIX Login role definitions that are predefined in the parent zone. You create this link between an Active Directory group name and the combination of rights associated with a role name by assigning the Active Directory group to the role.

Start Access Manager.
In the console tree, expand Zones, the top-level parent zone, and Authorization nodes.
Select Role Assignments, right-click, then click Assign Role.
Find the ZoneName_Role_Listed Active Directory group, then click OK.
Click Browse.
Select the listed role from the list of available roles, then click OK.
Check that the Start immediately and Never expire options are selected and appropriate or deselect those options and set start and end times, then click OK.
Repeat Step 3 through Step 7for the ZoneName_Role_Login Active Directory group and the UNIX Login role.

Create One or More Child Zones

After you have created a parent zone and prepared it with provisioning and role groups, you can create one or more child zones. You can create the child zones based on any logical model you choose. This is where the analysis of common and conflicting attributes and some creativity come into play.

Logical Models for Defining Zones

Because the zone design uses hierarchical zones, you can override attributes at any zone or computer level to deal with conflicts in legacy profile data. With this flexibility, you can experiment with different possible designs, for example, based on delegated administrative authority or physical location. Some common models for grouping a set of computers, users, groups, roles, and rights in the same zone include:

By shared identity store For example, existing identity stores, such as NIS domains or a centralized user and group database, often provide a natural boundary for zones. This strategy is especially effective if each identity store has a consistent namespace, without profile conflicts. It is less effective if the computers that share a common administrative group use local /etc/passwd and /etc/group file to store account information.
By application or function For example, you might want to groups all of your database servers or web farm servers into their own zones. As part of this design, you might need to evaluate whether you are combining development computers with production servers and what role assignments you’ll need to control what users can do on each type of computer.
By geographical region or line of business For example, all of the UNIX computers that support a business unit could be logically grouped together. As part of this design, you might evaluate whether different business units should be responsible for provisioning users or assigning roles within their own business unit.
By host name If you already have a meaningful host name convention that identifies machine owners or primary function, you may want to create zones based on that naming convention.
By platform and operating system You can use this strategy, for example, to create separate zones for Red Hat Linux workstations and Sun Solaris UNIX workstations.
By department or user community You can use this strategy, for example, to create separate zones for the computers that host financial applications and computers used by software developers.

You are not required to create child zones. You could control access to the parent zone through role assignments. For most organizations, however, one or more child zones makes it easier to assign roles and manage group membership.

Depending on your target set of computers, you may decide to start with one or two child zones or skip the creation of a child zone.

Create a Child Zone under the Parent Zone

Creating a child zone is similar to creating a parent zone. You select the parent in the left pane, then create and configure the child zone to prepare an environment into which you will migrate existing users and groups.

To create a child zone under the parent zone

Start Access Manager.
In the console tree, expand the Zones node.
Select the top-level parent zone, right-click, then click Create Child Zone.
Type a name and description for the child zone, then click Next.

For example, if you are organizing by functional group, this zone might be finance or engineering. If you are organizing by data center location, the child zone might be sanfrancisco or seattle.
Click Finish to complete the zone creation.

The new zone is listed under the Child Zones node in the left pane.

Create Role Groups for Child Zones

The next step in configuring the child zone is to create two Active Directory groups for the default listed and UNIX Login roles that apply to this zone.

In the child zone, users with a listed role can be recognized as having a valid profile but only on computers that are joined to the child zone. Users in the listed role for the child zone cannot log on to any of the computers joined to the child zone.
In the child zone, users with a UNIX Login role are allowed to log on to every UNIX computer joined to the child zone if they have a UNIX profile for the zone.

For the child zone, the UNIX Login role is intended zone-level administrators and users who were previously able to log on to the UNIX computers joined to the child zone. The listed and UNIX Login roles are key components of migration when you create one or more child zones.

To create the role groups for listed and UNIX Login roles in the parent zone

Start Active Directory Users and Computers.
Expand the forest domain and the top-level UNIX organizational unit you created in Selecting a location for the top-level OU.
Select User Roles, right-click, then select New > Group.
Type the group name using the format ChildZoneName_Role_RoleName. For example, if the child zone name is sanfrancisco, type sanfrancisco_Role_Listed, then click OK.
Select User Roles, right-click, then select New > Group.
Type the group name using the format ChildZoneName_Role_RoleName. For example, if the zone name is sanfrancisco, type sanfrancisco_Role_Login, then click OK.

Delegate Administrative Tasks on the Child Zone

The next step in configuring the child zone is to delegate administrative authority to the Zone Administrators group. The steps are the same for the child zone as the parent zone, except that you expand the Child Zones node and select the name of the child zone before selecting the Delegate Zone Control command. You should still assign the Zone Administrators group All permissions.

You also have the option of assigning the permissions to join or leave to the Join Operators Active Directory group. If you pre-create computer accounts and allow the computer to join itself to the Active Directory domain, you can skip this step.

If you don’t want to pre-create the computer account and allow the self-service join, you must give members of the Join Operators group the following administrative tasks:

Join Computers to the Zone
Remove Computers from the Zone
Modify Computer Profiles

Link Role Groups to Role Assignments in the Child Zone

The next step in configuring the child zone is to link the Active Directory role groups created in Create role groups for child zones with the listed and UNIX Login role definitions that are predefined in the child zone. You create this link between an Active Directory group name and the combination of rights associated with a role name by assigning the Active Directory group to the role. The steps are the same for the child zone as the parent zone, except that you expand the Child Zones node and select the name of the child zone before selecting the Authorization node.

When you search for the Active Directory group to assign, you will select the ChildZoneName_Role_Listed, for example sanfrancisco_Role_Listed, for the listed role, and ChildZoneName_Role_Login, for example sanfrancisco_Role_Login, for the UNIX Login role.

Users who are added to the ChildZoneName_Role_Login group will be able to log on to computers that are joined to the child zone or any of its own children, but will not be able to log on to computers in other child zones.

Create Computer Objects For The Target Set Of Computers

When you manage UNIX computers with Centrify software, you add computer objects to Active Directory for those computers. These computer objects can be created automatically when a computer joins the domain, or created in Active Directory before the computer joins the domain. In most cases, Centrify recommends that you create the computer account objects before joining, if possible.

For deployment and migration, creating the computer objects before joining provides the following key advantages:

You can define computer-level overrides before computers are added to the zone. This allows you to resolve issues with divergent UNIX profiles without having to change file permissions at the file system level.
You can check who will have access to which UNIX computers before those computers join the Active Directory domain.

Pre-creating the computer objects enables you to check that you have user profiles and role assignments correctly defined before you join the UNIX computers to zones. Verifying this information before the join operation helps to ensure a smooth migration without disrupting users’ access to files or applications.

Prepare A Computer Object Before Joining

In most cases, you should pre-create the computer object for every UNIX computer in every zone. For individual computers, you can use the Prepare Computer wizard to guide you through the process. However, you will probably want to create a Windows or UNIX script for performing the operation repeatedly. For example, you can use adedit or the Windows API to create a script.

To prepare a computer account in Active Directory using Prepare Computer

Start Access Manager.
In the console tree, expand the Child Zones node, then expand the child zone for this computer to join.
Select the Computers node, right-click, then click Prepare Computer.
Accept the default preparation options, then click Next.
Accept the default to Create a new computer object, then click Next.
Type the name of the computer object to create and modify the DNS host name of the computer object, if necessary.

The computer name is the name of the computer principal in Active Directory. The DNS name is how the UNIX computer is currently registered in DNS. If you have a disjointed DNS namespace, you should be sure the DNS name is the name used in the computer’s DNS entry.
Click Change and navigate to the organizational unit for storing computer principals. For example, if you created the organizational unit structure described in Creating recommended organizational units, select UNIX Servers and Workstations and click OK, then click Next.
Select an option for joining the computer to the domain, then click Next.
- If you want to require users to interactively join the computer to Active Directory, click Browse to select the Join Operators group.
- If you want to allow the computer to join itself to the zone, select Allow the computer to join itself to the zone. This option automatically associates the computer with the correct zone, so there’s less chance of a human error.
Click Browse to select the Zone Administrators group, then click Next.

With this setting, users in the Zone Administrators can override any inherited attributes of a UNIX user or a UNIX group profile on the computer.
Review your selections, then click Next to create the computer account.
Click Finish to complete the process.

You have now finished preparing the environment for migration and are ready to begin importing groups and users and assigning them appropriate roles.