Vas 2.6 Administration Guide

Transcript

VAS 2.6 ADMINISTRATION GUIDE SEPTEMBER 2004 c 2003, 2004 Vintela, Inc. All Rights Reserved. Copyright 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 1.1 What is VAS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 VAS Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8 8 2 VAS COMPONENTS 2.1 Active Directory Schema Extension . . . . . . . . . 2.1.1 Active Directory Schema Concepts . . . . . 2.1.2 Supported Schema Extensions . . . . . . . 2.1.3 The VAS Schema Extension Utility . . . . . 2.1.4 Global Catalog . . . . . . . . . . . . . . . . 2.2 The Display Specifier Registration Wizard . . . . . 2.3 The VAS Administrative Tools . . . . . . . . . . . . 2.4 The VAS Configuration Utility . . . . . . . . . . . . 2.4.1 Conflict Detection Tab . . . . . . . . . . . . 2.4.2 Preferred DC Tab . . . . . . . . . . . . . . . 2.4.3 Custom Schema Tab . . . . . . . . . . . . . 2.4.4 Logging Options Tab . . . . . . . . . . . . . 2.5 The pam vas PAM module . . . . . . . . . . . . . . 2.5.1 PAM Concepts . . . . . . . . . . . . . . . . 2.5.2 pam vas Features . . . . . . . . . . . . . . . 2.6 The nss vas NSS module . . . . . . . . . . . . . . . 2.6.1 NSS Concepts . . . . . . . . . . . . . . . . . 2.6.2 nss vas Features . . . . . . . . . . . . . . . 2.7 The vascd daemon . . . . . . . . . . . . . . . . . . 2.8 The vastool command line utility . . . . . . . . . . 2.9 The VAS Loadable Authentication Module for AIX 2.9.1 AIX LAM Module Concepts . . . . . . . . . 2.9.2 The VAS LAM module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11 11 12 14 14 14 15 15 15 16 17 18 18 18 18 19 19 19 20 21 22 22 23 3 UNIX HOSTS IN ACTIVE DIRECTORY 3.1 Kerberos and Active Directory . . . . . 3.1.1 Kerberos Concepts . . . . . . . . 3.1.2 Kerberos and Windows . . . . . 3.1.3 Multiple Domain Environments 3.1.4 Active Directory Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 24 24 25 25 26 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 Joining the Active Directory Domain . . . . . . . . . . . . . . . . Domain, Site, and Service Discovery . . . . . . . . . . . . . . . . Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . Computer Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Creating Computer Objects . . . . . . . . . . . . . . . . . 3.5.2 Deleting Computer Objects . . . . . . . . . . . . . . . . . 3.5.3 Moving Computer Objects . . . . . . . . . . . . . . . . . 3.5.4 VAS Keytab Files . . . . . . . . . . . . . . . . . . . . . . . 3.5.5 Security Considerations . . . . . . . . . . . . . . . . . . . NSS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 The NSS Configuration File . . . . . . . . . . . . . . . . . 3.6.2 Modifying the NSS configuration . . . . . . . . . . . . . . 3.6.3 Restarting services when the NSS configuration changes 3.6.4 Using nscd With VAS . . . . . . . . . . . . . . . . . . . . 3.6.5 Advanced nss vas Concepts . . . . . . . . . . . . . . . . . PAM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.1 The PAM Configuration File . . . . . . . . . . . . . . . . 3.7.2 Using vastool to modify PAM configuration . . . . . . . 3.7.3 Restarting services for PAM configuration changes . . . 3.7.4 Advanced pam vas Concepts . . . . . . . . . . . . . . . . 3.7.5 Debugging PAM Problems . . . . . . . . . . . . . . . . . AIX Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.1 AIX Configuration Files . . . . . . . . . . . . . . . . . . . 3.8.2 Account Information Functions . . . . . . . . . . . . . . . 3.8.3 Authentication Functions . . . . . . . . . . . . . . . . . . The vascd Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9.1 The vascd Data Cache . . . . . . . . . . . . . . . . . . . . 3.9.2 Disconnected Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 UNIX USERS AND GROUPS 4.1 User and Group Schema Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Configuring Schema Mappings for the Vintela Authentication Services Snapin 4.1.2 Configuring Schema Mappings for the Vintela Authentication Services Unix client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Managing Unix User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Using the VAS Administrative Tools . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Managing User Accounts from the Unix Command Line . . . . . . . . . . . . 4.2.3 Moving Users in Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4 Disabling Unix User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Managing Unix Group Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Using the VAS Administrative Tools . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Managing Active Directory Groups from the Unix Command Line . . . . . . 4.3.3 Moving Groups in Active Directory . . . . . . . . . . . . . . . . . . . . . . . . 4.3.4 Active Directory Group Types and Scopes . . . . . . . . . . . . . . . . . . . . 4.3.5 Nested Group Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 UID and GID Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 UID/GID Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Avoiding Duplications with Local Accounts . . . . . . . . . . . . . . . . . . . 3 26 28 28 29 29 30 30 30 31 31 31 32 32 32 33 34 34 34 35 35 37 37 37 38 38 39 39 40 41 41 41 42 43 43 45 47 47 48 48 49 50 50 51 52 53 53 . . . . . . . . . . . 53 53 54 54 54 55 56 56 56 57 58 . . . . . . . . . . . . . . . . . . . . 60 60 61 61 61 62 62 62 62 62 63 63 64 65 66 66 68 69 70 71 71 . . . . . . . 72 72 74 74 74 75 75 76 A VAS TROUBLESHOOTING GUIDE A.1 Troubleshooting the Unix Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.1 Attribute Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 77 77 B UNIX PLATFORM LIMITATIONS B.1 General UNIX limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 79 4.5 4.6 4.7 4.4.3 Detecting ID Conflicts . . . . . . . . . . . . . . . . 4.4.4 Overriding Unix Account Information . . . . . . . Password Management . . . . . . . . . . . . . . . . . . . . 4.5.1 Windows Domain Password Policies . . . . . . . . 4.5.2 Changing Passwords . . . . . . . . . . . . . . . . . 4.5.3 Password Expiration . . . . . . . . . . . . . . . . . Account Management in Multiple Domain Environments 4.6.1 Using an Alternate Default Account Domain . . . 4.6.2 Cross Domain Logon with Simple Name . . . . . 4.6.3 Minimizing the Size of the User Cache . . . . . . . Workstation Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 NIS COMPATIBILITY 5.1 A Brief NIS Overview . . . . . . . . . . . . . . . . . . . . . . . 5.2 The VAS NIS Support Components . . . . . . . . . . . . . . . . 5.2.1 The VAS NIS Schema Extension . . . . . . . . . . . . . 5.2.2 The VAS MMC NIS Map Snapin . . . . . . . . . . . . . 5.2.3 The vasypserv Daemon . . . . . . . . . . . . . . . . . . 5.3 Windows Installation and Configuration . . . . . . . . . . . . . 5.3.1 Installing the VAS NIS Schema Extension . . . . . . . . 5.3.2 Installing the VAS NIS MMC Snapin Extension . . . . . 5.4 Managing NIS Map Objects . . . . . . . . . . . . . . . . . . . . 5.4.1 Creating NIS Map Objects . . . . . . . . . . . . . . . . . 5.4.2 Managing NIS Map Data . . . . . . . . . . . . . . . . . 5.4.3 Managing NIS Map Database Configuration . . . . . . 5.4.4 Example: Configuring a hosts NIS Map . . . . . . . . . 5.5 Unix Installation and Configuration . . . . . . . . . . . . . . . 5.5.1 Linux VAS NIS Client Installation and Configuration . 5.5.2 Solaris VAS NIS Client Installation and Configuration . 5.5.3 HP-UX VAS NIS Client Installation and Configuration 5.5.4 AIX VAS NIS Client Installation and Configuration . . 5.5.5 NIS Map Search Locations . . . . . . . . . . . . . . . . . 5.6 Writing custom NIS Maps . . . . . . . . . . . . . . . . . . . . . 6 MIGRATION 6.1 Importing Users and Groups . . . . . . . . . . . . . 6.2 Migration from NIS . . . . . . . . . . . . . . . . . . . 6.2.1 Migrating NIS User and Group Information 6.2.2 Migrating NIS Map Data . . . . . . . . . . . 6.3 Migration from MIT Kerberos . . . . . . . . . . . . . 6.3.1 Keytabs and the krb5.conf . . . . . . . . . . . 6.3.2 User and Group migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.1.1 Group Membership Limitations . B.2 AIX Limitations . . . . . . . . . . . . . . . B.2.1 User and Group Name Limitations B.3 HPUX Limitations . . . . . . . . . . . . . B.3.1 User Name Limitations . . . . . . B.3.2 UID and GID Limitations . . . . . B.3.3 Authentication Limitations . . . . B.4 Solaris Limitations . . . . . . . . . . . . . B.4.1 UID and GID Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C VASTOOL MAN PAGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 79 79 80 80 81 81 81 81 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 R that include Solaris , R HP-UX , R VAS supports a number of different implementations of UNIX R R Linux , and AIX . To refer to all of these platforms, the term ”Unix” will be used for 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 2.1.1 Active Directory Schema Extension 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 2.5.1 The pam vas PAM module 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 2.6.1 The nss vas NSS module 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 configure create delete flush group info isvas join kinit klist kdestroy license list nss passwd realms search service setattrs timesync unconfigure unjoin user 2.9 List an Active Directory object’s attributes Update configuration files to use the VAS components Create a user, group, computer object, or service Delete a user, group, computer, service, or NIS Map Flush cached client daemon information Modify group membership Get infomation about host specific Active Directory configuration Check to see if the specified user or group belongs to VAS Join the host to the domain Obtain tickets for principals and services List cached tickets Destroy (erase) cached tickets Install your VAS license List users or groups and their attributes Call raw NSS function interfaces Change your password or reset another user’s password Update or display cached domain, site, and service information Perform LDAP searches Create/Modify service principals Set a principal’s attribute(s) synchronize the system clock with the domain Update configuration files to not use the VAS components Remove the host from the domain Enable or disable user accounts 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 3.1.1 Kerberos and Active Directory 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 3.6.1 NSS Configuration 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: group: files nis 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: group: files vas nis 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 positive-time-to-live negative-time-to-live suggested-size check-files passwd passwd passwd passwd passwd no 600 20 211 yes 32 # # # # enable-cache positive-time-to-live negative-time-to-live suggested-size check-files group group group group group no 3600 60 211 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 [email protected], 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 [email protected] 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 3.7.1 PAM Configuration 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 3.7.4.1 Advanced pam vas Concepts 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 auth.crit auth.debug 3.8 /dev/console root /var/log/auth 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 Installation 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 4.2.3.1 Moving Users in Active Directory 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 appendix 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 [email protected]:VAS:1001:[email protected],[email protected] [email protected]:VAS:1002:[email protected] 49 [email protected]:VAS:1003:[email protected] 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 [email protected]:VAS:1001:[email protected],[email protected] [email protected]:VAS:1002:[email protected] [email protected]:VAS:1003:[email protected] 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 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. 4.3.3 4.3.3.1 Moving Groups in Active Directory 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 4.6.1 Account Management in Multiple Domain Environments 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 ”[email protected]” 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. [email protected] and [email protected]), 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 A A A A D User D D D D D D Group D A D D D D OU D A A * D D Domain D A A A D D Not A A A A A 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 5.2.1 The VAS NIS Support Components 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 5.3.1 Windows Installation and Configuration 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 correctly 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 A.1.1 Troubleshooting the Unix Client 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 . 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 B.1.1 General UNIX limitations 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: [email protected] and [email protected].) 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 cacheto 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 = 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 = -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 = -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 = -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. [email protected] and [email protected]), 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. :::::: 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 ::: 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. [email protected]::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 /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 /opt/vas/lib/security/pam vas.so [debug] password /opt/vas/lib/security/pam vas.so [debug] [helper timeout=seconds] session /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 = 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: [email protected] [email protected] 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. [email protected] 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 = 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