VAS 2.

6
ADMINISTRATION GUIDE

SEPTEMBER 2004
Copyright
c 2003, 2004 Vintela, Inc. All Rights Reserved.
Legal Notice
Vintela documents are protected by the copyright laws of the United States and International
Treaties.
P ERMISSION TO COPY, VIEW, AND PRINT V INTELA DOCUMENTS IS AUTHORIZED PROVIDED
THAT:

1. It is used for non-commercial and information purposes.

2. It is not modified.
3. The above copyright notice and this permission notice is contained in each Vintela
document.
Notwithstanding the above, nothing contained herein shall be construed as conferring any
right or license under the copyright of Vintela, Inc.
RESTRICTED RIGHTS LEGEND
When licensed to a U.S., State, or Local Government, all Software produced by Vintela is
commercial computer software as defined in FAR 12.212, and has been developed exclusively
at private expense. All technical data, or Vintela commercial computer
software/documentation is subject to the provisions of FAR 12.211 - Technical Data , and FAR
12.212 - Computer Software respectively, or clauses providing Vintela equivalent protections
in DFARS or other agency specific regulations. Manufacturer: Vintela Inc., 333 South 520 West,
Lindon, Utah 84042.
DISCLAIMER
THE VINTELA DOCUMENTS ARE PROVIDED AS IS AND MAY INCLUDE TECHNICAL
INACCURACIES OR TYPOGRAPHICAL ERRORS. VINTELA, INC. RESERVES THE RIGHT
TO ADD, DELETE, CHANGE OR MODIFY THE VINTELA DOCUMENTS AT ANY TIME
WITHOUT NOTICE. THE DOCUMENTS ARE FOR INFORMATION ONLY. VINTELA
MAKES NO EXPRESS OR IMPLIED REPRESENTATIONS OR WARRANTIES OF ANY KIND.
TRADEMARKS
Vintela and the Vintela logo are trademarks or registered trademarks of Vintela, Inc. in the
U.S.A. and other countries. Linux is a registered trademark of Linus Torvalds. UNIX is a
registered trademark of The Open Group in the United States and other countries. Microsoft,
Windows 2000, Windows 2003, Windows XP, and Active Directory are either registered
trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries. All
other brand and product names are trademarks or registered marks of the respective owners.
CONTENTS

PREFACE 6

1 INTRODUCTION 8
1.1 What is VAS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 VAS Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 VAS COMPONENTS 11
2.1 Active Directory Schema Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Active Directory Schema Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2 Supported Schema Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3 The VAS Schema Extension Utility . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.4 Global Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 The Display Specifier Registration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 The VAS Administrative Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 The VAS Configuration Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Conflict Detection Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Preferred DC Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 Custom Schema Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.4 Logging Options Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 The pam vas PAM module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 PAM Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.2 pam vas Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 The nss vas NSS module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.1 NSS Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.2 nss vas Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7 The vascd daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 The vastool command line utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.9 The VAS Loadable Authentication Module for AIX . . . . . . . . . . . . . . . . . . . . 22
2.9.1 AIX LAM Module Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9.2 The VAS LAM module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 UNIX HOSTS IN ACTIVE DIRECTORY 24

3.1 Kerberos and Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 Kerberos Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.2 Kerberos and Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.3 Multiple Domain Environments . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.4 Active Directory Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2
 3.2 Joining the Active Directory Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Domain, Site, and Service Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Computer Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.1 Creating Computer Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.2 Deleting Computer Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.3 Moving Computer Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.4 VAS Keytab Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.5 Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 NSS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6.1 The NSS Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6.2 Modifying the NSS configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.3 Restarting services when the NSS configuration changes . . . . . . . . . . . . 32
3.6.4 Using nscd With VAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.5 Advanced nss vas Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 PAM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7.1 The PAM Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7.2 Using vastool to modify PAM configuration . . . . . . . . . . . . . . . . . . . 34
3.7.3 Restarting services for PAM configuration changes . . . . . . . . . . . . . . . 35
3.7.4 Advanced pam vas Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7.5 Debugging PAM Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.8 AIX Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.8.1 AIX Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.8.2 Account Information Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.8.3 Authentication Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.9 The vascd Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.9.1 The vascd Data Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.9.2 Disconnected Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 UNIX USERS AND GROUPS 41

4.1 User and Group Schema Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1 Configuring Schema Mappings for the Vintela Authentication Services Snapin 41
4.1.2 Configuring Schema Mappings for the Vintela Authentication Services Unix
client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Managing Unix User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.1 Using the VAS Administrative Tools . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.2 Managing User Accounts from the Unix Command Line . . . . . . . . . . . . 45
4.2.3 Moving Users in Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.4 Disabling Unix User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Managing Unix Group Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1 Using the VAS Administrative Tools . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.2 Managing Active Directory Groups from the Unix Command Line . . . . . . 49
4.3.3 Moving Groups in Active Directory . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.4 Active Directory Group Types and Scopes . . . . . . . . . . . . . . . . . . . . 50
4.3.5 Nested Group Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4 UID and GID Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.1 UID/GID Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.2 Avoiding Duplications with Local Accounts . . . . . . . . . . . . . . . . . . . 53

3
 4.4.3 Detecting ID Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.4 Overriding Unix Account Information . . . . . . . . . . . . . . . . . . . . . . . 53
4.5 Password Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5.1 Windows Domain Password Policies . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5.2 Changing Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5.3 Password Expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.6 Account Management in Multiple Domain Environments . . . . . . . . . . . . . . . . 56
4.6.1 Using an Alternate Default Account Domain . . . . . . . . . . . . . . . . . . . 56
4.6.2 Cross Domain Logon with Simple Name . . . . . . . . . . . . . . . . . . . . . 56
4.6.3 Minimizing the Size of the User Cache . . . . . . . . . . . . . . . . . . . . . . . 57
4.7 Workstation Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5 NIS COMPATIBILITY 60
5.1 A Brief NIS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2 The VAS NIS Support Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.1 The VAS NIS Schema Extension . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.2 The VAS MMC NIS Map Snapin . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.3 The vasypserv Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Windows Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.1 Installing the VAS NIS Schema Extension . . . . . . . . . . . . . . . . . . . . . 62
5.3.2 Installing the VAS NIS MMC Snapin Extension . . . . . . . . . . . . . . . . . . 62
5.4 Managing NIS Map Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4.1 Creating NIS Map Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4.2 Managing NIS Map Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4.3 Managing NIS Map Database Configuration . . . . . . . . . . . . . . . . . . . 64
5.4.4 Example: Configuring a hosts NIS Map . . . . . . . . . . . . . . . . . . . . . . 65
5.5 Unix Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5.1 Linux VAS NIS Client Installation and Configuration . . . . . . . . . . . . . . 66
5.5.2 Solaris VAS NIS Client Installation and Configuration . . . . . . . . . . . . . . 68
5.5.3 HP-UX VAS NIS Client Installation and Configuration . . . . . . . . . . . . . 69
5.5.4 AIX VAS NIS Client Installation and Configuration . . . . . . . . . . . . . . . 70
5.5.5 NIS Map Search Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.6 Writing custom NIS Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6 MIGRATION 72
6.1 Importing Users and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2 Migration from NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.2.1 Migrating NIS User and Group Information . . . . . . . . . . . . . . . . . . . 74
6.2.2 Migrating NIS Map Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3 Migration from MIT Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3.1 Keytabs and the krb5.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3.2 User and Group migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

A VAS TROUBLESHOOTING GUIDE 77

A.1 Troubleshooting the Unix Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.1.1 Attribute Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

B UNIX PLATFORM LIMITATIONS 79

B.1 General UNIX limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4
 B.1.1 Group Membership Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.2 AIX Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.2.1 User and Group Name Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.3 HPUX Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
B.3.1 User Name Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
B.3.2 UID and GID Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
B.3.3 Authentication Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
B.4 Solaris Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
B.4.1 UID and GID Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

C VASTOOL MAN PAGE 82

D VASCD MAN PAGE 103

E PAM VAS MAN PAGE 114

F NSS VAS MAN PAGE 123

G VASYPSERV MAN PAGE 126

5
PREFACE

Why VAS?

System administrators today must support heterogeneous platforms and applications for their
users’ business needs and requirements. When providing users with the best network
accessibility and state of the art applications, system administrators are left with an integration
and security nightmare.
Critical to the security of any network is the authentication and verification of user identities.
Adopting Microsoft Active Directory solves some issues with authentication and identity
management. However, this introduces significant problems for the organization that
additionally runs business-critical applications on Unix and Linux platforms. When system
administrators maintain multiple user authentication systems, users must often remember
multiple passwords. System administrators might be clever enough to devise script-based
password synchronization tools but this solution can become hard to support, maintain, and train
additional staff to use.
Vintela Authentication Services (VAS) provides the solution for integrating Unix and Linux
systems with Active Directory. It supplies the discipline and controls necessary to ensure the
security and integrity demanded in business environments.
VAS allows administrators to provide a secure environment where users have the same user
name and password for Windows, Unix, and Linux logins without having to maintain password
synchronizers or perform user administration tasks on multiple systems. VAS users can log in
and authenticate to Active Directory from their Unix servers and workstations the same way they
do from Windows XP and Windows 2000/2003. VAS makes it possible to manage all users from
within the standard Active Directory management environment.

Audience and Scope

This guide is intended for Windows, UNIX, and Linux system administrators who will be
deploying VAS and are interested in the following:
• More detailed explanations of how the VAS client components work
• Detailed explanations of how VAS works in multiple domain environments
• Detailed explanations of how VAS works with Active Directory Sites
• How to migrate existing Unix users and groups into Active Directory

6
For information on basic installation and configuration of Active Directory and the VAS client,
refer to the Installation and Configuration Guide.

Conventions Used in this Guide

The following notation conventions are used throughout this guide:

• Directories and filenames appear in mono font. For example, /etc/pam.conf.
• Executable names are bolded. For example, vascd.
• Specific file and packaging formats appear in bold. For example, the RPM package.
• Shell commands appear in mono font. For example,
# vastool configure pam
Within text, commands are bolded for readability. For example, using vastool you can
create users, delete users, and list user information.
• Menu items and buttons appear in bold. For example, click Next.
• Selecting a menu item is indicated as follows: Programs -> Administrative Tools -> VAS
->Active Directory Users and Computers
VAS supports a number of different implementations of UNIX R that include Solaris ,
R HP-UX ,
R
Linux , and AIX . To refer to all of these platforms, the term ”Unix” will be used for
R R
conciseness and consistency.

7
Chapter 1

INTRODUCTION

1.1 What is VAS?

Vintela Authentication Services (VAS) unifies Windows, Unix and Linux authentication and
identity management so that regardless of which platform you want to access, you can log in
using your Windows Active Directory user name and password. The VAS product securely and
conveniently eliminates the need for manual ”per-system” identity administration, User and
Group NIS maps, and password synchronization scripting.
Above all, VAS eliminates the need to layer third-party software on top of the critical security
components of Windows 2000/2003. Instead, VAS provides fully compatible client libraries and
utilities that transparently and securely redirect the core Unix authentication and identity
management functionality to Windows domain controllers using interoperable protocols (such as
Kerberos v5 and LDAP).
Other identity management solutions layer additional software on top of Active Directory or
replace it altogether. In either case, solutions that interrupt the core Windows 2000/2003 services
to provide a gateway for Unix interoperability, add to the Windows management complexity and
create dangerous security vulnerabilities that affect overall enterprise security and stability.
Figure 1.1 shows how a user named JD with a password of Hockey logs into a Unix or Linux
system while authenticating against Active Directory. The core protocol interaction between the
Windows domain controller and the Unix/Linux system is the same as that of a Windows XP
client. JD can now use the same user name and password to log into either the Windows or Unix
systems.

1.2 VAS Features and Benefits

Deploying VAS provides the following features and benefits:

True Integration with Active Directory. Active Directory users can authenticate to Unix
resources and Active Directory groups can be used to provide access control to Unix
resources. No password or account synchronization is used. All Unix authentication
identity management features operate in real time with changes made by administrators on
Windows domain controllers.

8
 Figure 1.1. User authentication against Active Directory from both Windows and Unix.

All Authentication Uses Kerberos. VAS uses Kerberos v5, which is the native authentication
protocol for Windows 2000 and Windows 2003. The use of Kerberos eliminates the need to
send passwords or password hashes over the network in plain text. All password change
requests are performed using Kerberos, and enforce Windows password policies
established by the domain administrator. Using Kerberos also eliminates the need for the
distribution of SSL certificates to Unix clients and modifying Active Directory to use SSL for
LDAP security. All VAS LDAP communication is secured using Kerberos. Finally, VAS
maintains compatibility with MIT-style Kerberos implementations and can be used with
Unix applications that link with 3rd party Kerberos libraries.

A Persistent Client Cache. VAS is a scalable product that uses a persistent client side storage to
cache frequently accessed user account information. Intelligent caching algorithms allow
VAS to limit the amount of network traffic it uses and simplifies the complexity of LDAP
searches for Active Directory. This design also allows for hundreds of concurrent Unix
processes to authenticate and resolve Unix account information (UID, GID, etc) without
overloading the Active Directory server with search requests. The persistent cache also
allows VAS to be configured to continue working even when it loses contact with the Active
Directory server. The option to use disconnected operation make VAS an ideal solution for
mobile Unix/Linux users or in environments here dial-up networking is used.

Simple Deployment. VAS is packaged using the native package formats for each supported
Unix platform. Native packaging makes it easy for Unix administrators to install and
manage their VAS installations using existing software administration tools. VAS also

9
 provides easy-to-use command line utilities such as vastool join and vastool timesync to
automate complex configuration tasks like PAM configuration and time synchronization.
VAS product installation and configuration only takes a few minutes and does not require
in-depth knowledge of Kerberos, LDAP, or Unix authentication and identity subsystems.

Integration with existing Unix utilities and applications. VAS has been designed to seamlessly
integrate with the core Unix authentication subsystems (PAM and NSS) so that existing
applications can take advantage of Active Directory integration without any modifications.
For example, Apache, OpenSSH, telnet, and ftp all easily integrate with VAS and can
authenticate Active Directory users immediately after the installation and configuration of
VAS.

10
Chapter 2

VAS COMPONENTS

This chapter provides a detailed explanation of the following VAS software components:
• The Active Directory Schema Extension. See Section 2.1
• The Display Specifier Registration Wizard. See Section 2.2
• The VAS Configuration Utility. See Section 2.4
• The VAS Administrative Tools. See Section 2.3
• The vascd daemon See Section 2.7
• The pam vas PAM module See Section 2.5
• The nss vas NSS module. See Section 2.6
• The vastool command line utility. See Section 2.8
• The VAS Loadable Authentication Module for AIX. See Section 2.9
A graphical depiction of an Active Directory domain and the VAS components is shown in Figure
2.1

2.1 Active Directory Schema Extension

2.1.1 Active Directory Schema Concepts

The Active Directory schema defines what type of classes can be created and what attributes
those classes can have in the directory. The base schema that is included when Active Directory is
installed contains class and attribute definitions that are required by core Microsoft applications.
However, to accommodate a wide range of applications, Microsoft Active Directory is designed
to allow schema extensions so that additional class types and attributes can be stored in the
directory.
Extending the Active Directory Schema is a procedure commonly performed when installing
directory enabled software that requires Active Directory to store types of information not
provided for in the default Windows schema. In the case of VAS, the default Active Directory
schema does not contain any provisions for the storage of Unix user and group account
information. In order for VAS to work, the Active Directory schema must be extended to allow
storage of Unix and group identity information such as UID, GID, home directory, login shell, etc.

11
 Figure 2.1. The VAS components working with Active Directory

2.1.2 Supported Schema Extensions

In order to be as flexible as possible, VAS was designed to be compatible with multiple schemas.
Supporting multiple schemas allows VAS to work in environments where the Active Directory
schema might have already been extended for use with other products or experimental software.
VAS is fully compatible with the following schema extensions:
• The experimental RFC 2307 Schema recommendation
• The VAS Schema Extension
• The Microsoft SFU 3.0 Schema
• The Microsoft SFU 2.0 Schema

2.1.2.1 The experimental RFC 2307 Schema recommendation

RFC 2307 is a document that describes ”An Approach for Using LDAP as a Network Information
Service”. The significance of RFC 2307 is that it introduces LDAP attributes that can be used to
store Unix user and group account information. RFC 2307 is an experimental recommendation
that has not yet been standardized by the IETF.

2.1.2.2 The VAS Schema Extension

The VAS Schema Extension follows the recommendations from RFC 2307 for the attributes used
to store Unix user and group account information. The VAS Schema Extension differs from RFC

12
2307 in that it does not include the entire experimental RFC 2307 schema extension.
Since VAS uses the Kerberos protocol for authentication and enforcing typical Unix ”shadow”
functionality, the RFC 2307 suggestion for the storage of ”shadow password” information and
crypted/hashed password attributes in Active Directory is not used. Use of these attributes
would duplicate functionality already accessible via the Kerberos protocol and would introduce
significant security holes by making sensitive information accessible to anonymous or insecure
users.
The VAS Schema Extension also omits RFC 2307’s NIS Map specific attributes for storage of hosts,
services, networks, etc. These attributes are unrelated to VAS’s authentication and identity
management solution. For more information on the VAS NIS compatibility features, see Chapter
5, NIS Compatibility.

2.1.2.3 The Microsoft SFU 3.0 Schema

The SFU 3.0 schema provides attribute and class definitions to store Unix account information for
users and groups. The VAS client will automatically detect this schema extension, and will be
able to use the users and groups that have already been configured in Active Directory for use
with SFU. You will not need to install any Windows components in this scenario or further extend
the Active Directory schema.
The VAS Windows Administrative Tools can be used with the SFU schema. The SFU schema will
be detected automatically by the VAS MMC extensions and the VAS Unix client during
installation and configuration. When the VAS components detect SFU, they will default to use the
following attributes for Unix account information: msSFU30UidNumber, msSFU30GidNumber,
msSFU30Gecos, msSFU30HomeDirectory, and msSFU30LoginShell.
SFU also defines two new attributes for group membership, analogous to the member and
memberOf attributes: msSFU30PosixMember and msSFU30PosixMemberOf. The SFU Snapin
also provides a gui for managing the duplicate SFU group membership lists. This forces you to
manage duplicate group membership lists for every Unix enabled group in Active Directory. This
can be very error prone and time consuming. It also makes the PAC information in Kerberos
tickets issued by Active Directory inaccurate since the PAC will not contain information about the
SFU group membership lists.
For these reasons, the Vintela Authentication Services components will not use the SFU group
attributes for group membership information by default. Instead, the Vintela Authentication
Services schema detection routines will use the SFU attributes for Unix account information and
the standard Active Directory attributes member and memberOf. It is possible to override this
behavior and use the SFU group membership attributes if desired by using the schema mapping
techniques for the Vintela Authentication Services Snapin and the Vintela Authentication Services
Unix client described in Section 4.1.
SFU installs an MMC property extension tab called UNIX Attributes which manages the same
attributes as the VAS Unix Account tab. In some cases, this can cause confusion since both tabs
modify the same attributes. To disable the SFU tab, rename the file nisprop.dll to nisprop.
dll.old. This file is located in the [SFU Installation Path]\common folder.

13
2.1.2.4 The Microsoft SFU 2.0 Schema

The SFU 2.0 schema provides the same functionality as the SFU 3.0 schema, with some differences
in attribute names. The VAS client and Windows Administrative Tools can operate with SFU 2.0
the same way as with SFU 3.0.

2.1.3 The VAS Schema Extension Utility

VAS provides a general use schema extension utility that allows the administrator to install the
VAS schema extensions on the Schema Master domain controller. The VAS Schema Extension
Utility is located on the VAS installation media in the schema/ directory.. For a complete
description of how to extend the Active Directory schema, see the VAS Installation and
Configuration Guide.

2.1.4 Global Catalog

The Windows Global Catalog is a database that contains a record of every object in the Active
Directory forest. Each object in the Global Catalog only contains those attributes that have been
enabled for Global Catalog storage. Windows requires that at least one domain controller in each
domain act as a Global Catalog server.
In order for VAS to efficiently support Active Directory environments where users’ login suffix
does not match the domain they belong too, VAS uses the Global Catalog to resolve a user’s
location in the Forest. Once it has been determined what domain a user belongs to, then the
user’s Unix account information is obtained from a domain controller in the domain the user
belongs to. If the VAS related attributes for user and group Unix account information is added to
the Global Catalog, then the second LDAP search against the domain controller can be
eliminated. This provides enhanced performance during login. Having the VAS attributes in the
Global Catalog also provides enhanced performance during cross domain logins as well.
The VAS schema extender provides a mechanism for adding the default VAS attributes to the
Global Catalog. For information on adding attributes to the Global Catalog when not using the
default VAS schema extensions, refer to your Active Directory documentation.
Again, this only applies to environments where there is not a direct mapping between a user’s
login suffix in their userPrincipalName and the domain they belong to. If your environment uses
only one domain for all user accounts and the vast majority of the user accounts have the logon
suffix in the userPrincipalName is set to that domain, then adding the VAS attributes to the
Global Catalog is unnecessary.

2.2 The Display Specifier Registration Wizard

In order for the Active Directory user interface extensions installed by the VAS Administrative
Tools (see Section 2.3) to be displayed in administration consoles such as Active Directory Users
and Computers Snapin, the VAS Administrative Tools must be registered with Active Directory.
This is accomplished by configuring ”display specifier” objects in Active Directory. The VAS
Display Specifier Registration Wizard is provided for this purpose. The Display Specifier

14
Registration Wizard must be run at least once. For more information on using the display
registration wizard, refer to the VAS Installation Guide.

2.3 The VAS Administrative Tools

The VAS Administrative Tools consist of a set of user interface extensions to Active Directory
user, group, and NIS Map object classes that are usable within the Microsoft Management
Console framework. When the VAS Administrative Tools are installed and configured, the Active
Directory Users and Computers Snapin properties dialogs for user and group objects are
extended with a Unix Account tab for managing Unix specific account information. If you have
installed the VAS NIS schema extensions, NIS map objects can be created and fully configured
using the Active Directory Users and Computers Snapin. The VAS Administrative Tools are
installed by the VAS.msi file and can be installed on any administrative workstation that has the
Active Directory Users and Computers snap-in installed.

2.4 The VAS Configuration Utility

The VAS Configuration Utility is a standalone Windows application that allows administrators to
configure advanced features of the VAS Administrative Tools. The VAS Configuration Utility
consists of several tabs which provide specific configuration functionality and other utilities. The
following describes the capabilities of each tab.

2.4.1 Conflict Detection Tab

Unix-enabled users and groups have attributes for user ID (UID) and group ID(GID). If multiple
users or groups share the same ID this is referred to as an ID conflict. By default the VAS Unix
client will deny access to a user if that user has any UID conflicts. It is recommended that
administrators avoid ID conflicts by defining a per-domain policy with regard to how new IDs
are allocated. For more information on managing user and group IDs, see Section 4.4.
To simplify the detection and resolution of UID and GID conflicts, the Conflict Detection Tab
provides a Conflict Resolution wizard. To search for ID conflicts in Active Directory complete the
following:
1. Open the VAS Configuration Utility by clicking Start -> Programs -> VAS -> VAS
Configuration Utility. The conflict detection tab is displayed:

15
 2. Select the radio button corresponding to users or groups depending on the type of conflict
search you would like to perform.
3. Click the Search for Conflicts... button to begin the search.
4. If conflicts are detected, a conflict resolution dialog is displayed which allows
administrators to see which objects are conflicting and resolve the conflicts automatically if
desired. The conflict resolution dialog will allow administrators to assign a new unique id
to one of the conflicting objects. The assigned ID is generated automatically and is
guaranteed to be unique in the forest. If you would like to assign a specific value to one of
the conflicting objects, open the Unix Account tab for that particular user or group and
enter the value there.
Check the VAS always prompts to check for conflicts when IDs change check box to enable or
disable this setting. If this setting is enabled, you will be prompted to check for ID conflicts
whenever a UID or GID is manually changed from the User or group properties dialog Unix
Account tab.

2.4.2 Preferred DC Tab

By default, communications with Active Directory occur via an automatically detected domain
controller. Normally, the default Domain Controller detected will work fine. However, in certain
situations it can be advantageous to specify a domain controller that the VAS Administrative
Tools should always use when communicating with Active Directory. This can be useful for
helping to avoid ID conflicts in situations where cross-site Active Directory synchronization is
slow. To force the VAS Administrative Tools to communicate exclusively with a specific domain
controller, perform the following:
1. Open the VAS Configuration Utility from the Start Menu.
2. Click on the Preferred DC tab.

16
 3. Check the Use specific domain controller check box and enter the DNS name or IP
address of the preferred domain controller.
4. Click Apply.

2.4.3 Custom Schema Tab

The Custom Schema Tab allows you to customize what LDAP attributes the Vintela
Authentication Services Admin tools will use when managing information in Active Directory.
For an explanation of when this is useful, and for complete instructions on configuring the
schema mapping, see Section 4.1.1.
The LDAP display names of the attributes used by the VAS Administrative Tools are cached in
the local system registry in order to increase performance and reduce LDAP traffic on the
network. In order to provide maximum flexibility, the schema is specified on a per-domain basis.
In most cases the attribute names will be identical for all domains in the forest.
Before you begin, you will need to know the LDAP display name for each of the equivalent
attributes from the schema that you wish to use. CAUTION: If you configure these names
incorrectly, the Administrative Tools will not function properly. Verify that you have the correct
LDAP display names for your needed attributes before continuing.
For example, assume you have a domain called example.com which has both the RFC2703
schema and the SFU 3.0 schema installed. By default, VAS will prefer the RFC2703 schema
attributes. To configure VAS to use the SFU 3.0 schema attributes, do the following:
1. Open the VAS Configuration Utility from the Start Menu.
2. Click on the Custom Schema tab.

3. Click the Add button to add example.com to the list. If ”DC=example,DC=com” is already
in the list, select it.
4. Change each of the attribute fields to their corresponding SFU attribute names.

17
 5. Click Apply.
Since the Vintela Authentication Services Snapin does not manage group membership lists, there
is no way, or need, to configure a schema mapping for group membership attributes. This may
need to be done on Unix clients depending on your schema. For information on configuring
schema mappings on Unix clients, see Section 4.1.2.

2.4.4 Logging Options Tab

The VAS Administrative Tools features a lightweight event logging facility which can be
configured to write troubleshooting information into a log file. The log file is reset each time the
VAS Administrative Tools .DLL is loaded, for example when running the Active Directory Users
and Computers MMC Snapin. The log file path and the level of detail are configurable. Every
time the Administrative Tools DLL is loaded, the log file will be re-created.
There are five levels of logging detail. Level one is the least detailed and will only log critical
errors. Level five is the most detailed and will write all logger events to the log file.

2.5 The pam vas PAM module

2.5.1 PAM Concepts

PAM stands for Pluggable Authentication Module, and is an API that allows the system
administrator to configure authentication mechanisms rather than having authentication
mechanisms hardcoded into the application. PAM is supported on Linux, HP-UX, AIX 5.2, and
Solaris. Administrators can customize an application’s authentication system by making changes
to /etc/pam.conf or an application specific file in the /etc/pam.d/ directory.
PAM modules are shared libraries that add support for a specific authentication mechanism. Unix
platforms that support PAM normally have a PAM module called pam unix for standard Unix
authentication.

2.5.2 pam vas Features

pam vas is a VAS module that supports the PAM API. Administrators can use it like any other
PAM module. pam vas is tightly integrated with the rest of the VAS components which allows it
to provide the following features:

Kerberos-based User Authentication The preferred authentication protocol in Windows 2000

and Windows 2003 domain environments. pam vas allows PAM enabled applications to
authentication users directly against Windows Domain Controllers and cache the
appropriate Kerberos ticket credentials for use by other applications. pam vas is designed
to use Kerberos to enforce Windows account access controls and password policies.

Disconnected Authentication pam vas can be configured to allow Active Directory logins when
Unix clients are disconnected from the network or when the Active Directory server is not
available.

18
Automatic Home Directory Creation Administrators can configure pam vas to automatically
create users’ home directories if they do not exist at login time. The home directory is set up
with the proper ownerships and permissions and is populated with the files from /etc/
skel.

UID Conflict Checking It is possible to inadvertently create UID conflicts between Unix enabled
Active Directory users and local system accounts stored in /etc/passwd. UID conflicts
create security holes where a local system user with the same UID as an Active Directory
user could access that Active Directory user’s files, and vice versa. pam vas prevents this by
not allowing Active Directory users to log in if they have a UID conflict and their UID is
greater than 1000.

Machine Based Access Control pam vas allows administrators to selectively control which
Active Directory users can access a Unix machine running VAS. Unix administrators can
restrict access based on Active Directory group membership, Active Directory domain
membership, and also for specific users.

Password Administration pam vas allows users to manage their Active Directory password.
With pam vas, password changes are immediately applicable to subsequent Unix and
Windows login events. pam vas enforces domain controller password policies so that
password complexity and the frequency of forced password change can be configured by
the Windows administrator.
For information on configuring the pam vas module, see the pam vas man page.

2.6 The nss vas NSS module

2.6.1 NSS Concepts

Unix operating systems use various ”databases” to obtain information about users, groups and so
forth. Traditionally, these databases were stored as flat text files in the /etc directory. For
example, user information is stored in /etc/passwd and group information is stored in /etc/
group. The Name Service Switch (NSS) is a subsystem built directly into the C runtime library
(libc) and allows user and group identity information to be obtained from a variety of backend
sources – not just the text files in the /etc directory. System administrators can change the NSS
configuration by modifying the /etc/nsswitch.conf file.
NSS modules are shared libraries that add support for user and group identity information to be
retrieved from a specific backend data source. Common NSS modules are for nis, files, and db
backends.

2.6.2 nss vas Features

nss vas is the VAS NSS module that allows user and group identity information to be retrieved
from Active Directory. In addition to allowing Unix identities to be managed from Active

19
Directory, nss vas provides the following important features:

Security nss vas differs from other LDAP NSS modules in that nss vas never directly generates
any LDAP traffic. The reason for this is that on Unix hosts, NSS modules cannot be
provided with any security context information that would allow authentication to the
Active Directory server. Instead, NSS modules that generate LDAP traffic are limited to
only being able to query ”public” LDAP attributes or require that ”guest” accounts to be
created with a password that is stored in a world readable file on the Unix host.
For security reasons nss vas only generates interprocess communication (IPC) requests to
the vascd daemon (detailed later in this section). With vascd’s help, nss vas can operate
securely and efficiently.

Scalability NSS modules are loaded into each process namespace separately. NSS modules that
directly generate LDAP traffic will create a new LDAP connection for each new Unix
process. Per-process LDAP connections and the amount of nss ldap generated LDAP
requests create a significant load for the Active Directory domain controllers.
To avoid per-process LDAP connections and excessive LDAP network traffic, nss vas uses
interprocess communication (IPC) to vascd and cached data to handle NSS requests that
would otherwise create scalability problems.

Disconnected Operation Because of the frequency which the NSS interfaces are called, an NSS
module must operate gracefully in a disconnected environment. Failure of an NSS module
to operate efficiently can have a very serious negative affect on all processes running on the
Unix host. If an NSS module blocks (for example, waiting for an LDAP connection to time
out), the resulting problems can range from very sluggish operation to the complete failure
of some Unix services.
With the help of vascd, nss vas is able to quickly detect disconnected situations and
continue to operate using the cached information.

2.7 The vascd daemon

vascd is the core Vintela Authentication Services client daemon. vascd must be running on Unix
clients in order for VAS to operate correctly. When started, vascd uses Kerberos to authenticate to
Windows Domain controllers using credentials that were established at the time that the
computer was joined to the Domain. vascd then uses Kerberos encrypted LDAP sessions to query
and cache Unix user and group information that is necessary for the scalable and secure operation
of the nss vas and pam vas modules.
vascd provides several important features:

Secure Access Control. Because of the way that PAM and NSS subsystems operate, most
LDAP-based Unix account management solutions require that anonymous or public access
to Unix account properties be allowed. Vintela Authentication Services does not require a
reduction in access control policy for Unix account properties. Since vascd authenticates as

20
 the Active Directory domain computer created when the Unix host was joined to the
domain, there is no need to provide Anonymous access to any information used by the VAS
client.

Secure LDAP without SSL. Once the Unix host is joined to the domain, vascd is able to
authenticate as a domain computer and encrypt LDAP communications with domain
controllers using a Kerberos session key. The Vintela Authentication Services client never
generates any plain-text LDAP traffic, and does not require the administrative overhead of
SSL certificate distribution to Unix clients or running Active Directory with SSL enabled.

Scalability. Because of the way that PAM and NSS subsystems operate, most LDAP based Unix
account management solutions generate excessive numbers of LDAP connections and
LDAP search requests. This results in dramatically increased network traffic and load on
the Windows Active Directory domain controllers. vascd establishes a single connection
that is used to proxy all information requests for processes that call the NSS interfaces. At
the same time, vascd is able to perform intelligent caching of frequently used information so
that LDAP traffic is reduced to the absolute minimum.

Disconnected Operation. vascd maintains a persistent cache of frequently used information.

This makes it possible for the system to continue to operate in environments where the
network connection to the Active Directory server is unreliable or completely unavailable.
Disconnected operation is particularly useful for dialup and laptop users that are frequently
not connected to the network.

2.8 The vastool command line utility

vastool is a script-friendly command line utility that exposes a wide range of functionality to the
Unix/Linux system administrator. The following table lists some of the vastool commands and
functionality. For a complete list of vastool functionality, see the vastool man page.

21
 attrs List an Active Directory object’s attributes
configure Update configuration files to use the VAS components
create Create a user, group, computer object, or service
delete Delete a user, group, computer, service, or NIS Map
flush Flush cached client daemon information
group Modify group membership
info Get infomation about host specific Active Directory configuration
isvas Check to see if the specified user or group belongs to VAS
join Join the host to the domain
kinit Obtain tickets for principals and services
klist List cached tickets
kdestroy Destroy (erase) cached tickets
license Install your VAS license
list List users or groups and their attributes
nss Call raw NSS function interfaces
passwd Change your password or reset another user’s password
realms Update or display cached domain, site, and service information
search Perform LDAP searches
service Create/Modify service principals
setattrs Set a principal’s attribute(s)
timesync synchronize the system clock with the domain
unconfigure Update configuration files to not use the VAS components
unjoin Remove the host from the domain
user Enable or disable user accounts

2.9 The VAS Loadable Authentication Module for AIX

Most versions of Unix use the NSS and PAM subsystems for account information lookups and
authentication. However, AIX uses an API called LAM (Loadable Authentication Module) that
combines the functionality of NSS and PAM. VAS provides an AIX LAM module, VAS, which
combines the functionality of pam vas and nss vas.

2.9.1 AIX LAM Module Concepts

LAM modules are shared libraries that the system’s libc uses based on the configurations in /
usr/lib/security/methods.cfg and /etc/security/user. The methods.cfg file lists
all of the available authentication modules. In /etc/security/user different users can be
configured to use different authentication modules. System-wide defaults can be set for the
”default” user; including a list of LAM modules to try when authenticating users.
Each LAM module must provide methods for authenticating users, changing user passwords,
and looking up user and group account information. AIX by default includes LAM modules for
DCE and NIS. AIX has built in functionality for authenticating local and NIS users when using
the compat setting in /etc/security/user.

22
2.9.2 The VAS LAM module

The VAS LAM module is installed in /opt/vas/lib/security. It provides the same

functionality as the pam vas PAM module for authentication. It also provides the same
functionality as the nss vas NSS module for user and group lookups. The VAS LAM module is
added to the default user’s authentication mechanism as part of joining VAS clients to the Active
Directory domain.

23
Chapter 3

UNIX HOSTS IN ACTIVE DIRECTORY

VAS allows Unix hosts to be intuitively represented in Active Directory as computer objects. This
chapter addresses the topics that are relevant to the creation of Unix computer objects and the role
Unix computer objects play in the VAS authentication and identity management solution:
• Kerberos and Active Directory. See Section 3.1
• Joining the Active Directory Domain. See Section 3.2
• Domain, Site, and Service Discovery. See Section 3.3
• Time Synchronization. See Section 3.4
• Computer Objects. See Section 3.5
• NSS Configuration. See Section 3.6
• PAM Configuration. See Section 3.7
• AIX Configuration. See Section 3.8
• The vascd Daemon. See Section 3.9

3.1 Kerberos and Active Directory

3.1.1 Kerberos Concepts

The name Kerberos comes from Greek mythology; it is the three-headed dog that guarded the
entrance to Hades. The Kerberos protocol originated at the Massachusetts Institute of Technology
and was later formalized as a network security standard in RFC 1510. Kerberos was developed to
provide a secure authentication mechanism across untrusted networks.
The Kerberos network authentication service provides a means for ”principals” to verify the
identity of other principals. A ”principal” is any entity that provides or consumes resources, (for
example users, workstations, servers, and even individual service processes that run on network
servers). Principals authenticate each other using tickets that are issued by the Kerberos Key
Distribution Center (KDC). Tickets are encrypted using secret keys that are only known to the
principals themselves and the KDC. Therefore, one principal can validate the authenticity of
another if they can present a ticket encrypted by the correct secret key. An illustration of a simple
ticket exchange is shown in Figure 3.1

24
 Figure 3.1. A simple Kerberos ticket exchange

3.1.2 Kerberos and Windows

The Kerberos version 5 authentication protocol is the default network authentication protocol for
Windows 2000, Windows XP and Windows 2003. The Windows Kerberos implementation is fully
compatible with RFC 1510 and is much more refined than what is generally available from the
MIT reference implementation. In fact, many users are not even aware that Kerberos provides
nearly all of the security underpinnings for Windows domains.
There is a very close symbiotic relationship between Kerberos and Active Directory on a Windows
Domain controller. On a domain controller, the KDC and Active Directory actually share some of
same account information data. This is how a domain controller can act as both a KDC and an
LDAP server. This means that user, computer, and service accounts created in Active Directory
can be used as Kerberos authentication principals. This also means that an authentication and
identity management solution must use Kerberos and LDAP together as shown in Figure 3.2.
The purpose of VAS is to provide the software components that allow Unix hosts to authenticate
user logins in the same way that Windows computers authenticate user logins. With VAS, the
Unix machine is joined to the domain after which ”Unix enabled” Active Directory users can
login to the Unix host using their Active Directory username and password. This is accomplished
without disturbing any of the core Windows domain controller services. As far as the domain
controller is concerned, a Unix host with VAS installed authenticates user logins the same way
that a Windows computer does.

3.1.3 Multiple Domain Environments

Large organizations often deploy multiple domains with many domain controllers. Trusts are
established between domains so that Kerberos tickets issued by one domain controller are
honored by domain controllers of other domains. Multiple domains tied together by trust
relationships are called a Forest as shown in Figure 3.3.
Unix participation in multiple domain environments (forests) adds a layer of complexity that VAS

25
 Figure 3.2. How Kerberos and LDAP are used together to create and authenticate users.

fully supports. For example, if a user in one domain would like to logon to a Unix host in another
domain, VAS is able to request an initial ticket from the appropriate domain controller in a
domain where the user resides.

3.1.4 Active Directory Sites

Organizations with a large number of geographically separate sites have an alternative to

deploying multiple domains – Active Directory Sites. An Active Directory Site is a
well-connected group of computers that share the same subnet. Often, these computers are all
located at one physical location. Each Active Directory Site will have a domain controller(s) that
should be used by all of the clients for authentication. This reduces the amount of WAN traffic
between geographical locations, since all of the necessary authentication information in the
directory is replicated between the domain controllers. All clients in a site then use the domain
controller(s) at their site for authentication.
As with forests, adding Unix clients into a site adds more complexity that VAS automatically
handles by detecting what domain controllers are for a given site and giving priority to those
servers.

3.2 Joining the Active Directory Domain

The first and most important VAS configuration step is joining the Unix host to a Windows
domain. As a member of the domain, the computer itself is able to communicate securely with
Active Directory and act as a Kerberos authentication principal for validating user login events.

26
 Figure 3.3. An Active Directory Forest

Although the vastool join command automates the entire process of joining the domain,
understanding the details of each step of the join process will help the administrator to more
quickly diagnose common configuration problems and recommend deployment
specific-solutions.
These are the steps performed by the vastool join command:
1. Check for clock synchronization.
2. Discover Domains and Sites.
3. Create a computer object for the Unix host.
4. Create a key for the computer object.
5. Modify the system NSS configuration.
6. Modify the system authentication configuration (PAM).
7. Start vascd.
8. Load the VAS user and group cache.

27
3.3 Domain, Site, and Service Discovery

VAS discovers domains, domain controllers, sites, and services using DNS service record lookups
and specialized LDAP queries. As domain controllers are added to the forest, the network DNS
servers are updated with service records that allow VAS to locate the domain controllers through
DNS queries. Once an LDAP service entry has been found, VAS can query the Active Directory to
find additional information about the domains and domain controllers in the forest as well as the
site to which each domain controller belongs.
When joining a Unix machine to the domain, it is critical that the Active Directory DNS service
entries are visible to the DNS name servers that are referenced in the Unix machine’s resolver
configuration (/etc/resolv.conf). If there is a DNS misconfiguration, the Unix machine will
not be able to join the domain. The following error message is an indication of a DNS
misconfiguration:
ERROR: The servers for the example.com domain could not be
detected. Please check your DNS configuration and ensure that
your DNS server(s) have been properly configured for use with
Active Directory.
The information about domains, domain controllers, sites, and services is cached so that it can be
used later to allow VAS to contact the appropriate domain controllers for cross domain
authentication, and when possible use domain controllers in the local site. The vastool realms
command is used to inspect and maintain the domain controllers, domains, sites, and services
cache. The vastool command realms refers to Kerberos realms which are equivalent to Windows
Domains.

3.4 Time Synchronization

Kerberos is a time sensitive protocol that requires the system clock of a client machine to be
roughly synchronized with the system clock of the Windows Domain Controller. Time
synchronization between domain controllers and Windows clients is handled automatically. To
ensure time synchronization Unix hosts may require additional configuration. If there is a
significant difference between the system clock of the client machine and the Windows Domain
Controller the following error message will be displayed:
Could not authenticate, error = Clock skew too great.
There are several ways to correct a clock skew on the Unix host. The easiest way is to use the
vastool timesync command which will automatically synchronize the host’s system clock to
within 1 second of the Windows domain controller. The vascd daemon also contains a Simple
Network Time Protocol (SNTP) implementation that will continue to keep the host’s system clock
roughly synchronized with the domain time.
There are situations where it is not advisable to use the vastool timesync. If the host is already
configured to use Network Time Protocol (ntpd) to synchronize the system clock with corporate
time service, then the time should be synchronized already. If a clock skew occurs on a system
running ntpd, then there is either an error in the NTP configuration (/etc/ntp.conf) or the
domain time itself has become unsynchronized.

28
Another situation that requires special attention is when the Unix host is running software that is
time sensitive. Certain transactional databases and distributed systems react badly if the system
clock is changed abruptly. If the Unix host is running time sensitive software NTP should be used
instead of the vastool timesync to synchronize time.
For more information on NTP, consult your Unix OS documentation.

3.5 Computer Objects

3.5.1 Creating Computer Objects

The creation of a computer object in Active Directory is a very important step in joining the
domain. The computer object identifies the Unix host in the domain and provides information
used by the domain controller to issue Kerberos tickets when a user logs on to the host.

3.5.1.1 Computer Object Names and Hostnames

By default, the name of the computer object that is created when joining the domain is derived
from the hostname of the Unix host. A fully qualified domain name (FQDN) must be used when
creating the computer object. vastool will attempt to derive a FQDN from the hostname. In cases
where the Unix hostname is set to a non-FQDN value, then vastool will use the system resolver to
try and resolve a FQDN hostname using the Unix hostname. If the hostname does not resolve to a
FQDN, then the domain name will be appended to the hostname to create a FQDN.
You can override the machine hostname by using the -n for vastool join. The same rule for
FQDN’s applies here. If the supplied name does not have a ’.’ character, then the name of the
domain will be appended to create a FQDN.
If you are interested in running Kerberized services such as sshd, telnetd, or ftpd, it is highly
recommended that the hostname, DNS name, and computer object name match. The reason is
that the DNS name will be used by Kerberized client applications to determine the service name
in a Kerberos ticket request. If the DNS name does not match information stored when the
computer object was created, the domain controller will not be able to issue the service ticket.

3.5.1.2 Delegating Computer Creation Privileges

In order to create a computer object, a user must be an administrator or have been delegated
permissions to create computer objects. When using the vastool join command the -u option
must be used to specify a user with the necessary rights in Active Directory. By default, users in
the Domain Admins group have permissions to create computer objects.

29
 N OTE

The built in Administrator account cannot be used with the vastool -u option
to join Unix hosts to the domain by default. This is because the Administrator
account does not have a full user principal name (UPN) by default. You must
modify the Administrator’s User Login Name to contain a domain component,
and reset the Administrator accounts password in order for it to be usable by
the VAS client for Kerberos authentication.

It is possible for Active Directory administrators to delegate the rights for computer object
creation to specific users or locations. For more information on privilege delegation consult your
Active Directory documentation.

3.5.1.3 Creating Computers in specific containers (OU’s)

By default, computer objects are created in the Computers container of the Active Directory tree.
To create the computer object in a different container, use the -c option when running vastool join.

3.5.2 Deleting Computer Objects

Removing a computer object from Active Directory using the Windows Active Directory Users
and Computers utility will cause all subsequent Active Directory user logins to the Unix host to
fail until the computer object is recreated using the vastool join.
The vastool unjoin command is the preferred method for removing Unix computer objects.
Using vastool unjoin will cleanly delete the computer object in Active Directory, delete the
cached user and group information, remove VAS configuration information in the Unix NSS and
authentication configuration files, and stop the vascd daemon.
vastool unjoin must be run as root, and a user with the administrative privilege to delete the
computer object must be specified with the -u.

3.5.3 Moving Computer Objects

When using the Windows Active Directory Users and Computers utility, Unix computer objects
can be moved (drag-n-drop) from one container (OU) to another as long as the source and
destination containers (OU’s) are in the same domain. Unix Computer objects can not be moved
across domain boundaries with Windows utilities such as movetree and netdom. Instead, the
computer object should be removed using vastool unjoin and re-joined to the new domain.

3.5.4 VAS Keytab Files

A keytab file stores Kerberos keys for computer and service principals. The creation of a keytab is
a complex process that involves setting the computer (or service) object password, generating the
appropriate keys, and checking for key version number correlation. With VAS it is not necessary
to manually export a keytab on the domain controllers and import it on the Unix host. The VAS

30
product performs the entire keytab generation process automatically when joining the Active
Directory domain or when creating service principals in Active Directory.
VAS keytab files are created in /etc/opt/vas directory. Each keytab file is named according to
the service that uses it. For example, the host principal keys are stored in the /etc/opt/vas/
host.keytab file. VAS keytab files are stored using the ”standard” MIT-style and may be used
by third party applications.
If the host.keytab file is compromised by unauthorized root access on the Unix system, then
the password for the associated computer object should be assumed to be compromised as well.
You can reset the computer object’s password and generate a new keytab file by running vastool
create host/. Another option is to delete the computer object and recreate it.

3.5.5 Security Considerations

The default permissions for a computer object restrict the computer from accessing and
modifying sensitive data in Active Directory. The schema extensions are carefully designed to
allow computers with default permissions to access only the Unix account data that is absolutely
necessary for the normal operation of the vascd daemon. We recommend that administrators not
modify the default permissions for the computer object to make them either more or less
restrictive. Changing the computer object permissions could disrupt normal operation or create a
security liability that might result in the compromise of sensitive data.

3.6 NSS Configuration

3.6.1 The NSS Configuration File

/etc/nsswitch.conf contains the configuration used by the Name Service Switch (NSS)
subsystem to determine which NSS modules should be used to obtain information about users,
groups, hosts, etc. Each line of the /etc/nsswitch.conf represents a configuration setting for
the particular database.
The following is a portion of a sample /etc/nsswitch.conf file:

passwd: files nis

group: files nis

The order that modules are listed on each line of /etc/nsswitch.conf is important. In the
example above, NSS would first use /etc/passwd and /etc/group to look up user and group
information. If the desired user or group information exists in /etc/passwd or /etc/group
then it will be used instead of identical information that may be stored in NIS. NIS will only be
used to look up user or group information if the information cannot be found in /etc/passwd
or /etc/group.

31
3.6.2 Modifying the NSS configuration

During vastool join the passwd and group lines of /etc/nsswitch.conf are automatically
modified to include the vas NSS module. The following is an example of what the passwd and
group lines will look like after a Unix host has been joined to the domain.

passwd: files vas nis

group: files vas nis

After a Unix host has been joined to the domain, the Name Service Switch will first use /etc/
passwd and /etc/group to look up user and group information. If the desired user or group
information exists in /etc/passwd or /etc/group then it will be used, otherwise, the user and
group information is obtained from Active Directory and lastly from NIS.
There are situations, such as troubleshooting NSS problems, when it is useful to change the NSS
configuration so that VAS is not being used. This can be accomplished by editing the /etc/
nsswitch.conf directly or by running vastool unconfigure nss. To restore the configuration
run vastool configure nss.

3.6.3 Restarting services when the NSS configuration changes

Service daemons should be restarted after changing the /etc/nsswitch.conf file. A daemon
restart is necessary so that the NSS instance for the daemon process will re-read the /etc/
nsswitch.conf file and load the appropriate NSS modules. Consult your Unix OS
documentation for more information on restarting services.

3.6.4 Using nscd With VAS

nscd is a rudimentary caching daemon that can increase the efficiency of the Name Service
Switch. nscd caches results supplied by NSS modules. This cache is used instead of calling the
NSS modules for a specified period of time. After a configurable timeout, the cached results are
flushed and NSS again calls the NSS modules directly to load the cache.
VAS uses it’s own caching mechanisms that are much more efficient at caching information
retrieved from Active Directory. It is possible to use VAS and nscd together, but doing so often
produces unpredictable results. Therefore, the default behavior for vastool join and vastool
configure nss is to modify /etc/nscd.conf to disable nscd caching of passwd and group data.
To verify that nscd caching of passwd and group data is turned off, inspect the /etc/nscd.conf
file. Ensure that all passwd and group entries have been removed with comments except for the
enable-cache entry which would be set to no.

enable-cache passwd no
# positive-time-to-live passwd 600
# negative-time-to-live passwd 20
# suggested-size passwd 211
# check-files passwd yes

32
 enable-cache group no
# positive-time-to-live group 3600
# negative-time-to-live group 60
# suggested-size group 211
# check-files group yes

N OTE

Instead of nscd, HP-UX uses a daemon called pwgrd whose configuration

is stored in /etc/rc.config.d/pwgr. As with nscd, VAS disables the
pwgrd caching of user and group data when joining the domain or configuring
NSS.

3.6.5 Advanced nss vas Concepts

3.6.5.1 Case sensitivity of user and group names

In some environments the user and group names in Active Directory will be all upper case.
Normally user and group names on Unix systems are lowercase. It is possible to have nss vas
explicitly change all user and group names to their lowercase versions. To enable the lowercase
behavior, add the line lowercase-names = true to vas.conf. This line should be added under
the [nss vas] section. You may need to restart the processes using nss vas to apply the change.

3.6.5.2 Case sensitivity of User Logon Names

User logon names in Active Directory are case insensitive. For example, a user with a logon name
of JOHND can logon to a Windows workstation with the username of johnd. Likewise, with VAS,
the user logon name used when logging on to Unix hosts is also case insensitive.

3.6.5.3 User Logon Names for Cross Domain Login

When a user logs in to a VAS client that is in another domain, the user must log in with their full
user logon name. This will be in the form of joe@example.com, where example.com is the domain
that the user joe is in. This allows the VAS client to determine where to get joe’s user account
information and also determine what domain to authenticate joe against.
When doing cross domain logins with ssh, it is necessary to specify the user name with the -l
option as follows:
ssh -l joe@example.com server.sub.example.com
The HP-UX telnet client does not accept standard user login names with the ”@domain”
component as login names. You will have to escape the ’@’ character in order to perform cross

33
domain logins. For example, you would specify your whole user logon name as
joe\@example.com in order for the HP-UX telnet daemon to accept you.

3.7 PAM Configuration

3.7.1 The PAM Configuration File

PAM stands for Pluggable Authentication Module and is an API that allows the system
administrator to configure authentication mechanisms rather than having them hard-coded into
applications. PAM is controlled by configuration settings in the pam.conf file or by individual
(service-specific) files in the /etc/pam.d directory. The PAM configuration allows PAM modules
to be ”stacked” and combined to provide flexible and powerful authentication configurations.
The pam vas module should be configured to be the first module in the stack. pam vas returns an
IGNORE result when the user being authenticated is not an Active Directory user. This gives
other standard PAM modules in the stack (such as pam unix) a chance to authenticate the user.
When joining the domain, vastool automatically modifies the PAM configuration to add auth,
account, session,and password entries for pam vas.so as part of the stack for all PAM services. On
Linux the entries are made with new explicit [value=action] control-flags. On Solaris, HP-UX, and
Solaris the entries are made as sufficient.
To verify that the PAM configuration has been modified correctly to use VAS, inspect the pam.
conf file or one of the (service specific) PAM configuration files in the /etc/pam.d directory.
Check to ensure that a an entry for pam vas.so exists as the first entry in the stack for each service
that should be using VAS to authenticate users.
Refer to the system administration documentation for your operating system concerning PAM
before performing any customizations beyond the changes made by the vastool configure pam
commands described in this section.

3.7.2 Using vastool to modify PAM configuration

The vastool configure pam command is particularly useful when installing new software on a
Unix host that has already been joined to the domain. When joining the domain, vastool only
configures PAM for existing services. Therefore, after installing new service software, you must
run vastool configure pam to add the correct pam vas.so entries for the newly installed service.
The following is an example of how vastool can be used to modify the PAM configuration for a
newly installed service (sshd):
# /opt/vas/bin/vastool configure pam sshd
There are situations, such as when troubleshooting problems, when it is useful to change the
PAM configuration so that VAS is not being used. This can be accomplished by editing the PAM
configuration files directly and commenting out the pam vas.so entries. An easier method is to
simply run the vastool unconfigure pam. The following command removes the pam vas.so
entries from the sshd service.
# /opt/vas/bin/vastool unconfigure pam sshd

34
If you omit the service name to unconfigure, vastool unconfigure pam will remove pam vas.so
entries from all services as shown below:
# /opt/vas/bin/vastool unconfigure pam

3.7.3 Restarting services for PAM configuration changes

Service daemons should be restarted after any modification to their PAM configuration. A
daemon restart is necessary so that the PAM library calls will re-read the new PAM configuration.
Service daemons can be restarted individually or all at once by cycling init run-levels.

3.7.4 Advanced pam vas Concepts

3.7.4.1 Kerberos Ticket Caches

The pam vas module uses the Kerberos protocol to authenticate users against Active Directory.
The Kerberos protocol allows users to obtain a Ticket Granting Ticket or TGT that can then be
used to obtain other tickets to authenticate to services. Once the TGT has been obtained it can be
used as a single sign on mechanism that does not make users repeatedly enter in their password.
By default, when a user establishes a login session via a service configured to use the pam vas
module, they will have a ticket cache stored in their home directory with the name .krb5cc. In
situations where the pam vas module cannot securely create the credentials cache file in a user’s
home directory, it uses a default location of /tmp/krb5cc xxx where xxx is the user’s UID. The
KRB5CCNAME environment variable is also set to allow other Kerberos-aware applications to
locate the ticket cache created by the pam vas module.
The tickets in the ticket cache do not contain the users password, but they could be used in a
brute force attack to determine passwords, much like an attacker could use the password hashes
in /etc/shadow if those were publicly available. To protect the ticket cache, the $HOME/.krb5cc
file is created with permissions of 0600 (readable and writable only by the file owner) and owned
by the user. This file should not be moved or modified by the user. To further reduce the
possibility of brute force attacks, the ticket cache is removed by the pam vas module when the
user terminates the logon session.

3.7.4.2 User Home Directory Creation

By default pam vas creates users’ home directories if they do not exist. The home directories are
created with the appropriate permissions of 0700 (readable, writable, and executable only by the
owner of the directory) and owned by the user. The files in /etc/skel are also copied into the
new home directory. pam vas can only create home directories on local file systems.
Automatic creation of home directories can be disabled by removing the create homedir option
from the auth entries in the PAM configuration for the desired logon service. Disabling automatic
creation of home directories may be useful in environments where home directories are stored on
network file servers.
To disable automatic home directory creation, modify the auth line to remove the create homedir
option:

35
 auth [ignore=ignore success=done default=die] \
/opt/vas/lib/security/pam_vas.so get_tgt create_homedir

The modified entry should look like the following:

auth [ignore=ignore success=done default=die] \

/opt/vas/lib/security/pam_vas.so get_tgt

3.7.4.3 Using pam vas For Authentication Only

pam vas can be optimized for use with services that do not provide shell login functionality.
Examples of non-shell services would be ftp, imap, and pop. In situations where pam vas is
being used with non-shell services you should consider removing the get tgt option from the auth
entry for pam vas. This reduces the amount of Kerberos network traffic that has to be performed,
and does not reduce functionality because most non-shell logon services will not need to use the
TGT for subsequent authentications anyway.
To optimize a non-shell service, modify the auth line to remove both create homedir and get tgt
options:

auth [ignore=ignore success=done default=die] \

/opt/vas/lib/security/pam_vas.so get_tgt create_homedir

The modified entry should look like the following:

auth [ignore=ignore success=done default=die] \

/opt/vas/lib/security/pam_vas.so

3.7.4.4 Disconnected Authentication

pam vas allows users to continue to use their Active Directory passwords to authenticate even
when the network connection to the Active Directory server is disrupted. Users must login at
least once while in the connected state in order to be able to log in when the system is
disconnected.
During a normal connected authentication operation, pam vas caches a salted SHA-1 hash of the
user’s password. When the system is disconnected, pam vas allows logins if the supplied
password matches the cached password hash for the given user. User password hashes are
cached in a secure file in /var/state/vas/authcache/authcache.vdb, which has
permissions of 0600 (readable and writable only by the owner of the file) and is owned by root.
Though SHA-1 is a strong hash algorithm it is important to protect the authcache.vdb file in
the same way as you would protect /etc/shadow.

36
On some systems and services it may be preferable to disable caching of usernames and
password hashes. To do this, add the no disconnected option to the auth entries for pam vas for
all services that should not cache users’ passwords.

3.7.4.5 pam vas and Password Management

Windows allows the configuration of a password policy to force users to change passwords often,
to select strong passwords, or to force password change at the next login after resetting the
password. The pam vas module also supports the full range of Windows password policy
features.
When users log in and their password is expired, pam vas prompts for the old password, and a
new password. However, not all services use the PAM interface correctly to support interactive
password change prompts. For example, KDE’s kdm does not process the PAM requests from
pam vas correctly, but GNOME’s gdm and the system login prompt do.

3.7.5 Debugging PAM Problems

If you experience problems authenticating Active Directory users using the pam vas module, it is
often helpful to enable verbose debug logging with the debug option. The debug option can be
appended to any pam vas entry. The debug output is logged to the authentication system log
through syslog. Check your /etc/syslog.conf to determine where authentication messages
are logged. On RedHat Linux, authentication messages are logged to /var/log/secure by
default.
On Solaris, there is no default syslog setup for auth messages. If you do not see verbose pam vas
messages in the system log you may need to enable syslog for auth messages, by adding the
following lines to /etc/syslog.conf, and then restarting syslogd (make sure that you use tabs
as a column separator):

auth.alert /dev/console
auth.crit root
auth.debug /var/log/auth

3.8 AIX Configuration

AIX supports the standard Unix functions for user and group information look-ups. However, it
does not support NSS in the same way that most other Unix versions do. On AIX there is no /
etc/nsswitch.conf file or support for NSS modules. AIX has its own system and API’s for
authentication and user account information lookup, and its own configuration files.

3.8.1 AIX Configuration Files

AIX has two main files that are modified when joining the machine to the Windows domain. The
first is /usr/lib/security/methods.cfg, which lists the available authentication modules

37
on the system. vastool join automatically adds an entry for the VAS authentication module.
Once the VAS authentication module has been added to the list of available modules, the VAS
authentication module must be added to the list of modules used when authenticating users
found in /etc/security/user. In /etc/security/user, AIX allows you to configure the
authentication mechanisms for specific users or a default for all other users. vastool join
automatically configures the ”default” user to use both the ”compat” authentication module and
the VAS authentication module.
The /etc/security/user file is very complicated. Refer to your AIX documentation for
information on the file format before changing any of the defaults that are set by the vastool join
command.

3.8.2 Account Information Functions

The VAS AIX module provides the standard functions for looking up user account information
and group information. The VAS AIX module works in the same way that nss vas does. When
requests for information come, IPC messages are sent to vascd. vascd updates the accounts cache.
When the cache has been updated, the VAS AIX module reads account information directly from
the cache.

3.8.2.1 Case sensitivity of User and Group Names

The VAS AIX module supports the same option as nss vas to explicitly change all group and user
names to lower case. To enable the lowercase behavior, add the line lowercase-names = true
to /etc/opt/vas/vas.conf. This line should be added under the [nss vas] section.

3.8.2.2 Enabling Account Lookup Debugging Information

It is possible to enable debugging messages for account information look-ups by modifying the /
etc/opt/vas/vas.conf file. Add the line nss-debug=true under the [aix vas] section.
This configuration change will be picked up in under 60 seconds.
When the nss-debug option is set to true, information about account look-ups is sent to syslog
as ”debug” information. To view this information syslog must be configured to log ”debug”
information. Debugging messages generated by this option include information about calls made
to functions such as getpwnam() and getgrnam().

3.8.3 Authentication Functions

By default, AIX applications use the authenticate function to authenticate users. The VAS AIX
module implements this function to authenticate users against the Windows domain controller
using Kerberos. The VAS authenticate function supports all the features of pam vas. The only
limitation is that the options cannot be configured or turned off the way they can in pam vas.
AIX 5.1 and 5.2 each support the PAM API. However, none of the applications included in the
base OS installation use PAM for authentication. pam vas is included so that applications that

38
have been PAM enabled can use its functionality. You must explicitly configure PAM by using the
vastool configure pam command, since PAM is not configured as part of vastool join on AIX.
The AIX Loadable Authentication Module does not provide an interface for cleaning up user
login sessions. This means that the VAS AIX module cannot delete the user’s Kerberos ticket
cache when they logout. We recommend that you use the vastool kdestroy command to cleanup
user ticket caches. You can run vastool kdestroy from a user’s .bash logout script, if they are
using the bash shell. Consult your OS documentation for information on other logout scripts for
the shells your users use.

3.8.3.1 Enable Authentication Debugging Information

If you are attempting to debug an authentication failure, you should enable debugging
information for authentication related problems. To enable authentication debug messages, you
must modify the /etc/opt/vas/vas.conf file. Add the line auth-debug=true under the
[aix vas] section. This configuration change will be picked up in under 60 seconds.
When the auth-debug option is set to true, ”auth” messages will be logged to syslogd similar to
the way that ”auth” messages are logged to syslogd by pam vas when the debug option is used.

3.9 The vascd Daemon

The vascd daemon (or process) must be started on Unix workstations in order for VAS to operate
correctly. vascd plays an important role in providing many of the security, scalability, and
stability features of VAS. vascd acts as a proxy for requests for information that is stored in Active
Directory. vascd provides the requested information either from a cache, or by contacting the
Active Directory server. When obtaining information from Active Directory, vascd authenticates
as the computer using the credentials that were established at the time that the computer object
was created in the Active Directory domain.

3.9.1 The vascd Data Cache

In order to minimize network traffic and the load on the Active Directory server, vascd
aggressively caches data that is retrieved from Active Directory so that subsequent requests can
be satisfied from the cache without having to generate LDAP traffic. The cache is only updated
when it is determined that a change has been made in the directory or when a new user logs in.
Nevertheless, because of the way that the NSS subsystem is called it is not uncommon for
hundreds of requests for user and group information to be generated in a matter of seconds.
Therefore, in order to further reduce the load on the network and on the directory, vascd enforces
a ”blackout period” during which all NSS-initiated requests are resolved from the cache.
By default, the ”blackout period” is set to a value of 10 minutes. This means that changes to Unix
Account information may take up to 10 minutes (by default), to become visible through the Name
Service Switch to VAS clients. In other words, there are two events that will force vascd to query
Active Directory for new information:
1. A user logs in
2. The ”blackout period” expires

39
Until one of the events listed above, logged-in users and existing processes will not see newly
added or modified users. For environments where changes must take affect faster, change the
”blackout period” by modifying or adding the update-interval setting to /etc/opt/vas/vas.
conf. The following change to /etc/opt/vas/vas.conf specifies the length of the ”blackout
period” to be 300 seconds:

[vascd]
update-interval = 300

As a general rule, decreasing the update-interval results in additional network traffic (depending
on the number of Unix hosts and their use). In small installations (less than 100 hosts or less than
100 users) the blackout period can be safely reduced. In larger installations it is recommended
that the blackout period be left at the default value or increased to 30 minutes or 1 hour.
Regardless of the blackout period, the administrator can force vascd to update the cache
immediately by signaling vascd with SIGHUP, using the vascd init script to restart vascd, or by
executing a vastool flush. Note that whenever calling vastool flush, the entire user and group
cache will be reloaded which can generate significant amounts of LDAP traffic, so it should be
used sparingly.

3.9.2 Disconnected Mode

When vascd is unable to contact the KDC or the Active Directory server, it reverts to disconnected
mode. While in disconnected mode all NSS and PAM requests are resolved from the cache.
Disconnected mode can be entered for one or more of the following reasons:
• The computer object has been deleted. If the host’s computer object has been deleted then
vascd can no longer communicate with Active Directory because it cannot authenticate. The
solution to this problem is to re-create the computer object, then restart vascd.
• The /etc/opt/vas/host.keytab file is missing or invalid. If /etc/opt/vas/host.
keytab is deleted or becomes corrupt then vascd is no longer able to communicate with
Active Directory because it does not have credentials to authenticate as the computer. The
solution to this problem is to delete then re-create the computer and restart vascd.
• The computer is physically disconnected from the network or the network is down.
• The Active Directory server is down.
Since most Unix account information requests are correctly handled by the cache, it is often
difficult to tell if vascd is in disconnected mode. One sure way to determine the state of vascd is to
look at the system log file. vascd makes a short log entry each time the connection mode changes.
Finally, the vascd disconnected mode is not intended to solve all problems related to completely
disconnected situations. For example, vascd does not have any control over the ability of the
system to continue to resolve DNS names or to continue accessing network file systems in an
abrupt and completely disconnected situation.

40
Chapter 4

UNIX USERS AND GROUPS

With VAS you can manage Unix user accounts, passwords, and Unix groups from Active
Directory. Information in this chapter addresses the following concepts:
• User and Group Schema Configuration. See Section 4.1
• Managing Unix User Accounts. See Section 4.2
• Managing Unix Group Accounts. See Section 4.3
• UID and GID Management. See Section 4.4
• Password Management. See Section 4.5
• Account Management in Multiple Domain Environments. See Section 4.6
• Workstation Access Control. See Section 4.7

4.1 User and Group Schema Configuration

Vintela Authentication Services has been designed to provide support for multiple Active
Directory schema extensions. The Vintela Authentication Services MMC Snapin and the vastool
join command will automatically detect some installed schema extensions - these include the
default VAS schema extension based on RFC 2307, the SFU 3.0 schema extensions, and the SFU
2.0 schema extensions.
In environments where there are custom schemas deployed, or multiple supported schema
extensions deployed, it may become necessary to perform custom schema configuration to ensure
that the Vintela Authentication Services components use the correct LDAP attribute names when
searching for information. The schema detection algorithms give priority to the Vintela
Authentication Services schema extension, followed by the SFU 3.0 schema extension, and last of
all the SFU 2.0 schema extension. This may create a situation where you want to override the
detected defaults. There are two places where you must configure the schema mappings: 1) on
your Windows administrative workstation where the Vintela Authentication Services Snapin is
used, and 2) Each Unix machine running the Vintela Authentication Services client.

4.1.1 Configuring Schema Mappings for the Vintela Authentication Services Snapin

The schema mapping for the Vintela Authentication Services Administrative Tools can be
configured using the Custom Schema Tab from the Vintela Authentication Services

41
Configuration Utility. For information on using the Custom Schema Tab, see Section 2.4.3.

4.1.2 Configuring Schema Mappings for the Vintela Authentication Services Unix
client

As part of the vastool join process, schema detection is performed. You can view the results of
this schema detection with the following command:
# /opt/vas/bin/vastool schema list
If the detected schema configuration is not what you want to use, you can specify a schema
mapping in /etc/opt/vas/vas.conf. The schema mapping must be made in the ”[vascd]”
section. The following options are supported:

uid-number-attr-name The name of the LDAP attribute that contains the Unix UID for users.

gid-number-attr-name The name of the LDAP attribute that contains the Unix GID for groups,
and the name of the attribute used for the Primary Group GID for users.

gecos-attr-name The name of the LDAP attribute that contains the GECOS information for users.

home-dir-attr-name The name of the LDAP attribute that contains the Unix home directory for
users.

login-shell-number-attr-name The name of the LDAP attribute that contains the name of users’
Unix login shell.

group-member-attr-name The name of the LDAP attribute that contains the membership list for
groups. This attribute must be multi-valued and contains the distinguished names (DN’s)
of all the users that belong to the group. If you override this attribute it will require you to
maintain two separate group membership lists (one for windows group membership and
one for unix group membership). VAS uses the windows group membership list by default.
Overriding this attribute is not recommended.

memberof-attr-name The name of the LDAP attribute that contains the list of the groups that a
user belongs to. This attribute must be multi-valued and contains the DN’s of all the groups
the user belongs to. If you override this attribute it will require you to maintain two
separate group membership lists (one for unix group membership and one for windows
group membership). VAS uses the windows memberof attribute by default. Overriding this
attribute is not recommended.

nismap-objectclass-attr-name The objectclass of the schema extension used to store NIS maps.

nismap-name-attr-name The name of the LDAP attribute used to store the name of the NIS map

42
nismap-data-attr-name The name of the LDAP attribute used to store the contents of the NIS
map

nismap-format-attr-name The name of the LDAP attribute used to store NIS map parser scripts
and other formating information.
The following is an example of how you would configure a schema mapping for the SFU 3.0
schema extension when using the VAS Administrative Tools to manage users and groups:

[vascd]
uid-number-attr-name = msSFU30UidNumber
gid-number-attr-name = msSFU30GidNumber
gecos-attr-name = msSFU30Gecos
home-dir-attr-name = msSFU30HomeDirectory
login-shell-attr-name = msSFU30LoginShell

Note that you do not typically need to do this, as vastool will auto detect this same configuration
if only the SFU 3.0 schema extension is installed already in Active Directory.
Any time you make changes to the schema mapping, you should run vastool flush. This will
ensure that vascd gets restarted and uses the new attribute names, and the user and group
databases will get reloaded to so that the information contained there is correct according to your
configured schema mapping.
You can actually specify this mapping in /etc/opt/vas/vas.conf before running vastool
join. This is useful during large deployments of VAS since you can avoid having to run vastool
flush after each host is joined to the domain.

4.2 Managing Unix User Accounts

4.2.1 Using the VAS Administrative Tools

After installing the VAS Administrative Tools package a Unix Account tab appears in the
properties dialog of all Active Directory users as shown in Figure 4.1.

N OTE

If the Unix Account tab does not appear in the User Properties dialog, review
the installation steps outlined in the Vintela Authentication Services Installa-
tion and Configuration Guide to ensure that the VAS Administrative Tools
extensions were correctly installed. Refer to the troubleshooting appendix of
the VAS Installation Guide for more information.

43
 Figure 4.1. The VAS Unix Account tab

The following is a list of the different fields on the Unix Account tab for users.

Enable Unix Account Use this check box to enable and disable Unix and Linux accounts. Check
this to enable a user to login to Unix machines that have been joined to the domain.
Uncheck this check box to disable a user’s Unix account. Disabling a Unix account sets the
Login Shell to /bin/false which will prevent a user from getting shell access on any
Unix or Linux machine.

User ID Use this field to set the numeric Unix User ID or UID. It should be set to a numeric value
between 1000 and the maximum UID for your Unix platform. When you enable a Unix
account for the first time, a default value is generated by searching the user’s organizational
unit for an unused user ID. Use the Generate Unique ID button to search the entire Active
Directory forest for an unused UID. The forest-wide search is not performed by default,
since it may be very expensive and time consuming depending on your Active Directory
domain configuration. If the user is the first user to be Unix enabled in the organizational
unit, then the default value will be 1000. For more information on avoiding UID conflicts
see Section 4.4.

Generate Unique ID Click this button to search the Active Directory forest for an unallocated ID
and set the User ID field to that value. The generated ID value is guaranteed to be unique in
the forest.

44
Primary Group ID Use this field to set the Unix User Group ID or user GID that is used when
determining the group ownership of files that are created by the user. The Browse button
allows the administrator to look through and select the Primary Group ID from the list of
Unix enabled groups. However, it is not required that the Primary Group ID be set to a
value from the browse list. If the user’s Windows Primary Group is Unix enabled, then the
Primary Group ID will be set to the Windows Primary Group’s Unix GID by default.

Primary Group Name Displays the name of the group which has the GID value set in the
Primary Group field. If the Primary Group ID is set to a value not associated with a Unix
enabled Active Directory group, then the field displays the text Unknown Group.

Comment (GECOS) Use this free form field to store information that is found in the GECOS
field in /etc/passwd. This information is usually used to record the user’s full name and
other information (such as phone number and office location). The only restriction is that
this field must not contain a colon (:) character. The default value is the user’s full name.

Home Directory Use this field to configure the user’s Unix home directory. If the home directory
does not exist when the user logs into a machine for the first time, it can be created by the
pam vas module. However, since a great deal of Unix user profile information (for example,
desktop environment, shell profiles, and application specific settings) are saved in a user’s
home directory it is common to store home directories on a network file system such as NFS.
Storing home directories on a distributed file system is especially desirable in environments
where Unix users log in to multiple workstations. Automount utilities can be configured so
that the user’s same home directory information is available in the same directory location
across multiple Unix machines.

Login Shell Use this field to configure the user’s Unix login shell. This is the shell that is
executed when the user logs in using a terminal-based login. The default value for Login
Shell is generated based on the Login Shell of a similar Unix-enabled user in the same
organizational unit. If this is the first user to be Unix-enabled in the organizational unit,
then Login Shell defaults to /bin/bash. Login Shell must specify a program or script
that exists on all Unix systems the user will log into. Since login shells reside in different
directories on different Unix operating systems it may be necessary to use symlinks to
ensure that login shell locations are uniform across multiple Unix systems.

4.2.2 Managing User Accounts from the Unix Command Line

Using vastool you can create users, delete users, and list user information from scripts or the
Unix command line. To create a user, use the vastool create command. For example, the
following command would create the user bsmith in Active Directory :
$ vastool create bsmith
The command above creates a user in Active Directory that does not have its Unix Account
enabled. To create a user that has its Unix account enabled, pass in a string formatted like a line
from /etc/passwd as an argument to the -i option, as follows:

45
 $ vastool create -i \
"bsmith:x:1003:1000:Bob:/home/bsmith:/bin/bash" \
bsmith

By default all users that are created with vastool create are created in the Users Organizational
Unit (OU). To create a user in a different OU, use the -c command line option. For example, the
following command creates a Unix enabled user bsmith in the OU=sales,DC=example,DC=com OU:

$ vastool create -i \
"bsmith:x:1003:1000:Bob:/home/bsmith:/bin/bash" \
-c "OU=sales,DC=example,DC=com" bsmith

To delete a user, use vastool delete. For example, the following deletes the bsmith user:
$ vastool delete bsmith
To list users, use vastool list users. For example, the following command lists all the users with
Unix accounts enabled:

$ vastool list users

jdoe:VAS:1000:1000:John Doe:/home/jdoe:/bin/bash
djones:VAS:1001:1000:Dave Jones:/home/djones:/bin/bash
molsen:VAS:1002:1000:Mary Olsen:/home/molsen/bin/bash
bsmith:VAS:1003:1000:Bob Smith:/home/bsmith:/bin/bash

The vastool list users command above does not directly contact Active Directory. Instead it uses
the information from the vascd cache.
To bypass the cache and contact Active Directory directly, run the vastool list command with the
-l option as follows:

$ vastool list -l users

jdoe:VAS:1000:1000:John Doe:/home/jdoe:/bin/bash
djones:VAS:1001:1000:Dave Jones:/home/djones:/bin/bash
molsen:VAS:1002:1000:Mary Olsen:/home/molsen/bin/bash
bsmith:VAS:1003:1000:Bob Smith:/home/bsmith:/bin/bash

Using vastool list users with the -l option is not efficient when used repeatedly from scripts
because it generates LDAP traffic at every call. When scripting it is preferable to use vastool list
users without the -l option and rely on vascd to keep the cache up to date.

46
 N OTE

When troubleshooting problems it is often useful to compare the output of

vastool list users and vastool list -l users. Differences between the output
of these two commands indicates that vascd is having problems keeping
the cache up to date. If this is the case, the system administrator should
check the system log for vascd error messages and flush the cache using
the vastool flush command.

For more information about the vastool list command see the vastool man page in the appendix.

4.2.3 Moving Users in Active Directory

4.2.3.1 Moving Users to New Organizational Units

Use the move action or drag-n-drop functionality of the Active Directory Users and Computers
Snapin to move existing users from one organizational unit (OU) to another. As long as Unix
enabled users are only moved within the same domain, no additional configuration (other than
the move action) is necessary.

4.2.3.2 Moving Users to new Domains

Unix enabled users can be moved from one domain to another using Windows admin utilities
such as movetree and netdom. However, after moving the user object the user will not be able to
logon to Unix machines until the user’s User logon name (or userPrincipalName) is modified to
correspond to the new domain the user belongs to after the move.
To change the User logon name, open Active Directory Users and Computers. Open the new
user’s properties page and select the Account tab. Ensure that the suffix of the User logon name
matches the new domain. If necessary change the username domain component (for example, the
part beginning with an @) by selecting the appropriate value from the drop-down list. After
changing the User logon name, reset the user’s password.

4.2.4 Disabling Unix User Accounts

When you disable a user’s Unix account (by unchecking the Enable Unix Account check box),
the user’s login shell is set to /bin/false. This prohibits the user from logging in via
interactive login utilities. In technical terms, the check for whether or not a Unix account is
disabled is determined in a PAM session call. This means that non-interactive PAM enabled
applications that do not use the PAM session interface would still be able to authenticate the user.
An example of one such application is the POP3 daemon (pop3d) commonly distributed on
Linux. Since pop3d is not concerned with giving the mail user a login shell there is no need to call
the PAM session interface.
Therefore, in the case of pop3d (and other non-shell services) a user would be allowed to
authenticate even if their Unix Account was disabled. To completely disable an account for
interactive and non-interactive authentication, select the Account is Disabled setting from the

47
Account tab or right click on the user and select Disable Account in the Active Directory Users
and Computers Snapin.
Another important behavior of a user with a disabled Unix Account is that all of the Unix account
information remains valid even though the user is not able to log in on Unix or Linux hosts.
Retaining Unix account information for disabled Unix accounts is necessary in order for the
ownership of files and directories to be properly displayed (such as when using the ls -l
command). If the user is removed (by removing the Active Directory user object) files owned bye
the deleted user will be ”orphaned” and will be listed as being owned by a numeric UID.

4.3 Managing Unix Group Accounts

4.3.1 Using the VAS Administrative Tools

After installing the VAS Administrative Tools a Unix Account tab appears in the properties
dialog of all Active Directory groups as shown in Figure 4.2.

Figure 4.2. The VAS Group Tab

N OTE

If the Unix Account tab does not appear in the Group Properties dialog,
review the installation steps outlined in the Vintela Authentication Services
Installation and Configuration Guide to ensure that the VAS Administrative
Tools extensions were correctly installed. Refer to the troubleshooting ap-
pendix of the VAS Installation Guide for more information.

Enable Unix Group Use this check box to enable and disable a Unix Group. Enabling a Unix
group allows you to assign a Unix GID to the group so that it can be used for access control
on Unix. Disabling a Unix group deletes the GID attribute which prohibits users who are
members of the group from accessing Unix files based on Unix group permissions.

48
Group ID Use this field to set the numeric Group ID or GID for the Unix Group. It should be set
to a numeric value between 1000 and the maximum group ID for your Unix platform.
When you check the Enable Unix Group check box, a default value will be suggested by
searching the group’s organizational unit for an unused GID. You can use the Generate
Unique ID button to perform a search for a unique group ID across the entire Active
Directory forest. This forest-wide search is not performed by default since it can be very
expensive and time consuming depending on your Active Directory domain configuration.
If the selected group is the first group to be Unix-enabled in the organizational unit, then the
default value will be 1000. For more information on avoiding GID conflicts see Section 4.4.

Generate Unique ID Click this button to search the Active Directory forest for an unallocated ID
and set the Group ID field to that value. The generated ID value is guaranteed to be unique
in the forest.

4.3.2 Managing Active Directory Groups from the Unix Command Line

Using vastool you can create groups, delete groups, and list group information from scripts or the
Unix command line. To create a user, use the vastool create command. For example, the
following command creates the sales group:
$ vastool create -g sales
The command above creates a group in Active Directory that is not Unix-enabled. To create a
group that is Unix-enabled, pass in a string formatted like a line from /etc/group as an
argument to the -i as follows:
$ vastool create -i "sales:x:1003:" -g sales
By default all groups created with vastool create are created in the Users Organizational Unit
(OU). To create a group in a different OU, use the -c command line option. For example, the
following command creates a Unix enabled group sales in the OU=sales,DC=example,DC=com OU:

$ vastool create -i "sales:x:1003" \

-c "OU=sales,DC=example,DC=com" -g sales

To delete a group, use vastool delete with the -g option. For example, the following command
deletes the sales group:
$ vastool delete -g sales
To list groups, use vastool list groups. For example, the following command lists all the groups
with Unix accounts enabled:

$ vastool list groups

eng@example.com:VAS:1001:jdoe@example.com,djones@example.com
it@example.com:VAS:1002:molsen@example.com

49
 sales@example.com:VAS:1003:bsmith@example.com

The vastool list groups command above does not directly contact Active Directory. Instead it
uses the information from the vascd cache.
To bypass the cache and contact Active Directory directly, run the vastool list command with the
-l option as follows:

$ vastool list -l groups

eng@example.com:VAS:1001:jdoe@example.com,djones@example.com
it@example.com:VAS:1002:molsen@example.com
sales@example.com:VAS:1003:bsmith@example.com

Using vastool list groups with the -l option is not efficient when used repeatedly from scripts
because when called repeatedly it may generate too much LDAP traffic. When scripting it is
preferable to use vastool list groups without the -l option and rely on vascd to keep the cache
up to date.

N OTE

When troubleshooting problems it is often useful to compare the output of

vastool list groups and vastool list -l groups. Differences between the out-
put of these two commands indicates that vascd is having problems keeping
the cache up to date. If this is the case, the system administrator should
check the system log for vascd error messages and flush the cache using
the vastool flush command.

4.3.3 Moving Groups in Active Directory

4.3.3.1 Moving Groups to New Organizational Units

Use the move action or drag-n-drop functionality of the Active Directory Users and Computers
Snapin to move existing groups from one organizational unit (OU) to another OU within the
same domain. You cannot move Unix enabled groups across domain boundaries with Windows
utilities such as movetree and netdom. Instead, delete the group and recreate it in the new
domain.

4.3.4 Active Directory Group Types and Scopes

There are two types of groups in Active Directory, distribution groups and security groups.
Security groups can be used to set permissions and provide access control. VAS only supports
”Unix enabling” security groups. Distribution groups are not supported by VAS because they
cannot be used for security purposes.

50
An Active Directory security group can have one of the following scopes:

Domain Local The group is only visible within its local domain. Domain local groups can
include other groups and users from any domain (when Active Directory is in native
mode), but are only usable in the local domain and sub-domains.

Global The group is visible throughout the Active Directory forest but its membership is
restricted to users and groups within the same domain or a parent domain in the same tree.

Universal The group is visible throughout the Active Directory forest and may contain users,
other universal groups, and global groups from any domain. Universal groups are useful
when a group needs to be used in multiple domains.
As a general rule, the VAS client will only use ”Unix enabled” security groups that reside in the
same domain as the VAS client, or in the default account domain for the VAS client. For
information on configuring the default account domain for a VAS client, see the vascd man page
for information on the alt-account-realm. The exception is for cross domain logins. When a
user logins into a Unix host and it’s Primary GID is for a group in the user’s domain, VAS
performs additional group discovery to ensure that the name of the primary group of the user can
be resolved on the Unix host. Primary groups that come from other domains will be named
differently than the groups that reside in the same domain as the Unix computer. When displayed
the primary groups from other domains names will consist of the group name appended with
”@” then the domain name. This ensures that no group name conflicts occur.
You cannot use Unix enabled groups from other domains besides the default account domain on
a Unix host. Windows domain local groups from the domain where the Unix computer object
resides will always be visible to the Unix host, and can contain users from other domains. Groups
with global and universal scope can also be used by VAS, but they will only be seen by Unix hosts
when they are in the Unix host’s default account domain. Windows domain local groups that are
in the Unix host’s default account domain are the best choice for use in controlling access to Unix
files and resources.

4.3.5 Nested Group Support

Nested group membership support allows you to put several users in a group and then add that
group to a parent group. Once this is done, all the users in the child group are members of the
parent group as well. For example, suppose that you had a user jdoe in Active Directory. jdoe is a
member of the Unix-enabled group Accounting, and Accounting is a member of the
Unix-enabled group Western States. This is a nested group configuration. In this example the
Accounting group is nested within the Western States group. jdoe is a member of both
Accounting and Western States. Membership in Western States is granted implicitly through
membership in the Accounting nested group. VAS supports nested group membership.

4.3.5.1 How VAS Supports Nested Groups

When a user authenticates to a Windows 2000/2003 domain controller, information is passed

back to the VAS client in the Kerberos ticket. This information (called the PAC or Privilege Access

51
Certificate) contains a list of all the global groups that the user is a member of, including nested
group membership information. The PAC information is used in addition to the standard group
cache to process nested group information for a user when they login. This minimizes the
amount of LDAP traffic required to determine nested group membership.
Without using the information in the PAC the only way to determine nested group membership
would be to query Active Directory about all of the groups in the directory and their membership
lists. From that information it would be possible to reconstruct the membership tree. However,
each group query would generate network traffic and would also increase the time required for
logon and other activities. The time required to calculate nested group membership would
continue to increase for each additional group added to the environment. The amount of network
traffic generated would become prohibitive in large environments. By using the PAC VAS takes
advantage of the information Active Directory has already prepared to determine group
membership.

4.3.5.2 Nested Group Limitations

VAS only gets information from the PAC at logon. Therefore, nested group membership updates
only occurs during logon events. Once this information is determined, it is cached until the same
user logs on again. The changes in Active Directory will signal VAS to update the cache. The
limitations of this method are as follows:

Updates To Nested Group Membership Occur Only At Logon Time A user that logs in when
they are a nested member of a group will stay a member of that group on the UNIX
machine even if their membership has been changed in Active Directory until one of the
following happens:
The cache is flushed (removing all nested group membership information until the user’s
next login)
The user logs in again after the group membership changes have been made.

No Nested Domain Local or Universal Group Support Nested membership is only determined
for nested global groups. This is because the PAC does not contain group nesting
information for domain local or universal groups.

No Mixed Mode Support To be able to nest global groups inside of other global groups you
cannot be running in mixed mode (that is, with both Active Directory and NT domains).
Nested groups are not supported by NT Domains.

4.4 UID and GID Management

When using VAS to manage users from Active Directory it is important to keep track of Unix user
UIDs and Unix group GIDs. Without careful planning, it is easy to lose track of which UIDs and
GIDs have been used. The VAS Unix Account tab for users and groups will detect ID changes
and prompt you to perform a forest-wide ID conflict search. If a conflict is detected, the
conflicting object names are displayed and the ID value is rolled-back.

52
4.4.1 UID/GID Partitions

A simple way to avoid UID/GID conflicts is to divide up the UID/GID namespace according to
an administrative model that makes sense to the network administrator. This strategy works
especially well if you use organizational units (OU’s) to divide users and groups into logical,
separately managed, containers.
If a range of UIDs or GIDs is administratively allocated per OU, the network administrator can
avoid conflicts simply by using the default UID/GID recommendations that are displayed when
an account is Unix-enabled for the first time. The exception is when the first user or group in an
OU is Unix-enabled. In this case the administrator needs to manually set the UID and GID values
to the first value in the allocated UID/GID range for the new OU. After this, all new users that are
Unix-enabled will suggest non-conflicting default values based on existing Unix-enabled users in
that OU. For more information about creating users see Section 4.2.

4.4.2 Avoiding Duplications with Local Accounts

When creating local user accounts in /etc/passwd and /etc/group it is important to not
duplicate UIDs or GIDs of Unix-enabled Active Directory users and groups. The administrator
needs to be especially careful when creating users with the useradd or adduser commands.
Unless the -u option is used to explicitly specify the local accounts’ UID, the default behavior of
useradd is to use NSS calls to determine the next highest UID. If the nss vas module is configured
in /etc/nsswitch.conf as it should be for a machine joined to the AD domain, the result will
be the creation of a new local user in /etc/passwd with a UID that is one higher than highest
UID in Active Directory. Using the standard UID allocation mechanisms with the VAS Snapin, it
will be very easy to create a UID conflict between the local user and the next Active Directory
user to be Unix enabled.
For security reasons, the pam vas module prevents Active Directory users who share a UID with
a system account, or another Active Directory user, from logging in. The one exception is that
pam vas does not perform UID conflict checks for Active Directory users with UIDs under 1000.

4.4.3 Detecting ID Conflicts

During a user logon event, if a UID conflict is detected, an error message will be displayed at
logon indicating that the user is not allowed to log in because of a UID conflict which must be
corrected by the administrator. GID conflicts can also be detected at run time by pam vas. This is
not done by default for performance reasons, but can be enabled with the check gidconflict
option for pam vas.
To proactively detect UID and GID conflicts, use the Conflict Detection tab in the VAS
Configuration Utility which is installed as part of the VAS Administrative Tools package. For
more information on the Conflict Detection tab see Section 2.4.

4.4.4 Overriding Unix Account Information

In some deployment scenarios, adminstrators will find a need to modify some part of a user’s
Unix account on a certain machine. This is possible using the Account Override ability of vascd.

53
For a complete description of how to use the override features for users and groups, see the vascd
man page.

4.5 Password Management

4.5.1 Windows Domain Password Policies

Windows 2000 and Windows 2003 allow you to apply password policies to be applied to domains
and domain controllers through group policy. Windows domain password policies allow
administrators to enforce strong password policies for Windows users including settings for
minimum password length, password complexity, password change frequency, and password
history. VAS enforces all the Windows password policies for Unix logins. See the Microsoft
Windows server documentation for more information about setting Windows password policies.

4.5.2 Changing Passwords

One of the primary features of VAS is that users can use the same user name and password to
logon to both Windows and Unix. In conjunction with this feature it is also possible for a user to
perform a password change from Windows and Unix so that subsequent logins to either platform
will accept the new password.
Changing a user’s Active Directory password from Unix using VAS can be accomplished using
the vastool passwd command, or existing PAM enabled password utilities that work with the
pam vas PAM module.

4.5.2.1 Changing passwords with vastool passwd

Use vastool passwd to perform a password change or to set another user’s password. For
example the following command prompts the current user to change their password:
$ vastool passwd
vastool will prompt the user for their current password, and if that is valid, will prompt for the
new password.
If vastool passwd is run with the -u vastool option then it will perform a password change for
the user specified with the -u option. For example, the following command will let the current
user change bsmith’s password (assuming they know bsmith’s password):
$ vastool -u bsmith passwd
When using vastool passwd from scripts it is often advantageous to use the vastool -s option
which allows the password prompts to be satisfied with input from stdin. This vastool
functionality could be used from a corporate intranet page that allows users to change their
passwords. The intranet page would need to get the user’s old password and the new password,
and then call vastool passwd as follows:
$ vastool -u $USERNAME -s passwd

54
The caller must write the user’s current password, the new password, and a verification of the
new password to the stdin of the vastool passwd process.
If you specify a user name is specified on the vastool passwd command line as an argument, then
the password is reset (not changed) for that user. This requires administrative privileges. For
example the following command would reset the password for the bsmith user. unixadmin must
be a user with administrative privileges:
$ vastool -u unixadmin passwd bsmith
For more information on using the vastool passwd, see the vastool man page in the appendix.

4.5.2.2 Changing passwords with system utilities and pam vas

On PAM enabled systems, password changes generate calls to the password interface of the PAM
modules configured for use with the application or utility that is changing the password. The
most commonly used utility is /bin/passwd. When /bin/passwd is configured to use pam vas,
then the password change will be made on the domain controller for Unix-enabled Active
Directory users.
On some systems such as HP-UX and Solaris, the /bin/passwd command does not properly
leverage the PAM abstraction and contains mechanism specific code that is keyed by settings in /
etc/nsswitch.conf. If this is the case, you may see the following output:

passwd: Changing password for mattp

Supported configurations for passwd management are as follows:
passwd: files
passwd: files ldap
passwd: files nis
passwd: files nisplus
passwd: compat
passwd: compat AND
passwd_compat: ldap OR
passwd_compat: nisplus

Please check your /etc/nsswitch.conf file Permission denied

If you see the above output, you must use the vastool passwd command to change passwords of
Unix enabled Active Directory users as described in the previous section. To change passwords of
local users listed in /etc/passwd, use the passwd -r files command to instruct /bin/passwd to
change local passwords.
Note that on HP-UX the passwd -r files command does not work if the passwd entry in /etc/
nsswitch.conf has more than two entries.

4.5.3 Password Expiration

Active Directory allows the configuration of a password policy to force users to change passwords
often, to select strong passwords, or to force password change at the next login after resetting the

55
password. The pam vas module supports the full range of Windows password policy features.
When users log in and their password is expired, pam vas prompts for the old password, and a
new password using the ”PAM conversation” mechanism. However, not all applications use the
PAM interface correctly to support the interactive password change prompts that are provided
through the ”PAM conversation” mechanism. For example, Linux KDE’s kdm does not process
the PAM requests from pam vas correctly, but GNOME’s gdm and the system login applications
do.

4.6 Account Management in Multiple Domain Environments

4.6.1 Using an Alternate Default Account Domain

Each Unix host running Vintela Authentication Services builds a persistent cache of user and
group information. By default, the cache is built from users and groups in the same domain that
the Unix host is joined to. It is possible to change this default account domain to another domain.
This is useful in organizations that use ”Resource Domains”, where computer objects are stored
in a separate domain from the domains where users and groups are located. Configuring a
computer object’s default account realm to be the domain where the majority of users that access
it from provides significant performance advantages.
An alternate account domain can specified with the -a as an option to the vastool join command.
For example, the following command joins the Unix host to the computers.example.com domain,
and configure the default account domain to be users.example.com:
# /opt/vas/bin/vastool -u admin join -a users.example.com computers.example.com
You can change a computer’s default account domain at any time by adding the
alt-account-realm option to /etc/opt/vas/vas.conf in the ”[vascd]” section, and
running vastool flush. The following is an example of how to configure /etc/opt/vas/vas.
conf to make example.com the default account domain:

[vascd]
alt-account-realm = example.com

4.6.2 Cross Domain Logon with Simple Name

By default, users outside a Unix host’s default account domain must use their whole User
Principal Name (UPN) when logging into the machine. For example, user jane from the
users.example.com domain must type ”jane@users.example.com” to login, instead of just jane.
Users from the default account domain can login with only their ”simple name” since the default
account domain will be appended to their login name by the VAS authentication components.
Administrators can configure the VAS client so that users can login using their simple name (i.e.
just ”jane”) regardless of what domain they are from. Use the alt-auth-realms option to
configure a list of domains to use when building user UPN during login. You can specify this list
during vastool join with the -r option. The following command joins the example.com domain,

56
and adds the corp1.example.com and corp2.example.com domains to the alternate authentication
realms list:
# /opt/vas/bin/vastool -u admin join -r corp1.example.com,corp2.example.com
example.com
Note that the order of the domains in the list is significant. vascd will check the domains in the
order they are listed in to find the domain the user is in. If one domain will be used more often
than the others, you should put that first in the list.
You can change the VAS client’s alt-auth-realms setting at any time by adding the option to /
etc/opt/vas/vas.conf and then restarting vascd. The following is an example of how to
configure the alternate authentication realms to sub1.example.com and sub2.example.com:

[vascd]
alt-auth-realms = sub2.example.com, sub2.example.com

N OTE

When using the alt-auth-realms option, it is your responsibility to ensure

that there are no simple user name conflicts in your Active Directory forest. If
there is a situation where multiple users have different UPN’s, but the same
simple name (i.e. joe@example.com and joe@sub.example.com), one of the
users will not be able to login with their simple name.

4.6.3 Minimizing the Size of the User Cache

By default VAS will cache unix user information for all users in a domain on every machine
joined to that domain. This cache includes gid, uid, home directory etc. There may be situations
in which it is desirable to change this default behavior. An alternate caching method, known as
workstation mode, allows you to limit the size of the user cache by only caching user infomation
for users who actually logon to a particular workstation. This behavior must be enabled on a per
machine basis.
To enable this behavior, add the workstation-mode option to /etc/opt/vas/vas.conf in
the ”[vascd]” section. The following is an example of how to configure VAS for workstation
mode.

[vascd]
workstation-mode = true

57
4.7 Workstation Access Control

Administrators commonly want to restrict access to sensitive machines on the network to only
selected users and groups. This is especially true of Unix machines which are used to host
business critical applications.
VAS allows you to specify the Active Directory users, groups and domains that can authenticate
to Unix hosts. The VAS authentication modules (pam vas and the VAS AIX LAM module),
consult two configuration files in the /etc/opt/vas/ directory named users.allow and
users.deny. If either of these files exist then the VAS authentication components will use them
to determine which users should be allowed to successfully authenticate.
For a detailed description of users.allow and users.deny and their formats, see the pam vas
man page in the appendix.
In general, 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 UPN is specified in the
users.allow, the user will be allowed access. If the users.allow exists and is not empty,
users must be directly or indirectly allowed access or they will be denied by default. In cases
where the same user, group, OU (organization unit) or Active Directory domain membership is
specified in both users.allow and users.deny, the user is denied access. The following
matrix specifies the rules for system access when a user is specified directly or indirectly in both
the users.allow and users.deny files. ”D” denotes that a user is denied access, and ”A”
denotes that user is allowed access.
No File User Group OU Domain Not
No File A D D D D A
User A D A A A A
Group A D D A A A
OU A D D * A A
Domain A D D D D A
Not D D D D D D
The columns denote denied scenarios while the rows denote allowed scenarios. The following list
describes the denied scenarios which make up each column:

No File There is no /etc/opt/vas/users.deny file, or else it is empty with no entries.

User The user’s UPN is explicitly listed in /etc/opt/vas/users.deny.

Group A group that the user belongs to is listed in /etc/opt/vas/users.deny.

OU An OU that the user belongs to is listed in /etc/opt/vas/users.deny. For example, if a

user’s distinguished name is CN=John,CN=Users,DC=example,DC=com, then the OU of
CN=Users,DC=example,DC=com would match the John user.

Domain The Active Directory domain that the user belongs to is listed in /etc/opt/vas/
users.deny. For example, if a user belongs to the example.com domain, then

58
 ”@example.com” would be listed.

Not There is a /etc/opt/vas/users.deny with entries, but none include the user in any way.
The following list describes all of the allowed scenarios that make up each row of the matrix
(Each row name is listed, along with a description of how the scenario occurs):

No File There is no /etc/opt/vas/users.allow file, or else it is empty with no entries.

User The user’s UPN is explicitly listed in /etc/opt/vas/users.allow.

Group A group the user belongs to is listed in /etc/opt/vas/users.allow.

OU An OU that the user belongs to is listed in /etc/opt/vas/users.allow. For example, if a

user’s distinguished name is CN=John,CN=Users,DC=example,DC=com, then the OU of
CN=Users,DC=example,DC=com would match the John user.

Domain The Active Directory domain that the user belongs to is listed in /etc/opt/vas/
users.allow. For example, if a user belongs to the example.com domain, then
”@example.com” would be listed.

Not There is a /etc/opt/vas/users.allow with entries, but none include the user in any
way.

N OTE

*: If a user is both denied and allowed by means of OU membership, the OU

closest to the object takes precedence. If the same OU is specified in both
files, the user will be denied access.

59
Chapter 5

NIS COMPATIBILITY

5.1 A Brief NIS Overview

NIS (Network Information System) is a system for providing centralized control over many types
of network data. The NIS namespace includes information about users and groups, network
services and addresses, and different types of network resources. Each type of information is
found in a corresponding database, or NIS Map. NIS Maps are collections of key/value pairs and
are typically named for what type of information they contain, and what the key represents.
NIS is commonly used to provide centralized management of users and groups in Unix
environments. Information about users can be found in two maps, the passwd.byuid and
passwd.byname maps. Group accounts can be found in the group.bygid and group.byname
maps. Each of those maps contain the entries that would be found in /etc/passwd or /etc/
group, but each map differs by what the key is. The key for the passwd.byuid map is the user’s
Unix UID, and the key for the passwd.byname map is the user name. The map values are the
actual account entries. One important difference between standard NIS and the VAS NIS
implementation is that the VAS NIS server will never make the password hashes available in the
passwd or group maps. This is a serious security hole since it makes all password hashes
available to everyone who can access the NIS server. When using the VAS NIS components, you
should use the VAS authentication components like pam vas for authentication.
The NIS map databases are located and managed on a master NIS Server. The master NIS server
can also control slave NIS servers, which replicate the NIS Map databases managed on the master
NIS server. NIS clients query the NIS servers for the information contained in the NIS maps. The
NIS client uses the ypbind process to determine what NIS server, or ypserv daemon, it should
communicate with. For example, when a user attempts to login to a machine running the NIS
client, the NIS client queries ypbind for the NIS server to use, then queries the bound NIS server
for the passwd.byname map for the user’s Unix account information and password hash, which
is then used for NIS authentication.
Compatible NIS client and server implementations are available on most Unix flavors, and NIS is
widely deployed in Unix environments. Applications like automount, sendmail, and other core
Unix applications commonly use NIS and play a key role in Unix network infrastructure.
However, NIS does have a number of well-documented flaws, especially in regards to security,
that motivates administrators to look for migration alternatives. These flaws include the fact that
NIS does not use encryption to protect the information that is transmitted over the network,
which exposes user passwords to brute force attacks. There is also no mechanism for providing
secure trusts between NIS servers and clients – impersonation is very easy in environments

60
where there may be untrusted hosts on the network.
A newer version of NIS, NIS+, was invented to address some of these issues, but it has been
notoriously difficult to install and configure. In fact, the NIS+ technology has been end-of-lifed,
and it should be considered a legacy technology. This leaves Unix administrators with a difficult
situation when they have a large investment in their NIS infrastructure, but no clear migration
path. Vendors have enabled some applications to use LDAP for their NIS data stores, but the list
of applications that have been LDAP enabled is small, and all of the current LDAP schema
requirements for these applications are very complicated and heavily impact Active Directory
deployments.
As we’ll show in the following sections, the VAS NIS framework addresses all of the above
problems. VAS provides a secure environment, backwards compatibility with existing NIS
applications, a simple migration path, and an architecture that provides great scalability
enhancements that simplify the deployment of NIS.

5.2 The VAS NIS Support Components

5.2.1 The VAS NIS Schema Extension

VAS provides a simple architecture that provides a true migration path for administrators from
NIS to LDAP, while maximizing an organization’s investment in their current NIS infrastructure.
The VAS NIS support has been designed to closely match the way that Unix administrators are
used to managing their NIS data.
The VAS NIS support requires the VAS NIS schema extension to be applied to Active Directory.
This is a very small, simple extension that simply adds a new Object type – the NISMap object.
This object represents the typical NIS Map data file, like hosts. The actual data will be contained
in the nisMapData attribute on the NISMap object. From this object, multiple NIS Map databases
can be generated, depending how the admin configures the object using the VAS MMC NIS Map
Snapin extension, which is a standard part of the VAS MMC Snapin. The information that details
which map databases are generated for the NISMap object is contained in the nisMapFormat
attribute.
This simple schema provides a mechanism for easily creating custom NIS Maps without having
to have a large schema extension that provides for all of the possible NIS Maps an organization
may want to use. Many organizations have widely deployed non-standard NIS Maps that have
their own parsing scripts to build the NIS Map databases, and now these non-standard NIS Maps
can have their data ported to Active Directory along with their parsing scripts.

5.2.2 The VAS MMC NIS Map Snapin

NIS maps can be easily managed from a central location using the VAS MMC extensions installed
as part of the VAS Administrative Tools. The NIS Map extensions allow you to edit NIS Map
objects from Windows using the Active Directory Users and Computers MMC Snapin.

61
5.2.3 The vasypserv Daemon

Most Active Directory NIS/LDAP solutions require another service to run on the Active
Directory servers to provide the NIS gateway. The VAS NIS framework does away with this
requirement by providing the vasypserv daemon. vasypserv runs alongside vascd on each Unix
client, and uses LDAP secured with Kerberos session keys to get the NIS Map data from Active
Directory. Instead of managing a persistent cache of user and group information, it manages a
persistent cache of NIS Map databases that are built from the NISMap objects in Active Directory.
vasypserv operates as both this cache manager, and as an actual NIS server by implementing all
of the necessary RPC functions to act like a standard ypserv daemon would.
When using vasypserv, the NIS client should be configured to talk to the NIS server running on
the localhost interface (this NIS server is vasypserv). This provides a great security enhancement
over standard NIS in that there is no need to for NIS traffic to go over your network. Instead, NIS
traffic just goes over each Unix machine’s local network interface. The actual NIS map data is
transported over the network using secure LDAP. Since all applications can use the VAS
authentication components for authentication, there is no need to publish user password hashes
in the passwd NIS maps.
Instead of deploying one master NIS server along with multiple slave servers to provide NIS
support for an entire network, administrator’s now simply deploy the vasypserv daemon on each
VAS client. Each vasypserv daemon will only answer requests for the machine it is running on.
This allows the vasypserv daemon to be very small and have minimal computing requirements,
since it only has to serve the requests of one machine.

5.3 Windows Installation and Configuration

5.3.1 Installing the VAS NIS Schema Extension

The VAS NIS Schema extension must be installed to use the VAS NIS infrastructure. To install the
VAS NIS schema instructions, follow the same instructions specified in the VAS Installation
guide. This only needs to be done once on your Schema Master domain controller for your Active
Directory forest.

5.3.2 Installing the VAS NIS MMC Snapin Extension

The NIS related extensions to MMC are installed automatically as part of the VAS Administrative
Tools package. (VAS.MSI) The NIS extensions are not visible until the schema has been extended
to support nisMap objects.

5.4 Managing NIS Map Objects

When using the VAS NIS components, NIS Map objects will be created in Active Directory. NIS
Map objects hold two types of key information: 1) NIS Map data, and 2) the NIS Map database
configuration. The NIS Map data corresponds to the typical data files used on Unix NIS servers
that are used to manage the information in the NIS Map database. Typically this is data you
would find in /etc/hosts, /etc/aliases, or /etc/auto master on a Unix machine. The

62
NIS Map database configuration components list the type of maps generated for this NIS Map
object, and how to convert the NIS Map data into key/value pairs.

5.4.1 Creating NIS Map Objects

To create a NIS Map object in Active Directory, perform the following steps:
1. Navigate to the desired organizational unit, right click and select the New->VAS NIS Map
option in the context Menu. The following dialog appears:

2. Enter the name for the NIS Map object in the NIS map object name field.
3. Click Finish.
At this point, the NIS Map object is empty and has no configuration information. In order for it to
be usable by VAS NIS clients, you must add both the NIS Map data and the NIS Map database
configuration.

5.4.2 Managing NIS Map Data

The NIS Map data is stored in the nisMapData attribute as a free form string. There are two ways
to set this attribute – directly editing the attribute contents, or importing an existing file’s contents
to the attribute. Each method is described below.

5.4.2.1 Editing NIS Map Data

The Map Data tab allows you to edit the NIS map data:

63
You can use an external editor to edit the map data by clicking the External Editor button. This
will launch the application currently associated with .txt files. When you are finished editing in
the external editor, save and close the editor. Changes will be reflected in the Map Data edit box.
Click the Apply button to commit the NIS Map data to Active Directory.

5.4.2.2 Importing NIS Map Data

You can import existing NIS map data files by copying the existing files to a location accessible
from your Windows workstation. On the Map Data tab, click the Load From File button. A
browse dialog will appear. Select the existing NIS map file and click Open. The data will be
imported into the Active Directory NIS map object.
You can easily use this to import existing NIS Map data files that are commonly found on Unix
NIS servers. You can simply copy those files to your Windows administrative workstation
running the VAS NIS Map Snapin extension, and then import the files into the NIS Map objects.

5.4.3 Managing NIS Map Database Configuration

Multiple NIS map databases can be generated from a single NIS Map object. The Map
Configuration tab allows you to add maps that will be generated from the NIS map object:

64
Each map that is added to the object will generate a database on the Unix client. Maps have
associated names and parse scripts that generate key/value pairs from the NIS Map data. The
map name corresponds to the NIS Map name displayed by the ypwhich -m command. The
parsing script is any script that can be run on a Unix client, and parses a file specified on it’s
command line generating output in specific format expected by the vasypserv daemon. The input
file for the parse script is the NIS Map data specified on the Map Data tab. Every map that is
added to the Map Configuration tab will generate a new map database on the Unix client side.
The screenshot example contains two maps: hosts.byaddr and hosts.byname.

5.4.4 Example: Configuring a hosts NIS Map

It is common to use NIS to centralize management of the /etc/hosts file. With VAS, this is
done by creating a NIS Map object called hosts, and adding two maps to the object,
hosts.byaddr and hosts.byname. Both of these maps are generated using the same data which is
parsed differently by map parsing script. This example should help you understand how to use
the Active Directory Users and Computers snap-in to manage NIS maps. Before you begin, make
sure that you have extended the schema with the VAS NIS schema extensions and that you have
installed and configured the VAS Administrative Tools. To create a hosts NIS Map object and its
associated map databases, perform the following steps:
1. From Windows, start the Active Directory Users and Computers console.
2. By default, NIS Map Objects will only be available to VAS clients in the same organizational
unit. For this example, the hosts object will be created in the default Computers container.
Right click the Computers container in the left pane and select New -> VAS NIS Map.
3. The New NIS Map dialog appears. Enter ”hosts” as the name for the NIS map and click
Finish.

65
 4. Right click the newly created NIS map object and select Properties.
5. Click on the Map Data tab and enter the hosts information in the standard /etc/hosts
format. For example:
127.0.0.1 localhost.localdomain localhost
192.168.131.1 host1.example.com host1
6. Now click on the Map Configuration tab. Several standard map parsing scripts are
installed as part of the VAS Administrative Tools package. All preconfigured maps are
available from the dropdown list. Select hosts.byname from the dropdown list and click the
Add button. Notice that hosts.byname was added to the list of configured maps.
7. Click on hosts.byname in the map list. The Map Parsing Script field now contains the
script that will be run on the Unix client in order to generate the hosts.byname database
from the NIS map data. You should not modify the default scripts unless you know what
you are doing. They have been heavily tested to ensure that they work correctly with all
possible /etc/hosts formats on all supported Unix platforms.
8. Repeat steps 6 and 7 to add the hosts.byaddr map by selecting the hosts.byaddr item from
the dropdown list.
9. Click the Apply button to commit the configuration changes to Active Directory. The hosts
map will now be available to Unix clients that have been configured to use VAS NIS
compatibility.

N OTE

You can make changes to NIS Map object configuration at any time, and
those changes will automatically be recognized by all the VAS Unix clients.

5.5 Unix Installation and Configuration

Installing and configuring the VAS ypserv daemon is very simple, but it is important to follow a
certain order to ensure that the NIS ypbind daemon does not cause any system hangs. The
following sections document the installation and configuration steps for each supported Unix
platform.
Before installing and configuring the VAS NIS components, you should have previously installed
the VAS client software and joined the Unix machine to an Active Directory domain.

5.5.1 Linux VAS NIS Client Installation and Configuration

vasypserv is packaged in the vas-ypserv RPM, which can be found in the linux/ directory on
the installation media. To install and configure vasypserv on Linux, perform the following:

66
1. Ensure that the system ypserv daemon is not running. You can this by running the
following as root (you will not need to do this if ypserv has not previously been configured):
# /etc/init.d/ypserv stop
2. Ensure that the system ypserv daemon is not configured to start at system boot time. The
commands for doing this vary for the different supported Linux distributions. Please see
your operating system documentation for instructions on disabling system services.
3. Ensure that the system ypbind daemon is not running by stopping it with the following
command:
# /etc/init.d/ypbind stop
4. Ensure that the system ypbind daemon is configured to start at system boot time. The
commands for doing this vary for the different supported Linux distributions. Please see
your operating system documentation for instructions on enabling system services.
5. As root, mount the VAS installation CD, change directories into the linux/ directory, and
run the following command:
# rpm -Uvh vas-ypserv-2.6.2-1.i386.rpm
As part of the install process, vasypserv will be registered with chkconfig to start at system
boot time.
6. Configure the ypbind daemon to only talk to NIS servers on the local network interface by
modifying /etc/yp.conf to contain only the following entry:
ypserver localhost
7. Set the system NIS domain name to match the Active Directory domain you are joined to.
This can be done by running the following command as root:
# domainname example.com
Where example.com is the domain your machine has been joined to.
The NIS domain name should be set on a permanent basis. This can be done on Red Hat
Linux by modifying /etc/sysconfig/network to have the following option:
NIS DOMAIN="example.com"
where example.com is the Active Directory domain the machine is joined to.
On SUSE Linux, modify the /etc/defaultdomain file to include only the following entry:
example.com
Where example.com is the Active Directory domain you are joined to.
8. Start vasypserv with the following command:
# /etc/init.d/vasypserv start
9. Start ypbind with the following command:
# /etc/init.d/ypbind start

67
You now should be able to use the NIS utilities like ypwhich and ypcat to query vasypserv for
NIS Map data.

5.5.2 Solaris VAS NIS Client Installation and Configuration

vasypserv is packaged in the vasypserv pkg, which can be found in the solaris/ directory on
the installation media. To install and configure vasypserv on Solaris, perform the following:
1. Stop the system ypserv and ypbind daemons by running the following commands as root:
# /etc/init.d/rpc stop
To ensure that the system ypserv daemon will not start at boot time, make sure that the /
var/yp/$domainname directory does not exist, where $domainname matches the NIS
domain returned by domainname. You will not need to do this if the machine has not
previously been configured as a NIS server.
2. As root, mount the installation CD and change directories into the solaris/ directory, and
run the following command:
# pkgadd -d vasypserv SunOS 5.8 sparc-2.6.2.pkg all
3. Create the /var/yp/binding/example.com directory where example.com is the Active
Directory domain you are joined to.
4. Create the /var/yp/binding/example.com/ypservers file, and add the following
line, or modify the existing file to only contain this line:
localhost
5. Set the system NIS domain name to match the Active Directory domain you are joined to.
This can be done by running the following command as root:
# domainname example.com
Where example.com is the domain your machine has been joined to.
The NIS domain name should be set on a permanent basis. This can be done by modifying
/etc/defaultdomain to include only the following line:
example.com
Where example.com is the Active Directory domain you are joined to.
6. Start vasypserv with the following command:
# /etc/init.d/vasypserv start
7. Start ypbind with the following command:
# /etc/init.d/rpc start
You now should be able to use the NIS utilities like ypwhich and ypcat to query vasypserv for
NIS Map data. Note that on Solaris ypbind may not bind to vasypserv until some actual NIS
requests occur – this may take up to 30 seconds.

68
5.5.3 HP-UX VAS NIS Client Installation and Configuration

vasypserv is packaged in the vasypserv depot file, which can be found in the hpux/ directory on
the installation media. To install and configure vasypserv on HP-UX, perform the following:
1. Stop the system ypserv and ypbind daemons by running the following commands as root:
# /sbin/init.d/nis.server stop
# /sbin/init.d/nis.client stop
To ensure that the system ypserv daemon will not start at boot time, modify /etc/rc.
config.d/namesvrs and set the NIS MASTER SERVER and NIS SLAVE SERVER
variables to 0. You will not need to do this if the machine has not previously been
configured as a NIS server.
2. As root, mount the VAS installation CD and change directories into the hpux/ directory.
3. If installing on HP-UX 11i v1.6, use swinstall to install the IA-64 depot by executing the
following command:
# swinstall -s /cdrom/hpux/vasypserv ia164-2.6.2.depot
vasypserv
If installing on a HP-UX 11i v1 or 11.0, use the following command line to install the depot
for PA-RISC machines:
# swinstall -s /cdrom/hpux/vasypserv 9000-2.6.2.depot
vasypserv
4. Create the /var/yp/binding/example.com directory where example.com is the Active
Directory domain you are joined to.
5. Create the /var/yp/binding/example.com/ypservers file, and add the following
line, or modify the existing file to only contain this line:
localhost
6. Set the system NIS domain name to match the Active Directory domain you are joined to.
This can be done by running the following command as root:
# domainname example.com
Where example.com is the domain your machine has been joined to.
The NIS domain name should be set on a permanent basis. This can be done by modifying
/etc/rc.config.d/namesvrs so that the NIS DOMAIN variable is set to the Active
Directory domain that the Unix machine is joined to.
7. Ensure that the system NIS client processes will start at boot time. You must set the
NIS CLIENT variable in /etc/rc.config.d/namesvrs to 1.
8. Start vasypserv with the following command:
# /sbin/init.d/vasypserv start
9. Start ypbind with the following command:
# /sbin/init.d/nis.client start

69
You now should be able to use the NIS utilities like ypwhich and ypcat to query vasypserv for
NIS Map data.

5.5.4 AIX VAS NIS Client Installation and Configuration

vasypserv is packaged in the vasypserv bff package, which can be found in the aix/ directory on
the installation media. To install and configure vasypserv on AIX, perform the following:
1. Ensure that the system ypserv and ypbind daemons are not running by running the
following commands as root:
# stopsrc -s ypbind
# stopsrc -s ypserv
To ensure that the system ypserv daemon will not start at boot time, make sure that the /
var/yp/$domainname directory does not exist, where $domainname matches the NIS
domain returned by domainname. Also make sure that the all entries dealing with ypserv
and ypbind in /etc/rc.nfs are commented out. You will not need to do this if the
machine has not previously been configured as a NIS server.
2. As root, mount the VAS installation CD and change directories into the aix/ directory.
3. Use installp to install the package appropriate for your version of AIX. For AIX 5.1 and 5.2,
run:
# installp -ac -d vasypserv AIX 5 1.2.6.2.0.bff all
For AIX 4.3, run:
# installp -ac -d vasypserv AIX 4 3.2.6.2.0.bff all
4. Modify the /etc/rc.d/init.d/vasypserv file and set the VAS NIS DOMAINNAME
variable to match the Active Directory domain that the AIX machine is joined to.
5. Start vasypserv with the following command:
# /etc/rc.d/init.d/vasypserv start
This script will start ypbind with the -ypsetme option, and then set ypbind to talk to
localhost for it’s ypserv server. The vasypserv init script will stop ypbind as necessary as
well.
You now should be able to use the NIS utilities like ypwhich and ypcat to query vasypserv for
NIS Map data.

70
 I MPORTANT

You must not configure the NIS client using the standard AIX configuration
instructions. Normally, you would configure the system domain name and
enable the NIS client in /etc/rc.nfs. In order for vasypserv to work cor-
rectly on AIX, you must disable any NIS configuration in the /etc/rc.nfs
file.

5.5.5 NIS Map Search Locations

By default, the vasypserv daemon will only search the Active Directory container, or OU
(organizational unit) that the Unix computer object has been created in. You can override this
search location by using the search-base option that can be configured in /etc/opt/vas/
vas.conf. This allows you to have different sets of NIS Maps for different groups of Unix
clients. For more information on the search-base option, see the vasypserv man page.

5.6 Writing custom NIS Maps

The NIS Map object parse scripts generate the key/value pairs for a given NIS Map database
from the NIS Map content. They are shell scripts that are run on Unix clients by vasypserv when
it builds it’s persistent cache. Since they are shell scripts, they can utilize any type of shell
scripting interface that is available on Unix. Note that the NIS Map parse scripts run on every
Unix client that vasypserv runs on, so there may be some compatibility problems from platform
to platform with certain scripting languages like Perl. It is up to the administrator to ensure that
their parse script will work on each Unix client that they will be using vasypserv on.
The built in VAS parse scripts utilize the standard Unix utilities awk and sed to provide the
greatest level of compatibility between Unix flavors. You can use those as examples for how to
write your custom parser scripts.
When a parse scripts runs, it is passed the name of a file that contains the NIS Map contents as it’s
only command line argument. This will be available as the $1 argument in a standard shell script.
The parse script should read the specified file, and then output the key/value pairs to its stdout.
The key/value pairs must follow this format:

VASNisMapKey>key string
VASNisMapValue>value string

Where ”key string” is the literal key string, and ”value string” is the literal value string.
vasypserv will use this to determine what key/value pairs it adds to the database. Note that this
format allows for multi-line keys and values if your custom map format requires those.
You can easily test your NIS Map parse script by running it on a Unix host against a file that
follows the format of your NIS Map data file. Once your NIS Map parse script is finished, you can
load it into your NIS Map object using the Load from File button on the Map Configuration tab
of the NIS Map object properties page.

71
Chapter 6

MIGRATION

VAS provides several features that allow you to migrate user, group, and other configuration
information stored in flat text files to Active Directory, which then serves as the central
management point for both Windows workstations and Unix hosts.
Information in this section addresses the following concepts:
• Importing Users and Groups. See Section 6.1
• Migration from NIS. See Section 6.2
• Migration from MIT Kerberos. See Section 6.3

6.1 Importing Users and Groups

For environments that have preexisting /etc/passwd files and /etc/group files either locally
or through NIS, the vastool load command provides a way to import these users and groups into
Active Directory.
The vastool load command can read any file that follows the /etc/passwd or /etc/group
format, or it can read from it’s standard in.
vastool load does not check for UID/GID conflicts before creating the user and group objects.
Therefore, before importing a passwd file or a group file, make sure that the import will not cause
UID or GID conflicts with accounts that are already in Active Directory. It is also important to
make sure that the file does not contain local system accounts that would be inappropriate for
storage in Active Directory.
There may be situations where Active Directory accounts already exist for the Unix users and
groups and you simply want to import their Unix identity information (such as UID and GID). In
this situation you will want to use the -e option. Using the -e option will cause vastool load to
set the Unix attributes for existing users and groups that are being imported. For more
information on using the -e option see the vastool MAN page.
Also, note that only users with the appropriate administrative rights in Active Directory can
create users and groups. So if your current login session is not as an administrative user, use the
vastool -u option to specify the administrative user name.
To import users from a file run the following command:

72
 $ vastool -u unixadmin load -f /tmp/my_passwd_file.txt users

The above command creates all of the users from the /tmp/my passwd file.txt in the default
Users container in Active Directory. Use the -c option to specify a container in which to create
users. The following is an example of importing users into the sales OU:

$ vastool -u unixadmin load -f /tmp/my_passwd_file.txt \

-c OU=sales,DC=example,DC=com users

One limitation of importing users is the inability for VAS to preserve the passwords of imported
users. VAS does not have access to users’ plain text passwords, and Active Directory cannot
accept the encrypted password hashes that are stored in passwd files. Therefore, the vastool load
command generates a new random password for each user which is saved to a file the
administrator can use to notify users of their login password. Another option is to instruct
vastool load to set a common default password for all newly imported user accounts with the -p
password option.

N OTE

By default, imported users are forced to change their passwords when they
first login.

To import groups from a file run the following command:

$ vastool -u unixadmin load -f /tmp/my_group_file.txt groups

As with vastool load users, groups are created in the default Users container. Likewise, the -c
option can be used to load groups into a specific container as follows:

$ vastool -u unixadmin load -f /tmp/my_group_file.txt \

-c OU=sales,DC=example,DC=com groups

73
 N OTE

Group membership lists are stored in the Active Directory Group object’s
members attribute. The values stored in members must be distinguished
names (DN’s). In order to create the group object with its existing members,
vastool must look up each users DN, meaning that all members of the group
must already exist in Active Directory. When importing users and groups, you
should always import the users first, then the groups.

I MPORTANT

After migrating your local user and group accounts to Active Directory, it is
crucial to remove the user entries from /etc/passwd and /etc/shadow.
You also need to remove the group entries from /etc/group. This should
be done on every Unix machine where the accounts were previously. If the
accounts are not removed, then VAS will be unable to operate correctly.

6.2 Migration from NIS

It is possible to easily migrate existing NIS information to Active Directory for use with the VAS
NIS components. For a complete description of the VAS NIS infrastructure, see Chapter 5, NIS
Compatibility. Complete instructions on installing the VAS NIS components and configuring the
Unix NIS clients can be found in that chapter.

6.2.1 Migrating NIS User and Group Information

When using the VAS NIS components, there is no need to have specific NIS maps for user and
group information. These maps should be migrated using the steps outlined in Section 6.1. The
vasypserv NIS server will automatically handle all requests for the passwd.* and group.* maps
from the vascd user and group caches. The same limitations for migrating passwords for local
users and groups also applies when migrating NIS users and groups.

6.2.2 Migrating NIS Map Data

Other standard NIS Maps like the hosts map, autofs maps, and alias maps can be migrated to
Active Directory by following the instructions in Section 5.4.4 for creating a NISMap object for the
hosts NIS maps. Instead of manually creating the NIS Map data, simply copy the hosts data file
from your NIS master server to your Windows administrative workstation, and import that file
into your NIS Map object data tab. You will then need to configure your NIS Map parser scripts.
There are many parser scripts already written for the standard NIS Maps that can be reused.

74
When migrating custom NIS Maps, you will need to migrate both the NIS data and the NIS
parsing script that parses the NIS Map data into the database key/value format. For information
on writing custom parse scripts for NIS Maps, see Section 5.6.

6.3 Migration from MIT Kerberos

VAS provides the same Active Directory Kerberos interoperability as MIT Kerberos without its
associated complexity that goes along with it. Setting up Kerberos inter-operation with Active
Directory is as simple as installing VAS on a Unix computer and joining the computer to the
Active Directory domain. With VAS there is no need to create ”computer service accounts”,
export keytabs on the domain controller, manage keytabs on the Unix host, or manipulate
Kerberos configuration files.

6.3.1 Keytabs and the krb5.conf

Because VAS utilizes Kerberos v.5 and because its configuration and keytab files (/etc/opt/
vas/vas.conf and /etc/opt/vas/host.keytab, respectively) are compatible with structure
and functionality used by MIT Kerberos, migrating from MIT Kerberos to VAS is very simple.
Assuming VAS is already installed, complete the following:
1. If necessary, rename the existing MIT /etc/krb5.conf file.

# mv /etc/krb5.conf /etc/krb5.conf.orig

2. Create a symbolic link pointing from /etc/krb5.conf to /etc/opt/vas/vas.conf as

follows:

# ln -s /etc/opt/vas/vas.conf /etc/krb5.conf

3. Store cached Active Directory domain or Kerberos realm information in vas.conf by

executing the following command:

# /opt/vas/bin/vastool realms cache toconf

Because VAS utilizes DNS SRV records to discover domains and domain controllers, the /
etc/opt/vas/vas.conf file does not normally contain any specific realm configuration
information. When using VAS with MIT Kerberos, the /etc/opt/vas/vas.conf file
must contain explicit realm configuration for each Active Directory domain. This is
accomplished with the vastool realms cache toconf command as shown above.

75
 N OTE

If Active Directory servers are added to or removed from your network and
the DNS SRV records change, you may need to re-run vastool realms cache
toconf as shown above.

6.3.2 User and Group migration

Because MIT Kerberos is an authentication-only solution, most MIT Kerberos deployments still
require that Unix account information be stored in /etc/passwd and /etc/group, or in NIS. If
this is the case, users can be migrated to Active Directory using instructions provided in Section
6.1 and Section 6.2.

76
Appendix A

VAS TROUBLESHOOTING GUIDE

A.1 Troubleshooting the Unix Client

A.1.1 Attribute Permissions

In certain situations you may notice on of the following messages in your system log files:
Insufficient permissions to read uSNChanged attribute for <user name>. Cache updates for this user may
not occur.
or
Error retrieving UserAccountControl : No such attribute
Verify that the userAccountControl attribute can be read by authenticated users
These messages are the result of attribute permissions problems. VAS requires that the host
principal be able to read certain attributes. These attributes include uSNChanged and
userAccountControl. VAS will still continue to function if the host pricipal cannot read these
attributes, but it is recommended that the issue be resolved.
VAS stores a local cache of user and group information in order to reduce network traffic and load
on the Active Directory server. This allows VAS to scale well even in very large enterprise
environments. The local cache is updated incrementally by checking the value of the
uSNChanged attribute. uSNChanged is updated each time an object is modified in Active
Directory. In order for VAS to perform incremental updates, the Active Directory security policy
must allow host principals to read uSNChanged on user, group and NIS map objects.
If VAS is unable to read the uSNChanged attribute the above message will be written to the
system log. In this case you should modify the Active Directory security policy to allow
Authenticated Users read access on the uSNChanged attribute for user, group and NIS map
objects. How you enable this permission depends on your particular Active Directory
configuration and security policies. If you do not enable these permissions, VAS will fail to
perform incremental updates which may lead to an inconsistent state and/or performance
degradation.
VAS requires that the host principal be able to have read access to the userAccountControl
attribute. Allowing read access to this attribute makes it possible for the name service switch to
determine whether a user is enable or disabled. If the user is disabled, the name service switch
will not return a valid shell for the user. If this attribute cannot be read, the NS switch will not be
able to determine whether the users account is disabled or not. As a result the NS switch will

77
always return a valid shell. If your application depends on the NS switch to determine whether
the user should have a valid shell, you must enable read access to this variable.
This is an example of how you might enable read access on the uSNChanged attribute of all
objects in a particular OU using the ADSI Edit MMC snap-in. Only Authenticated Users will be
granted access.
1. Open the ADSI Edit MMC snap-in. ADSI Edit is installed as part of the Windows Support
Tools package.
2. Right click the ADSI Edit root node in the left panel and select Connect to....
3. In the Connection Settings dialog select the Domain well known naming context from the
drop down in the Connection Point group box. Click OK.
4. Navigate to the OU where your Unix-enabled users and groups are stored. Right click the
OU and select Properties. Click on the Security tab.
5. Click the Advanced button. The Advanced Security Settings dialog is displayed. Create a
new permissions entry by clicking the Add button. Specify Authenticated Users as the
object name to select. Then click OK. The permission entry dialog is displayed.
6. From the Apply onto drop down box, select This object and all child objects.
7. Click on the properties tab.
8. Click the Allow check box for the Read uSNChanged permission.
9. Repeat this procedure for any other OU’s where Unix users, Unix groups or NIS map
objects are stored.
Again, this is only an example of how you could enable read access on the uSNChanged attribute
for host principals. There are any number of ways to perform this operation that may be more
appropriate to your Active Directory deployment

78
Appendix B

UNIX PLATFORM LIMITATIONS

VAS functionality may have some limitations on certain platforms. These limitations are
generally a result of a specific OS limitation. This section will discuss the limitations for
supported operating systems, as well as available workarounds.

B.1 General UNIX limitations

B.1.1 Group Membership Limitations

On all UNIX systems there is a limitation to the number of groups a user can be a member of. On
Linux systems a user cannot be a member of more than 32 different groups. On other supported
platforms the limit is 16 groups per user. These limits are UNIX kernel limitations. If a user is a
member of more than the maximum number of UNIX enabled groups in Active Directory, they
will still only be a member of the maximum number of groups on the UNIX client. Under these
circumstances it is unpredictable which groups they will be left out of. In order to avoid
confusion, do not make a user a member of more than the maximum number of UNIX enabled
groups.

B.2 AIX Limitations

This section lists limitations associated with the supported AIX platforms (AIX 4.3.3, 5.1, 5.2).

B.2.1 User and Group Name Limitations

System Utilities on AIX cannot handle user names or group names greater than 8 characters in
length; therefore, it is recommended that all user and groups UNIX enabled for use on AIX
systems have their name length restricted to 8 characters. Users can login with their full User
Principal Name, but the length of the user-name up to the ’@’ character must be less than or equal
to 8 characters.
The following utilities experience some degree of limitation due to restricted name length:

su The su utility will not function if the user name argument is longer than 8 characters. This
presents a problem when attempting to ”su” to a cross domain user. If a cross domain user
has never logged into this machine, to ”su” to this user you must specify the full UPN. The

79
 full UPN will almost always be longer than 8 characters due to that fact that it contains both
the user name and the domain name (user-name@domain). This issue is less severe if the
user has already logged in. Since the user’s information will be in the cache, you do not
need to specify the full UPN unless the user-name is duplicated in multiple domains (For
example: joe@a.com and joe@b.com.)

groups The groups utility reports which groups a user is a member of. If the user is a member of
any groups with names longer than 8 characters the groups command will not function
correctly. The id handles situation more elegantly. Also, if a user belongs to a group that has
a space in it’s name, then groups will not function correctly either.
This typically will not create any security holes since each login process still gets it’s process
credentials set correctly. There may be other problems though depending on how your
applications use commands like groups.

passwd The passwd utility allows a user to change his or her password; however, the AIX
version limits user names to 8 characters. To work around this issue, you can use the
vastool passwd command. The vastool utility is installed with VAS and can be found in
/opt/vas/bin.

lsgroup The lsgroup will list information about a specified group, or if ”ALL” is specified, it will
list all groups. However, only the local groups will be shown when ”ALL” is listed. AIX
does not iterate through all of the configure LAM modules to get the available groups. In
order to see information about the VAS groups, use the vastool list groups command.
lsgroup also will not list groups that have a space in the group name. The groups exist, but
lsgroup does not process them correctly.
All login utilities can accept UPN’s longer than eight characters. However, you will experience
problems if the user-name portion of the UPN (the user-name up to the ’@’ character) is longer
than the 8 character limit. These include ssh, telnet, login, and rlogin.
All login utilities that use the LAM API for authentication, authenticate(), will be unable to
cleanup credentials during logout. LAM does not have a session cleanup API. Users should add
the following line to their $HOME/.logout to force their tickets to be cleaned up during logout.
/opt/vas/bin/vastool kdestroy

B.3 HPUX Limitations

This section lists limitations associated with the supported HPUX platforms

B.3.1 User Name Limitations

The telnet and login utilities on HPUX cannot handle user names greater than 16 characters in
length. The ssh utility is unaffected by this 16 character limitation. This limitation will become
most obvious when cross domain users attempt to login via a UPN (user-name@domain). To
work around this problem, refer to the section on enabling ”Cross Domain Login with Simple

80
Name”. If a user’s simple name (the user-name up to the ’@’ character) is longer than the 16
characters, he/she must use the ssh utility to login.

B.3.2 UID and GID Limitations

User IDs and Group IDs on HPUX have the limited range of 1 - 2,147,483,648. The VAS
Administrative Tools will allow for entering UIDs or GIDs as large as 4,294,967,296; however, the
IDs in the range of 2,147,483,648 - 4,294,967,296 are considered invalid on HPUX. Any user which
has a UID or primary GID in this range will be denied access. Additionally, any secondary group
memberships which have invalid GIDs will not be reported. If it is necessary to have UIDs or
GIDs in this range, you can use the user-override/group-override features to locally assign valid
IDs.

B.3.3 Authentication Limitations

The HP-UX telnet application does not correctly call the PAM session close API. This means that
credential cleanup does occur correctly. To ensure that a user’s credentials get cleaned up during
logout, the following line should be added to the user’s $HOME/.logout file:
/opt/vas/bin/vastool kdestroy

B.4 Solaris Limitations

This section lists limitations associated with the supported Solaris platforms

B.4.1 UID and GID Limitations

User IDs and Group IDs on Solaris have the limited range of 1 - 2,147,483,648. The VAS
Administrative Tools will allow for entering UIDs or GIDs as large as 4,294,967,296; however, the
IDs in the range of 2,147,483,648 - 4,294,967,296 are considered invalid on Solaris. Any user which
has a UID or primary GID in this range will be denied access. Additionally, any secondary group
memberships which have invalid GIDs will not be reported. If it is necessary to have UIDs or
GIDs in this range, you can use the user-override/group-override features to locally assign valid
IDs.

81
Appendix C

VASTOOL MAN PAGE

vastool

Name

vastool – A command line administration tool for use with pam vas, vascd, and nss vas.

Synopsis

vastool [-h] [-v] [-u username] [-w password] [-s] [-f] [-d] [-g level]
vastool command [vastool command arguments]

Description

vastool is a command line program that allows you to configure vascd, pam vas, and nss vas;
access information stored in Active Directory; and to store information in Active Directory.
vastool is located at /opt/vas/bin/vastool. It has been designed to be script-friendly and to
allow administrators to easily manage users, groups, and other information stored in Active
Directory from Unix/Linux workstations.
In order to run vastool, you must specify the options for vastool, a command to run, and the
options for that specific command. The following is a list of supported vastool commands and a
brief description of each command’s purpose. A more detailed explanation of each command will
follow later.

attrs List an Active Directory object’s attributes.

configure Update PAM, NSS, and other configuration files.

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

delete Delete users, groups, computer objects, or NIS Map objects in Active Directory.

flush Flush the vascd cache.

82
group Add or remove users from Active Directory groups.

info Provides information about the hosts Active Directory configuration.

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

join Configure the system to use pam vas for authentication, nss vas for NSS user and group
information, adds a computer object to Active Directory, and starts vascd.

kinit Perform kinit functions - obtains Kerberos ticket(s) for service(s).

klist Perform klist functions - lists the Kerberos tickets stored in the calling user’s credentials
cache.

kdestroy Perform kdestroy functions- destroys all existing tickets in the calling user’s credentials
cache.

license Install a license for the installation.

list List users and groups in Active Directory, along with their Unix account information.

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

merge Merge VAS users and groups into /etc/passwd and /etc/group

passwd Change your password or reset another user’s password in Active Directory.

realms Detect the realms (domains) on your network and the servers providing LDAP and
Kerberos services for those realms.

schema Detect and/or modify the Active Directory schema to be used for storage of VAS
attributes (such as UID).

service Manage service accounts in Active Directory.

setattrs Modify attributes of Active Directory objects.

83
timesync Query and synchronize system time with Active Directory or other specified time
server.

unconfigure Update PAM, NSS, and other configuration files to not use the VAS components.

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

user Enable or disable user accounts in Active Directory. This allows you to completely disable
the account, or only disable a users’s Unix account.

vastool Options

These are the options you can pass to vastool. They must be specified before the command name.

-h [command] If no command is specified, it shows the vastool usage and a list of available
commands. If a command is specified, it shows the usage for that vastool command.

-v Print out the vastool version and exit.

-u principal Sets the principal name to authenticate as when the vastool command needs to
access Active Directory. If the caller has root access, ”host/” can be specified and vastool
will authenticate as the computer object that vastool is running on.
If -u is not used, then vastool will authenticate as the calling user, and will attempt to reuse
Kerberos tickets from the user’s credentials cache. If -u is specified, then no existing
credentials cache will be used, and new tickets obtained will not be saved to disk.

-w password This option allows you pass in a password on the command line. Please note that
this is a security hole in a production environment. This option should only be used in
testing environments.

-s This option will cause vastool to not prompt for any initial passwords, but instead read them
from stdin. This allows you to use some vastool commands in a non-interactive mode.

-f By default, vastool will delete whatever tickets are obtained during it’s operation if an
alternate username is specified using the -u option. -f will cause vastool to not flush the
ticket cache, but keep them in a disk based ticket cache for the calling user.

-d This option will enable debugging output to stderr. This is useful when trouble shooting
problems.

84
-glevel This allows you to override the default debugging level that vastool uses when the -d
option is specified. By default, the debug level is 2. It can be set anywhere from 1 to 5, with
a higher level producing more debug output.

Vastool Command Synopsis

The following is a detailed description of all the available vastool commands. Their usage
descriptions, a detailed explanation of their purpose, how they work, and examples are included
for each command.

vastool attrs

vastool attrs can be used to view attributes stored on objects in Active Directory. These attributes
are the LDAP attributes on the objects in Active Directory.
vastool [vastool options] attrs [-u] [-s] [-g] [-d] objectname
attribute...
The objectname parameter will be interpreted differently according to the flag used. The
following list explains how each flag works.

-u Interprets objectname as a user name. This is the default behavior if no flag is specified.

-s Interprets objectname as a service principal name.

-g Interprets objectname as a group name.

-d Interprets objectname as an LDAP distinguished name. This allows you to view the attributes
on any object in Active Directory.
-u will cause vastool to interpret the name as a user name. This is also the default behavior if no
flags are specified. However, if the user name starts with ”host/”, then the name will be
interpreted as a service principal name. -s will interpret the name as a Kerberos service principal
name. -g will interpret the name as a group name.
Following is an example of getting the home directory for the user john, getting the last time the
computers container was modified, and getting a list of the members of the eng group.
vastool attrs john unixHomeDirectory
vastool attrs -d "CN=computers,DC=example,DC=com" whenChanged
vastool attrs -g eng member

vastool configure

vastool configure can be used to modify your system’s PAM, NSS, and your Kerberos realm
configuration. This command must be run as root.

85
vastool [vastool options] configure realm realm name [server...] |
extra-realm realm name server... | computer-name name | nss | pam
[-g] [service...]
Note that these commands are for advanced usage only. The vastool join will automatically
perform these steps for you.
Configuring the realm will modify /etc/opt/vas/vas.conf to use the given realm name as
your default realm. If a list of server names is passed in, these servers will stored as the servers
for the given realm. In Active Directory terms, the realm will be the domain name of the domain
this computer will be a member of. vastool configure extra-realm can also be used to configure
other domains if you need to support multiple servers in your Active Directory tree. This will
add information for these realms, but it will not make the new realm the default realm.
Configuring NSS will modify the passwd and group entries in the /etc/nsswitch.conf to
include an entry for vas, (the nss vas NSS module), after the files NSS module. You can manually
edit /etc/nsswitch.conf to put vas in front of files. This change will cause any username that
has both a local account and a VAS account to be resolved to the VAS account. By default, local
accounts will override Active Directory accounts. At this time, no other NSS subsystems besides
passwd and group are supported.
Configuring PAM will modify either /etc/pam.conf, or the files located in /etc/pam.d/ to
use the pam vas PAM module. If no service names are specified, then all existing services,
including the default ”other”, will be configured to use pam vas. For more information on
configuring and customizing pam vas, see pam vas(5). The optional -g will configure the PAM
configuration file with the get nonvas pass. This will cause pam vas to get password’s and set
the AUTHTOK item in the PAM stack on all platforms. On Solaris and HP-UX, vastool join uses
this option by default.
If you are configuring a computer whose hostname will not always match up with the name of
the computer object in Active Directory that represents your computer, you must use vastool
configure computer-name to specify the name of the computer as it appears in Active Directory.
Otherwise, your computer will not be able to communicate with Active Directory. When using
vastool join you can specify this name with the -n option.
Following is an example configuring the example.com realm, configuring the example.com realm
and using a special name for the host computer, configuring NSS, configuring all PAM enabled
services, and configuring the login, telnet, and ssh services to use VAS.
vastool configure realm example.com
vastool configure extra-realm sub.example.com
server.sub.example.com
vastool configure computer-name mycomputer
vastool configure nss
vastool configure pam
vastool configure pam login telnet sshd
If you are configuring a Solaris 8 or 9 system, you will need to use the -g option so that vastool
will configure the pam.conf file to better handle authentication. The pam vas module will prompt

86
all users for their passwords, and pass those passwords down to the other modules. This allows
VAS to do better checking for authentication and improve security. Using this option causes
vastool to modify the pam.conf file by either commenting out, altering, adding, or removing pam
options for other modules in the file besides those for the VAS line entries.
vastool configure pam -g
vastool configure pam -g login telnet sshd

vastool create

vastool create can be used to create a user, group, or computer object in Active Directory. This
command must be run as root when creating a computer object.
vastool [vastool options] create [-g] [-c container] [-p password] [-i
info] [-x] [-e] name
vastool create will interpret the specified name, and then create different types of objects
according to the format of the name. To create a computer object, the name must be formatted as
”host/FQDN” where FQDN is the fully qualified domain name of the computer. Note that
computer object creation is normally handled by vastool join- the create computer option is
provided for advanced users. To create a computer object for the local computer and use it’s
hostname, just specify ”host/”. If the name does not start with ”host/”, the name will be
interpreted as a user name if -g is not specified. The -g option will cause the name to be
interpreted as a group name, and a group object will be created.
Note that all user, group, and computer object creation can only be done in the Active Directory
domain your computer is a member of.
The new user, group, or computer object will be located in the default users or computer
containers in Active Directory. You can create the new object anywhere in the Active Directory
tree by using the -c option to specify the distinguished name (DN) of a container to create the
object in.
When creating a user or a group, the new user or group will not be Unix enabled by default,
unless you use the -i option. By specifying an information string with -i, you can specify the
information for the user’s/group’s Unix account. This string should be formatted as an entry in /
etc/passwd or /etc/group. When creating a user, you can specify that user’s new password
with the -p option. Unless the -x option was specified, the newly created user will also be forced
to change their password during their first login.
It is possible to Unix enable an existing user or group. To do this, use the -e option. You must
specify an information string with the -i when using -e. Note that this will not create the user or
group- it will only add the Unix/Linux attributes to an existing user or group. It will also
override those attributes if they already exist for the user or group, so use caution when using -e.
vastool create must be run as root when creating a computer object for the computer that vastool
is running on. Part of the computer creation process is setting the computer object’s password so
that vascd can authenticate to Active Directory. This key is stored in a secure file that can only be
accessed by root at /etc/opt/vas/host.keytab. vastool create does not need to be run as
root when creating users or groups.

87
Also, when creating a computer object without using just ”host/” as the name, you will need to
also run vastool configure computer-name {name}. This is just the first name part of the FQDN
that should be passed in the ”host/FQDN” string.
The user you authenticate to Active Directory as must have the appropriate administrative
privileges in order to create the new user, group, or computer object. Computer object creation
can be delegated to other users besides Administrators. To accomplish this, the Active Directory
administrator must initially create the computer object in Active Directory using vastool create or
vastool join. Then, the administrator can give another user rights to reset that computer object’s
password. This will allow that user to reinstall VAS without the administrator. In this situation,
vastool will recognize that the computer object for this computer already exists, and will just try
to reset the computer’s password.
Following are two examples of user creation, two examples of group creation, and two examples
of computer creation.
vastool -u admin create -c "OU=Engineering,DC=example,DC=com"
jdoe
vastool -u admin create -i "jdoe:x:1001:1000:John
Doe:/home/jdoe:/bin/bash" jdoe
vastool -u admin create -g marketing
vastool -u admin create -g -i "marketing:x:1005:john,mary"
marketing
vastool -u admin create host/
vastool -u admin create -c "OU=Engineering,DC=example,DC=com"
host/

vastool delete

vastool delete can be used to delete users, groups, computer objects, and NIS Map objects in
Active Directory. This command must be run as root when deleting the computer object
vastool [vastool options] delete [-g] [-n] [-d] name...
You must have the appropriate administrative rights to delete objects in Active Directory. The
names passed in will be interpreted according to the options used. The -g option will interpret
the names as group names and the Active Directory objects for those groups will be deleted. -n
will interpret the names as NIS Map objects. -d will interpret the names as LDAP Distinguished
Names.
If no options are specified, then the names will be interpreted as user names, unless the names
start with ”host/”, then the names will be interpreted as computer names. To delete the computer
object for the computer vastool delete is running on, use ”host/” as the computer name. You
must have root access to delete the computer object for the local computer, since the key for the
computer is removed from /etc/opt/vas/vas.keytab.
Following is one example of group deletion, one example of user deletion, one example of NIS
Map deletion, two examples of computer deletion, and an example of deleting an LDAP object.

88
 vastool delete -g eng
vastool delete jsmith
vastool delete -n hosts
vastool -u admin delete host/
vastool delete host/server.example.com
vastool delete -d "CN=Foo,DC=example,DC=com"

vastool flush

vastool flush can be used to clear the vascd cache. This command must be run as root.
vastool [vastool options] flush [-r] [-l] [-x] accounts | auth | keytab |
users | groups
Flushing the accounts cache will remove all cached user, group and NIS Map information. This
will force vascd to do complete lookups the next time it receives any NSS IPC requests. Flushing
the auth cache will remove all cached user passwords. These are stored as SHA1 hashes in a
secure file that is only accessible by root. Flushing the keytab will delete the VAS keytab file.
Flushing the users cache will delete all cached user account information, and flushing the groups
cache will delete all cached group information.
The users and groups cache will be regenerated after being flushed, unless the -r option is
specified.
If the -x option is specified, the password hashes from the authcache will only be removed if they
are older than the configurable max password age. The max password age is 30 days by default.
See /etc/opt/vas/vas.conf.sample for an example of changing the max password age.
If you do not specify an argument to vastool flush, then the accounts and auth arguments will be
implied, and all user/group account information, NIS Map information, and cached passwords
will be deleted.
On systems that do not support PAM and NSS, then as part of flushing the users and groups, they
will also be removed from the /etc/passwd and /etc/group files as well. If the caches are
regenerated, then the users and groups will be merged back in.

vastool group

vastool group can be used to modify group membership lists.

vastool [vastool options] group group name add | del name...
You must have enough administrative privileges to modify the group object in Active Directory.
Using the add option will add the listed users to the specified group. The del option will remove
the specified users. Note that these changes will only appear on the Linux/Unix systems if the
group and users used in the command have been Unix-enabled. The changes will occur in Active
Directory regardless of whether or not the users and groups have been Unix-enabled.

89
Please note that if the specified members do not already exist in Active Directory, then those
names will not be added or removed from the group membership list.
Following is an example of adding the jsmith user to the eng group, and removing the jsmith user
from the eng group.
vastool group eng add jsmith
vastool group eng del jsmith

vastool info

vastool info is used to collect information about the host’s Active Directory configuration.
vastool [vastool options] info site | domain | forest-root-dn | root-dn |
servers [domain]
The info command provides information about the host’s Active Directory setup. The site
option returns the name of the Active Directory Site to which this host belongs to.
The domain option returns the name of the Active Directory Domain to which the host machine
is joined.
The root-dn option returns the forest root of the domain to which you are joined. If you were
joined to example.com, root-dn would return DC=example,DC=com. The forest-root-dn
will return the DN of the Forest Root domain.
The servers option will show all of the available servers for a given domain, including which
are in the Unix host’s Active Directory site.
Following is example of how to use vastool info to determine the host machine’s default site.
vastool info site

vastool isvas

vastool isvas can be used to check if a given user is an Active Directory user. This is very useful
for scripting.
vastool [vastool options] isvas user name
This command will simply try to look up the given user in the vascd user cache. If the user is a
local account, then the exit code will be 2. If the user is an Active Directory account, then the exit
code will be 0. If the user is not a local account or from Active Directory, then the exit code will be
3. If the user is both an Active Directory user and also a local account, then the exit code will be 4.
If some internal error occurs, then the return code will be 1.
Following is an example of checking to see if the jsmith user is an Active Directory user, and if the
root user is an Active Directory user. The first command’s exit code will be 0 if jsmith is in Active
Directory, and the second command will return 2 since root is a local account.
vastool isvas user jsmith
vastool isvas user root

90
vastool join

vastool join is a convenient command that wraps all of the necessary steps to configure the VAS
client on a computer into one. It configures your Active Directory domain, creates a computer
object in Active Directory, and configures PAM and NSS. This command must be run as root.
vastool [vastool options] join [-c container] [-n computer name] [-r
domain list] [-a domain name] [-b search base] [-f] [-w] [-l]
domain name [server...]
vastool join will internally call vastool configure realm to configure the domain, vastool create to
create a computer object in Active Directory for the computer, vastool configure pam to configure
the PAM subsystem, vastool configure nss to configure the NSS subsystem, and vgptool apply to
license VAS using any existing group policy objects. The vascd client daemon will then be started.
During the client daemon’s start up the user and group caches will be flushed. For more
information on each of these steps, see their respective sections in this document.
The -c option will allow you to specify a container where your new computer object will be
created. If that is not specified, then the computer object will be created in the default computers
container. The -n option allows you to specify a different name for the computer object than what
vastool would generate from your hostname. If -n is used, then a special parameter will be set in
/etc/opt/vas/vas.conf to denote to all the VAS components which name should be used for
the computer object. You can also set this name by running vastool configure computer-name.
The computer name specified with the -n option should not be in the ”host/FQDN” form- it
should just be a name which is an alternative to the system’s hostname. If the name specified
does not have a ’.’ character in it, then the domain name will be appended to the specified
computer name to create a FQDN.
Following the options, you must specify your Active Directory domain, which will act as your
Kerberos realm. The services for this domain will be automatically detected through DNS and
LDAP lookups. If you do not intend to use DNS, or it has not been configured to support Active
Directory SRV records, you must specify a space separated list of domain controllers for the
domain you are joining after the domain argument.
If a computer object already exists in the directory for the computer name you are trying to use,
an error will be reported. To override the existing computer object, use the -f option. In this case,
the computer object’s authentication key will be reset. Any other systems authenticating as that
computer object will no longer be able to authenticate after the authentication key is reset.
If you wish to load the user and group caches from an alternate domain this can be specified with
the -a. If this is specified, your users and groups cache will not be loaded from the domain the
computer is joined to; instead they will be loaded from the specified alternate domain.
By default, the vastool join command will load the cache with all the Unix-enabled users and
groups in the domain. VAS can also load the user and group accounts based on a specific ”search
base”. Specify the -b to force VAS to load users and groups from the specified search base. Only
users and groups in the search base subtree will be added to the cache as part of the join
command. If you specify a search base from a domain that you are not joined to, you must use the
-a to specify the alternate domain.
VAS also provides a ”workstation-mode” which avoids the overhead of loading any users into
the cache. Workstation mode can be specified during join using the -w option. If -w is specified

91
during join, the users cache will remain empty until a user logs on. This caching mode follows a
”load on demand” model. A user will never be cached on a machine until he/she logs onto that
machine.
Vastool also supports a -r option. If you are configuring your host to allow cross domain login
using only the simple name, you must specify a domain search order for resolving simple names.
This can be specified at join time using the -r join option. This option expects a comma separated
list of domains for resolving simple names. The default domain (the domain the host is joined to)
MUST be included in this list. For more information about cross domain login with simple name
see the VAS administration guide.
If VGP (Vintela Group Policy) is installed on the host, vastool will use vgptool to apply all
configured Group Policy settings after the join is successful. This may include automatic licensing
of VAS. You can disable this behavior by using the -l option. For more information about using
VGP with VAS, see the VGP Administrators Guide.
The following is an example of vastool join using all of the defaults, then an example of joining a
computer with a name other than it’s hostname into a non default container in an environment
where DNS is not properly configured.
vastool -u admin join example.com server.example.com
vastool -u admin join -c "OU=Testlab,DC=example,DC=com" -n
test server example.com server.example.com

vastool kinit

vastool kinit can be used to obtain Kerberos tickets.

vastool [vastool options] kinit [service...]
If no arguments are specified, then the Kerberos TGT is obtained if it is not in the user’s ticket
cache. If services are specified, then those tickets will be obtained. If the -u vastool option was
not specified, then these tickets will be stored in the user’s ticket cache.
vastool kinit can be used to debug problems with Kerberos authentication. For example, to test if
vascd can authenticate to Active Directory, you would run as root:
vastool -u host/ kinit
Using the vastool -s option, you can use the vastool kinit command as an authentication API from
scripts and other programs which do not use PAM or the VAS API. This can be done by running:
vastool -u jdoe -s kinit
and then writing jdoe’s password to stdin of the vastool process. The exit code of the vastool
process will be 0 on a successful authentication, and 1 if authentication failed.
If you see any error messages, then vascd could not authenticate to Active Directory.

vastool klist

vastool klist can be used to list all of the tickets currently in the calling user’s Kerberos ticket
cache.

92
vastool klist [-f] [-v]
The tickets in the user’s ticket cache are printed to stdout. They will show the name of the service
each ticket is for, the time the ticket was issued, and the time the ticket will expire. The ticket
cache will be stored as a file owned by the user with permissions of 0600 at $HOME/.krb5cc or in
/tmp/krb5cc {user’s UID}.
The -f option will show the flags that apply to each ticket. The -v will list more details about
each ticket.

vastool kdestroy

vastool kdestroy will destroy all of the tickets that are in the calling user’s Kerberos ticket cache.
vastool [vastool options] kdestroy
A user’s Kerberos ticket cache is a file owned by the user with permissions of 0600 that will be
either at $HOME/.krb5cc or in /tmp/krb5cc {user’s UID}. Normally, the user’s Kerberos TGT is
stored there along with any other tickets that have been obtained. These tickets can all be cleared
with vastool kdestroy.

vastool license

vastool license will install a license key and print out the current license information. This
command must be run as root when installing a license key.
vastool [vastool options] license [-q] [-s] [-f file] [serial number
key]
vastool license can be used to look up the installed license information with the -q. It will report
how many users the installed license is good for.
To install a license, you must omit the -q and supply the serial number and key. This can be done
by supplying the serial number key as command line arguments, by using the -s to pipe them
into the process’s stdin, or by placing the serial number and key in a text file where the serial
number is on the first line, followed by the license key on the next line.
After installing a license, the users cache will be flushed to ensure that correct number of users is
loaded into the cache.
Following is an example of installing a license key, and an example of querying the current
license information.
vastool license -q
vastool license NOT-A-REAL-SERIAL-NUMBER PUT-YOUR-KEY-HERE

vastool list

vastool list can be used to list the users and groups that are stored in Active Directory.
vastool [vastool options] list [-a] [-l] [-f] [-c] users | users-allowed
| users-denied | user username | groups | group groupname

93
By default, vastool list will not directly use LDAP, but will use vascd to lookup the group and
user accounts. This allows vastool list to take advantage of vascd’s information cache. The -l
option will force vastool list to directly use LDAP and bypass the vascd cache.
The -a option will list all the users or groups in Active Directory, not just the Unix enabled ones.
If -a is used the the -l option will also be used automatically. When -a is used, only the name
attributes will be listed. Not using -a will list all of the attributes for Unix enabled groups and
users.
The -f option will force vascd to update it’s cache immediately, without respecting the vascd
update-interval setting. The -c will force data to be read from the cache without respecting the
vascd update-interval setting. (See the vascd man page for more information about
update-interval.
vastool list user and vastool list group will only list information about the Unix user/group
specified.
vastool list users-allowed and vastool list users-denied will list users that are denied or allowed
access to the Unix host according to the rules found in users.allow and users.deny. The -l can
not be used with the vastool list users-allowed or vastool list users-denied commands. See the
pam vas man page for information on users.allow and users.deny.
The following examples list all Unix enabled groups, list all Unix enabled users, list all Unix
enabled users (bypassing cache), list only users that are allowed to login
vastool list groups
vastool list users
vastool list -l users
vastool list users-allowed

vastool load

vastool load can be used to import existing users and groups.

vastool [vastool options] load [-f file] [-c container] [-p password]
[-x] [-e] [-r] users | groups
vastool load will read from a file if the -f option is specified, otherwise it will read from stdin.
The input must follow the format of /etc/passwd if loading users. If loading groups the input
must be formatted like /etc/group. You can load the users or groups into any Active Directory
container using the -c option. Otherwise, they will be created in the default users container.
Please note that existing passwords cannot be imported into Active Directory. If -p is used to
specify a password when loading users, all of the new users will have their passwords set to the
specified password. Otherwise, a random password made up of alphanumeric characters will be
generated for each user. These generated passwords will be stored in a file the administrator can
use to notify the new user’s what their password is. Unless the -x option was specified, the
newly created users will be forced to change their password during their first login. Passwords
cannot be set for groups, and the -p option is ignored when loading groups.

94
Any errors will be logged to stderr and a log file whose location will be printed out at the end of
the vastool load operation. It is very important to ensure that the UIDs and GIDs specified for the
users and groups being imported do not conflict with existing users and groups already in Active
Directory. The import process does not check for conflicts before creating the new users and
groups.
When importing groups that have members, those members need to be created first. For example,
for the following group entry: group1:x:1400:user1,user2,user3, you should first import user1,
user2, and user3. Otherwise, when the group object is created in Active Directory none of the
members will be stored in the group. This is due to the fact that group membership lists in Active
Directory are stored as lists of distinguished names, and those DNs cannot be looked up if the
group members do not already exist.
Once the load is complete, the vascd user or group cache will automatically be updated to get the
newly create users or groups. This can be disabled with the -r option.
There may be situations where you already have Active Directory accounts for the Unix/Linux
users and groups you are importing. In this situation you will want to use the -e option. This
will cause vastool to set the Unix/Linux attributes for existing users and groups that are being
imported. Note that this will not create users or groups; they must already exist in Active
Directory. An error will be reported for each user or group that is the list being imported that
does not already have an account in Active Directory.
The following is an example of importing a file of users into a specific Active Directory container,
and setting all of their default passwords to ”change.me”.
vastool load -f /tmp/newusers.txt -p change.me -c
OU=eng,DC=example,DC=com users
Note that after migrating Unix users and groups into Active Directory, you will need to remove
those user accounts from the local /etc/passwd and /etc/shadow files, and remove the group
accounts from /etc/group on every Unix machine where they were previously.

vastool merge

vastool merge can be used to merge Active Directory users and groups into the local /etc/
passwd and /etc/group files. This should usually only be done on systems that do not support
NSS and PAM, but is available on all platforms. This command must be run as root.
vastool [vastool options] merge [-h] users | user username | groups
vastool merge users will merge Active Directory user accounts into /etc/passwd. vastool
merge user will merge only the given user into /etc/passwd. vastool merge groups will merge
Active Directory groups into /etc/group. If no option is specified to vastool merge, then both
Active Directory users and groups will be merged into /etc/passwd and /etc/group
respectively.
vastool merge will ask vascd to update the vascd passwd cache or the vascd group cache, then
merge the Active Directory users or groups into the existing passwd and group files. Merging
will not occur if the vascd cache has not been updated since the last merge- this is determined by
comparing the timestamps between the local account files and the vascd cache files. To force the
merge to occur, use the -f option.

95
The -h option will change the merge behavior so that only users who have host access will be
merged. This will check the settings in the VAS users.allow and users.deny file, and only users
who are denied access will not be merged. The -h applies to both the vastool merge users and
the merge user command.
Account merging is not necessary for operating systems that support PAM and NSS. This
functionality is provided to allow for account synchronization on platforms that do not allow you
to use NSS and PAM. Also, account merging is done automatically by the VAS login utility when
users attempt to login- in this case you will not need to manually run vastool merge.
It is not possible to synchronize users’ passwords using vastool merge. Only their user account
information will be stored in /etc/passwd Due to this, you must use the applications bundled
with the VAS client software to allow the Active Directory users to have access to the operating
system where PAM is not supported.
Following is an example of merging the Active Directory user accounts, and an example of
merging the Active Directory groups.
vastool merge users
vastool merge groups

vastool passwd

vastool passwd can be used to change your password, or to reset another user’s password if you
have enough administrative privileges.
vastool [vastool options] passwd [-c] [user name]
On some platforms, such as United Linux based Linux distributions and Solaris 8/9, the system
passwd change utility does not work correctly when the vas NSS module is listed in /etc/
nsswitch.conf. VAS users will not be able to change their passwords using the system passwd
command. vastool passwd can be used by VAS users as a workaround.
If no user name is specified, then the calling user’s (or the user specified with the -u vastool
option) password will be changed. If a user name is specified on the command line after the
vastool passwd command, then vastool passwd will attempt to set the specified user’s password.
To set (or reset) passwords you must have administrative rights. vastool passwd changes
passwords in Active Directory using the Kerberos change password protocol.
Note that these two modes of password changing are fundamentally different. When changing a
password, you must authenticate as the user whose password is being changed. When setting
another user’s password, you must authenticate as an administrative user that has privileges to
reset that user’s password. Changing passwords requires knowledge of the user’s current
password; setting passwords does not.
The following is an example of the calling user changing their own password:
$ vastool passwd
The following is an example of the calling user changing the bsmith user’s password (Note that
the calling user must know bsmith’s current password):
$ vastool -u bsmith passwd

96
The following example shows the calling user resetting the bsmith user’s password. Note that the
calling user does not need to know bsmith’s password, but must authenticate as the calling user’s
identity, and must have administrative rights to set bsmith’s password.
$ vastool passwd bsmith
It is possible to use vastool passwd in a non-interactive mode by using the -s vastool option.
This will cause all password prompts to be satisfied by reading from stdin. This allows web
applications, scripts, and other applications to use vastool passwd for users. The application
must get the necessary information from the user and then supply that information to the stdin of
the vastool passwd command.
When using the vastool -s option while changing a user’s password, the caller must write the
user’s current password to stdin followed by the ’\n’ character, then write the new password
followed by the ’\n’ character, then write the new password again followed by the ’\n’ character.
The following example shows the correct options to change the bsmith user’s password and
supply the necessary information to the stdin of the process.
$ vastool -u bsmith -s passwd
The process should then write bsmith’s current password, the new password, and the
new password again to the stdin of the command.
The -c option allows the root user to set a user’s cached password. This is useful mainly for
debugging purposes. It does NOT change the user’s password in Active Directory, only in the
local cache.
One important note is that when using the pam vas PAM module with disconnected
authentication enabled, then vastool passwd will not be able to sync up the user credential cache
with the new password for the user since it will not have root access on the system. On systems
where the passwd utility correctly works, the user’s changed password will be synced up
correctly in the user credential cache.

vastool realms

vastool realms can be used to query the network for the Active Directory domains and also will
detect the domain controllers on the network. This information can be stored in the realms cache-
to do this you must be root.
vastool [vastool options] realms find root | srvs | domains [realm] |
site names | srvs | local | subnet | cache list | update |
update-realm realm | flush [realm] | toconf
vastool realms find will detect various settings, services, and domains on your network. realms
find root will detect the forest root. realms find domains will detect all of the domains in the
entire forest. realms find srvs will find the services for a given domain.
vastool realms site names will detect all of the configured Active Directory sites in your forest.
vastool realms site srvs will list all of the domain controllers and which site they are in. vastool
realms site local will detect what site the local VAS client should belong to. vastool realms site
subnet will determine the subnet of your client.

97
vastool realms cache list will print out the service and domain information that is stored in the
realms cache. This cache is used to decrease the amount of DNS traffic that must be performed by
the VAS client. vastool realms cache update will detect all of the domains and services in the
entire forest and store that information in the realms cache. cache update-realm will detect the
services and update the cache for only the given realm.
vastool realms flush will clear all of the entries from the realms cache, and reload it. If a realm
name is specified, then only the entries for the given realm will be reloaded.
When using VAS with MIT Kerberos compatible applications, you will need to symlink /etc/
krb5.conf to /etc/opt/vas/vas.conf. Before doing that though, you need to make sure
that all of the realm information in the VAS realms cache is stored in /etc/opt/vas/vas.conf.
This can be done with vastool realms toconf. This will make a realms entry for each realm VAS
knows about in the [realms] section. This way the MIT-compatible applications will be able to
work by reusing the VAS configuration information.

vastool schema

vastool schema can be used to detect if there are any schema extensions in Active Directory that
will support vas, cache those supported schema locally, and modify the local cache so that you
can mix and match among supported schema extensions
vastool [vastool options] schema list | detect | cache
schema detect will detect the preferred active directory schema. The currently supported schema
extensions are the VAS/RFC2307 extensions as well as the SFU 3.0 extensions. The schema
extensions are preferred in the above order. If you wish to change the schema extensions from
those which are preferred, use the vastool schema map command.
schema list will list the schema extensions currently being used by VAS
schema cache will detect the preferred schema extension available in Active Directory, as per
schema detect, and will then cache this list locally for use

vastool service

vastool [vastool options] service create [-c container] name spn... |

delete name | list name
vastool service can be used to create and delete service accounts in Active Directory. An Active
Directory service account is a user account which is intended to be used by services running on
Unix hosts. When a service account is created, a random password is generated for the account
and a Kerberos keytab is created for the service.
Each service has a User Principal Name (UPN), and an optional set of Service Principal Names
(SPN’s). The UPN is typically named service/host@domain, where service matches the type of
service running - for example, http/ or ftp/. The keytab file created for the service will be named
service.keytab and will be created in the VAS configuration directory at /etc/opt/vas. The
default permissions on the keytab file will be 0600 and the file will be owned by root. You should
update the ownership of the file so that the corresponding service has the rights to read from the
keytab file.

98
To create a service account, you must run vastool service create name as root where name is the
service account name. By default, the service account will be created in the default computers
container. You can override this location by using the -c option to specify an alternate OU to
create the service account in. If you specify service/ as the principal name, then the hostname of
the machine the command is run will be used to build a complete service principal name. You
must supply the username and password of an Active Directory user that has permissions to
create users. You can add an optional list of other servicePrincipalName’s to the account. An
example of create a service account for an SQL server is:
vastool -u admin service create sql/
To delete a service account, run vastool service delete name. The account in Active Directory will
be deleted, and the keytab file for the service will be deleted. For example, to delete the sql
service account, run:
vastool -u admin service delete sql/
You can list the service principals associated with a Service account with vastool service list
service. To list the principals associated with the sql service account, do the following:
vastool -u admin service list sql/

vastool setattrs

vastool setattrs allows you to directly modify the attributes of Active Directory objects, users, and
groups. You can clear attributes, set multi-valued attributes, and set single-valued attributes.
vastool [vastool options] setattrs [-s] [-g] [-d] [-m] [-r] object-name
attribute-list...
The first three options deal with how the object name is interpreted. The -s will interpret the
name as a service principal name, or a user principal name. The -g will interpret the name as a
group name. The -d will interpret the name as a distinguished name (DN).
The attribute list takes on a different format depending on the -m and -r options. If you would
like to set a list of single valued attributes, then do not use either of those two options. The
attribute list should then look like: [attributeName attributeValue] which can be repeated over
and over.
If you want to set a multi-valued attribute, such as the group attribute member, then use the -m.
The attribute list should then look like [attributeName value...].
If you want to clear an attribute, use the -r option. The attribute list then becomes just a list of
attribute names to clear.

vastool timesync

vastool timesync can be used to query the time on the Active Directory server and synchronized
the system clock with the Active Directory server. In order to set the system clock this command
must be run as root.
vastool [vastool options] timesync [-q] [server]

99
Running vastool timesync without specifying a time server will automatically use the Active
Directory server that was configured using the vastool join or the vastool configure realm
command.
Use the -q option to query the server’s time with out setting the system clock.

vastool unconfigure

vastool unconfigure can be used to remove the VAS configuration from the NSS and PAM
subsystems. This command must be run as root.
vastool [vastool options] unconfigure nss | pam [service...]
Running vastool unconfigure nss will remove the vas settings in /etc/nsswitch.conf.
Running vastool unconfigure pam without specifying any service names will remove the VAS
configuration from all PAM enabled services. If service names are specified, only those specified
services will have their VAS configuration removed.
Running vastool unconfigure with no arguments will unconfigure both the NSS configuration
and all PAM enabled services from using VAS.
The following are examples of removing the VAS configuration from /etc/nsswitch.conf,
disabling VAS authentication from the ssh server, and disabling VAS authentication for all PAM
enabled services.
vastool unconfigure nss
vastool unconfigure pam sshd
vastool unconfigure pam

vastool unjoin

vastool unjoin is a convenient command that wraps all of the steps to remove your computer
object from Active Directory and to remove the VAS configuration from the NSS and PAM
subsystems in one step. This command must be run as root.
vastool [vastool options] unjoin [-n computer name]
vastool unjoin will first remove the NSS and PAM configurations with vastool unconfigure. It
will then prompt you for your administrative password in order to delete the computer object for
your machine in Active Directory. As part of this process, vascd will be stopped.
If you used the -n option in the vastool join process, then you need to specify that same name
that you used in the join in the vastool unjoin process.
The following are examples of unjoining the machine where the computer object is named after
the system hostname, and unjoining the machine when the computer object name does not match
the hostname.
vastool -u admin unjoin
vastool -u admin unjoin -n computer name

100
vastool unmerge

vastool merge can be used to remove Active Directory users and groups from /etc/passwd and
/etc/group. This should only be done on systems that do not support NSS and PAM. This
command must be run as root.
vastool [vastool options] unmerge [users | groups]
vastool unmerge users will remove all Active Directory user accounts from /etc/passwd.
vastool unmerge groups will remove all Active Directory groups from /etc/group. If no option
is specified to vastool unmerge, then both the Active Directory users and groups will be removed.
Following is an example of removing Active Directory user accounts, and an example of
removing the Active Directory groups.
vastool unmerge users
vastool unmerge groups

vastool user

vastool [vastool options] user [-u] enable username shell | disable

username | checkaccess username | checkconflict username
The vastool user command allows you to enable or disable user accounts in Active Directory, and
to verify certain access scenarios typically done during user logins. You can either completely
disable the account, or only disable the account for Unix users. You may only Unix enable an
account with the vastool user command if it has been previously Unix enabled using the VAS
MMC snap-in.
The -u option allows you to specify that only the Unix account should be enabled/disabled.
Without the -u the enable/disable command applies to all platforms including Windows.
Disabling a Unix account simply consists of setting the user’s login shell to /bin/false. If the user
does not have a valid shell, login is not permitted. If you wish to Unix enable a disabled Unix
user you must specify the login shell (”/bin/bash”, or ”/bin/sh” for example).
The checkaccess command will evaluate whether or not the given user has access based off of
the same logic that pam vas uses during user logins. It’s exit code will be 0 if the user has access,
and 1 otherwise.
The checkconflict command will check if the given user has any UID conflicts using the same
logic as pam vas. If the user has a UID conflict, the exit code will be 1. If there is no UID conflict
for the given user, the exit code will be 0.
Following is an example of Unix enabling a user as well as an example of completely disabling a
user’s account. Both of these examples will use the fictitious account jdoe.
vastool -u admin-user user -u enable jdoe /bin/sh
vastool -u admin-user user disable jdoe

101
See Also

pam vas(5), vascd(1), nss vas(5)

Authors

Copyright 2003,2004 Vintela, Inc. All Rights Reserved

102
Appendix D

VASCD MAN PAGE

vascd

Name

vascd – The client daemon for use with pam vas and nss vas

Synopsis

vascd [-h] [-v] [-l] [-p pidfile] [-o user] [-f logfile] [-c
update-interval] [-n principal] [-t timesync-interval] [-r
realmscache-sync-interval] [-b ldap-timeout] [-m] [-d] [-g level]

Description

vascd is a daemon that must be started on UNIX/Linux workstations in order for pam vas and
nss vas to operate correctly. When started, vascd authenticates to Active Directory using
credentials that were established at the time that the computer object was created in the Active
Directory domain (see vastool(1) for details). vascd then uses this secure connection to Active
Directory to proxy and cache user and group account information for other processes.
The use of vascd allows several important features:
Security - Due to the way that PAM and NSS subsystems operate, most LDAP based UNIX
account management solutions require that anonymous or public access be allowed to UNIX
account attributes. Since vascd authenticates as an Active Directory domain computer, vascd can
access UNIX account information that is protected by Active Directory access control restrictions.
Scalability - Due to the way that the PAM and NSS subsystems operate, most LDAP based UNIX
account management solutions generate excessive numbers of LDAP connections and LDAP
search requests. This results in dramatically increased network traffic and load on the LDAP
server. vascd establishes a single connection to Active Directory for the computer it is running on,
and proxies all of the NSS requests through that single connection. At the same time, vascd is able
to perform intelligent caching of frequently used information so that LDAP traffic is reduced to
the absolute minimum.
Disconnected Operation - Since vascd maintains a persistent cache of frequently used
information, it is possible for the entire authentication system to continue to operate in

103
environments where the network connection to Active Directory is unreliable or completely
unavailable.

vascd Command Line Options

These are the options you can pass to vascd when starting the daemon.

-h Shows the vascd usage.

-v Print the vascd version and exit.

-l Print the vascd licensing information and exit.

-p pidfile Specify an alternative pid file. Default is /var/state/vas/vascd/.vascd.pid

-o user Run vascd as the specified user. Default is daemon.

-f logfile Specify an alternative log file. Default uses syslog if the system supports syslog.
Otherwise, vascd will log to /var/log/vascd by default.

-c update-interval Specify the ”blackout” period in seconds. Default is 600 seconds (10
minutes). This setting can also be set in vas.conf file in the ”[vascd]” section. An example
is:

[vascd]
update-interval = <seconds>

In order to minimize network traffic and the load on the directory server, vascd aggressively
caches data that is retrieved from the directory server so that subsequent requests can be
satisfied from the cache with out having to contact the directory server. The cache is only
updated when it is determined that a change has been made in the directory. Nevertheless,
due to the way that the NSS subsystem is called it is not uncommon for hundreds of
requests to be generated in a matter of seconds. Therefore, in order to further reduce the
load on the network and on the directory, vascd enforces a ”blackout period” during which
all requests will be resolved from the cache.
By default the blackout period is set to 10 minutes. What this means is that the addition of
new users and changes to UNIX account information may take as long as 10 minutes to
become visible on the Linux/Unix workstation due to the blackout period. For
environments where changes must take affect quicker, it is possible to change the ”blackout
period” using the -c command line option when starting vascd. Using -c to decrease the
”blackout period” will result in a system where hosts are more responsive to changes made

104
 in Active Directory– at the expense of increased network traffic and load on the Active
Directory server.
The amount of additional network traffic depends on the number of Linux/UNIX hosts and
their use. In small installations (less than 100 hosts or less than 100 users) the ”blackout
period” could be safely reduced. In larger installations it is recommended that the ”blackout
period” be left at the default value or increased to 30 minutes or 1 hour. Regardless of the
”blackout period”, the administrator can force vascd to update the cache immediately by
signaling vascd with SIGHUP or by executing vastool flush, which will cause vascd to
reload all of it’s information.

-n principal The principal name that vascd will authenticate as. There must be a valid
keytab entry in the vas.keytab file for the principal. By default vascd will authenticate as the
host principal created during vastool join.

-t timesync-interval vascd will operate as a time synchronization agent if, on start up,
vascd detects that no other process has bound the NTP port (123). If the NTP port is not
bound, vascd will issue SNTP requests to the host that was configured with the vastool join
or vastool configure realm. The -t option allows the system administrator to specify the
frequency (in hours) that time synchronization occurs. The default is every 12 hours. If the
timesync-interval is set to 0 vascd will not operate as a timesync agent.
If a specialized NTP daemon is used to synchronize time, it is crucial that this daemon be
started *before* vascd. This way the NTP port will be bound when vascd starts. vascd will
not operate as a timesync agent and there will be no conflicts. If, for some reason, vascd
must be started before the NTP daemon, then the -t option should be set to zero to disable
vascd timesync and avoid what would otherwise be time synchronization thrashing
between the specialized NTP daemon and vascd.
This option can also be specified in /etc/opt/vas/vas.conf in the ”[vascd]” section.
An example is:

[vascd]
timesync-interval = <hours>

-r realmscache-sync-interval vascd will rebuild the realms cache periodically. This

cache is used to reduce the amount of DNS traffic that is needed in order to discover all of
the services in the Active Directory Domains- vascd will rebuild this cache periodically to
get any updates that have been made. Setting this option to 0 will disable the realms cache
syncing. By default this is done every 24 hours.
This option can also be specified in /etc/opt/vas/vas.conf in the ”[vascd]” section.
An example is:

105
 [vascd]
realmscache-sync-interval = <minutes>

-b ldap-timeout The -b option allows you to modify the default timeout that vascd will use
when waiting for LDAP searches to complete. By default, this is set to 30 seconds. In some
situations you may want to extend this. For example, Windows 2000 is much slower than
Windows 2003 when doing group searches. If you have a large amount of groups and you
see timeout errors from the vascd logs where the groups cache seems to be missing some of
the groups, then try extending the ldap timeout.
This option can also be specified in /etc/opt/vas/vas.conf in the ”[vascd]” section.
An example is:

[vascd]
ldap-timeout = <seconds>

-m The deamon will not load the users cache from default domain. Instead users will only be
cached as needed. Before a user will appear in the cache they must login at least once.
This option can also be specified in /etc/opt/vas/vas.conf in the ”[vascd]” section.
An example is:

[vascd]
workstation-mode = true

-d Causes the daemon to not detach from the controlling tty, and prints debugging messages to
stderr. This is useful for debugging purposes.

-g level This allows you to override the default debugging level that vascd uses when the -d
option is specified. By default, the debug level is 2. It can be set anywhere from 1 to 5, with
a higher level producing more debug output.

vascd vas.conf Options

There are other options that can be specified in /etc/opt/vas/vas.conf to customize the
behavior of vascd. The following options must all be configured in the ”[vascd]” section in order
to be used.

106
alt-search-base By default vascd caches all users and groups in the domain to which your
computer is joined. Under some circumstances it may be desirable to cache users and
groups from only a portion of the domain tree. To specify where in the domain tree to
search for users and groups, use the alt-search-base option.
An example of specifying a alternate search base of the users container in the example.com
domain would be:

[vascd]
alt-search-base = cn=Users,DC=example,DC=com

alt-auth-realms When users login to a Unix host through VAS, the VAS components must
resolve the user’s full userPrincipalName and determine where that user exists in the
Active Directory forest in order to determine what server to perform authentication against.
Users may login with their full userPrincipalName, including login suffix, to avoid the need
for resolving the user’s userPrincipalName. However, in most cases administrators will
want to allow users to login to Unix hosts with their simple names.
By default, vascd will use a list of possible logon suffixes generated from the alternate login
suffixes configured in Active Directory and the domains in the forest to search. This allows
a user from any domain or logon suffix to login with their simple user name. This search
order can be overridden with the alt-auth-realms option in situations where
administrators want to optimize that search path. You can specify this list during vastool
join with the -r option. The following command joins the example.com domain, and adds
the corp1.example.com and corp2.example.com domains to the alternate authentication
domains list:
# /opt/vas/bin/vastool -u admin join -r
corp1.example.com,corp2.example.com,example.com example.com
Note that the order of the domains in the list is significant. When a user attempts to login,
vascd checks the domains in the order they are listed. If one domain will be used more often
than the others, you should put it first in the list. When using alt-auth-realms, it is
necessary to put your default domain in the list. If you do not, you will not be able to login
with simple name from your default domain.
You can change the VAS client’s alt-auth-realms setting at any time by adding the
option to /etc/opt/vas/vas.conf and restarting vascd. The following is an example of
how to set the alternate authentication realms to sub1.example.com and sub2.example.com:

[vascd]
alt-auth-realms = sub1.example.com,sub2.example.com,example.com

107
 When using the alt-auth-realms option, it is your responsibility to ensure that there are
no simple user name conflicts in your Active Directory forest. If there is a situation where
multiple users have different UPN’s, but the same simple name (i.e. joe@example.com and
joe@sub.example.com), one of the users will not be able to login with their simple name.

workstation-mode By default VAS will cache unix user information for all users in a domain
on every machine joined to that domain. This cache includes gid, uid, home directory etc.
There may be situations in which it is desirable to change this default behavior. An alternate
caching method provided by VAS allows you to limit the user cache to those users who
logon to a particular workstation. This behavior must be enabled on a per machine basis.
To enable this behavior, add the workstation-mode option to /etc/opt/vas/vas.
conf in the ”[vascd]” section. The following is an example of how to configure /etc/opt/
vas/vas.conf to cache only those users who logon to the machine:

[vascd]
workstation-mode = true

After changing the conf file you must flush the vascd cache using the command vastool
flush. Changes to the caching method will not be apparent until you have flushed the cache.
To return VAS to the default caching mode, set workstation-mode to false (or remove the
workstation-mode option) and flush the cache.
You may also enable workstation mode at join time using the -p vastool join option.

alt-account-realm Each Unix host running Vintela Authentication Services builds a

persistent cache of user and group information. By default, the cache is built from users and
groups in the domain that the Unix host is joined to. Using the alt-account-realm
allows you to specify an alternate domain from which to populate the host’s user and group
cache. This is useful in organizations that use ”Resource Domains”, where computer objects
are stored in a domain separate from the user and group accounts. In instances such as this,
configuring a computer object’s ”alt-account-realm” to be the ”Resource Domain” provides
a significant performance advantage.
An alternate account domain can be specified with the -a option to the vastool join
command. For example, the following command joins the Unix host to the
computers.example.com domain, but loads the local cache with the users and groups in the
users.example.com domain:
# /opt/vas/bin/vastool -u admin join -a users.example.com
computers.example.com
You can change a computer’s default account domain at any time by adding the
alt-account-realm option to /etc/opt/vas/vas.conf in the ”[vascd]” section, and

108
 running thevastool flush command. The following is an example of how to configure /
etc/opt/vas/vas.conf to make example.com the default account domain:

[vascd]
alt-account-realm = example.com

debug-level You can enable debug output without having to run the daemon from the
command line with the -d option. By specifying debug-level in the vas.conf, you can
enable debug output from the daemon in normal operation. The value should be set to an
integer between 1 and 6, with 6 producing the highest level of debug output. This
information will be logged using syslog debug messages, so syslog must be configured to
log syslog.debug messages in order to view the debug output. Debug levels of 3 and above
produce a plethora of debug output, so use this option with caution.
An example of specifying a debug level of 2 is:

[vascd]
# get verbose application debug messages
debug-level = 2

password-change-interval The password for the host principal is changed automatically

every 30 days by default. You can specify how often the host password should be changed
using the password-change-interval option in the vas.conf file. The interval is
specified in days. In the following example, the password is changed every 15 days:

[vascd]
password-change-interval = 15

user-override-file By default, the account override file for users is located at /etc/opt/
vas/user-override. You can change this location by specifying the absolute path to
another text file with the user-override-file option. In the following example, the user
override file is changed to a NFS mounted location.

[vascd]
user-override-file = /net/fs.example.com/data/vas/user-override

109
group-override-file By default, the account override file for groups is located at /etc/
opt/vas/group-override. You can change this location by specifying the absolute path
to another text file with the user-override-file option. In the following example, the
group override file is changed to a NFS mounted location.

[vascd]
group-override-file = /net/fs.example.com/data/vas/group-override

Configuring Unix Client Schema Mappings

As part of the vastool join process, schema detection is performed. You can view the results of
this schema detection with the following command:
# /opt/vas/bin/vastool schema list
If the detected schema configuration is not what you want to use, you can specify a schema
mapping in /etc/opt/vas/vas.conf. The schema mapping must be made in the ”[vascd]”
section. The following options are supported:

uid-number-attr-name The name of the LDAP attribute that contains the Unix UID for users.

gid-number-attr-name The name of the LDAP attribute that contains the Unix GID for groups,
and the name of the attribute used for the Primary Group GID for users.

gecos-attr-name The name of the LDAP attribute that contains the GECOS information for users.

home-dir-attr-name The name of the LDAP attribute that contains the Unix home directory for
users.

login-shell-number-attr-name The name of the LDAP attribute that contains the name of users’
Unix login shell.

group-member-attr-name The name of the LDAP attribute that contains the membership list for
groups. This attribute must be multi-valued and contains the distinguished names (DN’s)
of all the users that belong to the group. If you override this attribute it will require you to
maintain two separate group membership lists (one for windows group membership and
one for unix group membership). VAS uses the windows group membership list by default.
Overriding this attribute is not recommended.

110
memberof-attr-name The name of the LDAP attribute that contains the list of the groups that a
user belongs to. This attribute must be multi-valued and contains the DN’s of all the groups
the user belongs to. If you override this attribute it will require you to maintain two
separate group membership lists (one for unix group membership and one for windows
group membership). VAS uses the windows memberof attribute by default. Overriding this
attribute is not recommended.

nismap-objectclass-attr-name The objectclass of the schema extension used to store NIS maps.

nismap-name-attr-name The name of the LDAP attribute used to store the name of the NIS map

nismap-data-attr-name The name of the LDAP attribute used to store the contents of the NIS
map

nismap-format-attr-name The name of the LDAP attribute used to store NIS map parser scripts
and other formating information.
The following is an example of how you would configure a schema mapping for the SFU 3.0
schema extension:

[vascd]
uid-number-attr-name = msSFU30UidNumber
gid-number-attr-name = msSFU30GidNumber
gecos-attr-name = msSFU30Gecos
home-dir-attr-name = msSFU30HomeDirectory
login-shell-attr-name = msSFU30LoginShell

Note that you do not typically need to do this, as vastool will auto detect this same configuration
if the only supported schema extension installed is the SFU 3.0 schema extension. It may become
necessary to configure these attributes when multiple supported schema extensions are installed.
Any time you make changes to the schema mapping, you should run vastool flush. This will
ensure that vascd is restarted and uses the new attribute names. It will also ensure that the user
and group databases get reloaded so that the cached information matches the newly configured
schema mapping.
You can actually specify this mapping in /etc/opt/vas/vas.conf before running vastool
join. This is useful during large deployments of VAS since you can avoid having to run vastool
flush after each host is joined to the domain.

Overriding Unix Account Information

Administrators may have a need to customize Unix account information for certain users and
groups on individual machines. For example, a user who accesses both Linux and Solaris
machines may want to have a different login shell for each machine. Administrators who are

111
gradually migrating Unix machines to use VAS may need to temporarily set a user’s UID to an
old value until all of the file permissions are updated. The Account Override capability of vascd
provides this functionality.
Administrators can override the following information for each Active Directory user’s Unix
account:
• Login Name
• UID
• Primary GID
• GECOS
• Home Directory
• Login Shell
For Active Directory groups, administrators can override the following information:
• Group Name
• GID
• Local users can be added to the group’s membership list
This override information can be configured in two files, the user-override file and the
group-override file. By default, these files are located at /etc/opt/vas/user-override and /
etc/opt/vas/group-override. These locations can be modified in /etc/opt/vas/vas.
conf with the user-override-file and group-override-file options. You must specify
an absolute path for these options. This allows you to place the override files at any filesystem
location, even on NFS mounted directories.
The user-override file follows the following format, where each line specifies the override data for
one user. Lines that start with a # character are considered comments.
<UPN>:<Login Name>:<UID>:<GID>:<GECOS>:<Home Directory>:<Shell>
The first field for the User Principal Name (UPN, also knows as the User Logon Name), must be
filled out and refer to an actual user’s UPN in Active Directory. The rest of the fields are optional.
If a field is left blank, then the corresponding field in the passwd struct will be set to the value in
Active Directory for the user. Note that if the UID is overridden, then that will affect getpwuid()
function calls as well as getpwnam() function calls. When the ”Login Name” field is overriden,
then the actual user in Active Directory will be able to login with that name.
There is also limited wildcard support for user-override. Administrators can use ”*” as the UPN,
and override the login shell and home directories for all users that do not have explicit entries in
the user-override file. This override information will not apply to any user that has it’s own entry.
The values for the home directory and login shell override fields can have the substring ”%s”.
When a user’s Unix account information is requested, the actual string produced for the login
shell and home directory value will have the ”%s” substring replaced with the user’s login name.
This allows for simple customization of the home directory location for all VAS users on a system.
The group-override file follows the following format, where each line specifies the override data
for one group. Lines that start with a # character are considered comments and will be ignored.

112
 <Group Name>:<Override Group Name>:<GID>:<Additional Members>
The first field must be an actual group name for an Active Directory group in the default account
domain for the Unix host. The second field is the override group name for the group. If you do
not need the groupname to be overridden, this field should be the same as the first field. The
third field is the GID override, which allows you to override the group’s GID. This will be the
new value used in getgrgid() lookups, as well as be reflected in getgrnam() function calls. The
additional members field allows you to add local users to an Active Directory group. This should
be a comma separated list of user names, just like the entries in /etc/group.
The permissions on these files must be at least readable to the user that vascd runs as. This is the
daemon user in most cases. vascd processes these files into a separate override database so that
lookups made by the VAS NSS module can be as efficient as possible. The override file processing
only occurs when the override files are actually modified. You do not need to restart vascd since
it monitors those files itself.
The following is an example of overriding the jdoe user’s UID and Login shell from his actual
UID of 1000 and actual home directory of /home/jdoe, and using a wildcard entry to change the
home directories and login shell for all users besides jdoe.

jdoe@example.com::345:::/home/jdoe-home:
*:::::/homes/%s:/bin/restricted-shell

The following is an example of overriding the UnixUsers group to change it’s GID to 500 from
1234 and add the local1 and local2 local accounts to it’s group membership list.

UnixUsers:UnixUsers:500:local1,local2

See Also

vastool(1), pam vas(5), nss vas(5)

Authors

Copyright 2003,2004 Vintela, Inc. All Rights Reserved

113
Appendix E

PAM VAS MAN PAGE

pam vas

Name

pam vas – A PAM module for authenticating Active Directory users on Linux/UNIX computers
via the Kerberos protocol.

Synopsis

auth <control-flags> /opt/vas/lib/security/pam vas.so [debug] [trace]

[get tgt] [service=servicename] [helper timeout=seconds]
[create homedir] [no access check] [no uidconflict check]
[no disconnected] [no force update] [get nonvas pass] [realm prompt]
[check pwdlastset] [acct mgmt pw expire] [store creds]
[check gidconflict] [no pw expiration warning] [no auth]
[screensaver mode] [tcb merge]
account <control-flags> /opt/vas/lib/security/pam vas.so [debug]
password <control-flags> /opt/vas/lib/security/pam vas.so [debug]
[helper timeout=seconds]
session <control-flags> /opt/vas/lib/security/pam vas.so [debug]

Description

pam vas is a PAM module that uses the Kerberos protocol to authenticate users against Active
Directory. It must be used in conjunction with the vascd daemon and the NSS module nss vas,
and enables Unix services to authenticate users whose credentials are stored in Active Directory -
which acts as the Kerberos Key Distribution Center (KDC).
PAM enabled services are configured with four types of entries, auth, account, password, and
session. pam vas can be used with all of these. The following is a list of each type of PAM
configuration entry and what pam vas can do for that type of PAM call:

114
auth pam vas will handle the authentication of a user name and password via the Kerberos
protocol against Active Directory. pam vas can also create a user’s home directory if it does
not exist, check for system UID conflicts, set up a user’s Kerberos ticket cache, and check for
computer access restrictions for the given user.

account pam vas will check for user account restrictions set in Active Directory.

password pam vas will change a user’s Active Directory password.

session pam vas will initialize a user’s login session.

vastool configure pam will configure the system’s PAM configuration. Do not change the
defaults created by vastool unless you really know what you are doing.

Control Flags

pam vas has some special features which allow you to take advantage of the extended syntax for
control flags in newer versions of PAM that are found in recent Linux distributions (this extended
syntax is not supported in current versions of Solaris). pam vas will ignore any calls for users that
are not Active Directory users, i.e. system accounts. This allows you to use the following syntax:
[ignore=ignore success=done default=die]
”ignore=ignore” allows the PAM library to call other PAM modules in the stack if the username is
not recognized by pam vas as an Active Directory user. ”success=done” instructs the PAM library
to complete the authentication process if pam vas is successful. ”default=die” instruct the PAM
library to error out if pam vas returns an error condition. This control flag syntax is the default
configuration on systems that support the /etc/pam.d/* PAM configuration. On platforms that
use /etc/pam.conf, the ”sufficient” control flag is used by default.
If the PAM library on your operating system (for example- Solaris 8 and 9), does not support this
extended syntax, you will need to use the ”sufficient” control flag. Unfortunately, this control flag
will cause the PAM library to continue down the PAM stack when pam vas fails which may result
in multiple prompts to the user.
For example, if the PAM library does not support the extended control flag syntax, it is not
possible to distinguish the difference between a local user login, and an Active Directory login
with an incorrect password. The result is that if an Active Directory user mis-types their
password, the PAM library will continue down the PAM stack and additionally allow the other
PAM modules (such as pam unix) to prompt the user for a password.
Please note that PAM configuration file syntax can be quite complex, so make sure you know
what you are doing before changing the default control flags that are configured by vastool.

Auth Arguments

These are the arguments that you can append on to the auth entries for pam vas. By default,
pam vas auth entries are configured with the get tgt and create homedir arguments.

115
debug Log debug messages to syslog. These will normally go to the secure system logs. This is
useful for debugging authentication problems.

trace Log debug messages to syslog that track the call stack of pam vas. These will normally go
to the secure system logs. This is useful for debugging authentication problems.

get tgt Obtains a Kerberos Ticket Granting Ticket (TGT) using the user’s supplied credentials,
and then uses that TGT to obtain a service ticket for the computer object in Active Directory.
A Kerberos TGT is a ticket that is obtained with the user’s password, and can then be used
to obtain other tickets without having to reuse the user’s password. In other words, the use
of get tgt saves the necessary TGT credentials for subsequent use of kerberized ”sign on”
utilities.
Removing get tgt option will cause pam vas to obtain a service ticket directly using the
user’s password, without obtaining the TGT. The ticket is not stored anywhere on the
filesystem, and is destroyed when the PAM session is ended. This results in less network
traffic and load on the KDC. It is therefore recommended that you remove the get tgt option
when using pam vas with a service that does not establish interactive login sessions, such
as a web server or an IMAP server.

service={service principal name} By default pam vas will try to obtain a service ticket
for your computer principal name. The computer principal name will be generated from the
computer’s hostname, or from the host principal override option in the [libdefaults]
section in /etc/opt/vas/vas.conf. In the default case, the computer object for the local
machine is the Service Principal used by pam vas. The service auth argument allows the
administrator to change the service name to be something other than the ”host” principal.

helper timeout=seconds pam vas uses an external program called vasauth helper to
perform the Kerberos operations. There is a default timeout of 10 seconds, after which the
external program will return. If using pam vas in an environment where the network
connection to the Active Directory KDC is very slow, or there is large number of backup
domain controllers that are often used, then you can extend the timeout.
If the helper timeout expires before vasauth helper completes, then pam vas will perform
disconnected authentication.

create homedir Create the user’s home directory if it does not exist. This will also copy the
contents of /etc/skel into the new home directory. Home directories will be created with
permissions of 700 by default. These permissions can be modified with the
homedir-perms option in the [pam vas] section in /etc/opt/vas/vas.conf. The
value for the homedir-perms option must be in standard Unix permissions format, i.e.
755.

no access check Disables the workstation access control checks that pam vas performs. These

116
 access checks are based on /etc/opt/vas/users.allow and /etc/opt/vas/users.
deny. See the Computer Access Control section portion of this man page for more details.

no uidconflict check Disables the UID conflict checking. UID checking will not allow any
Active Directory user to login to the system if they have a UID conflict with another user.
This does not affect local accounts. UID checking is performed for security reasons to
prevent users from accidentally gaining access to files and resources they should not be able
to.
UID checking is not performed for UID’s under 1000. This allows administrators to setup
accounts in Active Directory that could be used for root access.

no disconnected Disables disconnected authentication. Setting this option will also disable
the caching of the user passwords hashes.

realm prompt Adds the user’s realm name to the password prompt. Note that this is a
potential security hole since it shows that a valid account name has been entered.

no force update In order for users to be able to login immediately after being created,
pam vas will ask vascd to ignore it’s blackout period and update the cache for the user
immediately. To disable this behavior, add no force upate to the pam vas options. For
services that perform many authentications repeatedly, adding this option will greatly
reduce the amount of LDAP traffic and the number of LDAP searches the VAS client will
perform.

get nonvas pass On platforms that do not support the extended syntax for PAM, this option is
necessary to get the system PAM modules underneath pam vas, such as pam unix, to reuse
the password pam vas obtained. This also prevents Active Directory users from being
prompted twice when they enter an incorrect password.

check pwdlastset Checks the user’s pwdLastSet attribute after a successful authentication to
ensure that their password has not expired. If the pwdLastSet attribute is set to 0, then the
user is required to change their password before they can login. This provides a
workaround for situations where Active Directory will continue to give Kerberos tickets to
users’ whose passwords have expired.

acct mgmt pw expire Tells pam vas that if a user must change their password when they log
in and and the password change exchange fails from the auth interface, to return back the
appropriate error code in the pam acct mgmt interface so that the application knows that
the user’s password must be changed before they can login.
This option should be used with care. Many applications do not prevent users from logging
in if the pam authenticate function returns SUCCESS and the pam acct mgmt function
returns an error. This will allow some users access when they should be prevented from
gaining access to the system. The dtlogin on HP-UX requires this setting in order to allow

117
 users to change their passwords when they log in.

store creds This option provides a workaround for problems with OpenSSH version 3.7.1p2
and later. pam vas is unable to create the user’s ticket cache correctly with changes made to
this new version of OpenSSH. If you have installed OpenSSH version 3.7.1p2 you should
enable this option. Add the store creds option to make the pam authenticate() call store
the tickets in the user’s home directory instead of waiting for the pam setcreds() call. This
option is only recommended for use with this version of OpenSSH, and will be removed at
a future date when the problems with OpenSSH are fixed.
You may also see problems where there are many leftover files in /tmp that begin with
”.pam vas ccache” when users login through OpenSSH. Using the store creds option
will fix this behavior as well.

check gidconflict In some situations, administrators will want to prevent users from being
able to log in if they belong to groups that have GID conflicts. Typically, GID conflicts
should be managed and fixed from Active Directory, but there may be scenarios where
group conflicts may occur and users should be denied access until the conflicts have been
resolved.
By default, pam vas does not perform GID conflict checking since it impacts authentication
performance. It can be enabled with the check gidconflict option. When this option is
added to the PAM options, the PAM module will check that each group that a user belongs
to has a unique GID. If any group has a conflict, the user will be denied access. An alert log
message will be logged for administrators as well.

no pw expiration warning If a user’s password is set to expire within 14 days pam vas will
generate a message to warn users that their password will expire soon. If
no pw expiration warning is set, the application will not generate this warning. Use
this option with applications that do not correctly support the PAM conversation
mechanism.

N OTE

The default value of 14 days can be changed by specifying the

pw-expiration-warning-window option in the [pam vas] section
of the /etc/opt/vas/vas.conf file. For example:

[pam_vas]
pw-expiration-warning-window = <days>

118
no auth Set this option to completely disable password authentication in the pam vas module.
Use this option to support legacy applications such as rsh. Using this option is not secure
since any VAS-enabled user can log in without a password.
The following features are not compatible with the no auth option due to the fact that no
authentication takes place: the tcb merge option, password expiration warnings, and
nested group support.

screensaver mode Most screensaver applications on the supported Unix and Linux platforms
do not support the PAM calls to perform password changes during authentication. This can
be a problem for users whose password may expire during a login session where their
desktop was locked with the screensaver application. To provide a workaround for this
situation, use this option to have pam vas fail over to the password cache if the user’s
password is expired. This will allow the users to login and change their passwords.
The screensaver mode option should never be used with any login program; only with
screensaver applications like xscreensaver.

tcb merge This option is only available on HP-UX in Trusted Mode. This option is required for
VAS to work on HP-UX when trusted mode has been enabled. In this situation, when a user
logs in, pam vas will make an entry in the TCB user database for the user during a
successful login. This will allow the system to log the user in successfully. Without
tcb merge, users will not be able to login through the standard system login utilities.

Account Arguments

These are the arguments that can be append on to the account entries for pam vas. By default,
pam vas account entries are not configured with any arguments.

debug Log debug messages to syslog. These will normally go to the secure system logs.

trace Log debug messages to syslog that show the call stack of pam vas. These messages will
normally go to the secure system logs.

Password Arguments

These are the arguments that can be append on to the password entries for pam vas. By default,
pam vas password entries are not configured with any arguments.

debug Log debug messages to syslog. These will normally go to the secure system logs.

trace Log debug messages to syslog that show the call stack of pam vas. These messages will
normally go to the secure system logs.

119
helper timeout=seconds pam vas uses an external program called vasauth helper to
perform the Kerberos password change. There is a default timeout of 10 seconds, after
which the external program will return. If using pam vas in an environment where the
network connection to the Active Directory KDC is very slow or if there are many backup
domain controllers and it is common for primary domain controller to be unavailable, then
you should extend the timeout.

Session Arguments

These are the arguments that can be append on to the session entries for pam vas. By default,
pam vas session entries are not configured with any arguments.

debug Log debug messages to syslog. These will normally go to the secure system logs.

Computer Access Control

It is possible to have fine grained control over which Active Directory users can login using
pam vas. This is especially useful when pam vas is used on sensitive servers where shell access
should only be granted to a few users. Note that computer access control functionality does not
work with local user accounts, only with Active Directory user accounts.
By default, each time a user is successfully authenticated, pam vas will check to see if access
should be allowed by using information recorded in /etc/opt/vas/users.allow and /etc/
opt/vas/users.deny. It is possible to use different files for this location. For example,
administrators may want to put these files on an NFS share in order to centrally manage and
distribute the information. This is done with the users-allow-file and users-deny-file
parameters in the [pam vas] section in /etc/opt/vas/vas.conf. You must specify a complete
filepath for these options. These are global options for pam vas, meaning that this option will
apply regardless of what PAM service pam vas is running for.
For example, the following will cause pam vas to use two different NFS mounted files for
processing the allow and deny information:

[pam_vas]
users-allow-file=/net/corp/config/vas/users.allow
users-deny-file=/net/corp/config/vas/users.deny

Lines starting with ’#’ are comments. Valid entries are user principal names, groups,
organizational units, and Active Directory domain names. User principal names will have the
form of user@domain, OU (organizational unit) distinguished names will have the form of
ou=myou,dc=mydc,dc=com, and domain names will have the form of @domain. Any entry that
does not have the ’@’ character or is not an LDAP distinguished name will be interpreted as a
group name.

120
For a complete list of scenarios of how users are granted/denied access based on the many
different possible configuration options with users.allow and users.deny, see section 4.6 of the
VAS Administror’s Guide. As a quick rule of thumb though, precendence is given to matches in
the following order: UPN listed, group listed, OU listed, and domain listed. In the event of ties
between users.allow and users.deny, users will be denied access.
In order to lock down access to a machine, it is not necessary to deny everyone access and then
start granting access. When the users.allow file is used, only users granted access through that file
will have access. This simplifies the hardening process significantly.
Note that in determining whether a given user is a member of a listed group, both the explicit
group membership list of the given group and the user’s primary group id are used. So if a user
is not explicitly listed in a group’s membership list, but a user’s primary group ID is the same as
the listed group’s, then the user is considered a member of that group.
Also note that in determining whether a given user belongs to an organizational unit (OU), OU
nesting is supported with the OU closest to the user’s actual DN (distinguished name) taking
precedence.
Since it possible to put groups into /etc/opt/vas/users.allow and /etc/opt/vas/
users.deny, you can set each file’s contents once and then manage who has access to that Unix
client through Active Directory by managing the group membership lists of the groups used in
the files.
It is possible to turn off this access check in pam vas through the no access check. This may be
useful with applications such as imapd, pop3d, and Apache that don’t grant shell access to users
but still need to authenticate them. This allows administrators to set up Unix clients that have
restricted access to shell services, but still run business applications that can authenticate all
Active Directory users.
The following is an example of a /etc/opt/vas/users.allow file that grants access to the
kyle and jason users and to the unixAdmins group:
kyle@example.com
jason@example.com
unixAdmins
The following example shows a /etc/opt/vas/users.deny file that is configured to deny
access to the brad user – this user belongs to unixAdmins group, but is in trouble and has had his
access taken away.
brad@example.com
Note that the /etc/opt/vas/users.deny file will not be used as often as /etc/opt/vas/
users.allow in most cases. The /etc/opt/vas/users.deny file is provided to allow
maximum flexibility to administrators.

Disconnected Authentication

By default, pam vas supports disconnected authentication. Each time a user successfully logs in
against the Active Directory server, their password is stored as an SHA-1 hash in a secure cache
file that is only readable by the root user. A timestamp is also stored with the hashed password so

121
that the password hash cache is not permanent. By default, all cached password hashes will be
deleted after 30 days. This maximum password age can be configured with the
password-cache-age in the [pam vas] section in /etc/opt/vas/vas.conf. The option
should specify the length of time in days that the password hash will be kept in the auth cache.
This disconnected authentication allows services to continue to authenticate users if the network
connection to the Active Directory server goes down, or if a laptop is used without plugging into
the network. This behavior can be disabled by using the no disconnected flag- in this case
passwords will not be cached so no disconnected authentication can take place.
When a user logs in through disconnected mode, a message will be displayed to the user
notifying them that the machine is in disconnected mode and that some network services will be
unavailable.

See Also

vastool(1), vascd(1), nss vas(5)

Authors

Copyright 2003,2004 Vintela, Inc. All Rights Reserved

122
Appendix F

NSS VAS MAN PAGE

nss vas

Name

nss vas – A NSS module for obtaining UNIX identity information from Active Directory in
conjunction with vascd.

Description

nss vas is an NSS Module that works in conjunction with vascd to make Unix account
information for users and groups stored in Active Directory available on Unix clients. For
performance and scalability reasons, nss vas does not contact Active Directory directly, but
instead sends update requests to vascd and then reads out of a local cache that is managed by
vascd.
nss vas is only used if the /etc/nsswitch.conf files has been configured to use ”vas”. Only
the passwd and group entries are supported. An example /etc/nsswitch.conf follows:

passwd: files vas

group: files vas

files should always be listed before vas so that local accounts take priority. This configuration
change is performed automatically by the vastool join command.

Configuration Options

The behavior of nss vas can be modified by using the following options in the [nss vas] section
in /etc/opt/vas/vas.conf. Note that when these options are enabled they are enabled
system wide. There is no way to perform these checks on a service by service basis due to the
nature of the NSS implementation on Unix platforms. Changes to the /etc/opt/vas/vas.
conf file will be reflected within two minutes. To have these changes take effect immediately,
you must restart vascd in order for the changes to take effect.
The following options are available:

123
UID Conflict Checking By default, nss vas does not perform any UID Conflict checking. This is
performed by pam vas. There are some situations where applications will not use the PAM
stack to authenticate (i.e. rsh or password-less SSH authentication using private keys) and
administrators still want to ensure that no user can log in if they have a UID conflict with
another user on the system. To enable this behavior, add the line
check-uid-conflicts=true to /etc/opt/vas/vas.conf. You may need to restart
some services in order to make this change take affect.
When UID Conflict checking is enabled, nss vas will only perform that check for getpwnam
calls. If there is a UID conflict for the given user, then that user’s login shell will be set to /
bin/false. The user will then be unable to login. This ”access-denied” shell can be
configured to be a shell other than /bin/false. If you need to change the ”access denied”
shell, this can be accomplished by modifying the access-denied-shell option in the
[nss vas] section of /etc/opt/vas/vas.conf. This shell must not be a valid shell
(/bin/bash for example) or users will be granted access when they should not be. An
example of enabling this behavior is:
[nss_vas]
check-uid-conflicts = true

Host Access Control Checking By default, nss vas does not perform any host access checking.
This is left to pam vas. However, there are cases where applications bypass the PAM stack
during authentication and administrators would still like the VAS access controls stored in
/etc/opt/vas/users.allow and /etc/opt/vas/users.deny to apply. To enable
this behavior edit /etc/opt/vas/vas.conf and add the line
check-host-access=true to the [nss vas] section. You may need to restart some
services in order to make this change take affect.
When host access checking from nss vas is enabled, getpwnam calls handled by nss vas
will perform the same check that pam vas performs for the specified user. If the user is not
allowed access to the box, then the user’s shell will be set to /bin/false. This shell can be
overridden by specifying the path to an alternate shell in the [nss vas] section of /etc/
opt/vas/vas.conf. This is done by setting the access-denied-shell to the path of
the alternate shell, as shown below:

[nss_vas]
check-host-access = true
access-denied-shell = /sbin/login_denied_shell

Explicit lowering of usernames Some deployments in Active Directory will have usernames all
uppercase. pam vas does support case insensitive login names like Windows does, but the
user and group information available from the NSS interfaces will be still be all upper
cased. You may want to modify the user and group names that are returned from the
getpwnam and getpwuid functions to be all lower cased which is how it is commonly
done on Unix platforms.
It is possible to configure nss vas to explicitly convert user and group names to their

124
 lowercase equivalent. To enable the lowercase behavior, add the line lowercase-names =
true to /etc/opt/vas/vas.conf. This line should be added under the [nss vas]
section. You may need to restart the processes using nss vas to apply the change. Reverse
this behavior by setting lowercase-names to false, or removing it from vas.conf entirely.
The following is an example of how to enable this behavior:

[nss_vas]
lowercase-names = true

See Also

vastool(1), vascd(1), pam vas(5)

Authors

Copyright 2003,2004 Vintela, Inc. All Rights Reserved

125
Appendix G

VASYPSERV MAN PAGE

vasypserv

Name

vasypserv – The VAS NIS server for NIS compatibility

Synopsis

vasypserv [-h] [-v] [-d] [-p pidfile] [-c update-interval] [-b

search-base] [-a principal] [-x] [-f] [-g level]

Description

The vasypserv daemon acts as a NIS server which can provide backwards compatibility with
existing NIS infrastructure. The VAS NIS components (NIS Schema extension, and NIS MMC
Snapin extension), allow administrators to centrally manage their NIS Map data in Active
Directory, while the vasypserv daemon provides NIS server functionality without having to run
the NIS protocol over the network. vasypserv by default will only respond to requests from the
system vasypserv is running on, and all NIS Map data is obtained from Active Directory via
secure LDAP requests.
vasypserv will only work on machines that have the VAS client software installed, and which
have been joined to the Active Directory domain. The VAS NIS schema extension must have been
applied to Active Directory as well. NIS Map data in Active Directory can be managed using the
VAS MMC Snapin Extensions.
Using vasypserv provides the following features:
Security - NIS is notoriously insecure without any concept of encryption for data that goes across
the network. Typically, users’ password hashes are also made available in the passwd.byname
and passwd.byuid NIS Maps. With vasypserv, you can still have passwd and group NIS Maps,
but no password hashes will be made available in those maps. Clients can instead use the VAS
client components like pam vas for secure authentication with Active Directory, while still
making the passwd NIS maps available to NAS devices and other systems that need the NIS
information to function. vasypserv uses the same computer identity that vascd does to
authenticate to Active Directory and obtain the NIS Map data through secure LDAP.

126
Disconnected Operation - vasypserv manages a peristent cache of all available NIS Maps. This
allows applications like autofs that use NIS to get configuration information to continue to
function without interruption in situations where the Active Directory domain controller is
unreachable.
Scalability - vasypserv is a miniature NIS server that runs on each NIS client. Instead of having to
deploy a master NIS server along with a number of slave servers, each NIS client simply talks to
the vasypserv daemon running on the same machine. This allows each NIS server to only have to
handle one client. vasypserv has been designed to minimize it’s memory footprint and
computing requirements so that it has a minimal impact on the system’s resources.
Flexibility - The VAS NIS schema extensions allows you to easily create custom NIS Maps for
delivering information outside of the default NIS Maps commonly used. Administrators can
write their own NIS Map parser scripts that will be used to create the persistent cache for each
NIS Map.
vasypserv uses a two process model, where the parent process ensures that the child process
which handles all of the NIS RPC messages is always running. The NIS RPC process drops root
privileges and runs as the daemon user. The parent process will run a separate process to update
the NIS Map cache periodically. This arrangement avoids potential blocking problems when
using vasypserv for hosts and services resolving.

vasypserv Comamnd Line Options

These are the options you can pass to vasypserv when starting the daemon.

-h Shows the vasypserv usage

-v Shows the vasypserv version

-d Causes the daemon to not detach from the controlling tty, and prints debugging messages to
stderr. This is useful for debugging purposes. Only the RPC NIS server process will run in
this case, and Map updates will not occur.

-p pidfile Specify an alternative pid file. Default is /var/state/vas/vasypserv/.

vasypserv.pid

-c update-interval Specify the polling interval for NIS Map updates. The default is 30
minutes, or 1800 seconds. This setting can also be set in vas.conf file in the ”[vasypserv]”
section. An example is:

[vasypserv]
update-interval = <seconds>

127
 This polling interval allows vasypserv to to minimize the amount of LDAP traffic it
generates while managing the NIS Map data cache. By default, vasypserv will check for
updates in Active Directory every 30 minutes. Only those NIS Maps which have been
changed since the last update will be obtained. In situations where NIS Maps are changing
constantly, you may want to decrease the polling interval so that updates are checked for
more often. Since the information for the passwd and group maps is generated from the
vascd cache, updates for that information will follow the update rules and blackout period
for vascd.

-b search-base By default, vasypserv will only search the container that the computer object
is in for NIS Map objects. You can change this by specifying a search-base, where you will
be able to set the location where the NIS Maps for this machine are stored. This allows
administrators to have multiple sets of NIS Maps for different sets of machines within the
same domain.
This can also be set in vas.conf in the ”[vasypserv]” section. An example is:

[vasypserv]
search-base = ou=linux nismaps, dc=example, dc=com

-a principal Specify the principal to authenticate as. By default, we authenticate as the host
principal created at the time vastool join was run.

-x This option will flush the NIS Map cache, then load all NIS Maps.

-f This option will delete all of the vasypserv cache, including the NIS Map caches.

-g level This allows you to override the default debugging level that vasypserv uses when the
-d is specified. By default, the debug level is 2 when the -d is specified. It can be set
anywhere from 1 to 5, with a higher level producing more debug output.

vasypserv vas.conf options

There are other options that can be specified in /etc/opt/vas/vas.conf to customize the
behavior of vasypserv. The following options must all be configured in the ”[vasypserv]” section
in order to be used.

client-addrs By default, vasypserv will only answer requests originating from the local
machine network interfaces to avoid transmitting any plain text NIS traffic over the
network. However, if you do have other systems that need the NIS Map information
provided by vasypserv, you can use the client-addrs option to provide that
functionality. client-addrs takes a space separated list of IPv4 addresses and hostnames.

128
 vasypserv will respond to requests from these clients when it is running, so it can act as a
NIS server for clients other than the localhost. This is especially useful if you have a NAS
device that needs NIS to handle UID/GID mappings for NFS or CIFS file shares.
An example of specifying a list of addresses to respond to is:

[vasypserv]
# respond to 192.168.131.129 and the file server
client-addrs = 192.168.131.129 nas.example.com

debug-level You can enable debug output without having to run the daemon from the
command line with the -d. By specifying debug-level in the vas.conf, you can enable
debug output from the daemon in normal operation. The value should be set to an integer
between 1 and 5, with 5 producing the highest level of debug output. This information will
be logged using syslog debug messages, so syslog must be configured to log syslog.debug
messages in order to view the debug output. Debug levels of 3 and above produce a
plethora of debug output, so use this option with caution.
An example of specifying a debug level of 2 is:

[vasypserv]
# get verbose application debug messages
debug-level = 2

script-user By default, vasypserv will run all of the NIS Map parser scripts as the nobody
user to ensure that no malformed NIS Map parse script can damage the Unix system. If the
nobody user does not exist, or if a different user is desired, use the script-user in /etc/
opt/vas/vas.conf to specify a user to run the scripts as.
An example of specifying a specific user to run the script as follows:

[vasypserv]
# run NIS Map parse scripts as the nfsnobody user
script-user = nfsnobody

See Also

vastool(1), pam vas(5), nss vas(5), vascd(5),

129
Authors

Copyright 2003,2004 Vintela, Inc. All Rights Reserved

130