Migrating Existing Users To Hierarchical Zones

Now that you understand how zones are used and have prepared an environment for an initial migration, you are ready to import the existing users and groups that you have identified as candidates for being migrated to Active Directory.

This section uses a sample data set to illustrate how to migrate an existing user population into hierarchical zones and how to assign the appropriate roles to convert from a legacy authentication model to Active Directory and Server Suite.

Importing Group Profiles

After you have created one or more zones and separated the users and groups to ignore from the users and groups that you think should be migrated to Active Directory, you must decide which groups apply to which zones. For example, if you have some groups with the same group profile and group membership in all zones, you would import those groups into the top-level parent zone so that they also exist, with the same definition, in all child zones. If a group is only applicable for computers in a child zone, you can import the group profiles directly into that zone. You can also override group profile attributes on specific computers, if needed.

After you have made these decisions, importing the groups is a simple process using either the Import from UNIX wizard or ADedit scripts with two important considerations:

Group names must be unique in Active Directory. If you create a group with a common name, such as admins, you cannot create another group with the same name.
Having the same UNIX group name on computers in different zones can create group collisions and inadvertent privilege escalation or file ownership conflicts.

To prevent group name collisions, Centrify recommends that you include the zone name in the Active Directory group name. You may also want to add a suffix that identifies the group as an UNIX security group. In most cases, you create the Active Directory group object for the UNIX group in the UNIX Groups organizational unit if you created the organizational unit structure described in Creating recommended organizational units.

You should import group profiles and create the corresponding Active Directory groups for those groups before you import users. If you import group profiles first, you can resolve secondary group membership for users immediately after you import user profiles.

Import Unix Groups that Apply to All Computers into the Parent Zone

If your organization has a default UNIX administrators group or security group that you want to be available on all UNIX computers, that group is a good candidate for importing into the parent zone. Other groups that might be candidates for the parent zone are special purpose UNIX groups that own sudoers permissions that apply to all UNIX computers or an auditing group that requires access to all computers.

If you have identified any common groups, use the Import from UNIX wizard or a script to import the UNIX groups that should be available for all computers into the top-level parent zone.

To Import Unix Groups Using the Import from Unix Wizard

Start Access Manager.
In the console tree, expand Zones and the top-level parent zone.
Select UNIX Data, right-click, then click Import from UNIX.
Click UNIX configuration files, then click Browse to locate and select the group file to import, then click Next.
Select the option to automatically shorten the UNIX name, if desired, then click Next.
Leave Store in Active Directory selected and click Next.
Select Check data conflicts while importing, then click Finish.

This step places the profiles under Groups as Pending Import.
Select one or more group names that are Pending Import, right-click, then select Create new AD groups.
Click Browse, navigate to the UNIX Groups organizational unit and click OK, then click Next.
Click Add a prefix to group name, type the parent zone name and an underscore (), select the group scope as Global, then click Next. For example, if the parent zone name is arcadeGlobal, use the prefix arcadeGlobal.

Optionally, click Add a suffix to group name and type a suffix that identifies the group as a UNIX security group, for example, _unix.
Review the information displayed, then click Finish.

For more information about importing groups, see the Administrator’s Guide for Linux and UNIX.

Import Unix Groups that Apply Only to a Specific Zone into a Child Zone

From your initial analysis and zone design, you should also have a reasonable plan for groups that apply to specific child zones. Groups imported into a child zone are visible to all the UNIX computers in that zone, but not in other zones. For example, assume you have identified an application-specific group, ora_app01, that allows users to use a database, and the database application exists three computers. In your zone design, you decide those three computers should be a single child zone. In that case, you import the ora_app01 group profile into the child zone group because the database application group is only relevant to the UNIX computers in the child zone.

The steps for importing into a child zone are the same as for the parent zone, except that you select the UNIX Data under the child zone name in the console tree and specify the child zone name as the prefix for the Active Directory group name.

Import a Group Profile or Override Attributes on Specific Computers

In some cases, you may have a UNIX group that only exists on one computer in a zone or exists on more than one computer but has different attributes on different computers. You can use computer-level overrides to handle these cases. Computer-level overrides enable Zone Administrators to create and manage group profile attributes manually for individual computers.

To create a group profile for a specific computer

Use Active Directory Users and Computers to create an Active Directory group in the UNIX Groups organizational unit. If the group only applies to a specific computer, you may want to use the computer name as the prefix.
Start Access Manager.
Expand the console tree to display the individual computer object under the zone the computer will join.
Expand UNIX Data, select Groups and right-click, then click Create UNIX Group.
Click the attributes to define, type the appropriate values, then click OK.
- Click GID to manually specify a GID for the group profile on the selected computer.
- Click UNIX group name to manually specify a group name for the profile on the selected computer.

Avoiding Group Collisions When Using Computer-level Overrides

If you create group profile overrides on individual computers, you should make sure that the UNIX group name and GID are not being used by any other groups in the parent or child zone. If the group profile defined for the computer is the same as a group profile defined for a group in the parent or child zone, users who should only be able to access files on the local computer may be able to access files owned by the group defined for the parent or child zone. This can be a difficult problem to identify. For example, assume you have an Active Directory group named contract_admins, but you have used the UNIX group name admins and the same GID as a group in the parent zone. Any user who is a member of the contract_admins group in Active Directory is going to have the same GID as the parent zone’s admins group. If that happens, members of the contract_admins group will have access to the same files as the admins group in the parent zone.

The only way to identify when this problem occurs is by running the following command for a user in the contract_admins group:

id -a

Importing User Profiles

You can import user profiles into the parent zone or into child zones. If you import user profiles into the parent zone, all existing users will be included in the candidate set of users who have the potential to log on to all of the UNIX computers in the organization. However, they are not granted any access by default. Instead, the management of identity information, such as the user name, UID, and primary group, is separate from privilege management. Users cannot access any UNIX computers until they are assigned a valid role with the specific permissions they need to be recognized, allowed to log on, or run specific commands.

Although you can import users into the parent zone without granting them access rights, you may prefer to import them into one or more child zones. By importing users into specific child zones, you can limit the scope of their potential access. In general, this option is applicable for the majority of your end-users and can apply to other users, such as database administrators, project managers, and contractors who won’t ever need access to all the UNIX computers in the organization.

At this stage you should decide whether to give users the potential to access all computers in the organization, or only the computers in one or more specific child zones. After you import the user profiles, you will use the default listed and UNIX Login roles or custom roles to control access to the UNIX computers.

The steps for importing user profiles into a parent or child zone are essentially the same as importing groups. You can use the Import from UNIX wizard or ADedit scripts to import the profiles into one or more zones. The profile information for any user can be different in each zone. If the profile information is divergent on any computer within a zone, you can set computer-specific overrides for any or all attributes.

If you are importing users from a file, you can write a script that modifies the GECOS field to use the same format used in the Active Directory displayName attribute before importing so that users are automatically mapped to their corresponding Active Directory accounts. For example, if your convention for the GECOS field is first_name last_name (Jae Wilson) but the convention used in Active Directory is last_name, first_name (Wilson, Jae), you must manually map the UNIX user account to the Active Directory account. If you modify the format of the GECOS field before importing, the Import from UNIX wizard can automatically suggest a candidate for mapping the UNIX user to an Active Directory user, if an account exists.

After you import users, their profiles are placed under Users as Pending Import. If the user has an existing Active Directory account, you can select the user name, right-click, then select Extend existing AD user. If an Active Directory account does not exist, you can select the user name, right-click, then select Create new AD users. You can then use Check Status to resolve group membership for Pending Groups. This command adds the imported users to the appropriate Active Directory groups that have UNIX profiles in the zone to complete the first phase of the migration to Active Directory.

For more information about importing users and resolving group membership, see the Administrator’s Guide for Linux and UNIX.

How Group Membership Works Within Zones

When a UNIX group profile is imported into a zone, its group name and GID are recognized by all computers joined to that zone. However, the group membership might vary by computer. For a user to be a member of the UNIX group, the user must:

Be a member of the Active Directory group.
Have a complete UNIX user profile defined somewhere in the zone hierarchy (in the parent zone, a child zone, or with computer-level overrides).
Be assigned the listed role or the UNIX Login role somewhere in the zone hierarchy (in the parent zone, a child zone, or with computer-level overrides).

For example, assume the users Alison and Clyde are assigned the UNIX Login role for the Engineering zone. As discussed in Create role groups for child zones, that means they are also listed as members of the Engineering_Role_Login role group in Active Directory. Clyde is also a member of the denali project group in the Engineering zone and has a profile defined in the parent zone. Alison’s profile is defined in the Engineering zone. If the denali project group (Engineering_Denali in Active Directory) is added to the Engineering zone, both Alison and Clyde can log on to computers in the Engineering zone, but only Clyde will be a member of the denali UNIX group in the Engineering zone.

Assigning Roles to Existing Users and Groups

You have now imported the existing user and group profiles for a target set of computers into Active Directory. This is one critical component of migration because users must have a valid UNIX profile, that is, a unique user name, UID, primary GID, home directory and shell, in a zone for them to be recognized as valid users. However, Server Suite separates UNIX profile management from UNIX privilege management. Users cannot log on to UNIX computers until they are assigned a role that allows them to log on to those computers.

As discussed in Access controls and the assignment of rights and roles, a role is a collection of rights and there are two default roles: the listed role and the UNIX Login role. As part of deploying Server Suite software with the least disruption to your environment, your existing users must be able to log on to the UNIX computers they currently use. That is the primary purpose of the UNIX Login role: to allow you to quickly give log on access to a set of users in one or more zones. The UNIX Login role in the parent zone is intended for enterprise administrators who need log on access to all computers. The UNIX Login role in the finance zone would be for those users who currently have interactive access to the limited number of computers in that zone and would expect to have that access after migration.

The listed role is intended for users who need a valid profile defined but do not need interactive log on access to the computers in a zone. For example, you assign the listed role to remote NFS users so that they have access to their files without the ability to log on and open a shell. You can also use the listed role to give users access to applications, such as ClearCase or Samba, that require a UNIX profile without the ability to log on locally or remotely. The listed role in the software-dev zone would be for those ClearCase users who need to be recognized on all computers in the zone so they can check files in and out.

The next step in the migration is to identify which users should be assigned to each role in each zone you have created.

Using Active Directory Groups for Roles

For most organizations, the most efficient way to manage role assignment is by adding users to Active Directory groups, then managing those groups. Therefore, for management purposes, a Centrify access role should always be linked to an Active Directory security group. The Active Directory groups that identify the users in specific Centrify user roles are stored in the User Roles organizational unit. All of the users in a specific role group will share a common set of rights under UNIX. You can then use machine-level overrides for handling edge cases for individual computers.

Adding Users to Role Groups

There are many different ways you can add UNIX user profiles to an Active Directory group. For example, you can manually select a UNIX profile in a zone, right-click, then select Add to a group or select groups under the Role Assignments node for the zone, and modify the group membership. In most organizations, however, you can leverage your existing provisioning process. If your current provisioning process involves managing a group in Active Directory, whether it is through automated scripts or human processes, you can use the same process for provisioning UNIX users.

Migrating Existing Users Into The Unix Login Role In The Parent Zone

In Create groups for the default roles in the parent zone, you created Active Directory security groups for UNIX Login and listed roles in the parent zone. If you want to give all users the potential to log in to all UNIX systems, you can make them members of the parentZone_Role_Login group.

Users who are members of this group and have a complete UNIX profile in the parent zone can log on to all UNIX computers that are joined to the parent zone and all UNIX computers joined to the child zones of the parent zone. However, if you add users to the parentZone_Role_Login group in Active Directory, but do not define a UNIX user profile in the parent zone, those users will only be able to log on to the UNIX computers in the child zones where they have a UNIX user profile defined or the individual computers where you define machine-level overrides to give them a UNIX profile.

The default UNIX Login role associated with the parentZone_Role_Login group does not grant any additional privileges. It simply allows users to log on to UNIX computers. Therefore, one strategy for migrating users is to add them all to parent zone’s Login role group. You can then control access based on where the user’s UNIX profile is defined and control what the user can do using additional role assignments. For example, you may create custom roles to grant expanded UNIX privileges.

Migrating Existing Users into the Unix Login Role in Child Zones

If you define user profiles for most of your users in the parent zone, you should not make them members the parentZone_Role_Login group. Instead, you can add users to the appropriate childZone_Role_Login groups. All of your existing UNIX users who can currently log on interactively to existing UNIX systems should be added to one or more childZone_Role_Login groups. For example, users who currently have access to all of the computers in the Engineering zone should be added to the Engineering_Role_Login Active Directory group. If those users also have a UNIX profile in the parent zone or the Engineering zone, they will be able to log on to all of the computers in the Engineering zone. If a user only needs access to a specific computer in the zone, you can use a machine-level override to give the user access to that specific computer.

You can use the Access Manager console, Active Directory Users and Computers, ADEdit or custom scripts to add UNIX user profiles to the appropriate childZone_Role_Login groups. If possible, you should integrate this part of the migration with your existing provisioning process to ensure that future requests for UNIX role assignments use the processes that line of business personnel already understand.

Migrating Existing Users into the Listed Role in Child Zones

After you have assigned users who must be able to log on to the UNIX Login role, you should identify users who should be assigned the listed role to limit the number of users allowed to log on. The listed role is intended for existing UNIX users who have a UNIX user profile in one or more zones that you want to allow to be listed in getent output without the ability to log on to UNIX computers in those zones.

The listed role is most commonly used for users who access UNIX applications, such as ClearCase, or Samba, or an NFS-mounted file system, that require a UNIX profile. In practical terms, however, this role also allows you to migrate users you aren’t sure have been authorized for access. With this role, the user profile is recognized but the user cannot log on locally or remotely.

You can use the Access Manager console, Active Directory Users and Computers, ADEdit or custom scripts to add the UNIX user profiles to the appropriate childZone_Role_Listed groups. If possible, you should integrate this part of the migration with your existing provisioning process to ensure that future requests for UNIX role assignments use the processes that line of business personnel already understand.

Keep in mind that the childZone_Role_Listed group affects all the UNIX computers joined to the specified child zone. Before you move a user to the childZone_Role_Listed group, you should check whether there are any computers in the zone that the user must be able to access to prevent accidentally locking the user out. You can use a machine-level override to grant the UNIX Login role on a specific computer, if needed.

Using a Computer-level Override for the Unix Login Role

You can also create computer-level overrides for the UNIX Login or listed role, if needed. This is not typically part of the migration process. However, if your initial analysis identified a zone where overrides would be useful, you can include overrides in your migration plan. For example, assume you have a zone where most of the user profiles are common across a set of computers. If you import the UNIX profiles for that user population, you see that two users would have access to a UNIX computer where they previously did not have access. To preserve the existing access while migrating from the legacy environment, you can define the UNIX profile in the zone but control access for those two users with a computer-level override.

Managing Role Assignment Without Role Groups

You are not required to use Active Directory security groups to manage role assignments. You can manually add users and groups to roles within any zone. Manually adding a user or group to a role without using Active Directory groups makes integration with provisioning systems more difficult, however. Most identity management and provisioning systems are designed to work with Active Directory groups inherently. Therefore, associating Active Directory groups with Server Suite roles typically provides easier integration with existing provisioning processes.

If you decide to manually manage role assignments, you can use the Server Suite Access Module for Windows PowerShell, Server Suite Access SDK, or ADedit to create scripts that manipulate the objects in Active Directory. Role assignments are stored in Active Directory using Microsoft Authorization Manager containers. If you want to add and remove user and group assignments, you will need to develop custom code to accomplish those tasks.

Verifying Effective Users On Each Zone

Now that you have imported profiles and assigned existing users to the appropriate roles, you can verify who has access to the computers in each zone before you proceed with joining a domain. Checking the Effective Users in each zone enables you to verify the users who have been assigned the UNIX Login and listed roles before any users are affected by the changes.

You should have a checklist of the users who require interactive access on the computers in the target set and which user profiles you suspect only need to be recognized without the ability to log on. You can then using the Effective Users option to see the role assignments for the pre-created computer objects in the target set of computers. By comparing the list of users to the role assignments, you should be confident that you are ready to complete the migration by joining UNIX computers to the Active Directory domain.

Performing this step before joining the domain helps to ensure the transition to Active Directory does not interfere with end-users daily work or the delivery of business services. Therefore, verifying UNIX Login and listed access before joining computers to the domain is a key part of a successful migration.

To access the Effective Users for a zone

Start Access Manager.
In the console tree, expand Zones and the top-level parent zone.
Select a zone, right-click, then click Show Effective UNIX User Rights.
Review the list of UNIX user profiles for the zone in the UNIX users section.
Select a user name to display additional information about each user:
- Zone Profile displays details about inherited profile attributes. For existing users being migrated, the profile attributes are typically explicitly defined. If a profile is defined higher up in the zone hierarchy, the Inheritance tab indicates where the profile attributes are defined.
- Role Assignments lists the role assignments for the selected user in the zone. For the initial migration, users must be assigned the UNIX Login or listed role.
- PAM Access lists the specific PAM application access rights associated with the roles a user is assigned. For example, the default UNIX Login role has the login-all PAM access right, which enables PAM authentication for all computers in the zone.
- Commands lists the specific UNIX command rights associated with the roles a user is assigned. For example, you can define a role that allows users to run specific privileged commands as root. You can click the Commands tab to see the specific privileged commands defined for the role.
- SSH Rights lists the specific secure shell (ssh) command rights associated with the roles a user is assigned.
Click Close when you have finished checking role assignments for the users in target computer of computers.

You can also select Show Effective UNIX User Rights for individual UNIX computers and generate Hierarchical Zone reports that describe the effective rights for computers and users.

Adding Existing Users and Groups to Provisioning Groups

After you have added the existing users and groups to the appropriate Login and Listed role groups, the next step for completing the migration to Active Directory is to add the existing user and group profiles to the Provisioning Groups you created for the parent zone. This step is not directly related to data migration, but enables you to prepare the environment for automated user and group fulfillment using on the Zone Provisioning Agent.

Add Existing Users To The Provisioning Group For The Parent Zone

At this point, you have imported legacy data into one or more child zones and accepted divergent profile attributes using computer-level overrides. You should now add all of your imported UNIX users to the provisioning group in the top-level parent zone. Adding users as members of the provisioning group will enable the Zone Provisioning Agent to define a new “universal” UNIX profile for legacy users based on business rules you establish for the parent zone. The new profile will not affect the existing file ownership, but will make it easier to provision and deprovision users moving forward.

As discussed in Installing Zone Provisioning Agent, the Zone Provisioning Agent enables you to define business rules for creating new UNIX profiles for new UNIX users. After you complete the migration and enable the Zone Provisioning Agent, it runs at a regularly scheduled interval to determine whether there are new users or users who should be removed. At each interval, the Zone Provisioning Agent compares the members of the parent zone’s Users provisioning group with the user profiles currently defined for the zone.

If there are UNIX profiles for users who aren’t members of the provisioning group, the Zone Provisioning Agent removes those user profiles. To prevent the Zone Provisioning Agent from removing the imported data, you must add the Active Directory users associated with the imported user profiles to the parent zone’s Users provisioning group.

To add existing UNIX users to the provisioning group for 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.
Expand the Provisioning Groups organizational unit, then select the parentZoneName_Zone_Users group. For example, if the parent zone is arcadeGlobal, select arcadeGlobal_Zone_Users, right-click, then select Properties.
Click the Members tab, then click Add.
Search for and select the imported user accounts that you have mapped to Active Directory users, then click OK.
Click OK to save the provisioning group and close the Properties.

Add Existing Groups to the Provisioning Group for the Parent Zone

As with imported users, you should also add all of your imported UNIX groups to the provisioning group in the top-level parent zone. Adding the group profiles as members of the top-level provisioning group will enable the Zone Provisioning Agent to define a new “universal” UNIX profile for each group based on business rules you establish for the parent zone. The new profile will not affect the existing file ownership, but will make it easier to provision and deprovision users moving forward. Adding the UNIX group profiles to the top-level parent zone ensures that the Zone Provisioning Agent does not remove the imported groups from the zone.

To add existing UNIX groups to the provisioning group for 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.
Expand the Provisioning Groups organizational unit, then select the parentZoneName_Zone_Groups group. For example, if the parent zone is arcadeGlobal, select arcadeGlobal_Zone_Groups, right-click, then select Properties.
Click the Members tab, then click Add.
Search for and select the imported user accounts that you have mapped to Active Directory users, then click OK.
Click OK to save the provisioning group and close the Properties.