Planning Deployment for an Enterprise
This section provides a brief review of the information you should have to begin planning a successful enterprise deployment of Server Suite. It includes an overview of the deployment life cycle, roles and responsibilities to consider in assembling a deployment team, and the factors you should consider during the planning phase that will affect how you deploy Centrify software.
For an overview of Centrify software and an introduction to basic tasks, see the Evaluation Guide for Linux and UNIX. For a general introduction to identity, access, and configuration management or more detailed information about performing administrative tasks, see the Administrator’s Guide for Linux and UNIX.
What You Should Know Before Planning a Deployment
Before you begin planning a full scale deployment of Centrify software, you should be familiar with key concepts, terminology, and components for Server Suite and Active Directory. You should also have information about your existing environment.
Before you continue planning the deployment, verify you have information about:
- How Active Directory is used to store user, group, and computer information in your organization and the Active Directory schema you currently have deployed.
- How you currently manage services and provision users for both Windows and nonWindows computers.
- How the Centrify Agent installed on a UNIX, Linux, or Mac OS X computer makes that computer part of an Active Directory domain.
- How zones enable you to manage user profiles, control access to computer and application resources, and delegate administrative tasks.
If you are not familiar with Centrify architecture and the components that make up the Server Suite, see Architecture and basic operations to be sure you understand the concepts, core components, and operations that enable Active Directory users to log on to UNIX, Linux, and Mac OS X computers. This guide assumes you also have access to the Administrator’s Guide for Linux and UNIX and can refer to it, as needed, for additional details.
Why Planning a Deployment is Important
Because Centrify software becomes a critical part of your IT infrastructure once deployed, it is important that you plan and test your deployment strategy and validate the results you expect before placing Centrify components into a production environment.
After you deploy Centrify software in a production environment, the rights and roles you define will control whether users can log on and what they can do on specific computers if they are allowed to log on. Because preventing users from accessing critical resources or services can affect business operations, you should analyze the requirements of your environment as thoroughly as possible before moving from a pilot deployment into production.
The deployment process described in this guide is intended to help you to migrate existing users and groups to Active Directory with minimal disruption to end-user activity and ongoing business services. The recommendations presented are designed to give you flexibility and provide you with a framework for deploying that minimizes the effect of the deployment on the existing user population.
Planning is important regardless of whether you are deploying on Windows, UNIX, Linux, or Mac computers. However, some deployment steps can be skipped if you are only deploying on Windows computers or if you aren’t migrating any local users or groups. For more information about deploying only on Windows computers, see the Administrator’s Guide for Windows. For information that is specifically about deploying on Mac computers, see the Administrator’s Guide for Mac.
What to Expect During Deployment
In most organizations, a deployment takes place in the following stages:
Evaluation
A primary senior analyst or small group installs the software in an isolated test environment. The main goal of this stage is to learn basic concepts, terminology, and operations and validate any specific functionality that is critical to the organization adopting the software. The lab environment also allows you to test the planned changes to system and user management processes without affecting user access. This proof-of-concept stage often takes place before the decision to purchase the software or with the decision to purchase a small number of licenses for extended testing.
Analysis and Design
During this stage, a planning team does deeper analysis into the goals and requirements of the organization, the current state of the environment, and the deployment and management options that best suit the organization. The main goal of this stage is to design how you will use zones, import user account information, and assign rights and roles through a combination of Active Directory groups and zone definitions. Most of the information in this guide is intended to help you make those decisions and validate them in a pilot deployment.
Pilot Deployment
The pilot deployment is intended to be more robust than the evaluation stage. The pilot deployment is typically 10 to 20 computers, often with a common administrative owner or administrative group. The main goal of this stage is to verify your analysis accurately described your environment and to uncover any gaps that might have been missed or special circumstances that require adjustment to the design planned for zones, user account information, or rights and roles. You can include more than 20 computers in the pilot deployment, but limiting the number makes the initial migration of the user population more manageable while you become familiar with the process.
Testing and Validation
After deploying the software, most organizations perform at least some formal testing of specific scenarios to ensure the authentication and authorization rules they have defined operate as expected and users are not locked out of computers they need access to but are prevented from logging on where they don’t have access rights. The main goal of this stage is to execute a test plan that exercises software operations in a number of different use cases.
Roll-Out Deployment
After sufficient testing and verification of the pilot deployment, the deployment team can use a software delivery method to install Centrify Agent packages on remote computers and join an Active Directory domain. Typically, the roll-out is done in phases, so that Centrify software is deployed on a set of computers in one subnet, IP range, or administrative domain, then later deployed on another set of computers on a different subnet, with a different IP range, or in a different administrative domain. The goal of this stage is to deploy in a controlled manner, so that any issues can be resolved before they affect additional users or computers.
Ongoing Management and Evolution
As your environment changes and evolves, it is likely that you will want to refine, customize, and extend your deployment and your authentication, authorization, computer, and user management policies. You may also develop or enhance scripts that automate provisioning and decommissioning of accounts, or update business processes to take advantage of additional functionality, such as integration with other tools to capture Centrify data or configuring database applications to use PAM-based authentication. The goal of this stage is continuous improvement to streamline business processes and operational efficiency.
Preparing a Deployment Team
In large organizations, the network architecture and Active Directory infrastructure is often highly complex and sophisticated. Adding UNIX, Linux, and Mac OS X computers and users to this infrastructure requires careful planning and is handled best with a clearly documented deployment plan. This guide is intended to help you develop such a plan and to suggest the issues you should consider in designing a deployment that suits your organization. For an example of what a deployment plan might look like, see Simplified environment analysis and zone design template.
Depending on the size of your organization, you might want to assemble a cross-functional deployment team to plan and implement a deployment strategy, set up and test a pilot deployment program, and refine, document, and roll-out operations across the organization. In addition, a deployment team might include project leads and IT staff members who will be responsible for maintaining and managing Server Suite and Active Directory on an ongoing basis after deployment or developers who will extend or integrate applications to work with Server Suite and Active Directory.
A typical deployment team might consist of members in the following roles:
Active Directory Enterprise or Domain Administrators
Know the structure and trust relationships of one or more Active Directory forests, including the topology of the Active Directory site and the roles of the domain controllers. These administrators may also be responsible for provisioning and decommissioning accounts or maintaining the tools for these business processes.
UNIX Administrators or Administrators with Specific Expertise
Manage access for all or specific groups of UNIX, Linux, or Mac OS X computers. These administrators may be responsible for specific resources, such as the servers that host mission-critical applications or a web farm, or have specific knowledge, such Oracle database administration or AIX administrative tools.
Security Administrators
Establish security policies and audit trails and define the procedures for securing computer resources and user account information. These administrators may also define the provisioning rules for the organization or have detailed knowledge of the existing provisioning process.
IT or Network Architects
Understand the overall layout of the organization’s network, including internal connectivity and access to the Internet, firewalls, port usage, bandwidth and latency issues.
Application Developers
Write programs that require authentication and authorization services. Application developers might also include UNIX programmers who will be responsible for writing scripts to automate administrative tasks, such as creating zones or adding new users to a zone.
Functional Testers
Develop test cases for the user scenarios the deployment team wants to validate.
Centrify Administrative Operators
Use Access Manager and other consoles on Windows, UNIX command line programs, ADEdit library, or PowerShell scripts to manage users, groups, computers, or zones. These operators might be delegated administrators for specific zones after deployment or existing Active Directory administrators who add and remove users from groups or manage Active Directory containers.
Database Administrators
Install and manage database instances and control access to database records. If you are planning a deployment that includes auditing user activity, the deployment team should include at least one database administrator to plan for and create the databases that will store captured sessions and audit meta-data. A database administrator can also provide procedures and guidance for backing up, archiving, and removing historical data as appropriate for your organization’s record retention policies.
Internal or External Auditors
Understand regulatory compliance requirements for the organization and industry. Auditors typically know the type of information they need and can define the reports that will satisfy their needs.
Assembling a cross-functional team with members who have expertise in working with Active Directory and Windows architecture and members who have expertise in managing UNIX, Linux, or Mac OS X servers and workstations is often a key component of a successful deployment.
Preparing Deployment Documentation
In addition to deploying the software, the deployment team should prepare materials that document the solutions they are deploying and the processes and procedures to assist others in migrating. The deployment documentation might include training materials for new users and test plans to verify a successful deployment that can be reused when updating the software after the initial deployment.
In general, members of the deployment team should focus on the following activities to prepare for a roll-out of Server Suite to a production environment:
- Document the configuration settings you plan to use and update the documentation as needed based on the pilot experience. For example, during the planning phase you might have drafted a plan for user and group filtering or access controls that in practice you find must be adjusted. The pilot deployment gives you the opportunity to implement your planned solution but change it, if needed.
- Document and prototype any deployment scripts that you intend to use and any processes or policy decisions that impact using those scripts. For example, you might want to automate the join process or how new users are added to a zone or modify existing scripts that provision users.
- Document issues that require troubleshooting during the pilot deployment and the resolution for each issue. You can collect this information as an organization-specific operations manual for IT staff.
- Prepare training materials for testers, operations personnel, and end-users based on the experience gained in the pilot deployment and tailored to your organization’s specific needs and internal policies.
- Prepare test plans that sufficiently cover the types of scenarios that are specific to your organization’s needs and internal policies. For example, if you plan to use group policies, your test plans should include scenarios for testing the group policies you plan to implement.
- Update planning documents, such as the zone structure or role definitions that you developed during the planning phase in response to the practical experience gained in the pilot deployment.
- Create checklists or instructions that are specific to your organization’s deployment. For example, you may want to create a “site preparation checklist” that covers specific steps administrators should take before deploying, a “deployment checklist” that includes site-specific naming conventions and migration instructions, and a “handoff to operations checklist” to ensure a smooth hand-over to data center staff after deployment is complete.
Defining Goals for the Deployment
One of the first tasks of the deployment team should be to define the goals you want to achieve and the criteria you will use to measure whether you have met those goals. As part of this process, you should define:
- The primary reason for deploying Centrify in your organization. For example, if providing centralized directory service or a single point of account administration is your most important goal, you may make different deployment decisions than if auditing and restricting user access to specific computers is your primary goal. That is, you want to be sure the deployment addresses your most pressing concerns first.
- Priorities for any additional goals you want to set for the deployment. For example, you may want to transition to a rationalized namespace over time, but this may be a lower priority for your organization than moving from decentralized computer administration to delegated administration of the tasks users can perform on specific computers.
- Any specific auditing requirements or security requirements that are unique to your organization or industry. For example, the way you organize computers into groups may be determined by specific reports you need to produce.
- Internal policies for how you update and distribute software. For example, you should define how frequently you apply operating system patches and whether you automate software distribution.
- Internal policies for how you assign UNIX attributes and Active Directory account information. For example, you should identify how you have assigned UIDs, GIDs, and other UNIX-specific attributes and whether there are existing naming conventions for Active Directory users and groups.
- Plans for who will manage UNIX profiles after deployment. For example, you should identify the group or groups that will manage which UNIX users and computers and whether there will be separate UNIX and Active Directory administrators with shared responsibilities or a clearly defined division of responsibilities. In most cases, Centrify recommends a separation of duties model that enables UNIX administrators to manage zones and Active Directory administrators to manage user objects and group membership.