Vintela Single Sign-on for Java from Quest Software. Deployment Guide WebSphere Edition 3.2

Transcription

1 Vintela Single Sign-on for Java from Quest Software Deployment Guide WebSphere Edition 3.2

2 Vintela Single Sign-on for Java(c) 2006 Quest Software, Inc. All rights reserved. No part of this work may be reproduced or used in any form or by any means graphic, electronic or mechanical, including photocopying, recording, taping or information storage and retrieval systems without the permission of Quest Software, Inc. All copies of this document must include the copyright and other information contained on this page. Vintela is a trademark of Quest Software, Inc. Microsoft, Windows, Windows NT, Windows Server and Active Directory are registered trademarks and trademarks of Microsoft Corporation. IBM, WebSphere, and z/os are registered trademarks of IBM. Java, all Java-based trademarks and Solaris are registered trademarks and trademarks of Sun Microsystems, Inc. Apache and Tomcat are trademarks of the Apache Software Foundation. OpenLDAP is a registered trademark of the OpenLDAP Foundation. UNIX is a registered trademark of The Open Group. Linux is a trademark of Linus Torvalds. RC4 is a registered trademark of RSA Security, Inc. All other trademarks contained herein are the property of their respective manufacturers. Every effort has been made to ensure that the information contained in this document is accurate at the time of publication, however subsequent development may mean that the technical specification of these products have changed. For more information: Quest Software, Inc. World Headquarters 5 Polaris Way Aliso Viejo, CA USA Phone: Fax: info@quest.com Web: Please refer to our Web site for regional and international office information.

3 Contents Preface vii Who Should Read This Guide? vii What s in This Guide? viii Conventions ix 1 Introduction to VSJ (WebSphere Edition) Overview About VSJ (WebSphere Edition) About Kerberos About Active Directory Active Directory Groups Group Types Group Scopes Groups and the Logon Process Active Directory Sites Principals, Computer and User Objects User Principal Name (UPN) Service Principal Name (SPN) Computer/User Objects Use of Principal Names in VSJ VSJ and Active Directory SPNEGO and Internet Explorer How Does VSJ (WebSphere Edition) Work? Installing VSJ (WebSphere Edition) Overview Preparing Your Deployment Environment Domain Name Service (DNS) Time Synchronization Service Active Directory Application Server Client Machine Operating System Browser VSJ Examples Deployment Risks Service Unavailability Time Synchronization Replication Interruptions Resource Security iii

4 iv VSJ (WebSphere Edition) 3.2 Deployment Guide Installing VSJ Setting Up Active Directory for VSJ Create a User Account Map a Service Principal Name (SPN) Final Steps Installing the VSJ Components Installing VSJ on a VAS-Enabled Host Vintela Authentication Services (VAS) VAS Configuration VAS Keytabs vastool Using the VAS HOST Service Principal Name to Install VSJ Creating a HTTP Service Principal Using vastool Post-Installation Setting Up IBM WebSphere to Use VSJ Setting Up the VSJ TAI Setting up the VSJ User Registry VSJ Parameters for IBM WebSphere Setting Up Internet Explorer for SSO Windows Integrated Authentication Troubleshooting Your Internet Explorer Configuration Setting up Firefox and Mozilla for SSO on Linux and Unix Advanced Installation Manually Creating Keytab Files Upgrading VSJ Uninstalling VSJ Deploying VSJ for Web Applications Overview Adding VSJ Authentication to a Web Application Enabling NTLM Authentication for a VSJ Web Application Setting Up Logging Using the JKTools Overview The JKTools jkinit jklist jktutil Examples Authenticate and Request a Default Credential Authenticate and Request a forwardable and proxyable credential List the Default Credential Cache Showing the Key Encryption Type List the Default Credential Cache Showing the Ticket Flags Create a Keytab with an rc4-hmac Key List a Keytab Showing the Encryption Types Merge Two Keytabs

5 Contents v 5 Security Issues Overview Summary of Basic Recommendations Client Issues Cookies Caching of Passwords for Basic Fallback SPNEGO/Windows Integrated Authentication Lifetime of Authentication Session IDs Active Directory Permissions Basic Fallback Keytabs and Passwords Authorization Do You Need Authorization? Securing LDAP Using the "Principle of Least Privilege" Denial of Service Basic Fallback Session State Auditing Maintenance and Troubleshooting Overview Maintenance Logging New Users / Groups Account Settings Access Policy Changes Network Topology Changes Troubleshooting General Active Directory Browsers Internet Explorer Browsers Non-Internet Explorer Browsers Authentication Keytabs Network Connections Credential Delegation Debugging Glossary Index

6 vi VSJ (WebSphere Edition) 3.2 Deployment Guide

7 Preface As the use of distributed systems increases, users need to access resources that are remotely located. Traditionally users have had to sign-on to multiple systems, many requiring different usernames, passwords and authentication techniques. With single sign-on (SSO), users need only authenticate once and the authenticated identity is securely carried across the network to access resources on behalf of the user. The Java 2 Platform, Enterprise Edition (J2EE ) is an excellent platform for developing Internet, intranet and extranet applications. It provides a standardized architecture that makes reuse possible, and provides tight integration with databases and legacy applications through the JDBC and JCA interfaces. Many enterprises have deployed, or are in the process of deploying J2EE applications. In addition, many enterprises are moving to support a standardized authentication infrastructure. In particular, Microsoft's Active Directory provides an environment based on Kerberos and LDAP which provide Identity Management services including SSO, a centralized store for identity information. It makes a lot of sense to reuse this infrastructure where possible. Unfortunately, tight integration with Kerberos, and in particular the infrastructure provided by Microsoft s Active Directory which is already deployed or being deployed in many organizations, is simply not available for J2EE. VSJ (WebSphere Edition) fills this gap, providing SSO and access management for J2EE applications using Active Directory as their identity store.it provides an enterprise-wide method of identification and authorization that can be administered in a consistent and transparent manner and allows users to access information systems to which they are authorized. VSJ (WebSphere Edition) is a WebSphere-specific implementation of VSJ and integrates transparently with the IBM WebSphere Trust Association Interceptor (TAI) to provide full-featured SSO. Who Should Read This Guide? The VSJ (WebSphere Edition) Deployment Guide is intended for developers of VSJ solutions for enterprise SSO applications on the IBM WebSphere application server.you should have a good knowledge of Java programming, and a sound understanding of how Active Directory works in your environment. vii

8 viii VSJ (WebSphere Edition) 3.2 Deployment Guide What s in This Guide? This guide describes how to deploy VSJ and includes a number of examples designed to accelerate the implementation of your VSJ solution. The VSJ Deployment Guide includes: Chapter 1 - Introduction to VSJ (WebSphere Edition) This chapter provides an overview of the background technology, such as Kerberos and Active Directory, necessary to understand how VSJ works. Chapter 2 - Installing VSJ (WebSphere Edition) This chapter describes: What you need to do to set up your deployment environment and some of the risks associated with SSO-enabling your Web application How to install VSJ manually Post-installation activities Advanced installation activities Issues to consider when upgrading VSJ How to uninstall VSJ Chapter 3 - Deploying VSJ for Web Applications This chapter describes how to build Single Sign-On solutions using VSJ. Chapter 4 - Using the JKTools This chapter describes how to use the jkinit, jklist and jktutil tools which are included with VSJ. Chapter 5 - Security Issues This chapter outlines the mechanisms in VSJ used to achieve secure operation, and outlines some areas that may need attention. Chapter 6 - Maintenance and Troubleshooting This chapter discusses the common maintenance issues relating to a VSJ deployment and provides solutions to some common problems which may be experienced when configuring and deploying applications using VSJ. Glossary The Glossary provides definitions of the terminology used in this guide.

9 Preface ix Conventions Conventions used in this guide are shown below. Convention Code Code italic SansSerif SansSerif italics Italic Use Highlights commands and coding Highlights code variables Highlights file names and paths Highlights file name and path variables Highlights publication titles and emphasises important or new terms

10 x VSJ (WebSphere Edition) 3.2 Deployment Guide

11 Introduction to VSJ (WebSphere Edition) Chapter 1 Overview About VSJ (WebSphere Edition) About Kerberos About Active Directory Active Directory Groups Group Types Group Scopes Groups and the Logon Process Active Directory Sites Principals, Computer and User Objects User Principal Name (UPN) Service Principal Name (SPN) Computer/User Objects Use of Principal Names in VSJ VSJ and Active Directory SPNEGO and Internet Explorer

12 2 VSJ (WebSphere Edition) 3.2 Deployment Guide Overview This chapter introduces VSJ (WebSphere Edition) as well as covering underlying technologies, such as Kerberos, Active Directory and SPNEGO, and includes an outline of VSJ s operations from the point of initialization through to exit. About VSJ (WebSphere Edition) VSJ (WebSphere Edition) is an IBM WebSphere-specific version of Quest s VSJ Suite. It provides a mechanism for seamlessly integrating WebSphere applications into an enterprise SSO infrastructure based on Microsoft's Active Directory and Kerberos. The IBM WebSphere Trust Association Interceptor Interface (TAI) provides an interface for third-party security providers, such as VSJ, to integrate their security functions into the IBM WebSphere Application Server architecture. This pluggable, extensible architecture presents security as a service to other components, meaning: Security functions are kept separate from the application business logic All the resources hosted on an IBM WebSphere platform are given consistent and unified protection System administrators can manage security through the IBM WebSphere Web-based console using flexible security policies that can be changed without recoding and redeploying Quest s generic VSJ suite is a cross-platform solution which supports most Java application servers including: BEA WebLogic IBM WebSphere Oracle9i Apache Tomcat About Kerberos Kerberos is a network authentication protocol developed at the Massachusetts Institute of Technology (MIT). It is designed to provide strong authentication for client/server applications across insecure network connections by using secret-key cryptography. It allows entities communicating over networks to prove their identity to each other while preventing eavesdropping or replay attacks. It also provides for data stream integrity (detection of modification) and secrecy (preventing unauthorized reading) using cryptographic ciphers such as DES. Kerberos works by providing principals (users or services) with tickets that they can use to identify themselves, and secret cryptographic keys for secure communication with other principals. A ticket is a sequence of a few hundred bytes. The ticket can then be used to secure virtually any other network protocol, thereby allowing the processes implementing that protocol to be sure about the identity of the principals involved.

13 Chapter 1 Introduction to VSJ (WebSphere Edition) 3 Kerberos provides for mutual authentication and secure communication between principals on an open network by manufacturing secret keys for any requester and providing a mechanism for these secret keys to be safely propagated through the network. Kerberos does not, strictly speaking, provide for authorization or accounting, although applications may use their secret keys to perform those functions securely. There are several versions and distributions of Kerberos. Most of them are based on the MIT distributions. Some of the distributions are freely available, some are standalone commercial products, and others are part of larger free or proprietary systems. MIT Kerberos versions 4 and 5 are freely available. Versions 4 and 5 are based on completely different protocols, however version 5 contains some compatibility code. Figure 1: Kerberos Protocol Figure 1 shows how the Kerberos protocol works. A principal authenticates itself in Kerberos by using a principal name of the form principal-name@realm and a password. This is typically used to send an encrypted message to the Authentication Service (AS), which can then authenticate the principal and send back a session key and Ticket Granting Ticket (TGT). The TGT is like a certificate of identity which allows the principal to gain later access to one or more services. Once the user has supplied their password and obtained the TGT from the AS, authentication to any other service can happen automatically without the user having to resupply their password. For this reason, Kerberos is sometimes called a Single Sign-On (SSO) service. A ticket is a credential that enables a principal to gain access to a service. A principal obtains tickets from the Ticket Granting Service (TGS) using the TGT obtained from the AS as described above. The ticket is used to create an authenticator, which is then sent to the service being requested to authenticate the user. The authenticator is used to establish a session key for secure communication. Optionally, the user can also request to authenticate the server. If this happens, the server uses information in the user's authenticator to send back a server authenticator, which the user can use to verify the server's authenticity.

14 4 VSJ (WebSphere Edition) 3.2 Deployment Guide The Kerberos protocol has been widely analyzed and is supported by many vendors including Sun, Microsoft and Oracle to name a few. It forms the basis of the authentication system used by Active Directory in Windows operating systems. About Active Directory The Active Directory service is a core component of the Microsoft Windows operating system. It provides a directory service supporting the Lightweight Directory Access Protocol (LDAP), and a Kerberos KDC to authenticate users. It allows organizations to share and manage information about network resources and users and provides an SSO environment that integrates with the standard Windows desktop login. In addition, it acts as a single point of management for Windows-based user accounts, clients, servers and applications. The directory is arranged hierarchically, allowing the division of enterprise resources into different domains. Each resource (i.e., user, application), is represented as an object with a number of attributes (for example, the organizational group to which the resource belongs). The directory may be browsed hierarchically for resources, or each resource can be individually addressed by providing its Distinguished Name. The Distinguished Name is simply a group of attributes that uniquely identify an object within the Active Directory hierarchy (for example, CN=John Doe, DC=example, DC=com ). The directory also provides fine-grained security mechanisms to allow administrators to determine exactly what information may be accessed. Users can be restricted to specific objects, or even specific attributes within the directory. The main benefits of using Active Directory are that it simplifies the management of user accounts, and provides an SSO infrastructure to users. Its support for standard protocols such as LDAP and Kerberos means that it can be used as, or with, a cross-platform solution. The Kerberos support in Active Directory has been tested to ensure interoperability with the MIT Kerberos implementation used by many UNIX vendors. However, it is worth noting some differences between the Microsoft and MIT implementations: Support for Privilege Attribute Certificates (PACs) Microsoft's Kerberos implementation uses the AuthorizationData field of the Kerberos ticket to pass Privilege Attribute Certificates (PACs) to Kerberized applications. Applications that support Microsoft's PAC format can use this information to provide fine-grained access control to services. Integration with LDAP Active Directory's Kerberos features are tightly integrated with its LDAP server. This means that user information, such as groups, can be retrieved using standard tools and APIs. Windows Native Credential Cache Unlike the MIT implementation, the Windows Kerberos implementation uses an in-memory credential cache to store Kerberos tickets and TGTs (the MIT implementation uses a disk file). The implementation is stored in non-paged memory so it is never written to disk. Microsoft provides routines to obtain credentials from this cache through their Local Security Authority API (LSA API). Smartcard / PKI Support Microsoft supports a version of the PKINIT protocol which allows the initial authentication to the directory to be performed using a private key or smartcard.

15 Chapter 1 Introduction to VSJ (WebSphere Edition) 5 Active Directory Groups In large organizations, managing the authorization permissions of hundreds or even thousands of users creates a significant problem. One way that Active Directory addresses this issue is through the use of groups. These groups provide a way to classify users according to their roles or activities, and can be used as the basis for authorization permissions. Group Types Active Directory defines two types of groups: security groups and distribution groups. Distribution groups are mainly used for activities such as sending bulk , and do not allow permissions and audit settings to be associated with them. Security groups on the other hand are primarily designed for authorization, so are most interesting for VSJ. Microsoft Windows does not use distribution groups internally, although they are available for use by other directory-enabled applications. Group Scopes Each group has a scope which describes both its visibility to other users and applications throughout the enterprise, and the types of principals that can be included in the group. The three group scopes are listed below: Domain Local visible only within a domain, and to sub-domains. Domain local groups can include any other type of group, but cannot be included in any of the other groups. Commonly, Domain local groups are used to define the groups and users allowed to access a given local resource. Global visible throughout the enterprise, but can only include other users and groups within the same domain (or a parent domain). Global groups should be used to divide users within a domain into categories according to their roles or job functions. Universal visible throughout the entire enterprise. Universal groups may include both other Universal groups, and global groups from any domain in the enterprise. For reasons described below, Universal groups are expensive to use, so try to limit the number of these groups. You should use a Universal group wherever it is necessary to create a group that spans one or more domains. Note If you are using Active Directory in mixed mode (that is, with both Active Directory and Windows NT domains) the rules for scoping are more restrictive, and you cannot use Universal groups. See your Active Directory documentation for more details. Active Directory allows nested groups (groups that contain other groups), which can be nested to arbitrary levels. This is convenient, as it provides a way to hierarchically manage users, for example you can have a group for each type of manager in a department, and then create a group called Managers that includes all of these sub-groups.

16 6 VSJ (WebSphere Edition) 3.2 Deployment Guide Groups and the Logon Process When a Microsoft Windows user logs on to an Active Directory domain, Active Directory builds a token called a Privilege Attribute Certificate (PAC). The PAC contains the list of all the groups the user is a member of, and that are visible in the login domain. This list is the "transitive closure", meaning it includes any groups which the user is a member of due to nesting of other groups. For example, supposing we have the following global groups which contain the users "Alice" and "Bob": Group1 : contains Alice, Bob Group2 : contains Group1 Group3 : contains Group2 Then the PAC for Alice will contain Group1, Group2 and Group3. Computing this group membership can take some time and Active Directory may have to query several LDAP servers to determine membership. In addition, Universal groups require a full search of the global catalog, which stores information about every Active Directory object. For this reason, the number of Universal groups should be limited to ensure that logon times do not become too long. The PAC exists for the lifetime of the initial TGT obtained at logon time (typically 10 hours). For this reason, if a user is added to a new group, the user must log off and then log back on for this group to be used. Active Directory Sites Sites represent the physical topology of your Active Directory infrastructure based on subnets of TCP/IP addresses, and allow for replication, redundancy and load balancing across your Active Directory deployment. By defining sites in Active Directory, you effectively tell Active Directory what your underlying physical network looks like. This allows domain controllers to utilize the underlying network in the most efficient manner possible and allows Active Directory to conserve bandwidth that is required for other applications within your organization. However, sites are not related to the structure of the domain, nor must they maintain the same namespace a site may span multiple domains and, conversely, a domain may span multiple sites. While no formal relationship exists between a site and a domain, a site may be given the same boundaries as a domain. To ensure rapid and reliable network communication, Active Directory offers methods of regulating intersubnet, or intersite, traffic. The Active Directory physical structure governs when and how replication takes place. As users log on to the network, they are able to reach the closest domain controller site through the previous assignment of subnet information. The system administrator uses the Active Directory Sites and Services snap-in to manage the topology of replication services. VSJ supports replication and failover using Active Directory sites. (You can configure your site by setting the idm.ad.site parameter in your VSJ configuration; see VSJ Parameters for IBM WebSphere on page 23.) Principals, Computer and User Objects Active Directory uses a number of different names to refer to objects that are used by VSJ. These are discussed on the next page.

17 Chapter 1 Introduction to VSJ (WebSphere Edition) 7 User Principal Name (UPN) The fully qualified name used as the Kerberos client principal name. It consists of an RFC822/ style name and domain separated by an '@'. The UPN must be unique throughout the Active Directory forest. The UPN is the name that will appear in the Kerberos Ticket Granting Ticket (TGT) for a client returned by Active Directory. Service Principal Name (SPN) The fully qualified name of a Kerberos service principal. The SPN is of the form <service>/ <host>@domain, for example: HTTP/foo.example.com@EXAMPLE.COM The SPN is used when requesting a Kerberos ticket for a particular service. You will typically need to map an SPN to an Active Directory user or computer object using either the setspn or ktpass utilities with Microsoft Windows. Computer/User Objects SPN/UPNs may be mapped to two different types of object in Active Directory. Computer objects refer to computers which have been joined to a given Active Directory domain (for example, a Microsoft Windows machine joined using the Network Identification Wizard, or a Unix machine joined using VAS). When the computer object is created a corresponding HOST/<machine name>@<domain> SPN will be mapped to that computer object. It is also possible to map additional SPNs to the computer object. An Active Directory User object may refer to an actual physical person, or a Service Account which is an object created for the purposes of running a particular service. In the latter case you would map the SPN to the service account using the setspn or ktpass utilities with Microsoft Windows. Use of Principal Names in VSJ When running VSJ on Microsoft Windows it is only possible to configure VSJ to use the HTTP SPN mapped to a Service Account User Object. This is because it is not possible for VSJ to access the key material for the Computer account stored in the LSA database. For more details on setting up VSJ to use a Service Account, see Setting Up Active Directory for VSJ on page 17). However, when VSJ is used with Vintela Authentication Services (VAS), either the HOST/ or HTTP/ mechanisms can be used (see Installing VSJ on a VAS-Enabled Host on page 19 for more details). VSJ and Active Directory VSJ has been specifically designed to work optimally with Microsoft's Active Directory. It will use the default configuration to discover the services, hosts and port numbers necessary to integrate with Active Directory. To finetune your deployment you can configure VSJ to use Active Directory configuration such as sites and services, KDC servers, etc.

18 8 VSJ (WebSphere Edition) 3.2 Deployment Guide SPNEGO and Internet Explorer In addition to support for Kerberos through its Active Directory service, Microsoft has also provided extensions to Internet Explorer that allow it to participate in a Kerberos-based SSO environment. When a Web server receives a request from an Internet Explorer browser, it can request that the browser use the SPNEGO protocol to authenticate itself. This protocol performs a Kerberos authentication which is tunneled over HTTP, and allows Internet Explorer to pass a delegated credential so that a Web application can log in to subsequent Kerberized services on the user's behalf. When an HTTP server wishes to perform SPNEGO, it returns a "401 Unauthorized" response to the HTTP request with the "WWW-Authorization: Negotiate" header. Internet Explorer then contacts the Ticket Granting Service (TGS) to obtain a service ticket. It chooses a special Service Principal Name for the ticket request, which is: HTTP/webserver.domain@REALM The returned ticket is then used to construct an SPNEGO token which is encoded and sent back to the server in the HTTP headers. The token is unwrapped and the ticket is authenticated. If mutual authentication is required, then the Web server can return an additional SPNEGO token for the client to verify. Once authenticated, the page corresponding to the requested URL is returned. SPNEGO provides a useful mechanism for extending an SSO environment to Web applications. It is already supported in Microsoft IIS for authentication to ASP or Web pages. In addition, the ability to delegate credentials means that a Web application can log in to further services transparently on the user's behalf, providing full end-to-end authentication. Lastly, SPNEGO and HTTP can be used for authentication with Microsoft.NET SOAP clients, providing SSO for Web services. How Does VSJ (WebSphere Edition) Work? This section provides an outline of VSJ s operations, from the point of initialization through to exit. VSJ (WebSphere Edition) plugs into the IBM WebSphere Trust Association Interceptor (TAI) framework so that Web applications, Web services and Enterprise Java Beans can be protected. Access can be granted or denied on the authenticated user. On startup: 1. The IBM WebSphere server creates the TAI Interceptors, including the VSJ TAI Interceptor which: i Examines and determines the configuration, such as the default realm, default Key Distribution Center (KDC), security options, etc. ii Logs the configuration data to the appropriate destination. iii Requests a server Ticket-Granting Ticket (TGT) from the KDC. For the first request: 2. If configured, the VSJ TAI Interceptor locates the appropriate KDC and, using LDAP, obtains and caches the security identifiers (SIDs) for the group and users. For each request: 3. If the request is not yet authorized: i Choose an interceptor for this request. ii For every interceptor configured, check if it is an appropriate interceptor by calling the method 'istargetinterceptor' of that interceptor.

19 Chapter 1 Introduction to VSJ (WebSphere Edition) 9 iii If the interceptor is a target interceptor, WebSphere validates its trust on the third party server represented by the interceptor by calling the method 'validateestablishedtrust' of that interceptor. iv The VSJ TAI performs the appropriate authentication. Basic fallback: Mechanism name is "Basic", and mechanism token is a base64-encoded username and password. Converts username and password to a Kerberos principal and Kerberos password, and requests a TGT from the KDC. Requests a service ticket from the KDC. Stores credentials in session state for future authentication requests. SPNEGO Mechanism name is "Negotiate", and mechanism token is an SPNEGO token. SPNEGO handshake occurs, whereby the SPNEGO token in the request is processed, and SPNEGO tokens may be returned to the browser in the "WWW-Authenticate' field of the response. Eventually, authentication succeeds, and credentials are obtained. NTLM Mechanism name is "NTLM" or "Negotiate", and the mechanism token is an NTLM token. An NTLM handshake occurs, where messages are exchanged between the client and server including negotiate, challenge and authenticate packets. Once authentication occurs, a credential is obtained and stored in the session state for future authentication requests. v If the trust has been validated successfully, WebSphere retrieves the username of the end-user that submitted the HTTP request by calling the method 'getauthenticatedusername' of that interceptor. vi If a valid username has been retrieved, WebSphere creates the credentials for that user and proceeds with its normal processing. 4. If the request is authenticated, then IBM WebSphere passes the request and any accompanying authentication information to the application. Note This default mechanism allows IBM WebSphere to automatically make access decisions based on the authentication provided by VSJ. This is called declarative access control. Applications can programmatically use the IBM WebSphere security framework to integrate with VSJ and may then access the authorization information and make their own access control decisions.

20 10 VSJ (WebSphere Edition) 3.2 Deployment Guide

21 Installing VSJ (WebSphere Edition) Chapter 2 Overview Preparing Your Deployment Environment Domain Name Service (DNS) Time Synchronization Service Active Directory Application Server Client Machine Operating System Browser VSJ Examples Deployment Risks Service Unavailability Time Synchronization Replication Interruptions Resource Security Installing VSJ Setting Up Active Directory for VSJ Create a User Account Map a Service Principal Name (SPN) Final Steps Installing the VSJ Components Installing VSJ on a VAS-Enabled Host Vintela Authentication Services (VAS) VAS Configuration VAS Keytabs vastool Using the VAS HOST Service Principal Name to Install VSJ Creating a HTTP Service Principal Using vastool Post-Installation Setting Up IBM WebSphere to Use VSJ Setting Up the VSJ TAI Setting up the VSJ User Registry VSJ Parameters for IBM WebSphere

22 12 VSJ (WebSphere Edition) 3.2 Deployment Guide Setting Up Internet Explorer for SSO Windows Integrated Authentication Troubleshooting Your Internet Explorer Configuration Advanced Installation Manually Creating Keytab Files Upgrading VSJ Uninstalling VSJ

23 Chapter 2 Installing VSJ (WebSphere Edition) 13 Overview This chapter describes a basic deployment environment suitable for VSJ and provides instructions for installing VSJ. This chapter also explains how to: Configure the VSJ providers for IBM WebSphere Configure and deploy the supplied examples Configure Internet Explorer for SSO Manually create keytab files to setup multiple accounts for virtual hosts Upgrade VSJ Uninstall VSJ Before you install VSJ ensure that you have read Preparing Your Deployment Environment and Deployment Risks below. Preparing Your Deployment Environment This section discusses the environment needed for a VSJ deployment, including the DNS implementation, time synchronization service issues, Active Directory installation, and your application server and client machine software requirements. If you are not already familiar with Active Directory and other concepts related to VSJ, see Chapter 1 - Introduction to VSJ (WebSphere Edition). Domain Name Service (DNS) VSJ requires a DNS implementation to discover the location of: KDCs for a given realm Domain controllers and global catalogs for a given domain (and optionally for a given site) The DNS implementation must support SRV resource records as follows: For locating the domain controller(s) for a given domain: _ldap._tcp.domain where domain is the given domain. For example: _ldap._tcp.testsso.example.com would represent the SRV query for finding domain controllers representing the domain TESTSSO.EXAMPLE.COM. For locating the domain controller(s) for a given domain in a given site: _ldap._tcp.site._sites.domain where site is the given site and domain is the given domain. For example: _ldap._tcp.brisbane._sites.testsso.example.com would represent the SRV query for finding domain controllers representing the domain TESTSSO.EXAMPLE.COM for the site Brisbane.

24 14 VSJ (WebSphere Edition) 3.2 Deployment Guide For locating the global catalog(s) for a given domain: _ldap._tcp.gc._msdcs.domain where domain is the given domain. For example: _ldap._tcp.gc._msdcs.testsso.example.com would represent the SRV query for finding global catalogs representing the domain TESTSSO.EXAMPLE.COM. For locating the global catalog(s) for a given domain in a given site: _ldap._tcp.site._sites.gc._msdcs.domain where site is the given site and domain is the given domain. For example: _ldap._tcp.brisbane._sites.gc._msdcs.testsso.example.com would represent the SRV query for finding global catalogs representing the domain TESTSSO.EXAMPLE.COM for the site Brisbane. DNS services may be provided by using a Windows Server DNS server, or by using a UNIX BIND DNS server. All DNS servers must be physically and logically secure. For information on configuring DNS for Microsoft Windows, see: The Microsoft Windows Server 2003 Deployment Kit ( documentation/windowsserv/2003/all/deployguide/en-us/default.asp) Using BIND DNS Servers with Windows 2000 Detailed Instructions ( research.microsoft.com/programs/up_content/bind.doc) For information on configuring DNS for UNIX, see the BIND 9 Administrator Reference Manual ( Time Synchronization Service The Kerberos protocol requires synchronization of internal clocks within Kerberos domains, to ensure that ticket lifetimes may be calculated and compared correctly. A time service may be configured to provide the necessary synchronization. Time services may be provided by the UNIX Network Time Protocol (NTP) service, or the compatible Simple Network Time Protocol (SNTP) service available with Microsoft Windows Server. For information on configuring time services for Microsoft Windows, see: How to Configure an Authoritative Time Server in Windows XP ( How to Configure an Authoritative Time Server in Windows 2000 ( default.aspx?scid=216734) For information on configuring time services for UNIX, see NTP: The Network Time Protocol (

25 Chapter 2 Installing VSJ (WebSphere Edition) 15 Active Directory A Microsoft Windows 2000 or Windows Server 2003 Active Directory is required. The default installation is sufficient. 1. Install Microsoft Windows 2000 or Windows Server Add the Active Directory role to the server. 3. You will be asked if you also want to install the DNS Role. If you do, click OK. You will need an Administrator account and password for the Active Directory domain. Application Server You will need: IBM WebSphere Application Server 5.0.2, 5.1, 5.1.1, 6.0.*, 6.1 Java 2 Software Development Kit (JDK) 1.3 or greater A server running a supported operating system for WebSphere Application Server, such as z/os, Microsoft Windows, Linux, or an approriate version of Unix Note The Java 2 Software Development Kit is included with your IBM WebSphere installation (it is located in the WAS_HOME/java directory, where WAS_HOME specifies the location of your IBM WebSphere installation). Client Machine Operating System To support Windows Integrated Authentication (page 26), the client must be part of the Active Directory domain and must have one of the following installed: Windows 2000 Professional Windows 2000 Server Windows 2000 Advanced Server Windows XP Professional Windows Server 2003 Windows Vista Note These are the only operating systems that incorporate Active Directory. Note If Microsoft Windows 2000 is installed on the client, Internet Explorer 5.5 or later is also needed. Basic fallback is supported on most platforms and browsers, such as Mozilla and Konqueror.

26 16 VSJ (WebSphere Edition) 3.2 Deployment Guide Browser To support Windows Integrated Authentication (page 26), you will need one of the following browsers: Internet Explorer 5.5 Internet Explorer 6.x Internet Explorer 7 When using a browser that is not configured for Windows Integrated Authentication, VSJ provides a fallback mechanism that allows a user to log in with their Kerberos password using standard HTTP basic authentication. However, the basic feature is disabled by default for security reasons. For more details on the consequences of enabling basic fallback see Chapter 6 - Maintenance and Troubleshooting. VSJ Examples To build the VSJ examples you will need Apache Ant 1.5.x. This is available from: Deployment Risks This section discusses some of the deployment risks associated with the implementation of a VSJ-based solution. These risks are not inherent to VSJ, but may impact on VSJ s service availability or result in false positive/negative authentication. Service Unavailability If a host (for example, the domain controller indicated by a DNS SRV query) becomes unavailable, then VSJ processing may be suspended until a timeout expires. Note that VSJ maintains an internal database of unavailable hosts, and subsequent requests will ignore (for a time) any hosts that are known to be unavailable. If no hosts are available for a given service, then VSJ will indicate an error. Any subsequent VSJ operations that must communicate with the host will timeout until such time as the host becomes available. If a service (such as DNS) becomes unavailable, VSJ processing may be suspended until a timeout expires. After this, VSJ will indicate an error. Any subsequent VSJ operations that rely on the service will timeout until such time as the service becomes available. Time Synchronization If the internal clocks of two machines or services are sufficiently out of skew, then a Kerberos ticket which is valid on one machine may not be valid on the other machine. Thus, unsynchronized time services may lead to denial of service for otherwise valid Kerberos tickets.

27 Chapter 2 Installing VSJ (WebSphere Edition) 17 Replication Interruptions VSJ supports replicated domain controllers and global catalogs, and assumes that information is replicated across the network topology in a timely and consistent manner. Failure to replicate security information (such as group membership, SIDs, etc.) accurately may result in authentication failures. Resource Security VSJ relies on sensitive data (such as Kerberos keytabs, passwords, and Active Directory account information). Such data must be physically and logically secure. Typically, only the Active Directory administrator should have access to Active Directory configuration, and a keytab should be readable only by the principal represented by that keytab. Installing VSJ Setting Up Active Directory for VSJ The following three sections describe the procedures for setting up Active Directory for VSJ. Ensure that you perform all three steps: 1. Create a User Account 2. Map a Service Principal Name (SPN) 3. Final Steps Note If you are installing VSJ on a Windows server, before you begin, make sure that IIS is not being used on the same machine. The steps below will add a service principal name (SPN), which will clash with IIS's, causing IIS to no longer be able to decrypt Kerberos tickets. This will cause IIS's Windows Integrated Authentication to fail. Step 1 - Create a User Account To set up user authentication for a service you must register the service as a user in Active Directory on the Domain Controller. This can be done using the following steps: 1. On the Domain Controller with Active Directory installed, click the Start menu, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers. 2. Click the Users folder to display a list of users, on the Action menu, point to New, and then click User. Enter a name and logon name for the new service and click Next. The username should consist of standard alphanumeric characters and no whitespace, as it needs to be entered on a command line later. On the next screen, enter a password for the service. Ensure that User must change password at next logon is not selected, and Password Never Expires is selected. Click Next and then Finish. 3. Right-click the user you just entered in the User folder list, and then click Properties. A new dialog box will display. Select the Account tab.