Validating Operations After Deploying

This section provides sample activities for creating test cases and performing a formal validation of the Server Suite deployment. Although not required, executing a set of test cases that exercise Server Suite functionality will help you validate operations before extending the deployment to additional computers in the enterprise.

The specific use case scenarios and test cases you execute will depend on your organization’s goals and requirements.

Understanding Testing as Part of Deployment

Most organizations initially deploy in a lab environment that simulates the production environment. The lab environment allows you to test the planned changes to system and user management processes. For example, if you plan to automate migration using scripts, you should build and test the operation of your tools to verify they work as you intend. After testing in a lab, most organizations move to a pilot deployment with a limited number of computers and users to continue verifying that authentication, authorization, and directory services are all handled properly in a real-world environment before moving to a full-scale migration across the enterprise.

In many cases, the pilot deployment also requires more formal testing of specific use cases to validate the deployment before rolling out software to additional computers. This phase of the deployment may also include activities designed to help users transition to Active Directory.

To validate the deployment:

Execute test cases that verify authentication.
Execute test cases the verify authorization rules for login access and restricted access.
Execute test cases that verify the provisioning process.
Execute test cases that address issues unique to your organization or your user community.

Other activities you may want to perform as part of the validation process include:

Test configuration changes and customize configuration parameters.
Document test results.
Troubleshoot any authentication or authorization issues, if any are found.
Train staff on new procedures.
Communicate process changes to the users who are migrating to Active Directory.

For example, if you plan to eliminate local account access, implement stricter password policies, or apply new access controls, you should prepare the user community for these changes.

Validating Basic Authentication and Password Policy Operations

Before you begin testing organization-specific scenarios, such as the integration of migration scripts or customized access control policies, you should verify basic operations are handled as expected. At a minimum, you should perform some of the following tests to verify basic operations:

Verify a UNIX profile exists for the Active Directory users and groups to be used in testing.
Verify the UNIX computer has successfully joined an Active Directory domain and the computer account has been created correctly.
Verify an Active Directory user assigned the UNIX Login role is authenticated and can access computers in the zone used for testing.
Verify migrated users assigned the UNIX Login role can log on using their UNIX or Active Directory user name and Active Directory password.
Verify an Active Directory user assigned the Listed role has a valid UNIX profile, but cannot log on to computers in the zone used for testing.
Verify that workstation authorization or account lockout policies defined in Active Directory are enforced.
Verify that password management policies defined in Active Directory are properly enforced.
Verify that a previously authenticated user is authenticated successfully when the UNIX lab computer is offline.
Verify that common lookup commands and commands that require user and group information work as expected.

You can verify authentication, authorization, and password policy operations by setting options in Active Directory and attempting to log on and log off the computers in the pilot deployment.

Running Commands on the Unix Computer to Verify Operations

To confirm that a UNIX computer is a member of the Active Directory domain, you can run commands that retrieve information from Active Directory on the UNIX lab computer itself or by viewing the UNIX computer’s account information in Active Directory Users and Computers or the Access Manager console.

Verify the Computer is Joined to Active Directory

To verify a computer is joined to the Active Directory domain and is retrieving information from Active Directory by running commands on the UNIX computer:

Log on to the UNIX computer.
Type the following command to retrieve information about the computer’s connection to Active Directory:

adinfo

This command returns basic information such as the host name for the computer, whether the computer is joined to the domain, and whether the computer is currently connected to Active Directory. For example:

Local host name: magnolia
Joined to domain: ajax.org
Joined as: magnolia.ajax.org
Current DC: ginger.ajax.org
Preferred site: Default-First-Site-Name
Zone: ajax.org/Centrify/Zones/default <!--TODO: company name in file> Last password set: 2017-12-21 11:37:22 PST
CentrifyDC mode: connected

For more detailed information about the environment, you can use --diag or other options with the command. For information about the options available and the information displayed for each option, see the adinfo man page.
Type the following command to verify that the adclient process is running:

ps -aef|grep adclient

The command should return output similar to the following:

root 1585 1 0 14:50 ? 00:00:29 adclient
Type the following command to confirm that lookup requests use the information in Active Directory:

getent passwd

The command should list all of the Active Directory user accounts that are members of the zone and all local user accounts in the
/etc/passwd file format. For example:

ben:x:601:100:Ben Waters:/home/ben:/bin/bash
ashish:x:501:100:Ashish Menendez:/home/ashish:/bin/bash
sunni:x:900:100:Sunni Ashton:/home/sunni:/bin/bash
jolie:x:502:100:Jolie Ames:/home/jolie:/bin/bash
pierre:x:1001:100:Pierre Leroy:/home/pierre:/bin/bash
Review the contents of the /var/log/messages file and look for messages that indicate authentication problems or failures.

Verify Authentication for an Authorized User

To verify that an authorized Active Directory user can log on to a UNIX computer:

Restart the computer to display a logon screen or prompt.
Log on with the Active Directory user account you created for testing and provide the Active Directory password for that account.
- The user account must have a complete UNIX profile.
- The user account must be assigned the UNIX Login role.
- If the user account has been configured to set a new password at the next logon, you should be prompted to change the password. In this case, you must type and confirm the new password before continuing.
Log on using the UNIX login name for the user account and the Active Directory password.
Type commands to check the UID and GID assignments, home directory ownership, and other information for the logged on user.

Test Additional Administrative Tasks

You may want to try other typical administrative tasks that you expect to perform in the production environment. For example, you may want to test and verify the following tasks:

Changing the password for an Active Directory user using the passwd or adpasswd command on a UNIX computer changes the user’s Active Directory password for Windows computers.
Logging on as a user from another trusted Active Directory domain or another trusted forest is successful when you specify the user’s fully-qualified domain name (for example, milo.cutter@paris.arcade.com).
Setting a user’s effective group membership using the adsetgroups command.
Logging on using previously cached credentials. Offline authentication enables users to log on when computers are disconnected from the network or have only periodic access to the Active Directory domain. For example, users who have laptop computers must be able to log on and be successfully authenticated when they are not connected to the network.

Resolving Issues in the Pilot Deployment

Executing a formal test plan is intended to help you uncover issues that need to be resolved, troubleshoot any unexpected behavior, and correct any potential problems before end-users are affected. The pilot deployment enables you to deploy Server Suite software packages on a subset of typical users in the production environment in a controlled way. You can then use the pilot deployment to evaluate server and network load and how adding new computers and users to the Active Directory affects your environment. The initial deployment also allows you to closely monitor the experience of the user community participating in the pilot program.

With the pilot deployment, you can also develop and refine your processes and operational expertise before you roll out Server Suite authentication and authorization services to the entire organization.

You can install Server Suite Agents at any time without affecting any user or computer operations. Installing the Server Suite Agent on UNIX computers has no effect until you join the computer to the domain. Setting up the initial zone or set of zones does not affect the operation of any existing Active Directory infrastructure or Windows environment. Therefore, you can install the software for the pilot whenever it is convenient to do so.

Before you join computers to the domain, you must define and assign appropriate roles to the user community. Users who don’t have role assignments will not be allowed to log on to any computers. It is essential for you to test and validate role definitions and assignments to ensure users won’t be locked out of the computers they need access to when computers join the domain.

Preparing Training and Documentation for Administrators and Users

The deployment team should develop and deliver training for end-users, technical support personnel, help desk operators, and account fulfillment personnel. This role-based internal training will help new team members come up to speed and also help with the resolution of technical issues.

You should also train staff members to understand that there will be two fulfillment processes in place during migration: the legacy account fulfillment process for computers that have not joined the domain and a new account fulfillment process for computers that have joined an Active Directory domain. Both fulfillment processes should be clearly documented and staff should be trained on how to determine which process to use. For example, training material should indicate how the UNIX provisioning team can determine whether a computer is in a zone, so that members know whether to use the legacy process or the new process.

After a computer is migrated to Active Directory, you should not allow any local account provisioning on that computer. You should also be sure that this is clearly documented in training materials, especially if you don’t have centralized management of account creation policies. If you don’t prevent local account provisioning, orphaned and noncompliant UNIX accounts can continue to exist, may create conflicts in the UID and GID namespace, and create audit compliance issues because they are not included in required reports.

As you migrate each set of computers to an appropriate zone, you should also notify all affected users before you complete the migration. This notification can take the form of an email, voicemail, meeting with project personnel or management, or any other logical combination. Notifying users in advance helps to reduce the number of account lockouts caused by UNIX users attempting to log on using their old UNIX password on migrated computers.

Deploying to the Production Environment

After the initial deployment is stable and you have migrated existing users and groups successfully, you can begin moving the rest of your UNIX computers, users, and groups to Active Directory. In most cases, this migration is done in stages by repeating the tasks described in this guide for additional target sets of computers, users, and groups. After each stage, you should allow a period of time for monitoring and resolving issues for the migrated user population. Your deployment plan should include a schedule for when different sets of users are to be migrated and an analysis of how those users should be placed into zones according to your migration plan.

In general, you should migrate an increasing number of computers into zones in each stage of the production deployment. For example, in the first round of migration, you might migrate 15% of the computers into the first set of zones. You should then allow time in the schedule to troubleshoot and resolve issues to ensure that the migration was successful. In the next phase, you then might migrate another 25% of the computers. After you determine the second phase of the migration is successful, you might migrate the remaining computers into the remaining zones.

Whenever possible, you should also plan to migrate all of the computers that have been identified for a particular zone at the same time. Migrating all of the computers in a zone at the same time helps to reduce user confusion over which password to use when authenticating.

Training the Support Staff for a Production Deployment

You should provide the following information or training to the IT support staff who are responsible for a set of users to be migrated to Active Directory:

Review of the deployment project plan. Have the support staff read the deployment plan and review any changes to policies or procedures that deployment will entail.
Schedule for deployment. Make sure members of the support staff are aware of when the deployment is scheduled to take place and that they will be available at that time and for a reasonable period thereafter.
Location of documentation. Make sure all internal, operating system, and Server Suite-specific documentation is available so that support staff can use those documents to help them resolve any end-user issues that arise during the production deployment.
Pilot deployment experience and feedback. Explain the result of the pilot deployment, including any issues encountered during the pilot and the resolution for each issue.
Common Windows and Active Directory administrative tasks. For support staff members who are familiar only with supporting UNIX-based computers, provide training about Windows and Active Directory concepts and administration, as appropriate. If administrators will be using Windows-based programs or scripts to manage UNIX users and computers, they may need training specific to those tools. For example, administrators may need training to use Active Directory Users and Computers, Visual Basic scripts, or Access Manager console to manage Active Directory data.
Common UNIX administrative tasks. For support staff members who are familiar only with supporting Windows-based computers, provide training about UNIX concepts and administration, as appropriate. If administrators will be using UNIX-based programs or scripts to manage UNIX users and computers, they may need training specific to those tools. For example, administrators may need training to create and use ADedit or LDAP scripts to manage Active Directory data.
Common access control and privilege management tasks. Make sure members of the support staff are familiar with the tasks described in the Administrator’s Guide for Linux and UNIX, and provide hands-on training in performing the most common of those tasks.
Internal policies and procedures specific to your network and business environment. Create an operations handbook with details about common scenarios the support staff may be required to address, such as adding new UNIX computers or users to Active Directory.
Reporting and tracking issues related to Server Suite software. Make sure support staff members know how to report issues or problems with authentication, authorization, or directory services. If your organization uses a bug or problem-ticket system for tracking issues, set up a new subject area for Server Suite-related issues.

Preparing the User Community in a Production Deployment

As you prepare to migrate a set of users to Active Directory, you should provide training or informational materials to inform that user community about what to expect. For example, if your organization has decided to implement policies that prevent locally-defined user accounts from accessing some computers, be sure that the user community affected by this policy understands the change. Similarly, if your organization has decided to eliminate service accounts or restrict access to computers previously available, you should communicate these changes and notify users about any migration issues that may affect file access permissions and file ownership.

When you are ready to migrate a specific set of users, you should inform the user population about the upcoming deployment by providing the following information:

Schedule for deployment. Make sure that department managers and end-users know when the switch to Active Directory is scheduled to occur.
Computers and applications affected. Make sure that department managers and end-users know if their workstations or the servers they access for business applications are included in the deployment. If users need access to a computer that is being added to an Active Directory domain, they need to know whether their user account is in the same domain as the computer or a different domain. If there are applications hosted on a computer that is being added to an Active Directory domain, users need to know how this will affect access to the hosted application. For example, users may need to select a domain when logging on, or log on using the user_name@domain_name format.
Active Directory account information. Make sure that end-users know their Active Directory account information and understand that they must use their Active Directory password to access their UNIX workstations after the deployment is complete. You should inform users about the valid logon names and formats they can use, the Active Directory password assigned to their account if it is a new account, whether they are required to change their password when they next log on, and any password complexity rules you have implemented. Active Directory may lock accounts if users attempt to log on using their UNIX password, which could result in a large number of Help Desk requests for password resets.
Changes to access policies. Make sure that department managers and end-users are aware of any changes to access control policies. For example, if you are using group policies to deny access to some users or groups who could previously log on to a computer, you should inform those users or groups of the change and that it will take effect after the migration to Active Directory.

Populating Zones in a Production Environment

In planning your deployment, you should have determined your basic zone requirements and how you will migrate existing user communities to Active Directory. Based on your analysis, you should have a zone design with one or more parent zones and the child zones for each parent to define a candidate set of users and groups with the potential to access a given set of computers.

Typically, you should focus on one zone at a time, importing and mapping the existing users to Active Directory accounts. You should also determine whether you need to create new Active Directory accounts for any of the existing users or groups you are importing. If possible, you should use Active Directory group membership and role assignments to manage access for UNIX users and groups, you import.

Joining a Domain in a Production Environment

In smaller organizations or organizations where individual users have permission to join their own workstation to the Active Directory domain, you can run the adjoin command interactively on individual computers. This option works well when computers are distributed across many different domains or when individual users are joining their own workstation to the domain.

In larger organizations, however, you may want to use a custom script to remotely join a group of UNIX computers to an Active Directory domain. If you develop a custom script for joining a domain, the script should restart services or reboot the computers where it runs.

After joining a domain, you should monitor computers closely for a few days before extending the deployment to additional computers.

If the join operation fails or users cannot log on, you can run the adleave command to restore the computer to its previous state.