Export (0) Print
Expand All
Expand Minimize

Chapter 2: Using Quest Software VAS to Develop, Stabilize, Deploy, Operate, and Evolve End State 2

Published: June 27, 2006
On This Page

Introduction and Goals Introduction and Goals
Preparing Your Environment Preparing Your Environment
Developing the VAS Solution Developing the VAS Solution
Stabilizing Your Test Deployment Stabilizing Your Test Deployment
Deploying the VAS Solution Deploying the VAS Solution
Operating the VAS Solution Operating the VAS Solution
Evolving the VAS Solution Evolving the VAS Solution

Introduction and Goals

The Vintela Authentication Services (VAS) solution, a product of Quest Software, Inc., enables a rapid implementation of End State 2. In the Windows Security and Directory Services for UNIX Guide, End State 2 is defined as a solution that allows UNIX clients to use Active Directory Kerberos for authentication and to retrieve UNIX authorization and identity information from the Active Directory Lightweight Directory Access Protocol (LDAP) store. This chapter focuses on implementing VAS to achieve End State 2 with computers running Red Hat Linux version 9 or Sun Solaris UNIX version 9.

The VAS commercial solution uses the Microsoft® Windows Server™ 2003 Active Directory® directory service to provide a secure, open standards–based authentication and authorization solution for computers running UNIX or Linux operating systems. VAS enables the integration of UNIX or Linux clients with the Windows platform and consolidates all user and group accounts in Active Directory. With VAS deployed, Active Directory acts as the central point of administration for authentication, account information, and security policies for both Windows-based and UNIX-based computers.

This chapter describes how to prepare, develop, stabilize, and deploy the VAS solution to reach the End State 2 goal. It also explains how to operate the solution and how you might want to further evolve your implementation of VAS in the future to take advantage of Active Directory services beyond authentication logon and authorization. In addition, VAS is designed to let you take advantage of Active Directory scalability and performance features.

For more information about VAS, including capabilities that extend the Active Directory–based authentication and authorization solution described here, see:

  • "Evolving the VAS Solution" later in this chapter.

  • The following guides on the Quest Software Product page for Vintela at http://www.vintela.com/products/vas/index.php (click the "Documentation" link):

    • The VAS Installation Guide

    • The VAS Administration Guide

    • The Vintela Group Policy (VGP) Administration Guide

Chapter Organization

As described in “About This Guide,” the Windows Security and Directory Services for UNIX Guide is organized around the principles of the Microsoft Solutions Framework (MSF) Process Model and its five phases (Envisioning, Planning, Developing, Stabilizing, and Deploying) for managing IT projects, as well as the Microsoft Operations Framework (MOF) Operating Quadrant for improving operational efficiency.

The technology solution chapters in this volume, including both commercial solutions and several custom solutions, are built on the Envisioning Phase and Planning Phase chapters earlier in this guide—Volume 1: Chapter 2, “Envisioning Your Windows Security and Directory Services Solution” and Volume 2: Chapter 1, “Choosing the Right Technology and Planning Your Solution.”

The commercial solution chapters, including the Quest Software VAS solution, present information about the stages for preparing, developing, stabilizing, deploying, operating, and evolving the solution in a single chapter. This differs from the structure used for the custom solutions, which present the preparing and developing stages together but require separate chapters for the stabilizing, deploying, operating, and evolving stages.

For a depiction of the structure of the chapters in this volume, you might find it helpful to review Figure 0.2, "Volume and chapter structure of the Windows Security and Directory Services for UNIX Guide" in "About This Guide."

Intended Audience

All team leads should read each section of this chapter. In addition, specific sections of this chapter should be read by all team members who share a specific role:

  • Preparing. The primary audience for the Preparing section includes members of the Development and Test Roles who are responsible for setting up the development lab or test lab.

  • Developing. The primary audience for the Developing Phase is the Development Role. However, members of the User Experience (documentation and usability) and Test Roles are also responsible for specific tasks, such as setting up the development lab, performing verification testing, and creating or updating site preparation and rollout checklists as well as pilot and rollout plans.

    Some development work might continue into the Stabilizing Phase in response to test results.

  • Stabilizing. The primary audience for the Stabilizing Phase section includes the Test, Development, and Release Management Roles.

  • Deploying. The primary audience for the Deploying Phase section is the Release Management Role.

  • Operating. The audience for the Operating section is systems administrators, computer security personnel, IT support staff, and members of the operations group responsible for both UNIX-based computers and the Windows environment.

  • Evolving. The audience for the evolving section includes all teams. It is especially appropriate for:

    • Developers. Application developers can learn how to extend applications to take advantage of the security and directory infrastructure that has been enabled by the VAS product.

    • Deployment and Operations Staff. Deployment, operations, and support staff can learn how to apply centralized policy and configuration settings across their UNIX-based computers by using the Group Policy capabilities of VAS. Other topics of interest for administrators are also covered in the discussion about evolving the solution.

Knowledge Prerequisites

Ensure that your team possesses the knowledge requirements stated in "About This Volume" and identified in the “Project Team Skills Template” job aid. Members of the Development, Test, and Release Management Roles should review the information in this chapter and the following list of resources before completing planning or starting any development or testing.

CAUTION   Before you complete your planning preparations, it is important that you are familiar with the information specifically about the Quest Software VAS solution contained in this chapter.

Development, Test, and Release Management team members should review the following VAS documentation:

  • VAS Installation Guide

  • VAS Administration Guide

  • VGP Administration Guide

These documents are available with the Quest Software VAS product. See the next subsection, "Software Prerequisites," for information about how to obtain the VAS product.

Team leads should review the following Microsoft information:

For more information about MSF, MOF, and UMPG, see "About This Volume" in this volume.

Software Prerequisites

To develop and deploy the VAS End State 2 solution, you must acquire the VAS software. VAS is available for evaluation or purchase from Quest Software, Inc., on the Vintela Web site at http://www.vintela.com.

VAS 3.0 requires that you install one or more license files in the /etc/opt/quest/vas/.licenses directory. Unlike versions of VAS earlier than 3.0, if no license files exist or are found valid, VAS will not run.

Users are responsible for auditing their license counts. The license files for VAS 3.0 are specific to the VAS 3.0 version; that is, VAS 2.x licenses will not work with VAS 3.0.

For more information about VAS licensing procedures, see Chapter 7 of the VAS 3.0 Installation Guide.

In addition to obtaining the VAS software and meeting the prerequisites listed in About This Volume, you must have Active Directory configured and deployed to effectively implement this solution. For more information about these prerequisites, see “Preparing Your Environment” later in this chapter.

Overview of VAS Technology

VAS extends the reach of Active Directory beyond Windows by enabling you to use Active Directory to manage all user and computer accounts—regardless of the operating system platform. You can use either the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in or third-party tools to manage Active Directory accounts for UNIX users or computers.

VAS unifies authentication and identity management so that you can use your Windows Active Directory user name and password to log on to a computer running Windows or UNIX. Like the other End State 2 solutions presented in this volume, when you use VAS to deploy End State 2, each user has only one account and one password. Users can use these credentials (user name and password) to access any of the software platforms within their environment, subject only to the authorization limits that you set. VAS achieves this single sign-on capability by allowing UNIX hosts to be represented in Active Directory as computer objects in the same way that Windows hosts are represented.

During the VAS installation process, a UNIX-based computer joins the Active Directory domain, after which Active Directory users with UNIX attributes can log on to a UNIX host by providing their Active Directory user names and passwords. An Active Directory domain controller handles authentication for a logon attempt from a user on a UNIX-based computer on which VAS is installed in the same way that it handles a logon attempt from a user on a Windows-based computer.

This overview includes the following topics:

  • VAS core components

  • Additional VAS features

  • VAS components installed in the Windows environment

  • Securing authentication information

VAS Core Components

VAS consists of a number of components that are installed on computers in both the Windows and UNIX environments. VAS integrates computers running UNIX-based operating systems with Active Directory for authentication and account authorization through the pluggable authentication modules (PAM) service and the Name Service Switch (NSS) architecture.

When used in conjunction with Active Directory, PAM and NSS provide the following authentication and authorization services:

  • PAM. A set of shared libraries used to determine how a user is authenticated. PAM modules provide account management, authentication management, password management, and session management services. In the VAS solution described in this chapter, PAM enables UNIX-based computers to use Active Directory Kerberos for authentication instead of using the default method (which uses the text files /etc/passwd and, optionally, /etc/shadow for authentication).

  • NSS. A set of shared libraries used to determine whether a user is authorized to use a network resource. NSS is used to redefine where UNIX obtains configuration information and lets UNIX retrieve this information from a number of different types of databases. In the VAS solution described in this chapter, NSS enables UNIX-based computers to retrieve authorization information from the Active Directory LDAP store instead of using the default method (which uses the text files /etc/passwd and /etc/group for authorization).

For more information about PAM and NSS, see:

  • Volume 1: Chapter 1, "Overview of Authentication and Authorization Technologies and Solution End States."

  • Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization."

The relationship between VAS components, Active Directory, and the standard UNIX authentication and authorization modules is shown in Figure 2.1.

Figure 2.1. VAS core components

Figure 2.1. VAS core components

The VAS components depicted in Figure 2.1 are described in Table 2.1, "VAS Architecture Components." For information about how to install these components, see the section "Developing the VAS Solution" later in this chapter.

Table 2.1. VAS Architecture Components

Component

Description

Windows domain controller

Server running Microsoft Windows Server 2003 or Windows® 2000 Server that stores and replicates directory data for the Active Directory domain and provides authentication and authorization services. A domain controller is also sometimes referred to as an Active Directory server.

The domain controller acts both as Kerberos Key Distribution Center (KDC) and as the Active Directory LDAP authorization data store.

Active Directory Users and Computers snap-in

Microsoft Management Console (MMC) snap-in for managing users, groups, and computers in an Active Directory–based network.

In the VAS End State 2 solution, VAS modifies the Active Directory Users and Computers tool to include UNIX user attributes that store information about UNIX identities, such as user ID (UID), primary group ID (GID), default shell, and home directory.

VAS caching daemon (vasd)

The core VAS client daemon. The vasd component serves as the intermediary between the other modules depicted in Figure 2.1 and the Windows Active Directory domain controller. The vasd component establishes a secure connection with the Active Directory server to obtain account information and also improves performance.

The vasd component must be running on UNIX clients for VAS to operate. In addition to the performance management and disconnected operation features provided in tandem with nss_vas (described later in this table), vasd provides the following features:

  • Secure access controls. LDAP-based UNIX account management solutions normally require that anonymous or public access to UNIX account properties be allowed. Allowing anonymous access constitutes a security risk. Therefore, VAS (like the other End State 2 solutions in this volume) does not allow anonymous access. In the case of VAS, the vasd component authenticates to Active Directory using credentials that were established at the time that the computer object was created in the Active Directory domain. The vasd component then uses this secure connection to Active Directory to act as a proxy and cache user and group account information for other processes. Therefore, there is no need to provide anonymous access to any information that is used by the VAS client.

  • Secure LDAP communication. This feature enables VAS to authenticate as a domain controller and to use a Kerberos session key to encrypt LDAP communications with domain controllers. Like the other End State 2 solutions in this volume (except for the custom native OS Red Hat solution), the VAS client never generates LDAP traffic in clear text.

VAS PAM module (pam_vas)

The module that authenticates user logon attempts against information in Active Directory. The VAS PAM module provides the interface between the standard UNIX authentication libraries used by most system applications and the vasd component that manages direct communications between a UNIX host and Active Directory. Basic PAM configuration is performed when you join a UNIX host to an Active Directory domain. The pam_vas component provides the following features:

  • Kerberos-based user authentication. This feature allows PAM-enabled applications to authenticate users directly against the Windows domain and cache the appropriate Kerberos ticket credentials for use by other applications.

  • Disconnected authentication. This feature allows UNIX users to log on against Active Directory when they are disconnected from the network or the Active Directory server is not available.

  • Automatic home directory creation. This feature automatically creates a home directory for the user if a home directory does not exist when the user logs on.

  • UID conflict checking. This feature prevents user identification number (user ID or UID) conflicts between UNIX users enabled on Active Directory and local system accounts located in the /etc/passwd file by preventing such users from logging on with their Active Directory accounts.

  • Host-based access control. This feature allows system administrators to selectively restrict access by UNIX users to specific computers running VAS.

  • Password administration. This feature allows UNIX users to manage their own Active Directory passwords. It also enforces password policies for complexity and allows enforced password changes to be set by the Windows system administrator.

VAS NSS module (nss_vas)

The module that allow communication with the vasd component. The nss_vas module allows applications to access user and group information in Active Directory. This module implements the user and group name lookup and reverse lookup features needed to reference user names. It also supports the UNIX file-based permissions system (authorization).

In addition to allowing UNIX identity information to be retrieved from Active Directory, nss_vas provides the following features:

  • Secure traffic generation. The VAS NSS module differs from other LDAP NSS modules in that nss_vas never directly generates any LDAP traffic. Instead, LDAP traffic between nss_vas and the Active Directory server is mediated by vasd. This is because, on UNIX hosts, NSS modules cannot be provided with any security context information that would allow authentication to the Active Directory server. Instead, many NSS modules that generate LDAP traffic typically query “public” LDAP attributes or require that “guest” accounts be created with a password that is stored in a world-readable file on the UNIX host. (In a UNIX environment, the term "world-readable" means that all users can read the file.)

    For security reasons, nss_vas generates only interprocess communication (IPC) requests to the vasd service (described later in this section). With the help of vasd, nss_vas can operate securely and efficiently.

  • Performance management. To avoid per-process LDAP connections that can create a considerable traffic load on Active Directory, this feature transmits IPC requests to vasd as well as transmits cached data to handle NSS requests.

  • Disconnect operation. In conjunction with vasd, the nss_vas feature identifies situations where NSS modules disconnect while waiting for an LDAP operation to time out. This disconnection has potentially significant consequences for all processes running on the UNIX host. Without the intelligent caching features of vasd, NSS calls could block waiting for a response from Active Directory. This feature allows continuous operation using cached data. This same feature also supports disconnected logon if the user is disconnected from the network because of network failure or mobile (laptop) operation.

Note   Most distributions of UNIX use the PAM and NSS subsystems for account lookup information and authentication. The information in this chapter focuses on implementing VAS with Red Hat Linux version 9 and Sun Solaris UNIX version 9.

VAS command-line tool (vastool)

A command-line tool that allows you to access account information and perform VAS maintenance tasks. You use vastool to perform all administrative functions, such as joining the Active Directory domain. This tool supports creating new accounts from UNIX environments and is designed to be scriptable.

For more information about vastool and its subcommands, see "Directory Services Administration" in the section "Operating the VAS Solution" later in this chapter.

keytab

A key table file that includes an unencrypted list of principals and their keys. A service retrieves the key it needs from a keytab file (instead of by using kinit) in a process that is similar to the way that users use passwords. VAS keytab files are created in the /etc/opt/quest/vas directory.

Cache

A cache that is used by vasd. The vasd component aggressively caches data that is retrieved from Active Directory so that subsequent requests can be satisfied from the cache without having to generate LDAP traffic.

.ccache

Credential cache—the stored Kerberos ticket-granting tickets (TGTs) that are used as authentication credentials for single sign-on.

users.allow

users.deny

Configuration files located in the /etc/opt/quest/vas directory that are used by VAS authentication modules (such as pam_vas). VAS authentication modules use these files to determine which Active Directory users are allowed to authenticate to a VAS-enabled UNIX-based computer.

/etc/nsswitch.conf

The NSS configuration file. UNIX operating systems use a number of databases about hosts, ipnodes (a local database file that associates the names of nodes with their IP addresses), users, and groups. For example, host names and host addresses can be found in /etc/hosts, Network Information Server (NIS), NIS+, LDAP, or Domain Name System (DNS) databases. The sources and their lookup order are specified in the /etc/nsswitch.conf file.

C run-time library (libc)

Name Service Switch (NSS)

The library that contains the Name Service Switch (NSS). NSS is a subsystem built directly into the C run-time library (libc) and allows you to obtain user and group identity information from a variety of backend sources—not just the text files in the /etc directory. System administrators can change the NSS configuration by modifying the /etc/nsswitch.conf file.

PAM library (libpam)

PAM library that contains PAM functions.

/etc/pam.conf

The PAM configuration file. The pam.conf file includes the PAM modules that provide functionality for one or more of four possible services: authentication, account management, session management, and password management.

UNIX logon application

(such as dtlogin, login, telnetd, sshd)

Standard UNIX applications that use NSS or PAM to locate a name service or an authentication mechanism. After you deploy VAS, these applications can use Active Directory.

Additional VAS Features

In addition to the core components described in the preceding section, "VAS Core Components," the VAS product also includes features not discussed extensively in this chapter. These features are described briefly in Table 2.2, "Additional VAS Features."

Table 2.2. Additional VAS Features

Feature

Description

UNIX Personality Management (UPM)

(Optional)

Extends the capability for VAS to manage UNIX user attributes by defining different "personalities" (alternative identities) that the user can assume when logging on to different UNIX-based computers.

The UPM feature addresses the problem of nonrationalized values for UNIX UIDs and GIDs. Rationalization (also called normalization) refers to the process of ensuring that a UNIX user has the same UID and GID on different computers for an interoperability solution that enables UNIX users to use Active Directory for authentication and authorization. Typically, in End State 2 solutions that do not use VAS, rationalization is required if a UNIX user has multiple accounts or different UIDs and GIDs for different computers.

For more information about rationalizing UIDs and GIDs, see:

  • The subsection "Migrating UNIX Users and Groups to a Single Namespace" in the section "Deploying the VAS Solution" later in this chapter.

  • The VAS Administrator's Guide, which you can download from the Quest Software support site at http://support.quest.com. After registering at the support site, navigate to the Vintela Authentication Services documentation site on the download pop-up menu.

Instead of requiring that you perform rationalization, the VAS UPM feature allows you to maintain alternative personalities for a user, all of which are associated with a single Active Directory account and a single password. A personality is a new schema object used to store the attributes associated with a UNIX user account (UID, default GID, home directory, and default shell).

With UPM, multiple alternative personalities for a user are associated with one Active Directory account, and the user must use the Active Directory password to log on to each UNIX-based computer.

The UPM feature includes the uptool command (comparable to the vastool command) for managing UPM personalities.

For more information about the VAS UPM feature, see the following subsections later in this chapter:

  • "Using UPM to Maintain and Organize Multiple Existing Namespaces" under in the section "Deploying the VAS Solution."

  • "Normalize UID and GID Usage" in the section "Evolving the VAS Solution."

VAS Group Policy (VGP) daemon (vasgpd)

(Optional)

Allows you to manage UNIX configuration files centrally from Active Directory. For example, you can use vasgpd to manage standard UNIX tools such as crontab (used to schedule commands to be executed periodically) or sudo (used to enable a user to run programs as superuser).

Modeled on the Active Directory Group Policy feature in Windows, vasgpd includes many policies for the UNIX environment as well as policies for managing VAS itself.

For more information about VAS support for Group Policy, see "Add Group Policy Functionality" in the section "Evolving the VAS Solution" later in this chapter.

VAS NIS proxy (vasypd)

(Optional)

Allows NIS maps to be stored and managed in Active Directory. The vasypd service acts as a NIS server that provides backward compatibility with existing NIS infrastructure.

For more information about VAS support for legacy NIS maps, see "Manage Legacy NIS Maps" in the section "Evolving the VAS Solution" later in this chapter.

VAS Components Installed in the Windows Environment

The two VAS components that must be available in the Windows environment are:

  • Extensions to the Active Directory schema for UNIX users and groups.

  • An extension to the Active Directory Users and Computers snap-in that lets you manage the properties of UNIX users and groups.

The following subsections describe these components.

Extensions to the Active Directory Schema for UNIX User Attributes

The Active Directory schema defines each object, and the attributes of each object, that can be stored in Active Directory. The schema is a description of the object classes (the various types of objects) and the attributes for those object classes.

For each class of object, the schema defines the attributes that object class must have, the additional attributes it may have, and the object class that can be its parent. Schema definitions are themselves also stored as objects—Class Schema objects and Attribute Schema objects—in Active Directory.

The VAS End State 2 solution requires that the Active Directory schema include UNIX user and group account attributes, such as UID, GID, default shell, and home directory. VAS implements its support for storing UNIX attributes in Active Directory by using purpose-specific schema definitions that allow the UNIX user and group attributes to be stored in a way that lets the data be accessed transparently through conventional LDAP queries. The VAS solution also provides for direct interoperability with other LDAP and Active Directory management tools.

The two recommended methods to obtain the schema extension needed for the VAS solution are:

  • Use the VAS schema Wizard. The VAS Schema Wizard is a tool used to install required or optional schema extensions for Vintela products. It relies on the functionality of the Windows native command-line tool ldifde.exe. Both Windows Server 2003 and Windows 2000 Server support the ldifde.exe tool for importing and exporting LDAP Data Interchange Format (LDIF) data to and from Active Directory.

    You must run the VAS Schema Wizard one time before you deploy VAS within a given Active Directory forest (unless you already have R2 deployed and will not be using the additional special-purpose schema UPM or NIS schemas.) The Schema Wizard searches for an existing schema configuration that is compatible with VAS. For example, both Windows Services for UNIX and Windows Server 2003 R2 provide a compatible Active Directory schema.

  • Install or upgrade to the R2 version of Windows server. The Microsoft Windows Server 2003 R2 operating system includes the required schema definitions in its default schema. However, the procedures developed in this chapter are not designed for and were not tested with Windows Server 2003 R2.

The flexible VAS schema support allows custom schema extensions and is compatible with the following schema definitions:

  • RFC 2307 schema. The schema definition in RFC 2307 introduces LDAP attributes that you can use to store UNIX user and group account information. RFC 2307–based schemas are the preferred schemas for use with VAS. The RFC 2307 schema is required if you want to use advanced VAS features, such as UNIX Personality Management (UPM).

  • VAS RFC 2307 / R2 subset schema. The VAS schema extension provided with the VAS product is a subset of the RFC 2307 as found in Windows Server 2003 R2 but does not include the entire RFC 2307 schema definition. VAS utilizes the Kerberos protocol for authentication. Therefore, the RFC 2307 recommendations for shadow password files and encrypted or hashed password attributes are irrelevant and potentially less secure. The VAS schema extension also omits the NIS map–specific attributes for the storage of such entities as hosts, services, and networks because these are not relevant to the VAS authentication and identity management solution.

    If the VAS R2 subset is installed first and the R2 schema is installed later as part of a migration to R2, the already installed extensions are recognized as valid and the complete schema update proceeds transparently to complete the R2 default schema installation.

  • UNIX Personality Management (UPM) schema extensions. This extension is used to instantiate the posixAccount and posixGroup objects included in the VAS RFC 2307/R2 schema extension for use with the VAS UPM feature. VAS uses the UPM schema extensions to enable the UPM feature.

  • Windows Services for UNIX 3.0 schema extensions

    The schema extensions included in Microsoft Windows Services for UNIX provide the basic functionality for UNIX user and group account information. VAS can detect and use these schema extensions. However, the Windows Services for UNIX schema extensions are not compatible with the VAS extension to the Active Directory Users and Computers snap-in. If you want to use the recommended VAS MMC snap-in, you will need to use the VAS RFC 2307 schema subset and migrate Windows Services for UNIX data to these attributes manually.

  • Microsoft Windows Server 2003 R2 RFC 2307 schema

    Windows Server 2003 R2 includes support for RFC 2307 as part of its default installation. When using R2, you do not need to make any schema changes in order to enable the basic VAS functionality. VAS just auto detects and uses the RFC 2307 attributes already installed.

    The RFC 2307 schema can also be deployed on servers running versions of Windows Server 2003 or Windows 2000 Server earlier than Windows Server 2003 R2—you can use the Microsoft-supported tool ADSI Edit to add the R2 UNIX schema attributes to a pre-R2 domain.

    Note   The procedures in this chapter were developed and tested with Active Directory servers that are running a version of Windows Server 20003 prior to R2.

If you are not ready to upgrade to Windows Server 2003 R2, we recommend that you use the VAS R2 schema extensions. The VAS extensions implement the minimum set of attributes required for VAS to integrate UNIX users with Active Directory. As stated earlier, the schema definition supplied with VAS can be transparently upgraded to the full R2 schema later when you do deploy Windows Server 2003 R2.

Extension to the Active Directory Users and Computers Snap-In

The VAS End State 2 interoperability solution requires that the Active Directory Users and Computers snap-in include the UNIX Account tab, which displays the properties page for UNIX users and groups. You can install the VAS extension to the Active Directory Users and Computers snap-in, which adds the UNIX Account tab, on any domain controller or Windows-based workstation on which Active Directory Users and Computers is installed.

One alternative to using Active Directory Users and Computers to manage your Active Directory users, computers, and groups is to use the Quest Active Roles Server. The Active Roles Server tool provides a number of enhancements, including a Web-based interface to Active Directory. Active Roles Server includes a support pack for the VAS solution.

Securing Authentication Information

Simple Authentication and Security Layer (SASL) is a standard that separates authentication mechanisms from application protocols so that any SASL-aware application can use any authentication method that SASL supports. VAS employs SASL to access authentication mechanisms, such as Generic Security Service Application Programming Interface (GSS-API) and Kerberos session keys, to establish secure communication between a UNIX client and Active Directory. VAS encrypts LDAP traffic with the Kerberos session key that is established with Active Directory as part of the GSS-API SASL bind process. This is known as GSSAPI wrapping. The entire LDAP session is encrypted by VAS.

VAS establishes secure communications between UNIX-based computers and Active Directory through the use of a computer object in Active Directory. For each UNIX-based workstation or server that is joined to the Active Directory domain, thereby enabling UNIX logon with Active Directory credentials, you create one such computer object. Like several other End State 2 solutions in this volume, VAS provides the functionality both for creating these computer objects in Active Directory and for securing communication between Active Directory and the UNIX-based computer associated with the computer object.

Preparing Your Environment

The following sections describe how to prepare your environment for the VAS interoperability solution for End State 2. Preparing your environment requires that you perform the following tasks:

  • Install and configure the first Active Directory domain controller.

  • Set up a second domain controller.

  • Prepare for training, testing, and deployment.

Two key considerations for successfully installing and configuring the VAS End State 2 solution are DNS and time synchronization. Both are discussed in the following subsections.

Install and Configure the First Active Directory Domain Controller

The Windows Server 2003 or Windows 2000 Server Active Directory domain controller stores and replicates directory data for the domain and provides authentication and authorization services, acting both as Kerberos KDC and as LDAP authorization data store.

When setting up your development environment, Microsoft recommends that you install and configure two domain controllers so that you can test UNIX authentication and authorization under failover conditions. Installing both domain controllers at the same time helps avoid replication issues.

Installing and Configuring Active Directory and DNS

The first step in setting up your development lab is to install a domain controller that is running the Domain Name System (DNS) service and to create a test forest.

For detailed steps showing how to install Active Directory and DNS on a domain controller, see Appendix L: "Installing and Configuring Active Directory and DNS in Your Lab." Use the steps in Appendix L to set up the first Windows Server 2003 domain controller in your development lab. These procedures show you how to prepare the domain controller to provide Kerberos authentication and LDAP authorization services for UNIX-based computers.

IMPORTANT   It is possible to install the DNS service on a different server (either Windows or UNIX) than the domain controller or to install DNS on the domain controller later after you first install and configure the domain controller itself. For best results when deploying a solution that enables UNIX clients to authenticate to Active Directory, the recommended practice is to install and configure Active Directory and DNS at the same time.

The procedures in this chapter were developed and tested in a lab in which DNS is configured on the domain controllers as part of the Active Directory installation process.

Configuring the DNS Server

The preceding section assumes that you configure the DNS server role on the Active Directory domain controllers for your test environment, and Appendix L: "Installing and Configuring Active Directory and DNS in Your Lab" provides the steps to do so.

By default, the VAS domain join operation (vastool join) looks up DNS SRV records to automatically detect Active Directory domains, domain controllers for each domain, and the Active Directory site for UNIX-based computers. If Active Directory is using Windows Server 2003 DNS to dynamically update DNS resource records, this configuration occurs automatically when you first configure the domain controller role. Although VAS can function in an environment that does not use Windows Server 2003 DNS, this chapter assumes that you use the same Windows Server 2003 DNS that your Active Directory server uses.

If, however, you do not use the Windows Server 2003 Active Directory domain controller as the DNS server (as is assumed in this chapter) or if you do not allow dynamic updates, additional configuration steps are necessary:

  • For information about how to configure VAS when your DNS does not support Active Directory SRV records, see the VAS Installation Guide and the VAS Administration Guide. You can access the VAS product documentation by logging on to the Quest support site at http://support.quest.com. (Prior registration is required; registration is available to everyone.) After you register, follow the navigation drop-down menus to select the Vintela Authentication Services download section.

  • For more information about installing and configuring DNS, see:

    • Appendix G: "Configuring DNS for a Heterogeneous UNIX and Windows Environment" in this guide.

    • "Deploying Domain Name System (DNS)" in the Windows Server 2003 Deployment Guide at http://go.microsoft.com/fwlink/?LinkId=45677.

Creating Test OUs, Groups, and Users

We recommend that you add all UNIX users, computers, and groups under a separate Active Directory organizational unit (OU). Using a separate container lets you manage UNIX objects in Active Directory separately from Windows objects.

To create OUs , users , and groups for UNIX objects

  1. Log on with rights to add users and groups. Log on to a Windows-based computer on which Active Directory Users and Computers is installed with a user account that has rights to add new users and groups.

  2. Open Active Directory Users and Computers:

    • Click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

  3. Create OU container for UNIX objects. For example, create a new OU called Unix-Test-OU to hold UNIX test users and groups:

    1. In the console tree, right-click the domain name, point to New, and then click Organizational Unit.

    2. In New Object – Organizational Unit, type Unix-Test-OU under Name, and then click OK.

  4. Create OUs for users and groups. Create OUs to hold test UNIX users and groups:

    1. Right-click Unix-Test-OU, point to New, and then click Organizational Unit.

    2. In New Object – Organizational Unit, type Unix-Users-OU under Name, and then click OK.

    3. Repeat steps a and b to create an OU for Unix-Groups-OU.

  5. Create test groups. Create test group accounts under Unix-Groups-OU:

    1. Right-click Unix-Groups-OU, point to New, and then click Group.

    2. In New Object - Group, in Group name, type Unix-Group01, confirm that Group type is set to Security (the default), and then click OK.

    3. Repeat steps a and b to create additional test group accounts.

  6. Create test users. Create test user accounts under Unix-Users-OU:

    1. Right-click Unix-Users-OU, point to New, and then click User.

    2. In New Object - User, specify the following:

      In Full name type john.evans (that is, john dot evans).

      In User logon name, type john, and then click Next.

    3. Type and confirm a password, and then:

      Clear User must change password at next logon.

      Select Password never expires, and then click Next.

      CAUTION   In a test environment, you might want to choose these options. In a production environment, choose more secure options.

    4. Click Finish.

    5. Repeat steps a–d to create a user account for Rachel Valdez (type rachel.valdez for Full name, and type rachel for User logon name).

    6. Repeat steps a–d to create a user account for Dave Natsuhara (type dave.natsuhara for Full name, and type dave for User logon name).

Later, you will use these user and group accounts when you configure the VAS solution in your development lab, when you perform a quick validation of the VAS solution, and when you verify authentication and authorization during the Stabilizing Phase. For more information, see “Perform Quick Validation Tests” later in this section, and see “Stabilizing Your Test Deployment” later in this chapter.

You can also import user and group accounts from existing directories, such as a local /etc/passwd directory, a UNIX NIS directory, or an LDAP directory. For more information, see "Import a set of UNIX accounts into Active Directory" in Table 2.5, "Synopsis: Integrating UNIX Groups and Users with Active Directory" in the section "Developing the VAS Solution" later in this chapter, and see "Migration" in the VAS Administration Guide.

Verifying Time Synchronization

Time synchronization is a requirement imposed by the Kerberos protocol. That is, you need a mechanism for keeping the system clocks of UNIX hosts within your network environment synchronized with the Active Directory server's system clock or authentication will fail. All Kerberos tickets are time-stamped, and the Kerberos protocol has a narrow tolerance for discrepancies between system clocks. The recommended practice is to use the default time skew limit of 5 minutes.

You can use either of the following methods to ensure that the system clocks on the computers that you use in the test environment are synchronized:

  • Use NTP. You can configure your computers to synchronize with an external Network Time Protocol (NTP) time server.

    For more information about NTP, see Appendix H: "Configuring Time Services for a Heterogeneous UNIX and Windows Environment."

  • Use vastool timesync. You can use the vastool timesync command to synchronize time before you join a UNIX-based computer to the Active Directory domain.

    When you use this command, VAS automatically detects the master domain controller (or other specified time server) and synchronizes the client to its clock. VAS periodically checks that the clocks remain synchronized.

    For information about how to use the vastool timesync tool, see "Join the VAS Client to the Active Directory Domain" in the section "Developing the VAS Solution" later in this chapter.

Set Up a Second Domain Controller

Deploy a second domain controller using the same steps that you just completed to install the first domain controller. Installing at least two domain controllers is recommended because, if the first domain controller fails, the second one is available to support client computers.

After both domain controllers are installed, with the DNS service running on each one, all Active Directory changes, including DNS data, automatically replicate to the second domain controller. Although you can install a second domain controller at any time, installing it immediately after installing the first domain controller means that replication occurs quickly and avoids replication delays.

Prepare for Training, Testing, and Deployment

During the Developing Phase, described next, Development team members document the solution or solutions they deploy in the test lab. In addition, the User Experience, Test, and Release Management teams prepare for the upcoming stabilization, deployment, and operations stages.

Table 2.3 summarizes the documentation and usability tasks that each team should perform during the Developing Phase.

Table 2.3. Documentation , Training , and Release Management Tasks During the Developing Phase

Team

Tasks

Development

  • Document configuration of the VAS solution.

  • Document prototype deployment scripts that you develop (if any).

  • Document issues that require troubleshooting during development and the resolution for each issue.

User Experience

  • Update training plan developed earlier in the Planning Phase with information learned in response to the practical experience gained in the development lab.

  • Prepare training materials for testers.

  • Prepare training materials for operations personnel.

  • Prepare informational or training materials for end users.

  • Work with developers to ensure usability of the tested solutions for administrators and end users.

Test

  • Perform functional testing for the solution developed in the test lab, and provide feedback to developers.

  • Identify and document any issues or "pain points."

  • Design tests for the Stabilizing Phase that test the overall solution and ensure that any potential issues are stabilized. Update the test plan that was developed using the "Test Plan Template" job aid earlier in the Planning Phase.

  • Test configuration documentation written by the Development team.

  • Test training documentation written by the User Experience team.

Release Management

  • Update pilot and deployment plans developed earlier during the Planning Phase in response to the practical experience gained in the test lab.

  • Prepare checklists:

    • Site prep checklist. To prepare the production environment for deployment (site preparation).

    • Deployment checklist. To ensure a smooth rollout during deployment.

    • Handoff to operations checklist. To ensure a smooth transfer to operations after deployment is completed.

Developing the VAS Solution

During the Developing Phase, you will build the solution components. Because VAS is a commercially packaged product, "developing the solution" refers to building the installation in your test environment as a preliminary step to piloting and then deploying the VAS solution in your production environment.

Introduction and Goals

The information provided in this section, based on the activities of the MSF Process Model Developing Phase, focuses on using VAS to achieve End State 2.

Major Tasks and Deliverables

The major tasks in the Developing Phase for the VAS End State 2 solution are:

  • Develop the solution components.

  • Perform quick validation tests.

Develop the Solution Components

This section describes how to install and configure your development environment for the VAS End State 2 solution. The following subsections provide an overview of how to install and configure VAS:

  • Installing VAS components for Windows Server 2003. Extend the Active Directory schema (if needed); register VAS modifications to Active Directory consoles; and install the VAS Administrative Tools.

  • Enabling UNIX group and user properties in Active Directory. Add UNIX group and user properties to the Active Directory account for each UNIX group and user. Add a UNIX-enabled Active Directory user to an appropriate group so that this user has the rights to join UNIX-based computers to the Active Directory domain.

  • Installing VAS client components for UNIX. Use the native software installation mechanisms for each platform to install VAS client components (vasd, nss_vas, pam_vas, and vastool) on UNIX-based computers. For example, in the case of Red Hat Linux, you use the rpm tool.

  • Joining the domain and configuring the VAS client. After entering license information and synchronizing time, enable VAS operation. You do this by using the vastool command to join a UNIX-based computer running the VAS client to the Active Directory domain.

In addition to the instructions provided in the following subsections, you can find detailed information about installing and configuring VAS in the documentation that accompanies the product, the VAS Installation Guide and the VAS Administration Guide.

Installing VAS Components for Windows Server 2003

The procedures in this section show you how to configure Windows to interoperate with UNIX-based computers in the VAS solution.

This section includes the following procedures:

  • Extend the Active Directory schema.

  • Register VAS modifications to Active Directory consoles.

  • Install the VAS Administrative Tools.

Extend the Active Directory Schema

As explained in "Overview of VAS Technology" earlier in this chapter, VAS requires that the Active Directory schema include definitions for attributes that store information about UNIX user and group identities. VAS is compatible with the RFC 2307 schema, the Windows Services for UNIX schema, and others. (For more information about other supported schema extensions, see the VAS Administration Guide).

Determining Whether You Need to Extend the Schema

Table 2.4 explains when you do—and do not—need to extend the Active Directory schema.

Table 2.4. Do You Need to Extend the Active Directory Schema?

Extend schema?

Depends on whether schema is already extended

No

If you have Windows Server 2003 R2 installed (or another VAS-compatible schema extension, such as Windows Services for UNIX or RFC 2307), you do not need to extend the schema and can skip the schema installation procedure "To extend the Active Directory schema."

Note   The procedures in this chapter were developed and tested with Active Directory servers that are running a version of Windows Server 20003 prior to R2.

Yes

If you do not have Microsoft Windows Server 2003 R2 (or another schema extension) deployed, using VAS to extend the Active Directory schema for your VAS solution is the recommended method. This is the method described in this chapter.

Installing Extensions Only on Schema Master Domain Controller

You need to extend the schema only once in each Active Directory forest—on the schema master domain controller. The root domain of an Active Directory forest can include child domains, which automatically inherit the schema of the schema master domain controller. You do not need to install the schema extender or extend the schema on any workstations.

CAUTION   Extending the Active Directory schema is not reversible and therefore requires care. To reduce the chance that problems might arise during the schema extension process, the recommended practice is to select extension mechanisms that Microsoft supports. Before you extend the schema, see "Extending the schema" in the Windows Server 2003 Help and Support Center.

To extend the Active Directory schema

  1. Log on as Schema Admin. Log on to the schema master domain controller as a user who is a member of the Schema Admins group.

    Note   When you extend the schema, you must be logged on locally to the schema master itself. You cannot change the schema when logged on remotely from another computer.

  2. Start VAS schema extension utility: 

    1. Insert the VAS product CD into the CD-ROM drive.

    2. Browse to the schema folder \schema\win32 on the CD.

    3. Double-click schemawizard.exe.

  3. Select schema extension:

    1. On the VAS Schema Extension Tool screen, click Next to display the option screen shown in the following screenshot, Figure 2.2.

      Figure 2.2. VAS schema extension options

      Figure 2.2. VAS schema extension options
    2. Select Install Schema, and then select the appropriate options:

      Note   The procedures developed in this section for the Developing Phase assume that you select the first option, R2 Subset for VAS.

      R2 Subset for VAS (required) 

      Note   If Windows Server 2003 R2 is already installed, the schema installer will detect it. In this case, you do not need to extend the schema and do not need to complete the schema installation procedure. However, the procedures developed in this chapter are not designed for and were not tested with Windows Server 2003 R2.

      UNIX Personality Management Schema (optional). If you want to enable the UPM feature, select this option. For more information about UPM, see "Additional VAS Features" in the overview of this chapter.

      VAS NIS Schema (optional). If you want to import NIS map data into Active Directory, select this option. For more information about VAS support for legacy NIS maps, see "Additional VAS Features" in the overview of this chapter.

    3. Click Next.

  4. Confirm schema extension:

    1. When a screen listing the schema extension options that you selected appears, confirm that you have selected the desired options, and then click Next to extend the schema.

    2. When the message "The command has completed successfully" appears indicating that the schema extension is successful, click Finish to exit the wizard.

Register VAS Modifications to Active Directory Consoles

Display specifiers are objects in Active Directory that store localized graphical user interface (GUI) information and enable a GUI to be modified for each class of object in Active Directory. You must configure display specifier objects for each Active Directory object class that VAS extended in the schema extension procedure that you just completed: user, group, and (optionally) nisMap if you selected the VAS NIS Schema option shown under the Install Schema option in Figure 2.2.

The VAS product CD contains a utility called the VAS Display Speci?er Registration Wizard that creates the Unix Account tab in Active Directory administrative consoles. You need to run this wizard only once.

To register VAS modifications to Active Directory consoles

  1. Log on as Enterprise Admin. Log on to any Windows-based computer on which Active Directory Users and Computers is installed as a user who is a member of the Enterprise Admins group.

  2. Start VAS Display Specifier Registration Wizard:

    1. Insert the VAS product CD into the CD-ROM drive.

    2. Browse to the \adminTools\win32 folder.

    3. Double-click dsreg32.exe.

    4. On the Welcome to the VAS Display Specifier Registration Wizard page, click Next.

  3. Select management console:

    1. On the Provider Registration Selection page, select the management console that you want to use to manage UNIX objects.

      Typically, you can accept the default selection, Active Directory Users and Computers (LDAP).

      Note   If you see a message indicating that display speci?ers are already installed, click Cancel to exit the wizard. You need to register display speci?ers only once.

    2. Click Next.

  4. Confirm successful registration:

    1. On the Registration Results page, wait until the results output appears, and then examine the displayed results to confirm that all objects are registered successfully.

    2. Click Finish.

    Note   If any errors appear in the registration results output, make sure that you can contact the domain controller and that you have Enterprise Admin rights, and then run the wizard again.

Unlike extending the Active Directory schema, registering display specifiers is not a permanent operation—you can undo it at any time. To unregister display specifiers, rerun this wizard.

Install the VAS Administrative Tools

Installing the VAS Administrative Tools on an administrative workstation lets you manage UNIX user and group properties through the Active Directory Users and Computers snap-in.

To install the VAS Administrative Tools

  1. Log on with rights to install software. Log on to any Windows-based computer on which Active Directory Users and Computers is installed as a user who has rights to install software.

  2. Start the VAS Administrative Tools Installation Wizard: 

    1. Insert the product CD into the CD-ROM drive.

    2. Browse to the \adminTools\win32 folder.

    3. Double-click vas-3.0.0.11.msi.

    4. On the Welcome to the VAS Administrative Tools Installation Wizard page, click Next.

  3. Accept license. On the License Agreement page, review the terms of the license agreement. If you accept the license terms, select I accept the license agreement, and then click Next.

  4. Specify user and organization information:

    1. On the User Information page, type entries for Full Name and Organization.

    2. Select one of the following options, as appropriate:

      Anyone who uses this computer

      Only for me

    3. Click Next.

  5. Accept default destination folder. On the Destination Folder page, click Next to accept the default option to install the VAS Administrative Tools in the C:\Program Files\Vintela\VAS\ folder.

  6. Install complete set of features. On the Select Features page, click Next to accept the default option to perform a complete installation.

  7. Start installation:

    1. On the Ready to Install the Application page, click Next to start the installation.

    2. When the VAS Administrative Tools has been successfully installed page appears, click Finish.

Enabling UNIX Group and User Properties in Active Directory

When you use VAS to integrate UNIX with Active Directory, the goal is to use the same digital identity for both Windows and UNIX accounts.

This section includes information on the following procedures:

  • Integrate UNIX accounts and Active Directory accounts.

  • UNIX-enable an Active Directory group.

  • UNIX-enable Active Directory accounts for UNIX users.

  • Configure a UNIX-enabled account to join computers to the domain.

Integrate UNIX Accounts and Active Directory Accounts

This subsection summarizes how to accomplish the integration of UNIX groups and users with Active Directory. Currently, during the Developing Phase deployment in your lab when you have a very small number of users, you can perform tasks such as UNIX-enabling an existing Active Directory account manually. Later, in the Stabilizing Phase when you perform a pilot deployment and then when you deploy the solution in your production environment, you will likely want to automate many of the tasks associated with implementing the VAS solution.

Table 2.5 summarizes the process of integrating UNIX accounts with Active Directory accounts.

Table 2.5. Synopsis: Integrating UNIX Groups and Users with Active Directory

Pre-Integration State

Synopsis of Integration Process

Users who currently have a UNIX account and a separate Windows account

  • Manually UNIX-enable one account at a time:

    In Active Directory Users and Computers, you can use the UNIX Accounts tab on each Active Directory user or group account property page to add the user's or group's UNIX attributes to the Windows account.

    This is called UNIX-enabling an existing Active Directory account. For the specific steps, see the procedure "UNIX-enable Active Directory accounts for UNIX users" later in this section.

Users who currently have only a UNIX account

  • Manually create and UNIX-enable one account at a time. You can use Active Directory Users and Computers to create a new Active Directory account for each UNIX user and group, and then you can use the UNIX Accounts tab to add the user's or group's UNIX attributes to the new Windows account.

    This is called migrating an existing UNIX account to Active Directory.

  • Import a set of UNIX accounts into Active Directory. You can migrate a set of UNIX accounts that do not currently have a corresponding Windows account by importing them into Active Directory from the UNIX identity store (for example, from the /etc/passwd or /etc/group files or from a NIS store).

    You can use the vastool command from the UNIX command line or from a script to import these accounts. The importation process creates and UNIX-enables an Active Directory account for each UNIX account.

    • Use vastool load to import accounts from /etc/passwd or /etc/group.

    • Use vastool nis-import to import accounts from NIS.

    It is not possible to import UNIX passwords into Active Directory because the password is encrypted, so the password for the new account is set to a default or assigned value.

After UNIX accounts are integrated with Active Directory accounts, you will be able to retire the UNIX /etc/passwd and /etc/group files or the NIS identity store. After VAS is deployed in your development environment, test users will be able to log on and access any network resource (if authorized to access that resource) within the Active Directory domain without being prompted for credentials more than once.

In this Developing Phase deployment in your lab, you will use Active Directory Users and Computers to manually UNIX-enable the Active Directory group Unix-Group01 and to UNIX-enable an Active Directory account for the UNIX test users John Evans, Rachel Valdez, and Dave Natsuhara.

UNIX-enable an Active Directory Group

In this procedure, you UNIX-enable the test group, Unix-Group01, that you created in the section "Creating Test OUs, Groups, and Users" earlier in this chapter. Then, in the next procedure, you can use the primary group identifier (GID) of Unix-Group01 when you specify UNIX attributes to UNIX-enable the test users whose accounts you also created earlier in "Creating Test OUs, Groups, and Users."

Later, when you deploy VAS in your production environment, depending on your site configuration, you might want to provide a separate default group for different sets of users.

To UNIX-enable an Active Directory group

  1. Log on with rights to modify users or groups. Log on to a Windows-based computer on which Active Directory Users and Computers is installed as a user who has rights to modify users and groups.

  2. UNIX-enable Unix-Group01. Open Active Directory Users and Computers and configure the following:

    1. In the console tree, expand the domain name, expand Unix-Test-OU, and then click Unix-Groups-OU.

    2. In the details pane, right-click Unix-Group01, click Properties, and then click the Unix Account tab.

    3. Select Enable Unix Group, and then either accept the default value for Group ID (gid) or specify an appropriate GID.

      Note   If the Unix-Groups-OU contains only one UNIX-enabled group, this group receives a suggested GID of 1000 (the default). If there are other UNIX-enabled groups in this group’s OU, using an unused GID that is higher than the lowest allocated GID in the OU as a default is recommended.

      Most UNIX operating systems assign GIDs for local system groups between 0 and 500. To avoid conflicts with local group accounts, do not set any UNIX-enabled Active Directory group GIDs to a value less than 1000.

    4. Click Apply. If you see a warning message asking if you want to search the Active Directory forest for potential conflicting ID values, click Yes. Depending on the message that appears next, take one of the following actions:

      If you see the message No conflicts detected!, click OK.

      If you see a message indicating that the GID you just specified conflicts with the GID of another group, specify a different GID (larger than 1000) for this group.

    5. Click OK to save the changes.

UNIX-enable Active Directory Accounts for UNIX Users

Use the steps in the following procedure to UNIX-enable the existing Active Directory accounts for John Evans (john.evans), Rachel Valdez (rachel.valdez), and Dave Natsuhara (dave.natsuhara).

To UNIX-enable Active Directory accounts for UNIX users

  1. Log on with rights to modify users or groups. Log on to a Windows-based computer on which Active Directory Users and Computers is installed as a user who has rights to modify users and groups.

  2. UNIX-enable John Evans' Active Directory account. Open Active Directory Users and Computers, and configure the following:

    1. In the console tree, expand the domain name, expand Unix-Test-OU, and then click Unix-Users-OU.

    2. In the details pane, right-click john.evans, select Properties, and then click the Unix Account tab.

    3. Select Enable Unix Account, and then either accept the default values or specify appropriate values for the UNIX fields listed in Table 2.6.

      Table 2.6. Accept the Defaults for UNIX Attributes or Specify Alternative Values

      UNIX Field

      Description

      User ID (uid)

      UNIX numeric user identifier (UID). In this example, the default value for john.evans is 1000.

      Note   If this is the first user created in Unix-Users-OU, this user receives a suggested UID of 1000 (the default). If there are already other UNIX-enabled users in this OU, using an unused UID that is higher than the lowest allocated UID in the OU as a default is recommended.

      Most UNIX operating systems assign UIDs for local system users between 0 and 100. To avoid conflicts with local user accounts, do not set any UNIX-enabled Active Directory user UIDs to a value less than 1000.

      Primary Group ID (gid)

      UNIX numeric group identifier (GID). In this example, use the GID that identifies Unix-Group01.

      If you want to select a different primary group, click the ellipses (...) next to the Primary Group ID (gid) text entry box, and select a group from the list of groups that appears in the Primary Group Selection box.

      Comment (GECOS)

      The user's name. In this example, john.evans.

      Typically, the user's first and last name are stored in the GECOS field in the UNIX /etc/passwd file.

      Home Directory

      The user's home directory, including the full path. In this example, /home/john.

      Login Shell

      The name of the default UNIX shell (a program that enables users to interact with the operating system) that is used when a user first logs on. In this example, /bin/sh.

      The default value for Login Shell on the User Account tab is /bin/sh. If this shell does not exist on the computer the user logs on to, you must change this setting to the location of a valid logon shell or configure symbolic links on the computer to validate the shell location.

    4. Click Apply. If you see a warning message asking if you want to search the Active Directory forest for potential conflicting ID values, click Yes. Depending on the message that appears next, take one of the following actions:

      If you see the message No conflicts detected!, click OK.

      – or –

      If you see a message indicating that the UID you just specified conflicts with the UID of another user, specify a different UID (larger than 1000) for this user.

  3. Create two more users. Repeat these steps to UNIX-enable the Active Directory accounts for Rachel Valdez and Dave Natsuhara.

  4. Save changes. Click OK to save the changes.

Configure a UNIX-enabled Account to Join Computers to the Domain

Before you can join your UNIX-based computers to the Active Directory domain, you must add a UNIX-enabled Active Directory user account to a group—such as the Domain Admins (domain administrators) group—that has the user right to join a large number of computers to an Active Directory domain.

Later, in the section "Joining the Domain and Configuring the VAS Client," you will use this account to join UNIX-based computers to the Active Directory domain.

To configure a UNIX-enabled account to join computers to the domain

  1. Log on with rights to modify users or groups. Log on to a Windows-based computer on which Active Directory Users and Computers is installed as a user who has rights to modify users and groups.

  2. Add UNIX-enabled user to Domain Admins. Open Active Directory Users and Computers and configure the following:

    1. In the console tree, expand the domain name, expand Unix-Test-OU, and then click Unix-Users-OU.

    2. Right-click an existing UNIX-enabled user—in this example, right-click john.evans—and then click Add to a group.

    3. In the Select Group dialog box, type domain admins under Enter the object name to select, click Check Names, and then click OK.

    4. When you see the message The Add to Group operation was successfully completed, click OK.

Installing VAS Client Components for UNIX

The next major task is to install the VAS client components on computers running UNIX or Linux. The VAS client software enables UNIX-based computers to use Active Directory Kerberos for authentication and Active Directory LDAP for authorization.

Although the installation process for each type of UNIX platform is similar, the specific installation steps for each platform differ. The information provided in this chapter focuses on implementing VAS with Red Hat 9 Linux or Solaris 9 UNIX.

This section includes information about the following procedures:

  • VAS support for UNIX and Linux.

  • VAS client components installed on UNIX-based computers.

  • Install the VAS Linux client.

  • Install the VAS Solaris client.

VAS Support for UNIX and Linux

Although this chapter includes only Red Hat 9 and Solaris 9, the VAS client currently supports a number of other UNIX and Linux platforms and versions.

For the most up-to-date list of supported clients, see the Quest Software site for Vintela at http://www.vintela.com.

VAS Client Components Installed on UNIX-based Computers

The VAS client components that you install on Red Hat 9 or Solaris 9 workstations or servers include the modules listed in Table 2.7.

Table 2.7. VAS UNIX Client Components

Component

Description

pam_vas

Uses Active Directory to authenticate user logon attempts.

nss_vas

Enables applications to access user and group information in Active Directory through the mediation of the vasd service.

vasd

Establishes a secure connection with the Active Directory server and obtains user and group account information.

vastool

Lets an administrator access account information and perform VAS configuration and maintenance tasks.

libvas

Provides the library used by VAS components.

man pages

(UNIX manual pages)

Provides the system user documentation accessed with the UNIX man command.

For more information about the core VAS modules (pam_vas, nss_vas, vasd, and vastool), see "VAS Core Components" earlier in this chapter.

The following sections provide platform-specific procedures for installing these components on computers running Red Hat 9 or Solaris 9. This chapter assumes that you perform a new installation of the standard distribution of VAS version 3.0.

You can also request an evaluation key from the Quest Software Downloads page for Vintela at http://www.vintela.com/downloads for use before purchase. An evaluation key is installed in the same way as a permanent key; however, it has a fixed expiration date after which the VAS software will no longer operate.

Install the VAS Linux Client

This subsection describes how to install the VAS client software for the Red Hat 9 Linux operating system. The VAS Linux client includes all of the components listed in Table 2.7, "VAS UNIX Client Components," in the preceding subsection.

The VAS Linux client is packaged in RPM format. Originally developed by Red Hat and called Red Hat Package Manager, RPM is now used by several operating systems to install, update, uninstall, verify, and query software.

To install the VAS client RPM on Red Hat 9

  1. Log on as root. Log on to a computer running Red Hat 9 as the root user.

  2. Insert CD. Insert the installation CD, and then open a terminal window.

  3. Access installation directory. At the UNIX shell command line, type the following commands to mount the CD and change to the client installation directory:

    # mount /mnt/cdrom
    # cd /mnt/cdrom/Build-vas-VAS_3_0_0_11/client/linux-x86
  4. Install VAS client for Red Hat. At the UNIX shell command line, type the following command to install the VAS client RPM:

    # rpm -ivh vas-client-3.0.0-11.i386.rpm 

    Note   The numbers in the file name might differ with the specific build of VAS on your distribution CD.

  5. Confirm VAS client configuration. Wait until you see a message indicating that VAS has prepared the VAS client.

Note   If, at some point while developing your test lab installation, you want to restart the VAS installation for Red Hat, you can uninstall VAS by using the following command:

# rpm -e vas-client.
Install the VAS Solaris Client

This subsection describes how to install the VAS client software for the Solaris 9 operating system. The VAS Solaris client includes all of the components listed in Table 2.7, "VAS UNIX Client Components" earlier in this section, with the addition of 64-bit versions of the libraries and modules.

The VAS Solaris client is packaged in pkg format. Pkg is a software package management system used by Solaris.

To install the VAS client package on Solaris 9

  1. Log on as root. Log on to a computer running Solaris 9 as the root user.

  2. Access installation directory. Insert the installation CD (it is mounted automatically), and then type the following command to change to the installation directory:

    # cd /cdrom/cdrom0/client/solaris8-sparc

    where /cdrom/cdrom0 is the path to your CD-ROM device.

  3. Install VAS client for Solaris. Type the following command to install the VAS client pkg:

    # pkgadd -d vasclient_SunOS_5.8_sparc-3.0.0.0.pkg

    Note In certain situations, pkgadd requests additional information. Respond appropriately for your system con?guration.

Joining the Domain and Configuring the VAS Client

After installing the appropriate VAS client package for your UNIX platform, you must first apply a license key and then configure the VAS client by running the vastool join command.

This section includes the following procedures and information:

  • Enter license information.

  • Join the VAS client to the Active Directory domain.

  • Understand the configuration changes made by the vastool join operation.

Enter License Information

As explained earlier in "Software Prerequisites," you will need to install a license key in order for VAS to operate.

You can manage your license information in two ways:

  • Manually. You can manually install license information on each UNIX host. The procedure in this subsection uses this method.

  • Centrally. You can centrally install license information in Active Directory through Group Policy by using vasgpd. For information about using VGP and configuring the Vintela Licensing Policy, see the VGP Administration Guide provided with the VAS product. For more information about VGP in general, see "Add Group Policy Functionality" in the section "Evolving the VAS Solution" later in this chapter.)

CAUTION   When no license is installed, vastool operates correctly, but the other VAS components will not work. If all licenses expire, vasd will exit and cease to function.

To manually install a license file

  1. Log on as root. Log on to a UNIX-based computer as the root user.

  2. Install license. Install the license file:

    1. Copy the file to the /etc/opt/quest/vas/.licenses directory.

    2. Confirm that the permissions on the file are set to 644 (which makes the file readable by anyone but writeable only by the owner).

    CAUTION   Do not modify the license file in any way. Any modifications will invalidate the license.

    Note   You can manually install multiple licenses in the licensing directory. Each valid unexpired license is used to calculate the user limit.

Join the VAS Client to the Active Directory Domain

For the VAS client to work correctly, the UNIX-based computer on which you installed the VAS client must be joined to the Active Directory domain. You use the vastool join command to join the computer to the domain.

The vastool join command configures the VAS client not only by joining it to the Active Directory domain and creating a computer object in Active Directory, but also by configuring the PAM subsystem, configuring the NSS subsystem, and using VGP to apply the VAS license.

The join operation creates a computer object in Active Directory corresponding to the UNIX host that is being joined to the domain. This computer object is the security principal that VAS uses to securely communicate with Active Directory.

This section includes the following series of procedures:

  • To prepare to join VAS clients to Active Directory.

  • To synchronize time.

  • To join a computer running the VAS client to the Active Directory domain.

  • To check the output of vastool join.

  • To restart services.

  • To stop using the legacy UNIX store.

To prepare to join VAS clients to Active Directory

  1. Verify domain name. Obtain the name of the Active Directory domain to which you want to join the VAS client.

  2. Confirm user account membership in Domain Admins. Make sure that you performed the procedure "Configure a UNIX-enabled account to join computers to the domain" earlier in this section to make a user (John Evans in this development lab example) a member of the Domain Admins group.

    Alternatively, you can use another account that has rights to create computer objects in Active Directory

  3. Confirm DNS. Make sure that your test environment uses the same DNS server for dynamic updates that the Active Directory domain controller uses. (For best results when developing the VAS solution in your lab, Active Directory and DNS should be installed at the same time on the same server. The procedures in this chapter were developed and tested in a lab in which DNS is configured on the domain controllers as part of the Active Directory installation process.)

    For more information about how DNS should be set up in your lab, see "Installing and Configuring Active Directory and DNS" and "Configuring the DNS Server" in "Preparing Your Environment" earlier in this chapter.

To synchronize time

CAUTION   You must synchronize time before you join the UNIX host to the Active Directory domain. This synchronizes the system clock on the UNIX client with the system clock on the Active Directory server.

  1. Log on as root. Log on to the UNIX host that you want to join to the Active Directory domain as the root user.

  2. Synchronize clocks. Unless you are already running an NTP server or have otherwise synchronized the VAS client clock with the Active Directory clock, type the vastool timesync command at the UNIX shell command line as follows:

    # /opt/quest/bin/vastool timesync –d domain

    Note   When you run the timesync command before joining the UNIX host to the domain, you must use the –d domain option (where domain is the name of the domain to which you will join the UNIX host) so that vastool can locate the domain with which it will synchronize.

For more information, see "Verifying Time Synchronization" in "Preparing Your Environment" earlier in this chapter.

To join a computer running the VAS client to the Active Directory domain

  1. Join UNIX-based computer to Active Directory domain. While you are still logged on as root, type the vastool join command at the UNIX shell command line as follows:

    # /opt/quest/bin/vastool -u john.evans join fabrikam.com

    where, in this example, john.evans is the user name of an Active Directory user with sufficient administrative privileges to create a computer object in Active Directory (typically, a user who is a member of the Domain Admins group), and fabrikam.com is the name of the Active Directory domain (and Kerberos realm) to which you join the computer.

    Note   If DNS is not configured to support Active Directory SRV records, you must specify a list of domain controllers (separated by spaces) after fabrikam.com. For example:

    # /opt/quest/bin/vastool –u john.evans join fabrikam.com dc01name.fabrikam.com dc02name.fabrikam.com

  2. Type password. When prompted for the user’s password, type the password on the command line.

To check the output of vastool join

  • Review changes. The results of vastool join—which adds the computer to the domain, loads users and groups, starts vasd, and configures PAM and Kerberos—are returned on the shell’s standard output (stdout):

    Configuring Realm fabrikam.com ... OK
    Detecting Domain Services for fabrikam.com ... OK
    Password for john@fabrikam.com:
    Detecting All Domain Services ... OK
    Detecting Site Membership ... none, defaulting to: Default-First-Site-Name
    Adding server.fabrikam.com to the Domain ... OK
    Detecting Schema Configuration ... OK
    Loading users cache: ... Finished.
    Loading groups cache ... Finished.
    Starting vasd:
    Configuring Name Service Switch ... OK
    Configuring PAM Authentication ... OK

For details about the changes produced by this command, see the next subsection, "Understand the Configuration Changes Made by the vastool join Operation."

To restart services

  • Enable system services to use VAS. After you join the UNIX client to the domain, you must restart all of the currently running operating system services (such as telnet, ftp, and ssh) so that they can use the new VAS configuration. To restart these services, do one of the following:

    • Restart the computer.

    • Cycle your UNIX init (initialization) levels to single user mode and back.

    • Restart each daemon individually.

To stop using the legacy UNIX store

  • Replace UNIX identity store with Active Directory.

    Note   You might not need to perform this step in this test deployment in your development lab if you are not working with legacy accounts. However, you will need to do this in your pilot deployment and in your production deployment.

    When VAS is enabled and UNIX-based computers are joined to the Active Directory domain, you must delete or disable the local account (or NIS directory store) before Active Directory authentication can occur.

Understand the Configuration Changes Made by the vastool join Operation

The vastool join operation that you ran in the preceding subsection makes the following modifications to your UNIX-based computer:

  • Modifies users and groups. The computer’s configuration files for user and group account information are modified to include VAS. This is accomplished by modifying /etc/nsswitch.conf to include vas as an entry for the passwd and group entries. The vas entry is inserted after the files entry.

  • Modifies PAM. The computer’s configuration files for authentication are updated to use VAS as an authentication backend. This is done by modifying the PAM configuration file or files located in /etc/pam.conf or in the /etc/pam.d directory. These modifications allow the VAS authentication modules to authenticate Active Directory users while allowing the native system authentication modules to continue to authenticate UNIX users who do not have Active Directory accounts.

  • Modifies Kerberos. The /etc/opt/quest/vas.conf configuration file is configured with information to enable the VAS libraries to use Kerberos authentication against Active Directory.

  • Creates computer object. An object in Active Directory is created for the computer. The computer account’s password is set to a generated random password, which is stored as a Kerberos key at /etc/opt/quest/hosts.keytab.

  • Starts vasd. The vasd service is started, and the VAS user and group caches are loaded.

VAS confirms these modifications after completing the vastool join command by returning the output shown earlier in the procedure "To check the output of vastool join" in the preceding subsection.

Perform Quick Validation Tests

At this stage in the Developing Phase, you should run quick tests to validate that the VAS software is installed correctly. Later in this chapter, the section "Stabilizing Your Test Deployment" provides more comprehensive tests to ensure that the VAS End State 2 solution developed in your test environment is functioning as expected.

Determine Whether VAS Is Operational

To determine if VAS is operational by listing UNIX-enabled Active Directory users

  • Run the vastool list users command at the UNIX shell command line to list UNIX-enabled users in Active Directory:

    # /opt/quest/bin/vastool list users
Authenticate Against Active Directory

To authenticate against Active Directory with a UNIX-enabled user account

  • Assuming that you are still logged on as root, use the switch users (su) command to switch from the root account to the UNIX-enabled account for Rachel Valdez:

    # su - rachel

    where rachel is the user account that you want to switch to.

    IMPORTANT   You must use the '-' option on the su command so that the user’s environment is initialized; use of this option causes a password-based authentication to be performed: pam_vas requests a Kerberos credential and authenticates the user rachel, who now has a Kerberos ticket.

Confirm That the User Has a Kerberos Ticket

To display the Kerberos ticket cache to confirm that the user has a Kerberos ticket

  • Use the vastool klist command to display the Kerberos ticket cache:

    $ /opt/quest/bin/vastool klist

    The klist command confirms that a Kerberos ticket has been issued and returns output similar to the following:

             Principal: rachel@FABRIKAM.COM
         Issued            Expires            Principal
    Aug 1 2005 14:54:51  Aug 1 2005 22:54:51 krbtgt/ FABRIKAM.COM@FABRIKAM.COM
Confirm That User Authorization Is Functioning

To confirm that user authorization is functioning by listing groups

  • Type the getent groups command at the UNIX shell command line to list UNIX groups with their members:

    $ getent groups 

    The output should list all of the active groups and their membership. This group membership list should be identical to the membership list of UNIX-enabled users in the corresponding Windows security group (except that, in addition to the Active Directory groups, local UNIX groups are also listed).

Completing the quick validation tests confirms that the UNIX client computer in your development environment is successfully joined to the Active Directory domain.

Developing Phase Major Milestone: Scope Complete

This completes the Developing Phase for reaching End State 2 by implementing the VAS solution. Users on configured UNIX-based computers can now use Active Directory Kerberos for authentication and Active Directory LDAP for authorization.

At this major milestone, you should gain formal approval from the sponsor and key stakeholders that all solution elements are built and that solution features and functionality are complete according to the functional specifications agreed upon during the Planning Phase.

You can now test and stabilize your VAS solution in preparation for deploying it in your production environment.

Stabilizing Your Test Deployment

This section describes how to test and stabilize the VAS solution in order to prepare for deploying VAS in your production environment. Before you start testing, review the test plan created by using the "Test Plan Template" job aid during the Planning Phase.

Introduction and Goals

Stabilizing Phase testing emphasizes operation under realistic environmental conditions. During this phase, you should prioritize the bugs that testing discovers and fix those that are important for achieving a successful deployment in your production environment.

Major Tasks and Deliverables

The major Stabilizing Phase tasks are:

  • Test the VAS solution.

  • Resolve issues.

  • Conduct a pilot deployment.

Test the VAS Solution

This section describes how the Test team can test the VAS development environment to ensure that key capabilities are enabled and functioning correctly.

The primary activities described here include:

  • Preparing the test lab environment.

  • Running tests.

  • Developing an installation script for your pilot deployment.

Preparing the Test Lab Environment

The tests described in this section assume that you have a lab set up as described earlier in the sections:

  • Preparing Your Environment

  • Developing the VAS Solution

These tests also assume that you are familiar with the tests performed during the Developing Phase in the section:

  • Perform Quick Validation Tests

Members of the Test and Release Management teams who did not participate in the Developing Phase should review the section "Developing the VAS Solution."

Assess Status of Test Lab Used by Developers

Assess the current state of the test lab and, if necessary, rebuild it:

  • Use current lab. If the test lab used in the Developing Phase is in a known stable state appropriate for testing, use the existing lab infrastructure to perform the steps described in this section.

  • Re-build lab. If the test lab used in the Developing Phase is in an unknown or unstable state, rebuild the lab as described in "Preparing Your Environment" and "Developing the VAS Solution."

Expand Test Lab to Model Your Production Environment

Developing the VAS solution served as an initial proof of concept for the VAS implementation of the End State 2 solution that you plan to deploy in your production environment. Now, in the Stabilizing Phase, you must expand the lab to more accurately model your production environment and to address the objectives that you defined during the Planning Phase.

Running Tests

Perform the tests in this subsection to determine if your development deployment is successful and stable.

After you expand your test lab to more closely resemble your production environment, repeat the following series of tests described in the section "Perform Quick Validation Tests" earlier in this chapter:

  • Determine whether VAS is operational.

  • Authenticate against Active Directory.

  • Confirm that the user has a Kerberos ticket.

  • Confirm that user authorization is functioning.

After you rerun those tests successfully, perform the additional series of tests in this subsection:

  • Test new account provisioning.

  • Test password management policies.

  • Test that disabled or deleted accounts cannot log on.

  • Test offline authentication.

  • Test Active Directory failover.

In addition to these tests, which are described in the following subsections, you might also want to test that the Active Directory Group Policy objects (GPOs) that VAS supports for users on UNIX-based computers function correctly. For more information about VAS support for Group Policy, see "Add Group Policy Functionality" in the section "Evolving the VAS Solution" later in this chapter, and see the VGP Administration Guide provided with the VAS product.

Note   In addition to the tests for VAS described in this chapter, you might also want to review the tests in this volume that are designed for the custom solutions for some additional ideas that you might be able to adapt for testing your VAS solution. You can find these tests in Volume 2: Chapter 5, "Stabilizing a Custom Solution." The tests in Chapter 5, "Stabilizing a Custom Solution" are not designed specifically for the VAS solution, and we did not use them to test the VAS solution.

Test New Account Provisioning

To test new account provisioning

  1. Log on with an Active Directory–enabled account. Log on to a UNIX-based computer with the rachel.valdez account.

  2. Check UID and GID. At a UNIX shell prompt, check the UNIX UID and GID assignments for the account. For example:

    • Type the following command to display the UID and GID for the currently logged on user:

      id 
    • Type the following command to display the current user’s home directory with the correct ownership and group names:

      ls -al 
    • Type the following command to display all of the groups (in addition to the primary group) that are retrieved for the currently logged on user:

      groups 
  3. Repeat with another user. Repeat steps 1–2 with the account for Dave Natsuhara.

  4. Log off. Type exit to log off from the current session.

Test Password Management Policies

To test changing passwords and enforcing password policy

  1. Log on with rights to change passwords. Log on to a Windows-based computer on which Active Directory Users and Computers is installed as a user who has rights to reset passwords.

  2. Change password for rachel.valdez. In the console tree, expand the domain name, expand Unix-Test-OU, and then click Unix-Users-OU.

    1. Right-click rachel.valdez, and then select Reset Password.

    2. Enter a new password, and then select User must change password at next logon, and then click OK.

  3. Log on as rachel.valdez. Log on to the UNIX computer with the rachel.valdez account:

    1. When prompted, type rachel, and then type the current password for her account.

    2. When prompted to create a new password, specify a new password. The new password must be a strong password that conforms with Active Directory password policy.

      Make the password sufficiently complex such that the rules of the UNIX password policy would reject the password—this will let you test that any limits-to-complexity imposed by the old system are no longer imposed once End State 1 is achieved. For example, if the UNIX rules require that passwords be 16 characters or less, specify a password that contains 17 characters.

      Note   A strong password is one that contains at least seven characters; does not contain the user's real name, user name, or company name; does not contain a complete dictionary word; and contains a combination of uppercase letters, lowercase letters, numbers, and symbols found on the keyboard. For more information about strong passwords, see "Strong passwords" at http://technet2.microsoft.com/WindowsServer/f/?en/Library/804fd807-9708-4d00-ac17-539814a56f791033.mspx.

  4. Log off , and then log on again as rachel. Log off from the UNIX computer, and then log on again with the rachel.valdez account for which you just configured a new, complex password.

    • Confirm that you are able to log on.

Test That Disabled or Deleted Accounts Cannot Log On

To test that users with disabled or deleted accounts cannot log on

  1. Log on with rights to create , modify , and delete accounts. Log on to a Windows-based computer on which Active Directory Users and Computers is installed as a user who has rights to add, modify, or delete accounts.

  2. Disable Rachel's account. In the console tree, expand the domain name, expand UNIX-Test-OU, and then click UNIX-Users-OU.

    1. Right-click rachel.valdez, and then select Disable Account.

    2. Click OK to confirm that you do want to disable this account.

  3. Delete Dave's account: 

    1. Right-click dave.natsuhara, and then select Delete.

    2. Click OK to confirm that you do want to delete this account.

  4. Log on as rachel. Try to log on to the UNIX computer with the rachel.valdez account:

    • Confirm that you are unable to log on.

  5. Log on as dave. Try to log on to the UNIX computer with the dave.natsuhara account:

    • Confirm that you are unable to log on.

  6. Re-enable Rachel's account. On the Windows-based computer, in Active Directory Users and Computers, right-click rachel.valdez, and then select Enable account.

Test Offline Authentication

To test user authentication when a UNIX-based computer is not connected

  1. Disable network connection. Disable the network connection on a computer on which VAS is installed, either by disconnecting network hardware or by disabling the software interface.

  2. Confirm that offline logon works:

    1. Log on as the user rachel and, when prompted, type the password.

    2. Confirm that the logon is successful even though the computer is not currently connected to Active Directory.

Test Active Directory Failover

To test that Active Directory failover is functional

Note   This procedure assumes that you have already installed two domain controllers in your lab as described in "Install and Configure the First Active Directory Domain Controller" and "Set Up a Second Domain Controller" earlier in this chapter.

  1. Disable one domain controller. To simulate a failure of the connection to the domain controller, remove the first domain controller from the network, and then perform the following steps:

    1. Flush cache. At a UNIX shell command line, type the following command to flush the users and groups cache:

      # vastool flush
    2. Confirm users exist. At a UNIX shell command line, type the following command to confirm that UNIX-enabled users in Active Directory are present as expected:

      # /opt/quest/bin/vastool list users
  2. Disable the other domain controller. Reconnect the first domain controller to the network, and then disconnect the second domain controller from the network.

    • Repeat steps 1a and 1b.

    In this case, as in the case when the first domain controller "failed," the vastool list users command should provide the same output: a list of all VAS-enabled users. This demonstrates that VAS has successfully reconnected to the available domain controller, despite the simulated failure of the other domain controller.

Developing an Installation Script for Your Pilot Deployment

Typically, most organizations with a network infrastructure that includes both Windows and UNIX will want to deploy the VAS solution across a number of computers. To facilitate installation and configuration of VAS on multiple and possibly divergent systems, you should develop a script to run on your UNIX clients that can perform the following functions:

  • Identify the host operating system.

  • Download the VAS package for a given platform from a central location.

  • Install, remove, or upgrade the VAS package.

  • Apply the license key.

  • Back up existing VAS or Kerberos configuration files.

  • Join the domain (based on a lookup keyed on the current host, the domain to join might be specified in a multidomain forest configuration).

  • Configure the environment, including:

    • Customize PAM service configuration.

    • Configure allow/deny access files.

    • Map Kerberos configuration files to VAS (MIT compatibility).

To test a sample deployment script

  1. Adapt sample script. Adapt the following sample deployment script as needed for your pilot environment:

    Note: Some of the lines in the following code have been displayed on multiple lines for better readability.

    #!/bin/sh
    ## Example script that will install VAS on a given platform.
    ## Missing error checking and result reporting for brevity. 
     
    # Location for tmp files.
    VAS_TMP=/tmp/vas-join
     
    # Domain name.
    DOMAIN=fabrikam.com
     
    # VAS
    VAS=/opt/quest/bin/vastool
     
    # Auth line. This is where you set keytab to use, or put in a 
    # username/password (this is not the reccommended method).
    AUTH_LINE="-u admin -w Test1234"
    #AUTH_LINE="-u joiner/${DOMAIN} -k joiner.keytab"
     
    # Find OS, tell Solaris and Linux apart:
    case `uname` in
        "Linux")
            PLATFORM="LINUX" ; PKG="vas.i386.rpm"
            ;;
        "SunOS")
            PLATFORM="SUN" ; PKG="vas.sparc.pkg"
            ;;
        *)
            echo "Unknown OS"
            exit 1
            ;;
    esac
     
    # Make some temporary folders.
    mkdir ${VAS_TMP}
    cd ${VAS_TMP}
     
    # Get the needed files, using scp and pre-shared keys.
    scp file_server:vas_files/${PKG} .
    scp file_server:vas_files/vaslicense.txt .
    scp file_server:vas_files/joiner.keytab .
     
    # Install
    if [ $PLATFORM = "LINUX" ]
    then
        rpm -ihv ${PKG}
    else
        pkgadd -d ${PKG} all
    fi
     
    # Make the directory structure to lay down the license file, 
    # then copy it over.
    mkdir -p /etc/opt/quest/vas/.licenses
    cp vaslicense.txt /etc/opt/quest/vas/.licenses/
     
    # Join.
    ${VAS} ${AUTH_LINE} join -f ${DOMAIN}
  2. Run sample script:

    1. Create several new users for four UNIX-based computers that you have not previously included in your development environment.

    2. Run the sample script for those new users.

    3. Confirm that the script worked by using the vastool list users command to list UNIX-enabled users in Active Directory:

      # /opt/quest/bin/vastool list users

Resolve Issues

The goal of testing is to discover and track issues that need to be resolved and to learn from the testing experience to help ensure successful pilot and production deployments.

Fixing Bugs

Members of the Test and the Development teams work together in the reiterative process of troubleshooting and resolving bugs discovered during testing.

Integrating Experience into Deployment Planning

After performing the tests described earlier, developing a prototype installation script, and resolving all bugs whose resolution is necessary for a successful deployment, you should adjust your planned deployment strategies and update your pilot and rollout plans based on what you have learned so far during the Developing and Stabilizing Phases.

You should also evaluate the potential impact of your VAS deployment on server and network load. Your existing Active Directory infrastructure might need to be updated to handle the additional users.

For more information about the VAS application, which has been extensively tested, see the product documentation for release notes and other information about known anomalies, platform-specific features or behaviors, and other operational parameters.

Conduct a Pilot Deployment

After the Test team tests the VAS solution and works with the Development team to stabilize the solution in a test environment, the next step is for the Release Management team to work with the Test team to conduct a pilot deployment by deploying the solution to one or more groups of typical users in your production environment.

Performing a pilot deployment helps you develop your deployment, loading, and operational expertise before you roll out the VAS solution to the entire organization. Before you start, review the pilot plan created by using the “Pilot Plan Template” job aid during the Planning Phase.

You can use Table 2.8, which provides a synopsis of pilot tasks, as a checklist when you perform your pilot deployment.

Note   You can find detailed information about installing the VAS solution in the VAS Installation Guide available on the Quest Software Product page for Vintela at http://www.vintela.com/products/vas/index.php (click the "Documentation" link).

Table 2.8. Checklist of Tasks to Perform a Pilot Deployment

Task

Action

1. Identify success criteria

Review success criteria identified during the Planning Phase in the “Pilot Plan Template” job aid.

If appropriate, update the success criteria.

2. Identify pilot users

Identify a set of users who will participate in the pilot.

Select:

  • A set of users who have both UNIX accounts and Active Directory accounts.

  • A set of users who only have UNIX accounts.

  • For the initial pilot, select knowledgeable users, such as help desk or other IT personnel.

After you successfully complete an initial pilot deployment with these users, you will expand the pilot to include a subset of users whose expertise is in an area other than IT. Try to select users whose access patterns allow you to install VAS on a controlled number of UNIX-based or Linux-based computers. This will reduce the amount of work required for the expanded pilot and will control the amount of rollback activity required in the event of a failure.

3. Identify pilot computers

Identify which computers you want to include in the pilot, and back up all system and data information.

4. Install VAS

Install the VAS software on a Windows-based computer in the pilot domain and on all UNIX-based computers included in the pilot:

  • For more information, see “Installing VAS Components for Windows Server 2003” earlier in this chapter.

  • For more information, see “Installing VAS Client Components for UNIX” earlier in this chapter.

5. Choose user account store

Choose an established user account store from an existing UNIX-based computer to conduct the initial pilot.

For example, use:

  • A local /etc/passwd user account database.

  • A NIS identity store.

6. Import existing UNIX information

For users in the pilot group who already have both a UNIX account and an Active Directory account, import their UNIX information into their Active Directory accounts:

  • Use the vastool load command to import into Active Directory existing UNIX users and groups whose information is stored in local /etc/passwd and /etc/group files.

  • Use the vastool nis-import command to import into Active Directory existing UNIX users and groups whose information is stored in NIS.

For information about importing existing UNIX user accounts into Active Directory, see "Import a set of UNIX accounts into Active Directory" in Table 2.5 "Synopsis: Integrating UNIX Groups and Users with Active Directory" earlier in this chapter or refer to the section "Importing Users and Groups" in the VAS Administration Guide.

7. Create new user accounts

For users in the pilot group who currently have only a UNIX account, create a new Active Directory account (see “Creating Test OUs, Groups, and Users”), and use the UNIX Account tab to UNIX-enable the Active Directory accounts (see “Enabling UNIX Group and User Properties in Active Directory”).

8. Create test user account

UNIX-enable an existing test Windows account (which does not correspond to an existing UNIX user) for use in testing VAS functionality before migrating existing users.

9. Prepare pilot users

To prepare the pilot users to switch their UNIX-based computers to begin using Active Directory authentication, prepare the pilot users:

  • Conduct informational or training sessions to ensure that pilot users know what to expect.

  • Teach pilot users how to use bug-tracking software so that they can report any problems that arise during the pilot deployment.

  • Inform users when the switch to Active Directory authentication will occur.

    Note   At this point, UNIX-based computers included in the pilot cannot yet use Active Directory authentication but can use only the old UNIX-based method of validating users.

  • Inform users what their Active Directory passwords are and that, after the deployment occurs, they must use only these passwords for logging on to their UNIX workstations.

  • For users new to Windows, provide any needed information or training.

  • Inform users that, because the users' account information has been migrated from their existing UNIX directory to Active Directory, they will log on using their existing UNIX logon name. They must use their Active Directory password because their existing UNIX password will no longer be active after the solution is deployed—unless your organization uses a solution for synchronizing passwords between Active Directory and the UNIX-based or Linux-based computers included in the pilot, in which case the current UNIX password is also the current Active Directory password.

10. Join one UNIX host to domain

At the time scheduled for the switch to Active Directory, log on as root to one UNIX-based computer and use the vastool join command to join it to the Active Directory domain.

For more information, see “Join the VAS Client to the Active Directory Domain” earlier in this chapter.

11. Confirm join for one host

After you successfully run the vastool join command on one UNIX-based computer, test that the UNIX-based computer is correctly joined to the domain.

For more information, see “Perform Quick Validation Tests” earlier in this chapter.

12. Verify test user

Log on as the test user created in step 8 earlier to validate that VAS is authenticating properly

13. Remove local account of one user and ask that user to log on

Remove (from /etc/passwd or NIS) the non-Active Directory user account of a UNIX-enabled user, thereby VAS-enabling the user account.

Ask this user to log on with Active Directory credentials (logon name and password) to the UNIX-based computer that is joined to the domain.

14. Join remaining UNIX hosts to domain

Join the remaining hosts to the domain in two stages:

  • Log on as root to each of several of the remaining UNIX-based computers in the pilot, and then run the vastool join command to join those computers to the Active Directory domain.

  • Run the deployment script that you developed in "Developing an Installation Script for Your Pilot Deployment" earlier in this section to join the computers of the remaining pilot users to the Active Directory domain.

It is important to use a script that lets you join multiple computers to the domain in your pilot deployment to help ensure that you will be able to successfully join multiple computers to Active Directory when you are ready to deploy the VAS solution in your production environment.

15. Confirm join for multiple hosts

Test that each UNIX-based computer is correctly joined to the domain.

For more information, see “Perform Quick Validation Tests” earlier in this chapter.

16. Remove local accounts

Remove the non-Active Directory user accounts (from /etc/passwd on each individual host or from NIS after all of the affected computers have been joined to the domain) of the UNIX-enabled users in the pilot group, thereby VAS-enabling the accounts.

17. Log on remaining pilot users

Ask the rest of the users participating in the pilot deployment to log on to their UNIX-based computers with their Active Directory credentials (logon name and password).

Because the user information from the UNIX /etc/passwd file (or other UNIX-based store such as a NIS store) now populates their UNIX attributes in Active Directory, members of the pilot group see no change in their UNIX user experience. Their selected UID, GID, home directory, and shell program are the same as before.

The only change for users is that they now need to use their Active Directory password to log on to their UNIX-based computers.

18. Ask pilot users to change passwords

Ask the UNIX users participating in the pilot to change their Active Directory passwords and log on again to confirm that password changes function correctly.

19. Let pilot users perform daily tasks

Ask the pilot users to perform their usual tasks so that their UNIX hosts interact with other infrastructure components and with a variety of applications on the network.

For example, for each pilot user, check that the following continue to function correctly:

  • Any application running on the UNIX-based computer.

  • Any server application for which the UNIX-based computer is the client.

  • Enterprise monitoring systems.

  • Systems that might be sensitive to changes in the Active Directory schema, such as identity management or directory synchronization systems.

20. Perform administrative tasks on servers

Perform a wide variety of typical administrative tasks on the Active Directory server and on other servers on which pilot users access resources. For example:

  • Add users.

  • Delete users.

  • Change Active Directory Group Policy objects (GPOs) that affect users or computers in the pilot.

21. Interview pilot users

Interview or send a questionnaire to the pilot users to determine whether the change to Active Directory authentication and authorization caused any problems or raised any issues for the users.

22. Resolve issues

Resolve any issues that you encounter or that the pilot users report. In addition to issues directly related to authentication and authorization, you should look for and resolve problems such as issues related to security and network and server traffic.

23. Update pilot and deployment plans

Based on your experience in deploying the pilot and on the feedback you receive from users who participate in the pilot:

  • Update your pilot plan so that the larger pilot with non-IT users (that you will perform after completing this initial pilot) will go more smoothly.

  • Update your deployment plan (part of the master project plan).

  • Update (or write) training materials for operations personnel.

  • Update (or write) informational or training materials for end users.

24. Confirm success criteria have been met

Confirm that the pilot deployment has met the success criteria specified in "Identify success criteria" at the start of this checklist.

25. Perform a second pilot with a set of typical end users

For the initial pilot just completed, you used knowledgeable users, such as help desk or other IT personnel.

Now, expand the pilot to include a set of users whose expertise is in an area other than IT.

This time, deploy the solution just as you plan to do for the full production deployment (see the "Deployment Plan Template" job aid).

Stabilizing Phase Major Milestone: Release Readiness Approved

This completes the Stabilizing Phase for reaching End State 2 by implementing VAS. You have tested the solution, resolved issues found, and successfully completed a pilot deployment. At this point, your team and customers should agree that all outstanding issues have been addressed and that the solution is ready to be released into the production environment.

Deploying the VAS Solution

After you complete the Stabilizing Phase, you are ready to place all UNIX-based user, group, and computer accounts into Active Directory throughout your production environment. After you complete the Deploying Phase, you can use Active Directory to manage all authentication and authorization services for both Windows-based and UNIX-based computers.

Introduction and Goals

This section provides an overview of deployment tasks required for the VAS solution. For additional information about deploying VAS, see the following guides on the Quest Software Product page for Vintela at http://www.vintela.com/products/vas/index.php (click the "Documentation" link):

  • The VAS Installation Guide

  • The VAS Administration Guide

  • The VGP Administration Guide

All three guides are also included on the VAS product CD.

VAS is typically deployed into an existing, perhaps large, heterogeneous infrastructure. Within a large enterprise environment, you might need to take the following conditions into consideration as you deploy the VAS solution in your production environment:

  • Load. Adding load to your Active Directory servers, depending on the number of users and computers that will be included in the VAS deployment.

  • Single identity store. Creating a single identity store—probably for the first time—for all of your UNIX, Linux, and Windows identities. Although, in some environments, VAS might replace existing full or partial identity management solutions, the typical case is that you will be creating a single identity store for the first time. The first-time creation scenario is assumed in this chapter.

  • Wider Active Directory integration. The availability of the UNIX systems that are integrated with Active Directory might prompt you to evaluate other areas of system or application integration with Active Directory–based identities beyond simple logon. These types of solutions are explored in the "Evolving the VAS Solution" later in this chapter.

The actual deployment of VAS across an organization is subject to multiple factors defined by the scope of the deployment and the preexisting authorization and authentication infrastructure. The guidelines that follow consist of highlights and special considerations important for most deployments.

Knowledge Prerequisites

Preparing for VAS deployment requires:

  • Familiarity with the VAS solution as described earlier in this chapter.

  • Familiarity with Volume 2: Chapter 1, "Choosing the Right Technology and Planning Your Solution" earlier in this volume.

  • A complete inventory of existing infrastructure elements affected by the deployment, including hosts, operating systems, and versions.

Major Tasks and Deliverables

In the Deploying Phase, you perform the following major tasks:

  • Complete deployment preparations.

  • Deploy VAS.

  • Stabilize the production deployment.

Complete Deployment Preparations

Before you begin the VAS deployment in your production environment, as described in "Deploy VAS" later in this section, you should review the following topics that describe how to prepare for the deployment:

  • Inventorying current state

  • Managing digital identities

  • Developing an installation script for your production deployment

  • Securing the VAS deployment

  • Considering a phased deployment

  • Preparing to activate VAS

  • Preparing the IT support staff and user community

Inventorying Current State

Typically, large organizations have many divergent systems that are important to the VAS deployment. Table 2.9 summarizes the inventory of computers and user accounts that you need to perform to prepare to deploy VAS.

Table 2.9. Inventorying Computers and User Accounts

Task

Action

Inventory computers

Inventory all target computers that you want to include in the VAS deployment.

Identify atypical computers

Document those computers that are nonstandard in terms of security, configuration, or criticality.

Although, ideally, in a large-scale deployment, you should automate as many steps as possible, you might need to deploy nonstandard computers manually rather than include them in the automated deployment.

Inventory user accounts

In addition to inventorying and updating your hardware, you need to identify all existing UNIX accounts—including inactive accounts that need to be retired.

For more information, see the subsection "Identify Active and Inactive UNIX Accounts" under "Managing Digital Identities" later in this section.

Managing Digital Identities

Digital identities, also known as security principals or just as principals, are users, computers, and services that can be authenticated when they log on to a network or, after logon, when they authenticate to a network service.

Before you deploy VAS in your production environment, you must prepare to handle the following digital identity management tasks:

  • Map existing UNIX UIDs and GIDs into Active Directory.

  • Prepare Active Directory for adding UNIX-enabled accounts.

  • Administer UNIX accounts.

  • Identify active and inactive UNIX accounts.

Map Existing UNIX UIDs and GIDs into Active Directory

When you map existing UNIX UIDs and GIDs to Active Directory user and group accounts, you need to ensure that conflicting UIDs and GIDs do not occur. You can use either a single namespace or a multiple namespace strategy to avoid conflicting UIDs and GIDs when you deploy the VAS solution.

This section describes:

  • Migrating UNIX users and groups to a single namespace.

  • Using UPM to maintain and organize multiple existing namespaces.

Migrating UNIX Users and Groups to a Single Namespace

If you choose the single namespace option, you must update UNIX UIDs and GIDs so that they are consistent across all computers. Frequently, in an organization that does not have a single identity management structure in place, UNIX hosts evolve organically, with the result that local UNIX accounts are created with UIDs and GIDs that are not consistent across different computers—that is, one user might have different UIDs or GIDs for different computers.

For example, user john might have a UID of 1027 on host workstation.mydomain.com and a UID of 2043 on host server.mydomain.com. When you join both of these computers to the Active Directory domain, you must associate the account for john with a single UID if you plan to use a single namespace in your VAS deployment. You must also make the files and permissions on both computers uniform so that john can access and control his files on both computers. In particular, you need to ensure that you do not add another user on a given host to Active Directory with a UID that corresponds to the UID of files owned by john. This can easily occur if you do not perform a rigorous normalization of UIDs and GIDs before you deploy VAS.

Table 2.10. Checklist for Rationalizing UIDs and GIDs Across a Single Namespace

Task

Action

1. Identify inconsistent UIDs and GIDs

Begin by identifying which users and groups have multiple or conflicting UIDs and GIDs on multiple UNIX-based computers.

2. Define a unified scheme

Develop a consistent scheme for a single namespace across your entire organization:

  • Define a single UID for each user account.

  • Define a single GID for each group.

3. Choose a manual or an automated approach

Make adjustments manually:

If only a few discrepancies exist, you can manually associate each user with a single UID and each group with a single GID.

Use a script:

If many discrepancies exist, you can develop a script that:

  1. Assigns a new globally unique UID to each user and assigns a new GID to each group.

  2. Changes the ownership of each file that belongs to each user to the new UID.

  3. Changes the group ownership of each file that belongs to each group to the new GID.

4. Integrate these changes into a phased deployment

If you have a medium-size or large organization and plan to deploy VAS in phases, make sure that you integrate this process of making UIDs and GIDs consistent across a single namespace into your phased deployment.

For more information about using a phased deployment, see "Considering a Phased Deployment" later in this section.

Using UPM to Maintain and Organize Multiple Existing Namespaces

The new UPM feature introduced in VAS 3.0 provides an alternative to migrating users into a single namespace for UIDs. UPM lets you associate UNIX-based computers with a specific "personality OU," which contains alternative UNIX user personality objects and, in the case of groups, "group personalities."

These personality objects are instances of the posixAccount and posixGroup objects defined in RFC 2307 and included in both the default VAS schema and the Windows Server 2003 R2 schema. Personality objects let you define alternative profiles that present different attributes to computers associated with a particular personality OU. You then link the personality objects to a single underlying Windows account—it is this Windows account that is used for authentication.

For example, you can accomplish the migration of UNIX users in disparate NIS domains by importing existing NIS users as personality objects into a personality OU that corresponds to the previously existing NIS domain. The personality OU then contains a personality object that contains attribute values that are specific to the OU (NIS domain) that conflict with values imported from other NIS domains into other OUs. The UNIX host is joined only to a specific OU, and thus sees only the attributes that are associated with the personality objects for these users. When the user authenticates, however, the password of the underlying Windows account (to which the personality is linked) is used. The Windows account is the real "identity" with which the personality is associated.

The UPM feature thus lets you quickly migrate information about each user, as defined in each disparate NIS domain, into one Active Directory OU for each NIS domain. Thus, UPM lets the user log on to different UNIX-based computers with a single user account and a single password without requiring that the UNIX-based computers themselves be re-permissioned to reflect a single user ID because the attributes (which define ownership) are correct for the systems previously managed using NIS.

Detailed description of the VAS UPM feature for UNIX users is outside the scope of this chapter.

Prepare Active Directory for Adding UNIX-Enabled Accounts

As you prepare to integrate the UNIX and Windows user and group accounts in your production environment, you need to coordinate how to handle Active Directory schema extensions, OUs, user accounts, passwords, groups, and sites.

Table 2.11 summarizes these Active Directory issues.

Table 2.11. Active Directory Considerations as You Prepare to Deploy VAS

Active Directory Issue

Description

Schema extensions

Extending the schema on your schema master domain controller is the first step in making Active Directory ready for use with UNIX user or group accounts.

For more information, see "Extensions to the Active Directory Schema for UNIX User Attributes" earlier in this chapter.

OUs

How you manage the integration of UNIX accounts with Active Directory accounts depends on how your organization handles Active Directory administrative tasks.

For example, if you group sets of Active Directory users or groups into a hierarchy of organizational units (OUs) and delegate authority to manage each OU to different network administrators, your deployment preparations need to reflect this OU structure and its associated system of delegation.

Before you deploy VAS, develop training, guidelines, and scripts that allow delegated administrators to UNIX-enable the accounts in the OUs for which each administrator is responsible.

User accounts

For UNIX users, you configure UNIX-enabled accounts in Active Directory either by UNIX-enabling an existing Windows account (for a user who has both a UNIX and a Windows account) or by migrating a UNIX account to Active Directory (for a user who currently has no Windows account). For more information, see "Integrate UNIX Accounts and Active Directory Accounts" earlier in this chapter.

After you have configured UNIX-enabled accounts in Active Directory for all UNIX users, you can retire the UNIX /etc/passwd files or NIS identity store because Active Directory is the sole identity store used from that point forward for both UNIX and Windows users.

Passwords

In the case where you import existing UNIX account information into Active Directory, you cannot import the password from that account into Active Directory because the password itself is encrypted. Therefore, you must reset the password for the new account either to a default value or to an assigned value—unless your organization uses a solution for synchronizing passwords between Active Directory and UNIX or Linux computers, in which case the current UNIX password is also the current Active Directory password.

You must communicate this password information to users and manage security issues related to this requirement.

Groups

In some cases, it might be appropriate to map existing UNIX groups to corresponding Windows groups, and then UNIX-enable the Windows groups.

In other cases, you must create new UNIX-enabled Windows groups, either because their significance—for example, "administrators" or "managers"—spans both the UNIX and Windows environments, or because the privileges and/or access rights of the members of these groups differ depending on the context of the environment.

Sites

Your network infrastructure might intermingle UNIX computers in the same network topology that connects Windows-based computers.

Alternatively, UNIX computers might be geographically or topologically separate from Windows-based computers. In the latter case, you might want to configure a new Active Directory site to support the UNIX-based computers and users that become Active Directory objects when you deploy the VAS solution.

Administer UNIX Accounts

As you prepare to begin using Active Directory as your administrative interface for managing UNIX accounts, you need to decide how to handle any existing mechanisms, policies, and procedures currently in use for managing these accounts.

For example, you might have different password reset policies in place for UNIX accounts than for Windows accounts. Depending on your administration model, you might need to modify or adapt your policies or procedures for password resets or other account management practices.

Identify Active and Inactive UNIX Accounts

As you prepare to deploy the VAS solution, you must identify all existing UNIX accounts for both users and groups. Part of this process requires identifying any inactive accounts. Therefore, one major potential benefit of creating a single data store for your UNIX and Windows accounts is the opportunity it affords to identify—and retire—inactive UNIX accounts.

Determine which inactive accounts you will want to reactivate later and migrate those along with active accounts; remove inactive accounts that you do not want to reactivate later. If your predeployment state includes disjoint identity stores, it is likely that orphaned or otherwise irregular accounts exist.

Remove any inactive accounts from the local UNIX-based computers to ensure that you do not migrate these accounts to Active Directory. This is a critical step to achieve the security benefits—such as the capability to audit accounts—made possible by using Active Directory as your primary identity store.

Developing an Installation Script for Your Production Deployment

If necessary, rework the installation script that you created earlier for your pilot deployment so that it will work for your production deployment. If you plan to deploy the VAS solution in phased stages, you might need to adapt the script for each new stage.

Securing the VAS Deployment

Because installing VAS requires the use of the root account on the UNIX host, you must perform any automation or scripted installation within a secure perimeter. Either:

  • Access the root account directly (not remotely).

  • Access the root account by using an ssh session.

    Note   Secure Shell (the ssh command, which provides secure, encrypted remote logon, secure file transfer, and other secure communication services) lets you securely access a remote computer.

After the VAS solution is deployed, your VAS installation greatly facilitates secure Kerberos functionality because it provides for automatic and secure creation and installation of Kerberos keytab files. Active Directory passwords managed by VAS are always encrypted.

Considering a Phased Deployment

Depending on the size of your organization and the number of UNIX servers, workstations, and users that will become part of the Active Directory domain through implementing VAS, it might be advisable to deploy VAS in stages.

You can use the initial small-scale pilot deployment that you performed in the section "Stabilizing Your Test Deployment" earlier in this chapter to tune and debug your production deployment scripts and procedures. As in the initial pilot, the optimal approach for the first phase of your production deployment requires close coordination with a relatively small number of knowledgeable and cooperative users.

As your procedures and scripts evolve and become stabilized, you can deploy to a larger group. As in the initial pilot, update your deployment documentation with the resolution of any new issues that you encounter. After you achieve a successful deployment with this larger group, you can then decide whether to continue deploying one group at a time or whether to deploy VAS across your entire organization.

Phased deployment is a tactic that you can use to mitigate risk. It is important to identify the risks that you intend to mitigate when designing a phasing strategy:

  • If you want to mitigate "people" risks, consider migrating users group by group.

  • If you want to mitigate risks to the UNIX-based or Linux-based computers being incorporated into your VAS solution, consider migrating one computer at a time. In this case, migrating a commonly used single computer might require the migration of a large number of users.

It is much easier to configure a UNIX-based computer to authenticate some users against Active Directory and other users against previous authentication sources than it is to train users to understand that some UNIX-based computers are using older authentication systems while others are now using Active Directory. Nonetheless, there are times when your risk mitigation strategy requires you to adopt the latter approach.

Preparing to Activate VAS

After you install VAS components for Windows, create UNIX-enabled Active Directory accounts, install VAS components on the client systems, and join the UNIX clients to the Active Directory domain, the final step will be to activate the Active Directory accounts used for UNIX users and groups so that these users can start to authenticate against Active Directory. You activate Active Directory–based authentication by disabling UNIX-based authentication, as described in "Activating VAS" in the section "Deploy VAS" later in this chapter.

If you plan to deploy VAS to a large number of computers and users, the recommended practice for activating VAS accounts is as follows:

  • Pilot. Manually activate your first pilot group of users, and then ask for user feedback to determine if any problems occurred.

  • Larger pilot. Automate or batch the migration of a larger group, taking into account the user feedback from the initial pilot group. After this deployment, ask for user feedback again and resolve any new issues.

  • Network-wide. Activate VAS users across your organization using scripts or wholesale deletion of file or NIS-based account information.

Preparing the IT Support Staff and User Community

Before you can deploy the VAS solution, you must prepare the IT support staff and your user community.

Train IT Support Staff

Provide training to your IT support staff—such as network administrators, Active Directory administrators, and help desk personnel—that answers the questions in Table 2.12.

Table 2.12. Providing Information to Prepare Administrators and Help Desk Staff

Question

Action

When is the deployment date?

Make sure that IT support staff are available at the time the deployment is scheduled to take place.

What project plans should I read?

Make all plans related to the VAS deployment available to IT support staff.

Schedule time for IT support staff to read the plans relevant to their role.

What documents should I read?

Make available all system and solution documentation, including inventory information and this chapter, to IT support staff so that they can solve end-user issues that arise during the production deployment.

Schedule time for IT support staff to read the documents relevant to their role.

What did you learn from the pilot?

Explain the result of the pilot project, including any issues encountered during the pilot and the resolution for each issue.

How is Windows managed?

If your IT support staff members are familiar only with supporting UNIX-based computers, provide training about Windows and Active Directory concepts and administration.

How is the new VAS solution managed?

Create an operations handbook with details about new policies and about implementing common operations scenarios in your network and business environment. Use the handbook when you provide training about:

  • Naming conventions for OUs, groups, users, and computers, including accounting for and reconciling differences between naming conventions for Windows and UNIX accounts.

  • Policies for password resets, password aging, and password complexity.

  • Policies about delegation and granting access, including:

    • Using Active Directory for delegating authority to perform specific tasks and for granting specific users fine-grained access based on group membership. Include guidelines about the appropriate use of GPOs.

    • Using the UNIX root account to determine the level of privilege.

    • Using open source tools, such as sudo, (which stands for "superuser do" and lets a user act as the system's superuser) or other third-party tools to determine the level of privilege.

      For information about how to use sudo with VAS, see "Using VAS and SUDO to manage administrative (root) access to UNIX systems" at http://rc.vintela.com/topics/sudo.

  • Procedures for adding (and retiring) a UNIX-based computer or user to Active Directory, as part of the process of employee provisioning and deprovisioning.

How do I report VAS issues?

If your organization uses a bug or problem-ticket system for tracking issues, set up a new subject area 0for this solution.

Provide training to IT support staff about how to report VAS issues.

What needs to be retired?

Determine if UNIX-based computers, identity stores, or other infrastructure will be retired after the VAS deployment.

Assign appropriate IT support staff to retire or repurpose redundant or unnecessary infrastructure after the VAS deployment is completed and stabilized.

Prepare End Users

Provide information to the UNIX user community that answers the questions in Table 2.13.

Table 2.13. Providing Information to End Users

Question

Action

When is the deployment date?

Inform end users when the switch to Active Directory will occur.

Is my computer affected?

Inform end users which UNIX-based computers are included in the new deployment.

What password should I use?

Explain to end users that, after the VAS deployment is complete, they must use a single Active Directory password to access their UNIX workstations. They cannot continue to use their current UNIX passwords after the deployment—unless your organization uses a solution for synchronizing passwords between Active Directory and UNIX-based or Linux-based computers, in which case the current UNIX password is also the current Active Directory password.

  • Windows and UNIX users. Users who currently have both UNIX-based and Windows-based computers (and thus have both UNIX and Active Directory user accounts) typically have different passwords and often have different user names for each computer.

    Inform these users that—when VAS is enabled and the local account or NIS directory store is deleted or disabled—they will need to use their Active Directory user name and password to log on to both their Windows and UNIX-based computers.

  • UNIX only users. Users who currently have only a UNIX-based computer (and thus have only a UNIX account) do not at present have an Active Directory account.

    Inform these users that—when VAS is enabled and the local account or NIS directory store is deleted or disabled—they will need to use their new Active Directory user name and password to log on to their UNIX-based computers.

    Let these users know what the password is for their new Active Directory account, and make sure that they understand that they will be prompted to provide a new password.

Deploy VAS

With deployment preparations complete, you are ready to deploy the VAS infrastructure in your production environment. This section briefly summarizes the tasks that you need to perform to deploy the VAS solution in your production environment. For deployment details, see "Developing the VAS Solution" and "Conduct a Pilot Deployment" earlier in this chapter, and see the administrative guides that come with the VAS product.

  • Smaller organization. If your organization is small, you can do a manual deployment by performing the following procedures:

    • Deploying the VAS infrastructure.

    • Joining UNIX-based computers to the Active Directory domain.

    • Activating VAS.

  • Larger organization. If your organization is medium-sized or large, you can automate some of the deployment tasks:

    • Perform a phased deployment as described earlier in "Considering a Phased Deployment."

    • Use the script that you developed earlier (see "Develop an Installation Script for Your Pilot Deployment" and "Develop an Installation Script for Your Production Deployment"), and skip the procedures "Deploying the VAS Infrastructure" and "Joining UNIX-based Computers to the Active Directory Domain."

    • Perform the procedures in "Activating VAS."

Deploying the VAS Infrastructure

[Smaller Organizations Only]

Navigation Note   Perform the tasks described in this subsection only for a smaller organization. If your organization is medium-size or large, skip this subsection.

You can use the synopsis of deployment tasks listed Table 2.14, "Deploying VAS in the Windows Environment," and Table 2.15, "Deploying the VAS Client" as a deployment checklist.

Table 2.14. Deploying VAS in the Windows Environment

Task

Action

1. Install VAS components for Windows

Install VAS on Windows Server 2003 by performing the procedures in these subsections (described earlier in this chapter):

  • Extend the Active Directory Schema

  • Register VAS Modifications to Active Directory Consoles

  • Install the VAS Administrative Tools

2. Configure Windows accounts for UNIX

Configure Windows accounts for UNIX users and groups by performing the procedures in these subsections (described earlier in this chapter):

  • UNIX-enable an Active Directory Group

  • UNIX-enable Active Directory Accounts for UNIX Users

  • Configure a UNIX-enabled Account to Join Computers to the Domain

After deploying the Windows environment, as summarized in the preceding table, you can deploy the UNIX-based computers, as summarized in Table 2.15.

Table 2.15. Deploying the VAS Client

Task

Action

Install VAS client components

Install the VAS client on UNIX-based computers by performing the procedures in these subsections (described earlier in this chapter), as appropriate, to your target platform:

  • Install the VAS Linux Client

    – or –

  • Install the VAS Solaris Client

At this point, although the software is fully installed, the UNIX-based computers are still functioning in their predeployment state. Installing the VAS components on Windows-based computers and on UNIX-based computers does not by itself change the authentication or authorization behavior of any of the computers on your network. The VAS components are inactive until you join the UNIX-based computers to the Active Directory domain and delete or disable the UNIX identity store.

You can initiate the deployment to Active Directory at any time, based on the constraints or requirements of your organization, by performing the tasks described next in "Joining UNIX-based Computers to the Active Directory Domain."

Joining UNIX-based Computers to the Active Directory Domain

[Smaller Organizations Only]

Navigation Note   Perform the tasks described in this subsection only for a smaller organization. If your organization is medium-size or large, skip this subsection.

After installing the VAS components on both Windows-based and UNIX-based computers, you install a license key for VAS and then join the UNIX-based computers to the Active Directory domain, as summarized in Table 2.16.

Table 2.16. Joining UNIX-based Computers to Active Directory

Task

Action

1. Install license key

You can centrally install license information in Active Directory through Group Policy by using vasgpd.

For information about using VGP and configuring the Vintela Licensing Policy, see the VGP Administration Guide provided with the VAS product.

2. Join UNIX-based computers

Join the UNIX-based computers to the Active Directory domain by performing the following series of procedures (provided earlier in this chapter in the subsection "Join the VAS Client to the Active Directory Domain"):

  • To prepare to join VAS clients to Active Directory

  • To synchronize time

  • To join a computer running the VAS client to the Active Directory domain

  • To check the output of vastool join

  • To restart services

Activating VAS

[All Organizations]

Navigation Note   Perform the tasks in this subsection for all organizations.

The final step to deploy VAS is to activate VAS by making the transition from authenticating to the UNIX identity store to Active Directory authentication.

To switch from UNIX-based to Active Directory–based authentication

  • As appropriate , switch off UNIX-based authentication: 

    Delete or disable the appropriate UNIX, Linux, or NIS store:

    • /etc/passwd store. If, currently, UNIX or Linux user and group accounts use /etc/passwd for file-based authentication, delete the local /etc/passwd account on each computer.

      Note   If the /etc/passwd file containing user or group identity information is present on the local computer, Active Directory authentication does not occur even if there is a UNIX-enabled account in Active Directory for the user who logs on to this computer. A local account, if present, takes precedence for all authentication and password operations.

    • NIS store. If, currently, UNIX user and group accounts use a NIS directory store for authentication, either disable NIS for that host or, in a phased migration, disable the specific accounts within NIS for the set of users participating in the migration.

    Do not delete or disable any UNIX identity store:

    • If you plan to continue to use that store for UNIX users who do not have Active Directory accounts.

    • If you plan to perform a phased deployment and you have not yet deployed VAS to certain sets of users.

Stabilize the Production Deployment

Verify that your UNIX-based computers are joined to the Active Directory system and that the UNIX-based computers function correctly.

To check that your deployment is stable

  1. Verify join. Verify that a UNIX-based computer is successfully joined to the Active Directory domain by executing a vastool command that requires Active Directory to be Active:

    # /opt/quest/bin/vastool list users 

    If the computer has been successfully joined to the Active Directory domain, the output from this command lists the UNIX-enabled Active Directory users.

  2. Check log on process:

    Ask a user to log on to a computer. Monitor the logon process to make sure that the logon works and that the user does not experience any difficulty logging on.

  3. Re-do earlier tests. Perform additional tests described earlier in this chapter:

    Refer to the testing guidelines in "Perform Quick Validation Tests" in the section "Developing the VAS Solution," and to the guidelines in "Test the VAS Solution" in the section "Stabilizing Your Test Deployment" earlier in this chapter to perform the tests in the following sections (use the tests that are appropriate for your deployment):

    • Determine Whether VAS Is Operational

    • Authenticate Against Active Directory

    • Confirm That the User Has a Kerberos Ticket

    • Confirm That User Authorization Is Functioning

    • Test New Account Provisioning

    • Test Password Management Policies

In addition, confirm that the UNIX-based computers that now use Active Directory for authentication and authorization do not overload your Active Directory servers.

Deploying Phase Major Milestone: Deployment Complete

After completing the deployment:

  • Obtain final customer approval of the project.

  • Conduct a project review.

  • Conduct a customer satisfaction survey.

  • Continue stabilizing the deployment during this period as you hand over responsibility for ongoing management of the VAS solution to the operations team.

Your deployment of the VAS solution to reach a stable End State 2 state is complete. The project is now ready to be handed off from the project team to the operations and support staff.

Operating the VAS Solution

This section addresses operation of the VAS End State 2 solution after deployment is completed. The completion of the Deploying Phase marks the end of the final phase in the MSF project life-cycle, when the MSF Release Management team hands off the solution to Operations. From this point forward, operations personnel use the principles defined by Microsoft Operations Framework (MOF) to organize and guide their efforts to support the mission-critical interoperability solution. The operations guidelines provided here are organized according to the MOF guidelines described in detail at http://www.microsoft.com/mof.

Introduction and Goals

The operations guidelines provided in this section, which supplement the VAS product documentation listed later under "Knowledge Prerequisites," address two areas:

  • Aspects of the Windows environment that are modified as a result of deploying the VAS solution.

  • Aspects of the deployed solution that are not covered by the product documentation.

Knowledge Prerequisites

Because the staff handling the operational activities of the new interoperability solution might be different from those who handled the Planning, Developing, Stabilizing, and Deploying Phases, they might be unfamiliar with the End State 2 solution-related features of Windows, UNIX, and VAS. Therefore, it is important that they review the background information provided here.

Ensure that the operations team possesses the knowledge requirements stated in “About This Volume” and identified in the “Project Team Skills Template” job aid.

The operations guidelines provided here are organized according to the Microsoft Operations Framework (MOF) guidelines at http://www.microsoft.com/mof.

Operations staff should:

  • Review this chapter—especially Windows and Active Directory–related tasks described earlier in this chapter if they are new to Windows.

  • Take the training described in "Train IT Support Staff" in "Deploying the VAS Solution" earlier in this chapter.

In addition, members of the operations team should review the documentation that comes with the VAS product:

  • The VAS Installation Guide

  • The VAS Administration Guide

  • The VGP Administration Guide

All three guides are also available as downloads on the Quest Software Product page for Vintela at http://www.vintela.com/products/vas/index.php (click the "Documentation" link).

Major Tasks and Deliverables

For the VAS solution, the operations staff manages tasks in the following MOF-defined service management functions (SMFs):

  • Change Management

  • System Administration

  • Security Administration

  • Directory Services Administration

  • Service Desk

  • Capacity Management

This section provides information for each of these SMFs that is relevant to your VAS deployment. For a complete list and detailed description of all MOF SMFs, see the MOF site at http://www.microsoft.com/mof.

Change Management

Quest Software periodically updates the VAS product in both minor and major revisions. Minor revisions, called service packs (SPs), are primarily released to fix errors in the program code. Major releases introduce new features or significantly enhance existing features.

Managing change for your VAS solution includes—but is not restricted to—the synopsis of tasks listed in Table 2.17.

Table 2.17. Tasks to Manage Updating VAS

Task

Action

Test operating system updates

Changes in the UNIX or Linux operating system as a result of operating system patches might affect the VAS solution. Be prepared to test that VAS continues to function correctly after an operating system update or to make adjustments as needed if the patch does affect VAS functionality.

Assess VAS updates

Put in place a formal process to assess new releases of the VAS product in terms of its suitability for redeployment in your organization.

Develop and test VAS updates

It is important that you first develop and test each new release of VAS in a lab environment, using a process similar to that described in "Developing the VAS Solution" earlier in this chapter.

Update VAS Windows components

Update VAS components for Windows as described in "Installing VAS Components for Windows Server 2003" earlier in this chapter.

Update VAS client components

Update VAS components for UNIX clients by using the same package management tools (such as, for example, rpm on the Linux platform) that are available on the various UNIX hosts. See the section "Installing VAS Client Components for UNIX" earlier in this chapter.

Specific per-platform examples of how to update VAS are provided in the VAS Installation Guide provided with the product.

Update deployment script

When you update VAS, you must also update the deployment script.

Update plans and training

After completing each deployment of a new version of VAS:

  • Document any configuration changes for the VAS solution, any issues encountered, and the resolution for each issue.

  • Update your project plans, checklists, and training documentation for IT support staff and for end users.

System Administration

Important issues that you need to understand about system administration when you deploy the VAS End State 2 solution include those listed in Table 2.18.

Table 2.18. Important System Administration Issues for VAS

Issue

Best Practices

Root password

The UNIX root account does not correspond to a person. Instead, it is a generic account with the highest level of privilege.

Recommended practices to manage access to the UNIX root include:

  • Do not store root account in Active Directory. When you deploy the VAS solution, do not include the UNIX root account in Active Directory.

  • Keep root account local. Leave the root account as a local account with a highly complex password.

  • Avoid using su. If administrators are allowed to su (substitute or switch user) directly to root, the ability to audit their actions and clearly identify the actual user invoking the root privilege is lost.

  • Do use sudo. Manage access to root-level functions through a tool such as the UNIX sudo tool (or a commercial equivalent). These types of program allow administrators to define precisely which privileged functions requiring the root account are to be made available to which users. Administrators who use sudo never actually assume the root identity but rather "borrow" it for a specific function. The command itself along with the actual user's identity is logged.

  • Use VGP for sudo. The VAS Group Policy module, VGP, includes policies for managing the sudo application by managing the configuration file, sudoers.conf. For more information about VGP, see the VGP Administration Guide.

DNS

Ensure that the DNS configuration is always capable of resolving the service names needed for accessing the Active Directory Kerberos and LDAP services.

The best and easiest way to do this is to ensure that UNIX hosts use the Windows DNS service that is configured for use with Active Directory.

PAM and keytabs

As new security-aware services are added to VAS-enabled UNIX hosts, system administrators must learn how to configure new service keytabs or new PAM configurations.

You can find information about how to use the vastool command to perform these functions in the VAS Administration Guide provided with the product. Refer to the "vastool Options" section.

Other than system and root accounts, you typically do not need to maintain any user information on a per-host basis because all user identity information is now provided by VAS.

Security Administration

The best way to secure access to a VAS-enabled UNIX-based computer is to use the users.allow and users.deny configuration files that are configured on a per-host basis in the /etc/opt/quest directory.

VAS allows you to specify the Active Directory users that can authenticate to UNIX hosts. The VAS authentication module (pam-_vas and the VAS AIX LAM module) consult users.allow and users.deny. If either of these files exists, the VAS authentication component will use them to determine which users should be allowed to authenticate.

More specific identification of a user always takes precedence. For example, if a user’s Active Directory domain is specified in users.deny, but the user’s User Principal Name (UPN) is specified in users.allow, the user is allowed access. If users.allow exists and is not empty, users must be directly or indirectly granted access or they will be denied access by default. In cases where the same user, group, OU, or Active Directory domain membership is specified in both users.allow and users.deny, the user is denied access.

VAS also has the capability to create service-specific users.allow and user.deny files for any PAM service, such as telnet. You can find details about this functionality in the pam-_vas man page.

In addition, VAS supports the management of users.allow and users.deny in a centralized fashion using Active Directory GPOs. For more information about the VAS VGP, see "Add Group Policy Functionality" later in this chapter).

Directory Services Administration

Directory services administration refers, in part, to managing Windows users in Active Directory. UNIX-enabling Active Directory accounts for UNIX users or groups, which is part of the process of deploying VAS, adds a set of UNIX attributes to the Active Directory user object. Before you can UNIX-enable an account, the Active Directory schema must include UNIX user and group account attributes, including UID, GID, default shell, and home directory attributes.

If your domain controllers run a version of Windows prior to Windows Server 2003 R2, the VAS deployment process includes installing the UNIX schema extensions. If your domain controllers run the R2 version of Windows Server 2003, the schema extensions for UNIX are part of the default schema.

Except for deploying schema definitions (if needed), no VAS code runs on the Active Directory domain controller. Therefore, the only directory services administration issue related to the VAS solution is the requirement that you support the provisioning and management of the additional user attributes. Because VAS uses standard schema definitions to store the UNIX attribute information, managing UNIX attributes is similar to managing Windows attributes.

VAS lets you manage the UNIX attributes of an Active Directory object in two ways:

  • UNIX Account tab. As described in "Extension to the Active Directory Users and Computers Snap-In" earlier in this chapter, you can install the VAS extension to the Active Directory Users and Computers snap-in. This extension adds the UNIX Account tab to the snap-in on any domain controller or on any Windows server or workstation on which Active Directory Users and Computers is installed.

  • vastool. You can run the vastool command from the UNIX command line. You can use vastool to join the computer to the Active Directory domain; to create, modify, or delete users; to set or reset any attribute within Active Directory that the user has privileges to create, modify, or delete; and for other Active Directory–related administrative tasks.

    The vastool command is designed to be used in script development. You can use vastool if you want to develop your own front-end application to manage UNIX user account information.

    The vastool commands include:

    • attrs. Lists Active Directory object attributes.

    • configure. Updates PAM, NSS, and other configuration files.

    • create. Creates a user, group, or computer object in Active Directory.

    • delete. Deletes a user, group, computer object, or any object in Active Directory.

    • flush. Flushes the vasd cache.

    • group. Adds or removes users from Active Directory groups.

    • info. Provides information about host Active Directory configuration.

    • isvas. Checks to see if a given user is an Active Directory user.

    • join. Joins the host to the Active Directory domain.

    • kinit. Obtains Kerberos tickets for services.

    • kdestroy. Destroys all existing tickets in the calling user’s credentials cache.

    • klist. Lists the Kerberos tickets stored in the calling user’s credentials cache.

    • ktutil. Manages entries in a keytab file.

    • license. Shows current license information.

    • list. Lists users and groups in Active Directory with their UNIX account information.

    • load. Imports users and groups into Active Directory from a file that follows either the /etc/passwd or /etc/group format.

    • nss. Performs various NSS functions.

    • passwd. Changes your password, or sets another user's password in Active Directory.

    • schema. Detects or shows the Active Directory schema to be used for storage of VAS attributes (such as UID).

    • search. Performs LDAP searches against Active Directory.

    • service. Manages service accounts in Active Directory.

    • setattrs. Modifies attributes of Active Directory objects.

    • timesync. Queries and synchronizes system time with the Active Directory server or other specified time server.

    • unjoin. Removes the host from the domain.

    • ypcat. Provides functionality similar to the UNIX ypcat command for imported NIS maps (databases): lists the values of all keys in a NIS map specified by mapname.

    • unconfigure. Updates PAM, NSS, and other configuration files so that they will not use VAS components (used, typically, while troubleshooting).

    • unjoin. Configures the system not to use the VAS client for authentication and for NSS, and then removes the computer object from Active Directory.

    • user. User-specific account tools for Active Directory users.

    For detailed information about vastool, see the man page for vastool included with VAS.

In addition, many organizations manage Active Directory objects with their own management and provisioning tools—either third-party applications such as the Quest Software Active Roles Server, or internally developed applications that manipulate Active Directory directly. If you use such tools, you must extend them so that you can use them to manage the UNIX user attributes added to Active Directory accounts.

Best practices for directory services administration are documented in other Microsoft operations guides, including the following:

Service Desk

One of the primary benefits of the VAS product is that it virtually eliminates the need for a separate service desk function for managing UNIX accounts. VAS makes the separate UNIX identity management system redundant by making Active Directory the identity store for both UNIX and Windows accounts.

Using Active Directory and retiring the redundant UNIX identity infrastructure means that the password reset function for UNIX users is the same as the password reset function for Windows users. By resetting the password in Active Directory, service desk personnel simultaneously update the password used for both Windows and UNIX.

VAS also lets you manage group memberships from Active Directory. You must therefore establish new procedures and policies for managing UNIX groups for the service desk personnel responsible for managing UNIX groups. You can, optionally, delegate the management of UNIX groups to a UNIX-specific administration team by creating UNIX-specific groups within an Active Directory OU and granting the UNIX administration team rights to manage that OU.

The VAS UNIX Personality Management (UPM) feature provides additional possibilities, such as delegating management of UNIX user attributes to existing UNIX administrative teams while retaining the control of the password and security principal (the Active Directory account) in another administrative group. 

For more information about the VAS UPM feature, see "Additional VAS Features" in the overview of this chapter; and see "Using UPM to Maintain and Organize Multiple Existing Namespaces" under "Managing Digital Identities" in the section "Deploying the VAS Solution" earlier in this chapter.

Capacity Management

During the Planning Phase, you assessed the potential impact of adding additional users and computers to your Active Directory infrastructure and the increased load this might impose on it. During the Deploying Phase, when VAS is deployed in stages, the Deployment team monitored any potential impact to Active Directory load as part of the stabilization process.

The type of users—for example, whether they are also Windows users or what their usage patterns are—can affect performance. The actual load placed by VAS users is essentially comparable to a corresponding set of Windows hosts and users. If the load is too great, consider adding capacity to your Active Directory infrastructure by upgrading hardware (especially memory) of existing domain controllers, or by adding additional domain controllers.

After the VAS solution is deployed and stabilized, the VAS solution, with its UNIX-based computers and users, typically does not impose any special monitoring requirements beyond the overall health and performance monitoring required for your entire Active Directory infrastructure. Operational measures already in place to monitor the stability and performance of Active Directory should not require any further VAS-specific actions or procedures. Active Directory performance management is outside of the scope of this chapter.

Operations Summary

Your deployment of the VAS solution to reach a stable End State 2 state is now fully operational. The operations and support staff know how to maintain the solution and perform day-to-day tasks.

Evolving the VAS Solution

Now that you have used VAS to deploy your End State 2 solution, you might want to explore expanding your implementation of VAS to take advantage of Active Directory services beyond authenticated logon and authorization.

Introduction and Goals

Implementation of a VAS authentication and authorization solution lets you use a single identity store—Active Directory—for your Windows environment and UNIX-based computers. This solution also provides users of UNIX-based workstations and servers with a Kerberos credential for authenticating to other services configured in the Active Directory domain.

Two related directions for evolving this solution are:

  • Increasing the integration and coordination of all aspects of identity management within your organization.

  • Building on the shared Kerberos infrastructure that is now in place for your Windows-based and UNIX-based computers to use.

Both of these efforts support the development of an identity and authentication infrastructure that is more secure, easier to manage, and more convenient for the user.

These following topics describe these efforts in detail:

  • Determine your next steps

  • Integrate with provisioning systems

  • Normalize UID and GID usage (if not done earlier)

  • Make applications PAM-aware

  • Expand your single sign-on capabilities

  • Add VAS authentication proxy for LDAP

  • Add privilege and access control

  • Add Group Policy functionality

  • Manage legacy NIS maps

Determine Your Next Steps

The focus of future development of your VAS solution will be motivated, in large part, by the same considerations that initially justified the Windows-to-UNIX interoperability project as well as by your operational experience in this new environment. Logical next steps to consider consist of expanding the integration at all levels of your infrastructure by including application-level authentication so that all identities are coordinated through Active Directory.

You might also choose to take advantage of other features provided by the VAS solution, such as support for Active Directory Group Policy objects (GPOs) or NIS integration.

If your infrastructure includes applications and services hosted on Java application servers, Quest has a complementary product, Vintela Single Sign-on for Java (VSJ). VSJ provides a facility similar to VAS for Java environments, allowing users to authenticate to J2EE application servers with Kerberos credentials acquired from Active Directory by using SPNEGO SSO, without requiring any user name/password authentication.

Note   SPNEGO stands for Simple and Protected GSS-API Negotiation Mechanism. GSS-API stands for Generic Security Service Application Programming Interface. Microsoft applications such as Internet Explorer and the Internet Information Services (IIS) Web server use SPNEGO for Kerberos-based user authentication and thus provide a single sign-on capability. On the Windows platform this is referred to as "Integrated Windows Authentication." For more information about SPNEGO and GSS-API, see "Kerberized Applications" later in this section.

VAS also provides a software development kit (SDK) that allows you to customize applications to support the VAS authentication interfaces, including PAM and SPNEGO. The SDK provides direct access to Kerberos and LDAP interfaces through VAS.

Some applications do not support PAM, are not Java-based or Web-based, and cannot be directly modified. These applications have authentication built into the application itself. To integrate this collection of applications into an Active Directory–centered identity management scheme, in the near term, you must implement a solution such as a metadirectory. A metadirectory enables the synchronization of identity data between one or more directory services and databases. One example of a metadirectory is Microsoft Identity Integration Server (MIIS). In this approach, the metadirectory is a bridge to Active Directory, which functions as the authoritative single store.

Ideally, for many organizations, the long-term goal is to move all applications away from a metadirectory requirement and toward a fully integrated Kerberos-aware and PAM-aware identity management solution.

Integrate with Provisioning Systems

After VAS is deployed, UNIX attribute information is stored as part of the Windows user or group object in Active Directory. This means that integrating UNIX accounts with your Windows provisioning system is just a matter of provisioning the additional attributes as part of the Windows provisioning workflow.

Because VAS uses the RFC 2307 standard schema attributes to store UNIX attribute information, it is easy to provision UNIX attributes by making relatively simple modifications to the configuration of your provisioning system. Some applications, such as the Quest' Active Roles Server, provide extensions for managing the UNIX attributes. It is also simple to extend the Active Directory Management Agent in MIIS to populate the UNIX attributes as part of user provisioning through MIIS by populating the additional attribute fields as appropriate.

Normalize UID and GID Usage

If UNIX UIDs and GIDs were not rationalized as part of the process of preparing for and deploying the VAS solution in your production environment, you might want to perform rationalization as part of evolving the solution to a more secure state.

During the initial deployment of the VAS solution, some organizations might have chosen to defer rationalization of UIDs and GIDs by using the VAS UPM feature. You can use UPM to manage multiple "personalities" (alternative identities) that the user can assume that enables the user to log on to different UNIX-based computers with a single Active Directory user account and a single password. However, best practices for security prescribe that each person (security principal) should have exactly one identity (UID) throughout the entire organization.

For more information about the VAS UPM feature, see "Additional VAS Features" in the overview of this chapter; and see "Using UPM to Maintain and Organize Multiple Existing Namespaces" under "Managing Digital Identities" in the section "Deploying the VAS Solution" earlier in this chapter.

Make Applications PAM-Aware

To achieve the primary benefit of VAS integration—unification of the user names and passwords associated with an individual’s digital identity—it is necessary for any application that you want to be able to automatically use the VAS software to be designed with, or modified to support, PAM.

Most modern system-level applications (such as telnet, ssh, or ftp) on most platforms already support PAM. Other applications, such as sudo, have added support for PAM recently. In many cases, you might need to acquire a more recent version of a given platform that has built-in PAM support.

The Quest Resource Central site for Vintela products (located at http://rc.vintela.com) includes notes and patches about VAS-aware versions of applications. For example, a technical article about using a PAM authentication module for the Apache Web server is available for download at this site. Resource Central is updated periodically with new information and resources for VAS support.

For more information about PAM, see Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization."

Expand Your Single Sign-on Capabilities

This section includes information about expanding your single sign-on capabilities by using Kerberos-aware, or Kerberized, applications, and about Kerberizing your existing applications.

Kerberized Applications

If you want to provide a network environment that enables users to take advantage of the fact that they automatically acquire a Kerberos ticket when they log on to their computers, you must make sure that the applications or services that users access are Kerberized.

A Kerberized service is an application that requires authentication (such as telnet, ssh, or ftp) and that has been enhanced to accept Kerberos credentials that are presented to it using a known protocol such as GSS-API. Kerberized clients are the corresponding client programs that likewise have been modified to retrieve the user’s Kerberos credentials from a local cache and to initiate a session with the service by transmitting, in an agreed-upon format, the Kerberos ticket. The service is capable of validating the user’s ticket because it has been encrypted using a "shared secret" that the Kerberos KDC and the service both know. If the service determines that the ticket is valid, the client is accepted as belonging to the user identified in the ticket, and the service grants whatever access that user is authorized to have.

Different conventions and protocols exist for forwarding Kerberos tickets. Two standards have emerged that enable client and service applications to interoperate: GSS-API and SPNEGO.

GSS-API is a set of library functions that provides a standard authentication programming interface, allowing application developers to support specialized authentication without requiring knowledge of implementation specifics. Most applications that support GSS-API also support Kerberos. On the Windows platform, Security Support Provider Interface (SSPI) is a comparable set of interfaces that can be made to interoperate at the network level. Applications that agree on using Kerberos can use GSS-API to implement the exchange of credentials.

The most important GSS-API–aware application that almost all organizations that have deployed VAS will want to deploy is the openssh implementation of ssh for VAS found at the Quest Resource Central site for Vintela products at http://rc.vintela.com. The openssh service enables single sign-on between UNIX hosts that are joined to the Active Directory domain, which means that the user on one host can access an application on the other host.

A GSS-API version of PuTTY, the ssh-enabled terminal emulation program, is also available at Resource Central. PuTTY allows a Windows user to log on automatically to a UNIX shell by using the Kerberos credential acquired during Active Directory logon to the Windows desktop.

SPNEGO is a mechanism for negotiating which protocol to use. SPNEGO is supported by Microsoft Exchange, SQL Server™, Server Message Block (SMB), Internet Explorer, and IIS. It allows users to use their Kerberos credentials to authenticate transparently to these applications. An Apache plug-in, mod_auth_vas, available on Resource Central, provides the capability to achieve single sign-on ("Integrated Windows Authentication") when using Internet Explorer and VAS-enabled UNIX Apache Web applications.

A number of applications are available with different levels of support for these protocols. Quest maintains a repository of VAS-enabled Kerberized tools at their Resource Central Web site at http://rc.vintela.com.

Finally, many third-party applications—for example, SAP R/3—provide support for Kerberos or GSS-API. You can also configure these applications to support single sign-on from the Windows desktop.

As mentioned earlier, for Java application servers, the Quest companion product, VSJ, provides a similar, SPNEGO-based single sign-on for Apache Tomcat and Java 2 Platform, Enterprise Edition (J2EE) application servers.

Kerberize Your Applications

The software development kit (SDK) included in VAS 3.0 supports C language header files that allow application developers to link directly to the libvas library. The libvas library provides most of the standard Kerberos and LDAP functions, as well as GSS-API functions, all integrated with the VAS environment so that no additional application configuration is required.

Example applications using the VAS SDK are available at the Quest Resource Central for Vintela products Web site at http://rc.vintela.com. Most of the VAS-integrated applications, such as openssh and mod_auth_vas, are provided with source code that illustrates using the VAS interfaces from an application.

Add VAS Authentication Proxy for LDAP

The VAS authentication proxy is another useful VAS tool for securely integrating with Active Directory the existing LDAP-aware applications that run on UNIX servers. The LDAP proxy is installed on the VAS-enabled application server, which is then configured to use localhost (127.0.0.1) to securely access LDAP services.

When an application makes the call to do an LDAP bind with a user name and password entered by the user within the application, the LDAP proxy accepts the bind request and converts it to a Kerberos authentication request. The Kerberos authentication request is communicated securely, as are all VAS transactions with Active Directory. If the user can successfully authenticate to Kerberos with the user name and password provided in the bind call, the bind call succeeds.

All LDAP requests other than the bind request are forwarded securely to Active Directory for processing and returned to the application.

In this way, an application running on a UNIX-based server that can be configured to use LDAP for authentication, but not to use Kerberos directly, can still easily and securely benefit by using the same Windows user name and password credential. This eliminates the need to maintain or synchronize a secondary identity system for the application.

Add Privilege and Access Control

Your existing infrastructure might already have fine-grained access control or privilege control mechanisms in place, or you might choose to add these as you assess your total identity and security requirements. Open source applications such as sudo allow UNIX users to be granted limited root-account privileges for role-specific tasks. Third-party access control applications are also available.

For information about how to use sudo with VAS, see "Using VAS and SUDO to manage administrative (root) access to UNIX systems" at http://rc.vintela.com/topics/sudo.

Add Group Policy Functionality

One of the new features introduced with VAS 3.0 is Vintela Group Policy (VGP), which lets you add Group Policy objects for UNIX to Active Directory. This feature allows you to create and store policies for Linux and UNIX computers that control various UNIX configuration files. VGP has a broader scope than just managing digital identities, but it is also useful for this purpose. Because VGP can centrally manage Linux or UNIX configuration files, it is useful for:

  • Centralizing control of authorization-related files, such as the VAS users.allow and users.deny files that control access per-host.

  • Managing the sudoers.conf configuration file, if you use sudo for fine-grain control of root privileges.

The VAS VGP module, formerly a separate product, is now included with VAS. Installation and configuration of the VGP module is optional. However, it provides a set of policies for managing VAS licensing, configuration, and access control that makes it valuable for every VAS deployment.

For more information about VGP, see the VGP Administration Guide, available on the Quest Software Product page for Vintela at http://www.vintela.com/products/vas/index.php (click the Documentation link).

Manage Legacy NIS Maps

You can also use Active Directory to store legacy NIS information. Typically, for management and security reasons, you should migrate digital identities from NIS into Active Directory and then retire the NIS infrastructure. However, NIS can store network information other than digital identities (such as printers or file shares). Using NIS to store this type of information does not have the same security risks as does using NIS to store digital identities. Therefore, you might want to migrate these NIS maps into Active Directory.

Schema extensions and migration tools included with VAS support storing legacy NIS information in Active Directory.

In addition, some legacy applications require the use of NIS for authentication. For these applications, the vasypserv daemon (the VAS NIS proxy) functions as a local NIS server that can be accessed securely on a given host but which uses the secure VAS infrastructure to communicate directly with Active Directory.

Often, organizations want to retire their existing NIS infrastructure entirely as part of their identity integration strategy. However, you must continue to support NIS maps that store non-account information. The VAS NIS proxy supports storing NIS maps in Active Directory.

Approaches to retiring the NIS infrastructure include:

  • Migrate your NIS maps into Active Directory and then access them via LDAP. In this case, you are no longer using NIS as a system but you are still using NIS data. This is a good long-term solution.

  • Use the VAS NIS proxy. In this case, you have client processes (that is, applications that act as NIS clients) that need to communicate with a NIS server. You let the client processes communicate with the NIS proxy instead of with a real NIS server. As in the preceding approach, you continue to store NIS data. This is a reasonable short-term solution when you expect that these applications will no longer require NIS in the future.

Download

Get the Windows Security and Directory Services for UNIX Guide

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft