Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
.gif){kind=icon}
Introduction and Goals
Completing Deployment Preparations
Deploying the Solution
Stabilizing the Deployed Solution
Deploying Phase Major Milestone: Deployment Complete
In the Deploying Phase described in this chapter, you place the custom authentication solution, or authentication and authorization solution, that you have selected into your production environment. The solution that you plan to deploy is one of several possible custom solutions for implementing interoperability between UNIX or Linux clients and the Microsoft® Windows® Active Directory® directory service. These solutions are described in detail in Volume 2: Chapter 4, "Developing a Custom Solution."
Depending on which solution you deploy, interoperability between UNIX hosts and an Active Directory domain is established as follows:
Authentication only. An End State 1 solution, as defined in this guide, enables UNIX or Linux clients to use Kerberos to authenticate to Active Directory. In an End State 1 solution, you continue to use your current UNIX-based authorization method.
Authentication and authorization. An End State 2 solution, as defined in this guide, uses both Active Directory–based Kerberos authentication and Active Directory–based LDAP authorization to support UNIX or Linux clients.
To achieve either End State 1 or End State 2, your custom solution might use native operating system (native OS) components available by default in UNIX or Linux, or it might use native OS components supplemented by open source components and free software downloads. Both native OS and open source solutions described in this volume include solutions designed for Red Hat 9 Linux and for Solaris 9 UNIX.
CAUTION We do not recommend deploying the native OS Red Hat 9 solution in your production environment because of the security risks inherent in this solution. For more information, see the discussion in the section "Use Red Hat 9 with Native OS Components for End States 1 and 2" in Volume 2: Chapter 4, "Developing a Custom Solution."
IMPORTANT For the open source Red Hat 9 solutions, we recommend deploying the Kerberos client tools and underlying Kerberos libraries built on MIT Kerberos version 1.3.5 (or later) instead of the native Red Hat 9 versions of these tools and libraries. The Kerberos client tools and underlying libraries are not needed for the functionality of the open source Red Hat 9 solution for End State 1. However, they are often quite useful even post-deployment for help desk support and troubleshooting; many organizations choose to deploy them for these reasons. For more information, see the discussion in the section "Use Red Hat 9 with Open Source Components for End States 1 and 2" in Volume 2: Chapter 4, "Developing a Custom Solution."
After the solution is deployed and stabilized, you transfer the ownership of and responsibility for the solution to operations and support personnel. The information provided in this chapter is intended to help you through the deployment process. However, it is important to keep in mind that the relevance of this content to your deployment depends on your current environment and on the specific business needs, technology requirements, chosen end state, and technology solution that you defined during the previous phases.
The primary audience for the Deploying Phase chapter is the Release Management team. Release Management is responsible for the majority of the tasks during this phase but might require input from all of the roles associated with the project during the course of deployment. Therefore, it is recommended that all team leads review the information in this chapter.
Ensure that members of the Release Management team, who are primarily responsible for conducting the Deploying Phase, and the operations team, who will take over managing the solution, possess the knowledge requirements stated in "About This Volume" and identified in the “Project Team Skills Template” job aid.
Team leads should also be familiar with the following Microsoft information:
Microsoft Solutions Framework (MSF). Available at https://www.microsoft.com/technet/itsolutions/msf/default.mspx, MSF 3.0 provides the methodology for the Envisioning, Planning, Developing, Stabilizing, and Deploying Phases of the solutions described in this guide.
Microsoft Operations Framework (MOF). Available at https://www.microsoft.com/mof, MOF provides methodology for operations personnel.
UNIX Migration Project Guide. Available at https://go.microsoft.com/fwlink/?LinkId=20012, this guide, also known as the UMPG, provides "people and process" guidance for MSF projects.
For more information about MSF, MOF, and the UMPG, see “About This Volume.”
The major Deploying Phase tasks are:
Completing deployment preparations
Deploying the solution
Stabilizing the deployed solution
This chapter provides the technical information needed to enable you to accomplish these tasks. Refer to the UMPG for guidelines about how to organize team members and the work processes used to complete this phase.
Before you begin deploying your authentication or authentication and authorization solution into your production environment, complete the following deployment preparation activities:
Finalize the deployment plan.
Create or update operations procedures.
Obtain customer sign-off on deployment and operations plans.
Begin your deployment preparations by reexamining your current production environment in relation to the authentication, or authentication and authorization, solution that you want to deploy. Next, evaluate whether the deployment plan that you developed earlier will facilitate the transition from your current state to the new solution.
The deployment plan, created initially during the Planning Phase from the “Deployment Plan Template” job aid, is typically updated during the Developing and Stabilizing Phases to respond to empirical experience gained in the development and testing labs and during the pilot deployment. Your deployment plan should identify the following information:
Deployment scope, including the solution architecture and deployment size.
Schedule of all critical dates associated with the deployment.
An installation strategy defining whether the deployment will occur all at once or in a phased approach, such as site-by-site or department-by-department.
All staff responsibilities and resources necessary to complete the deployment.
Resources necessary to support the deployed solution.
Any necessary training requirements and available training resources.
Site installation process, including preparation, installation, training, stabilizing efforts, and how to transfer responsibilities of the deployed solution to Operations.
Deployment readiness checklist that reviews the readiness of each aspect of the solution, including Active Directory considerations, application and business layer considerations, and technical and business layer considerations.
Note Examples of deployment readiness checklists for database tier, application and business layer, presentation layer, and general technical and business considerations are available in the UMPG. Refer to those examples and modify or add considerations as they apply to your deployment.
Fallback plan that describes contingency actions to take in the event that it is necessary to recover from unexpected problems during the deployment. Because it is impossible to prepare for every possible event, the plan should clearly assign responsibility for decisions if the fallback plan does not cover a particular issue.
Note Fallback plans will differ depending upon the complexity of the original environment and the specific details of your solution. Your fallback plans should include a plan to revert to predeployment UIDs and GIDs if the process of rationalization encounters problems.
Later, after deployment is complete, the operations team will take over responsibility for the day-to-day administration of the solution. To facilitate the transition to Operations, the deployment team, as they perform the deployment, should document procedures associated with successfully operating the solution so that they can hand this information over to Operations.
The following table is an example of a deployment readiness checklist for operating a deployed solution.
Table 6.1. Operations Considerations Developed by the Deployment Team
Number |
Consideration |
Answer |
|---|---|---|
1 |
Is there a suitable fallback plan for the deployment of the solution? |
|
2 |
Does an adequate disaster recovery plan exist for the solution? |
|
3 |
Do all necessary security procedures exist for the solution? |
|
4 |
Have all service packs, drivers, and new hardware and software been adequately tested? Is there a procedure in place to alert the team should these items fail? |
|
5 |
Is the solution's capacity monitored on a daily basis? Is there an alert if additional equipment is required? What is the procedure to obtain new equipment? |
|
6 |
How will the team monitor the performance of the Kerberos and LDAP services in Active Directory? How will the team know if the performance is not in line with specifications? How will the team correct performance problems? |
|
7 |
How are critical diagnostic messages identified? What will the team do to provide immediate relief to the critical error messages? |
|
8 |
Will the team use third-party tools to identify and correct any failures? |
|
9 |
How will the operations team validate data integrity on a daily basis? How will the team ensure that nothing is corrupt because of memory or program failure? |
|
10 |
How will the team monitor services such as the Domain Name System (DNS), Network Time Protocol (NTP), or the Name Service Caching Daemon (NSCD)? If DNS, NTP, or NSCD fails, how will the team rectify the problem? |
|
11 |
What process will the team use for file and data backups? |
|
12 |
What process will the team use for authentication changes? |
|
13 |
What process will the team use for user identity changes? |
|
14 |
What processes will the team use to ensure that the system provides the functionality that was intended and defined in the specification? |
|
15 |
For End State 2 open source solutions, how will the team monitor the acquisition of credentials by a cron job for the LDAP proxy user to authenticate and retrieve authorization data? (A cron job is the UNIX clock service that is used to run commands at scheduled times.) Note For more information, see "LDAP Proxy Authentication via Kerberos" and "Example: LDAP Proxy User Authentication" under "Monitor Automated Processes" in Volume 2: Chapter 5, "Stabilizing a Custom Solution." |
|
16 |
How will the team manage certificates for a solution using Secure Sockets Layer/Transport Layer Security (SSL/TLS)? This includes:
|
|
17 |
Is there a process in place that defines key table management? How often will it be necessary to rotate service key tables? |
|
18 |
How will the team handle change management? |
|
19 |
How will the team address troubleshooting issues? |
|
20 |
How will the team monitor performance? Will there be a performance management system in place? Will the team use an internally developed or vendor-provided performance management system? |
|
21 |
How will the team manage users, such as users' UNIX attributes? |
|
22 |
How will the team manage the distribution of UNIX patches and Windows updates? How will updates for one environment be tested against the other environment to ensure functionality? |
|
23 |
How will the team monitor and manage load balancing? |
|
24 |
What service level agreements (SLAs) are currently in place? Are more SLAs necessary? |
|
25 |
How will the team manage physical security incidents, such as equipment being stolen? Are the procedures currently in place adequate? |
|
26 |
How will the team manage help desk incidents? Are any modifications needed to the incident management system? Are escalation paths defined properly (for example, a UNIX authentication issue might also be a Windows infrastructure issue)? Are external vendors or consulting firms part of the escalation path? |
|
Note For more information about creating the operations procedures checklist, refer to the “Operations Plan Template” job aid and the UMPG. For more information about some of the tasks in this checklist, see Volume 2: Chapter 4, "Stabilizing a Custom Solution" and Chapter 7, Operating a Custom Solution."
After deployment preparations are complete, the key stakeholders should review the solution and all associated network infrastructure to confirm that it is ready for deployment. The project team should then prepare a document that reiterates that the key stakeholders have reviewed and confirmed that the solution and related infrastructure are finalized and approved. Approval of the deployment plan and the operations plan signifies that the solution is ready for deployment into the production environment.
The development and testing phases, including the pilot deployment, were designed to show that the solution will provide the necessary functionality after you deploy it into your production environment. After the predeployment phases have been approved, you can begin the deployment of your solution.
Possible approaches include:
Implement a new system that does not directly replace existing functionality. Using this method, you can deploy the computers carefully one computer at a time. You can also choose which users will be affected and effectively manage the performance levels of those users' computers.
Build a parallel infrastructure. This is typically a more complicated process than implementing a new system because it requires that you have parallel infrastructures running during deployment to ensure that functionality is not lost.
Deploy the new system , but wait for activation. After the solution is deployed on the computers participating in the solution, at a predetermined time, you activate the new system and deactivate the old system. This requires that support staff be on-site to ensure that the transition takes place seamlessly.
Regardless of your approach, the primary goal during deployment is to minimize the negative impact of the deployment on users and on the organization. Deploying the solution is divided into the following steps that can occur either in the following sequence or in parallel with one another, depending on the resources that are available:
Rationalize UIDs and GIDs.
Prepare the support staff and user community for the deployment.
Upgrade the infrastructure.
Preconfigure UNIX or Linux computers.
Create or import user and group data into Active Directory.
Enable the deployed solution.
Note Before deployment, support personnel should be trained and available to support users as changes are introduced. After a successful deployment, you might experience an increase in the volume of support calls just because changes were made.
Rationalization is usually the initial step when preparing to deploy an End State 1 or End State 2 solution. Rationalization refers to the process of ensuring that a user has the same UNIX user ID (UID) and group ID (GID) on different computers. Rationalization requires that you examine user names, UIDs, group names, and GIDs across the entire UNIX environment whose users you plan to migrate to Active Directory. You must also identify differences in UNIX and Active Directory user and group names and make a decision about whether those names should be the same. Depending on the current configuration of your environment, this process will vary in difficulty.
To prepare for the process of rationalization, it is important to identify all existing types of users, systems, applications, access permissions, and home directories that you plan to include in the new interoperability solution as well as those—if any—that will not be included. You need to assemble this information before you can perform the tasks identified in the next subsection, "Rationalization Tasks." To collect this information, identify staff (or hire consultants) who are knowledgeable about:
Each separate data store. Identify each data store so that you can determine who all the users are and then identify which users you plan to migrate to Active Directory.
Access control issues related to each set of computers and the files on each computer. Determine what files each user needs to access and with which identity. For example, if user Bob is identified as UID 123 on some computers and as UID 456 on other computers, it is likely that he needs to access some files as owner 123 and others as owner 456. Identifying all access control issues of this sort enables you to make decisions as to which UID to use for Bob in the new solution and how to handle the files associated with the UID that will not be in use in the new solution.
Any existing provisioning systems and procedures. Make sure that no one continues to add users and groups with UIDs and GIDs that would create conflicts to any existing provisioning systems while you are in the process of rationalizing existing UIDs and GIDs. In addition, identifying existing provisioning systems and procedures can help you identify additional users or resources (for access control purposes) that need to be included.
Any exceptions that do not follow the defined procedures. Identifying exceptions can help you identify any users or resources that might otherwise be missed.
The following table lists the tasks that you need to perform to rationalize UIDs and GIDs.
Table 6.2. Tasks Associated with Rationalization
Task |
Action |
|---|---|
1. Determine if rationalization is necessary |
Typically, rationalization is required if a user has multiple accounts or different UIDs and GIDs for different computers. If each user is associated with only one account, rationalization might not be necessary. If you answer all of the following questions in the positive, rationalization is likely to be unnecessary:
Note There are exceptions to the questions preceding, such as users who have a regular account and an administrative account, or groups that are named differently on Windows and UNIX although they have the same purpose. |
2. Review existing processes for account and group management |
Review existing processes for account and group management to ensure that managing user accounts and groups will not become problematic during the deployment. Note Before the deployment starts, review the extensive tests for users and groups (including users who belong to a large number of groups) and the pilot deployment described in Volume 2: Chapter 5, "Stabilizing a Custom Solution," including the resolutions for any issues encountered during those tests. |
3. Communicate and enforce interim processes, if any |
You might need to implement interim processes if users will be accessing both pre-rationalization and post-rationalization data during the deployment. If so, communicate the interim processes to everyone who will be affected by the rationalization. Enforcing these processes will help ensure that the rationalization is completed successfully. |
4. Validate that rationalization is complete |
Test the rationalization by validating that users have access to appropriate computers, files, and applications; do not have access to inappropriate data: do not share the same account name with another user; and that each user is assigned one UID and one GID. Note Before the deployment starts, review the extensive tests and the pilot deployment described in Volume 2: Chapter 5, "Stabilizing a Custom Solution," including the resolutions for any issues encountered during those tests. |
After you complete rationalization and perform tests on UNIX computers to validate the result, if issues arise, you might need to roll back the rationalization and begin again. It is important to keep in mind that restoring from backup might not be a simple one-step process. For example, passwords that have changed from those stored in the UNIX-based store will no longer be valid. Define limits to the fallback period, such as a predetermined period of time or a specific number of user changes, after which reverting to the pre-solution state is not an option.
To prepare for how to address and resolve potential issues associated with rationalization during the fallback period, the following are some preventive measures to consider:
Develop a script that identifies all changes made to UIDs and GIDs during the fallback period.
Track all group membership changes, password changes, the addition and deletion of user accounts, and changes to UNIX user attributes.
Save appropriate databases containing password information until after the fallback period is over.
Establish a system that synchronizes passwords between the new Active Directory environment and the existing databases until after the fallback period is over.
Extend the time limits for password expiration and limit the number of password changes allowed during solution deployment.
For critical UNIX computers, consider having duplicate hardware and drives fully configured for immediate fallback, if necessary.
Manage operating system patches, including whether to apply patches during the fallback period if fallback would remove those patches, and ensure that all patches are properly tested.
Create a contingency plan for extensions to the Active Directory schema (if you extended the schema) because you cannot undo schema changes.
Note If you upgrade your Active Directory servers to Microsoft Windows Server™ 2003 Release 2 (R2), you do not need to extend the schema because Windows Server 2003 R2 includes support for RFC 2307 as part of its default installation. The custom solutions described in this volume were not developed or tested with Windows Server 2003 R2.
Consider using an intrusion detection system (IDS) during the period when rationalization is implemented and during the overall deployment effort. An IDS system can identify which computers users access, including users of any servers that you plan to retire.
It is important that everyone—including administrators, support staff, and end users—is aware of any changes that will occur as a result of the deployed solution and that training is provided where needed.
The following table lists the tasks that you need to perform to help prepare the support staff and user community for the deployment.
Table 6.3. Tasks to Prepare the Support Staff and User Community
Task |
Action |
|---|---|
Train help desk staff |
Make sure that you have a sufficient number of help desk personnel to support an increased number of calls during the deployment. Cross-train help desk staff to support the different platforms, or communicate to users that they might need to contact different help desks depending on the platform they are using. Training provided to help desk staff should include:
|
Train operations staff |
Train operations staff in operational procedures and troubleshooting, including Kerberos-specific and LDAP-specific troubleshooting tips. |
Train administrators |
Train administrators in administration and management tasks, including DNS, time synchronization systems, and changing user passwords. |
Communicate with application owners |
The Stabilizing Phase tests performed in Volume 2: Chapter 5, "Stabilizing a Custom Solution," included in-depth testing for applications, including (but not limited to):
The pilot deployment at the end of the Stabilizing phase tested:
Any issues encountered should have been documented and handed over to the Release Management team. Make sure that the test data and problem resolutions developed during the Stabilizing Phase are available to application owners before you start the deployment. |
Communicate with end users and provide necessary training |
Identify and communicate any changes in the user interface, such as differences in overall user experience, procedures, and password change prompts. Identify and communicate any potential issues that users might encounter during deployment. Explain how unified logon functions and how users can change their passwords after the deployment. Explain how users can troubleshoot any problems that they might encounter with authentication or authorization, and clarify when they should contact help desk personnel. |
Prepare checklists |
Prepare checklists about how to monitor the solution and how to identify any problems. Deliver the appropriate checklist to:
|
Additional items you might need to address in order to properly prepare users, staff, and groups within your organization will depend on which solution you chose and the level of individual involvement with that solution. For example, administrators, operations staff, and end users might all need to be familiar with command-line tools, but with varying depth of knowledge. Adjust training content for your target audience accordingly.
Note A list of command-line tools and their usage are available in Appendix E: “Relevant Windows and UNIX Tools.” Help desk personnel who provide first-level support might require only tools that help reset passwords or that display the UNIX attributes for a specific user. Higher-level support personnel might require tools that verify consistent DNS and time synchronization or that list Kerberos tickets and attributes (for example, kerbtray and klist).
Upgrading can occur after or in parallel with rationalization and the migration of user data to Active Directory. Infrastructure upgrades will vary depending on your solution and requirements, but might include building or upgrading Active Directory servers and the UNIX infrastructure.
Deploying the solution requires that the Active Directory infrastructure be present in your environment. If you currently do not have an existing Active Directory infrastructure, you will need to implement one before deploying your solution.
For information about creating and implementing an Active Directory infrastructure, refer to *Windows Server 2003 Deployment Kit: Designing and Deploying Directory and Security Services, *available at https://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=6cde6ee7-5df1-4394-92ed-2147c3a9ebbe.
In addition to the Active Directory infrastructure, depending on the solution you have developed, you might also need to address the following:
For all solutions, a DNS service must be installed and configured that can be used to meet Active Directory requirements and the requirements of the solution. An Active Directory server can itself function as a DNS server.
For all solutions, a time synchronization service must be installed and configured for Kerberos to function properly.
Note The procedures required to deploy each of the core infrastructure components are found in Volume 2: Chapter 4, "Developing a Custom Solution."
The following table lists the tasks that you need to perform to upgrade the Active Directory infrastructure.
Table 6.4. Tasks to Upgrade the Active Directory Infrastructure
Task |
Action |
|---|---|
1. Deploy Active Directory servers and all necessary certificates |
Deploy Active Directory servers according to the instructions provided in the Windows Server 2003 Deployment Kit: Designing and Deploying Directory and Security Services. |
2. If necessary, upgrade to Windows Server 2003 |
The "Software Requirements" section in "About This Volume" specifies that the Windows Server 2003 operating system is required. If your servers are not already running Windows Server 2003, you can upgrade to Windows Server 2003 according to the instructions provided at https://www.microsoft.com/windowsserver2003/upgrading/default.mspx. Note Although the authentication and authorization functionality presented in this volume for End States 1 and 2 is based on the Active Directory Kerberos and LDAP services provided by a domain controller running either Windows Server 2003 or Windows 2000 Server, the procedures for all of the solutions presented in this guide, including the custom solutions, were developed and tested on servers running Windows Server 2003. |
3. If necessary, raise the domain level |
Raise the domain and forest levels to Windows Server 2003 native mode to ensure proper functionality of your solution features. |
4. Upgrade Active Directory schema to store UNIX attributes |
Alternatively, you can upgrade Windows Server 2003 to R2, which includes support for RFC 2307 and thus includes UNIX attributes in Active Directory as part of its default installation. However, the custom solutions described in this volume were not developed or tested with Windows Server 2003 R2. |
5. Optional: Install NIS and Active Directory integration service to provide NIS to UNIX systems |
The custom solutions in this volume describe the use of Network Information Service (NIS) features that are used in conjunction with authentication and authorization. If your environment also makes use of other NIS features, consider how to handle these functions in the new system. Some useful features (which are out of scope for this guide), include automounts, netgroups, and other NIS maps. |
6. Validate stability of Active Directory infrastructure on the Windows system |
Validate the stability of the Active Directory infrastructure by verifying that it is functioning properly after completing the previous tasks. |
To achieve optimal levels of performance and security for your solution, you might need to upgrade your UNIX network infrastructure, depending on the solution you choose to deploy and the operating system versions currently in your environment. After upgrading the UNIX infrastructure, be sure to apply all appropriate patches in order for the operating systems to function correctly.
Note For more information on the appropriate operating system version for your solution, refer to the relevant sections of Volume 2: Chapter 4, “Developing a Custom Solution.”
How authentication and authorization data is currently stored is a factor when upgrading your UNIX network infrastructure. For example, if your current authentication and authorization systems make use of local files instead of centralized data stores, deploying an Active Directory–based solution might significantly increase the volume of network traffic. In addition, if a centralized data store is already in place but does not handle transactions securely, you might experience an increase in network activity for a new solution that uses SSL/TLS to handle authorization data.
The following table lists the tasks that you need to perform to upgrade the UNIX infrastructure.
Table 6.5. Tasks to Upgrade the UNIX Infrastructure
Task |
Action |
|---|---|
1. If necessary, upgrade UNIX-based computers to an operating system supported by the solution |
Upgrade the UNIX-based computers according to the instructions provided by the operating system vendor. |
2. Apply all appropriate UNIX operating system, Kerberos, and LDAP patches to the UNIX-based computers |
Apply all patches to the UNIX-based computers as instructed by vendor documentation or, for a custom solution, by referring to the appropriate sections in Volume 2: Chapter 4, “Developing a Custom Solution.” |
3. Upgrade the network infrastructure to support potential additional load of network transactions |
During the Planning and Developing Phases, you determined if changes were necessary to your network infrastructure. All changes required because of the need for greater bandwidth capacity or because of a change in network topology must be completed before you deploy the solution. For example, you might need to ensure that there is network connectivity to Active Directory servers in order for users to log on. |
4. Validate stability of the UNIX infrastructure |
Verify the stability of the upgraded UNIX infrastructure by validating the functionality of DNS and NTP, reviewing and addressing any issues you encounter, and initiating the fallback plan, if necessary. |
Preconfiguring the UNIX-based or Linux-based computers requires the installation of appropriate tools, binaries, and configuration files. Approach the preconfiguration process in a manner that allows you to easily back out of each procedure, if necessary. The recommended practice is to control centrally the installation, configuration, activation, and management processes instead of configuring each computer individually.
Some users might need to continue to access UNIX-based computers that are not included in the UNIX-to-Active Directory interoperability solution. If this is the case, you cannot remove the UNIX-based authentication system and will need to continue to operate it in addition to the new Active Directory–based authentication system. When more than one authentication method is in use on your network, you can specify the Kerberos authentication against Active Directory as the preferred method of authentication by setting it higher in priority in the pluggable authentication module (PAM) configuration file or in the Name Service Switch (NSS) configuration file (/etc/nsswitch.conf) entries for /etc/passwd and /etc/group.
Many organizations choose to deploy the Kerberos client utilities, “k-utils” (such as kinit, klist, ktutil, kpasswd), to all UNIX-based computers (see Task 3 in Table 6.6 later in this subsection). For the native End State 1 and 2 solutions and for the open source End State 1 solutions described in this volume, these tools are required; for the open source End State 2 solutions, these tools are not required but are often quite useful for help desk support and troubleshooting.
As mentioned earlier, the Red Hat 9 native OS solutions for End States 1 and 2, as well as the Red Hat 9 open source solution for End State 1, include k-utils and underlying Kerberos libraries that are known to have security vulnerabilities. This is one of the reasons that Microsoft does not recommend the deployment of the Red Hat 9 native OS solution in your production environment. The Fedora Legacy project has made available Red Hat install packages (also called RedHat Package Manager packages or RPMs) for Red Hat 9 with a patched version of MIT Kerberos 1.2.7 that resolve the security vulnerabilities in the Kerberos client tools and libraries. This patch addresses only the vulnerabilities in the k-utils and underlying libraries; it does not address the other concerns discussed in the section "Using Red Hat 9 Native OS Components for End State 1 or 2” in Volume 2: Chapter 4, "Developing a Custom Solution."
The open source solutions for Red Hat 9 described in this guide do not contain the security vulnerabilities found in the native Red Hat 9 solution. However, the native Red Hat 9 Kerberos client tools and underlying libraries used for development of the open source solutions do contain security vulnerabilities. For this reason, we recommend deploying either the updated Fedora Legacy Kerberos client package for Red Hat 9 or the MIT Kerberos version 1.3.5 (or later) client package built as part of the open source End State 2 solution instead of the native Red Hat 9 versions of these tools and libraries.
For more information about the security vulnerabilities in the Red Hat 9 solutions and about the Fedora Legacy RPMs for Red Hat 9, see "Use Red Hat 9 with Native OS Components for End States 1 and 2" and "Use Red Hat 9 with Open Source Components for End States 1 and 2" in Volume 2: Chapter 4, "Developing a Custom Solution."
Note Neither the native nor open source solutions for Solaris described in this volume are affected by the security vulnerabilities described previously for native OS Red Hat 9.
You should also keep the following in mind when beginning the process of migrating computers:
Find an optimal strategy that minimizes disruption to users.
Identify clusters of user-machine affinity. You can use scripts to analyze /etc/passwd files to find this information or to identify this information in NIS.
Confirm which features of NIS should be migrated if NIS is used in the current environment.
Consider configuring different LDAP proxy accounts for End State 2 on different computers to make password changes easier. If all computers use the same proxy account, they must be updated simultaneously when a password change occurs for that account.
Ensure that Network File System (NFS) mounting is accomplished in a manner that is compatible with Active Directory prior to deployment. This is an important consideration because home directories might not exist locally on each computer but might instead be NFS-mounted from a UNIX-based server.
The following table lists the tasks that you need to perform to preconfigure the UNIX-based computers.
Table 6.6. Tasks to Preconfigure Your UNIX-based Computers
Task |
Action |
|---|---|
1. Acquire and build open source tools |
[For all open source solutions] Open source solutions add open source Kerberos and LDAP components as well as free tools to the existing base operating system. Before you can deploy an open source solution, you must set up a development environment, download and install tools to support building the components for the solutions, download the correct source code packages, build those packages, and prepare the resulting binaries for installation (including setting permissions on the files and, if desired, creating an install package). For more information, see the following sections in Volume 2: Chapter 4, "Developing a Custom Solution":
|
2. Provision computer accounts in Active Directory for UNIX-based computers and create key tables |
For all End State 1 and End State 2 solutions: Key tables for computer accounts are unique to each UNIX-based computer. When creating key tables, keep in mind the following considerations:
For open source End State 2 solutions: Key table installation for the LDAP proxy user must be coordinated as follows:
|
3. Build required images and scripts, and install required tools and binaries on UNIX-based computers |
For all End State 1 and End State 2 solutions: Each UNIX-based computer must be configured with the appropriate pam_krb5 module and Kerberos client tools (for example, kinit, klist, or kpasswd). The installation, including these modules and tools, can be imaged because they might not be unique to each computer. However, a host-specific krb5.keytab file must be placed on each host and should not be imaged. When building images and scripts or installing tools and binaries, keep the following considerations in mind:
For all End State 2 solutions: Each UNIX-based computer must be configured with the appropriate nss_ldap module and LDAP client tools (for example, ldapsearch). The installation, including these modules and tools, can be imaged because they might not be unique to each computer.
|
4. Configure Kerberos |
If the UNIX-based computers already use Kerberos, you cannot put the krb5.conf and key table files for the solution into place until the deployed solution is enabled. Existing Kerberos configurations must be taken into consideration when a new file is distributed. If the UNIX-based computers are not already using Kerberos, you can put the krb5.conf and key table files into place with the correct names and locations. When configuring Kerberos, keep the following considerations in mind:
|
5. Configure, but do not activate, PAM Kerberos authentication |
The PAM configuration file containing the entries for pam_krb5 should be distributed to each computer but should not be activated. When it is time to enable the deployed solution, the new PAM configuration file will replace the old one. When creating PAM configuration files for distribution, keep in mind that existing PAM configuration files might vary from computer to computer. Therefore, it might not be appropriate to use the same PAM configuration files for each computer. |
6. Configure, but do not activate, NSS LDAP authorization (End State 2 only) |
If UNIX-based computers that you plan to incorporate in an End State 2 solution already use LDAP, the LDAP configuration files—such as ldap.conf and files in /var/ldap in the Solaris native solution—should not be put into place until the deployed solution is enabled. Existing LDAP configurations must be taken into consideration when a new file is distributed. If the UNIX-based computers do not currently use LDAP, you can install the LDAP configuration files in the standard location with the standard names. If LDAP is currently in use on these computers, you should install the files in a nonstandard directory or with nonstandard names in preparation for swapping them in (changing the name or location) when the solution is activated. When configuring LDAP, it is important to keep the following considerations in mind:
|
7. Validate Kerberos functionality against Active Directory |
Validate Kerberos functionality by verifying that a user logged on to a Windows-based computer is able to acquire the appropriate Kerberos credentials from Active Directory. Note For more information on validating Kerberos functionality, refer to the "Perform a Quick Kerberos Configuration Verification Test" in Volume 2: Chapter 4, “Developing a Custom Solution.” |
8. Validate resulting environment on the UNIX-based computers |
Validate the stability of the UNIX-based computers and ensure that proper functionality was retained, review and address any issues, and initiate the fallback plan, if necessary. |
Your approach to creating or importing user data into Active Directory will vary depending on your initial state. For example, your environment might already use the same user name in both UNIX and Windows with the password synchronized; you might have users that use different user names in the two systems; or you might have users that do not have accounts in both systems.
In many cases, migrating a list of user names from a UNIX-based store to Active Directory is relatively easy. However, it is more difficult to move user passwords, and you might therefore choose to assign a new password to users after migrating their user information. Setting up password synchronization at this point might help the migration process, ensuring that passwords are synchronized while the users and computers are in transition.
Note You must evaluate the authorization model used for applications, computers, and services to determine if these restrictions are appropriate. For example, you might want to use Active Directory Group Policy to restrict UNIX users who have Active Directory accounts but who use only UNIX-based computers from logging on to Windows-based computers. The same type of restriction may be necessary to prevent Windows-only users from logging on to UNIX-based computers.
The following table lists the tasks that you need to perform to create or import user and group data into Active Directory.
Table 6.7. Tasks to Create or Import Data into Active Directory
Task |
Action |
|---|---|
1. Import user data (and, for End State 2 only, group data) for UNIX-only users to Active Directory, or manually create accounts for these users |
User accounts must either be imported or created in Active Directory before you enable the deployed solution. Keep the following considerations in mind when creating or importing user and group data into Active Directory:
|
2. Assign UNIX attributes to preexisting Windows accounts for UNIX users |
Active Directory accounts for UNIX users that will be used for both authentication and authorization must include UNIX attributes. Depending on the database that currently stores UNIX user data, this could be as simple as copying the user data and attributes to a file and importing it into Active Directory, or it could require the manual re-creation of user information in Active Directory. Note For more information about tools such as ldifde, which can be used to import UNIX user data into Active Directory, see Appendix E: “Relevant Windows and UNIX Tools.” |
3. Optional: Migrate NIS data into NIS and Active Directory attributes |
If your environment currently uses NIS, you might also need to set up Active Directory to act as a NIS server. This will allow you to retire the existing NIS infrastructure as soon as the transition takes place. You can then use the Active Directory NIS server to support UNIX computers that will not be migrated. Note In some cases, you might want to delay migrating users into Active Directory—for example, if you plan to add users to Active Directory by using an on-demand migration tool or module. |
4. Validate the imported or created data |
Validate the stability of the data, review and address any issues, and initiate the fallback plan, if necessary. |
Enabling the deployed solution is dependent on the solution you have developed, how much of the solution has been deployed, and the initial state of your environment before deployment. The configuration information and files that you will need to replace are dependent on your initial state and on the use of Kerberos, LDAP, a central data store, or local files in your environment.
Generally, enabling the solution is accomplished by using a script or set of scripts that replaces existing configuration files with new files. These scripts, and the capability to swap files, might be part of the enterprise management system already in your environment.
The following table lists the tasks that you need to perform to enable the deployed solution.
Table 6.8. Tasks to Enable the Deployed Solution
Task |
Action |
|---|---|
1. If not done earlier, enable the Kerberos configuration files that direct requests to Active Directory and swap in the new key table |
If Kerberos is already in use on client computers, new Kerberos configuration files must be designed that support Active Directory. However, these must not be installed in a way that disables existing Kerberos functionality before the solution is enabled. If there is an existing Kerberos environment, distribute a configuration file before deployment that contains Kerberos configuration for both the old and new environments, using the Kerberos configuration file for the old environment as the default. When the new solution is enabled, modify the file to make the Kerberos configuration file for the new Active Directory environment the default but retain the configuration for the old environment as a backup. All existing Kerberos functionality should be tested with the new krb5.conf file designed for use with Active Directory. Implement the new krb5.conf file and key table, but do not implement pam_krb5 until after all Kerberized applications on the computer have been tested. Enabling the Kerberos configuration assumes that the configuration files, such as krb5.conf file and the key table files, have already been distributed and that the DNS and NTP were tested. |
2. Enable PAM authentication via Kerberos |
Enabling PAM authentication using Kerberos assumes that a PAM configuration file, such as pam.conf or /etc/pam.d/system-auth, was distributed to the computer but has not been installed. When enabling the deployed solution, the PAM configuration file containing pam_krb5 will replace the old PAM configuration file. Retain the old PAM configuration file for fallback purposes. |
3. Enable NSS authorization via LDAP |
Enabling NSS authorization using LDAP assumes that configuration files, such as ldap.conf or /var/ldap files for native Solaris, have already been distributed. It also assumes that an nsswitch.conf file has been distributed to the computer but not installed. If you have chosen to implement an open source End State 2 solution, acquire a credential for the LDAP proxy user immediately before enabling the deployed solution. |
4. Validate the enabled solution |
Validate the stability of the deployed solution, review and address any issues, and initiate the fallback plan, if necessary. |
Typically, stabilizing the solution is a joint venture between the project and operations teams.
Stabilization tasks include:
Transfer ownership to Operations
Monitor performance
Retire redundant infrastructure
Document Deploying Phase information
Part of disengaging from the project includes transferring ownership of the solution to operations and support staff. In many cases, the resources to manage the new systems will already exist. In other cases, you might need to design new support systems.
During this time, the project team will be closing any open issues and handing off maintenance activities to the operations team. The operations team will begin initiating procedures and validating all collateral and equipment received from the project team.
The following table lists the tasks that you need to perform to transfer ownership of the solution to the operations team.
Table 6.9. Tasks to Transfer Ownership of the Solution to Operations
Task |
Action |
|---|---|
1. Transfer information to Operations |
Transfer all information regarding the solution to Operations, including design documents, procedures, configuration settings, and all changes logged during development and deployment, such as changes to the settings within Active Directory, the Kerberos and LDAP services, and the UNIX or Linux client configuration files. |
2. Define project team tasks |
The project team's closing tasks might include:
|
3. Define operations team tasks |
The operations team will work closely with the project team and complete the following activities:
Upon completion of these activities, the project team transfers ownership of the solution and all documentation to the operations team. However, a member of the development team will usually remain available for an agreed-upon time to assist the operations team in its early maintenance endeavors. In the event a crisis occurs that requires additional support, the development team might be called on to assist support staff, the operations team, or management personnel. |
The following table lists the tasks that you need to perform to monitor service and load handling performance.
Table 6.10. Tasks to Monitor Performance
Task |
Action |
|---|---|
Monitor service performance |
Monitor service performance to verify that the solution is functioning at required levels. For example, you might want to use an automatic system, or manual checklist, to test authentication and authorization from each computer in your environment after it is migrated to ensure it has basic functionality (for example, logon capabilities, correct group membership, and application access). For an open source solution, you might want to check that the cron job running on each computer acquires Kerberos credentials correctly and runs when the computer is restarted. |
Monitor load handling performance |
Monitor load handling performance, the number of help desk calls logged during the transition to the new infrastructure, any authentication failures, processor performance, and available disk space. Monitor the general performance of Active Directory servers, UNIX-based computers, and other infrastructure components, including the performance levels of the network, DNS, and NTP. Note During stabilization, you might choose to leave the UNIX-based authentication infrastructure in place while testing the new Active Directory–based authentication infrastructure. To do this, set Active Directory as the preferred server by placing it higher in the PAM or NSS configuration file, as appropriate. |
After the solution is deployed, stabilized, and transferred to Operations, you should decommission and retire any redundant equipment or software according to organizational procedures and relevant regulations regarding the disposal of computer equipment.
Before retiring any hardware, verify that the new infrastructure provides the necessary functions without dependence on the infrastructure that will be retired and that the computers you want to retire do not provide any additional functionality. When you take the redundant infrastructure offline, you might want to maintain it in an operational state for a predetermined period of time so that you can restore it if necessary.
Evaluate the retirement of any UNIX-based authentication and authorization data stores separately from the retirement of hardware. Do not retire data stores that support authentication or authorization needs that were not migrated.
Begin the process of retirement only after all users have been migrated and all users have completed a password change. You might need to monitor password changes and postpone retirement of infrastructure until the password expiration time has passed and you have confirmed that the password changes were successful.
The following table lists the tasks that you need to perform to retire redundant infrastructure.
Table 6.11. Tasks to Retire Redundant Infrastructure
Task |
Action |
|---|---|
1. Confirm infrastructure is functioning properly |
Check that all appropriate services are running properly and that the new infrastructure does not have any dependencies on the old infrastructure and that the old infrastructure is not providing any services. Note It might useful to review the results of the tests in the section "Monitor Potential Long-Term Failures" in Volume 2: Chapter 5, "Stabilizing a Custom Solution." As indicated in that chapter, the test period for these tests should include as many significant time cycles as possible in your organization, including end of week, end of month, end of quarter, and any other time period that is important in your IT environment. |
2. Retire redundant infrastructure |
Retire redundant infrastructure after a sufficient amount of time has passed to ensure that all necessary functions are available. |
The following table lists the tasks that you need to perform to document Deploying Phase plans and activities.
Table 6.12. Tasks to Document Deploying Phase Information
Task |
Action |
|---|---|
Continue to update documents as necessary |
Update all relevant documents, including the master project plan and individual plans, with any changes that occurred during the deployment. A change control process will help enable the documentation of solution changes made to resolve any problems. |
Collect documentation to be used in signing off Deploying Phase |
Closing the Deploying Phase requires completing a milestone approval process. The team needs to document the results of the different tasks it has performed during this phase so that the customer and other key stakeholders have sufficient information to sign-off on completion of the phase. The list of documentation (deliverables) that should be completed during the Deploying Phase includes:
|
It might be difficult to determine when a deployment is considered complete because of the continuous process of identifying and managing production support issues associated with the newly deployed solution. For this reason, it is necessary to clearly define a completion milestone for the deployment instead of attempting to reach a point of absolute finality.
The Deployment Complete Milestone closes the Deploying Phase. By this time, the deployed solution should be providing the expected business value to the organization and you and your team should have effectively terminated the processes and activities you employed to reach this goal.
Download
Get the Windows Security and Directory Services for UNIX Guide
Update Notifications
Sign up to learn about updates and new releases
Feedback