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

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

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 https://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

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."

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.

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:

• Microsoft Solutions Framework (MSF). Available at https://www.microsoft.com/technet/itsolutions/msf/default.mspx, MSF provides the methodology for the development, test, and deployment sections of this chapter.

• Microsoft Operations Framework (MOF). Available at https://www.microsoft.com/mof, MOF provides the methodology for the operations section of this chapter.

• UNIX Migration Project Guide (UMPG). Available at https://go.microsoft.com/fwlink/?LinkId=20012, the UMPG provides "people and process" guidance for MSF projects.

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

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 https://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.

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 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

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

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

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.

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.

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.

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.

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.

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.

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.

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 https://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 https://go.microsoft.com/fwlink/?LinkId=45677.

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.

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.

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.

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

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.

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.

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

• Develop the solution components.

• Perform quick validation tests.

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.

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.

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?

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

   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.

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.

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.

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.

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

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.

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.

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

      Expand table

      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.

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.

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.

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 https://www.vintela.com.

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

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 https://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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

The major Stabilizing Phase tasks are:

• Test the VAS solution.

• Resolve issues.

• Conduct a pilot deployment.

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.

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 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."

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.

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.

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.

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 https://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.

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.

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.

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.

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
   

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

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.

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

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.

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 https://www.vintela.com/products/vas/index.php (click the "Documentation" link).

Table 2.8. Checklist of Tasks to Perform a Pilot Deployment

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.

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.

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 https://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.

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.

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

• Complete deployment preparations.

• Deploy VAS.

• Stabilize the production deployment.

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

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

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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

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

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

Table 2.13. Providing Information to End Users

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."

[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

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

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."

[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

[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.

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.

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.

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 https://www.microsoft.com/mof.

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.

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 https://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 https://www.vintela.com/products/vas/index.php (click the "Documentation" link).

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 https://www.microsoft.com/mof.

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

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

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.

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 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:

• Active Directory Operations Topics, available from the Windows Server 2003 Operations page at https://go.microsoft.com/fwlink/?LinkId=39226 by clicking Active Directory (which opens the Active Directory Operations Topics page).

• Active Directory Operations Guide at https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/9c6e4dd4-3877-4100-a8e2-5c60c5e19bb0.mspx.

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.

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.

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.

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.

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

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.

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.

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.

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 https://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."

This section includes information about expanding your single sign-on capabilities by using Kerberos-aware, or Kerberized, applications, and about Kerberizing your existing 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 https://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 https://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.

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 https://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.

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.

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 https://rc.vintela.com/topics/sudo.

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 https://www.vintela.com/products/vas/index.php (click the Documentation link).

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