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: [email protected] 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/[email protected] 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.

28 18 VSJ (WebSphere Edition) 3.2 Deployment Guide 4. Select the Account is trusted for delegation check box if you wish to allow a service to use delegated credentials to access other services on the users' behalf. This is significant when your service depends on data from other secure services for which you don't want users to have to enter credentials manually. 5. Select the Password never expires check box. This will prevent the service account from ever expiring, which would cause Kerberos errors if it occurred. 6. Click OK. Step 2 - Map a Service Principal Name (SPN) For Internet Explorer to be able to authenticate to VSJ, it needs to know the user account created in Create a User Account above. It does this by looking up a Service Principal Name (SPN) of the form HTTP/ host@realm. The following describes how to create a mapping between a user account and an SPN: 1. Obtain the ktpass utility. This is available from the Windows 2000 resource kit. For more information on this tool, go to: ktpass is included on the Windows Server 2003 installation CD under /Support/Tools/. 2. Launch a command prompt and run ktpass with the following arguments: ktpass -princ HTTP/host.domain@REALM -mapuser user Where: host is the fully-qualified domain name of the server where VSJ will be installed. (for example, server.example.com) REALM is the Active Directory realm in which the server is located (for example, EXAMPLE.COM). Note that REALM needs to be entered in uppercase characters. user is the logon name of the user account you created above. Note If you want to use ktpass under Microsoft Windows 2003, the user must be the user account's fullname and must be enclosed by quotes (" "). Note Ensure that the principal name (SPN) you are entering at this step does not already exist in Active Directory, otherwise the installation will not work. The most common reason for this is if IIS has been installed on the host. Removal of IIS does not remove the principal name. This has to be done manually using the setspn.exe utility.

29 Chapter 2 Installing VSJ (WebSphere Edition) 19 Step 3 - Final Steps To prevent Kerberos integrity-check failures later on, ensure that you perform 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. Right-click on the user account that you created previously, and click Reset Password... A login dialog box will display. 3. Enter and confirm the same password that you entered previously. Ensure that User must change password at next logon is not selected. 4. Click OK to finish. Installing the VSJ Components This distribution requires a VSJ license and does not include one; see the release notes (Quest_VSJ_Release_Notes.html) for details on how to obtain a license for VSJ. The following instructions describe how to install the VSJ components for IBM WebSphere. 1. Copy the VSJ library jars from the lib directory to the WebSphere WAS_HOME/lib directory. WAS_HOME is defined as the directory where IBM WebSphere is installed, such as C:/Program Files/WebSphere/AppServer or /opt/pkg/websphere-5.1/appserver. You do not need to copy the file winsspi.dll to the WAS_HOME/lib directory. 2. Copy the third party support libraries from the thirdparty/lib directory to the WebSphere WAS_HOME/lib directory. 3. You will now need to start or restart the IBM WebSphere server. Installing VSJ on a VAS-Enabled Host VSJ supports integration with Vintela Authentication Services (VAS) to allow you to simplify installation on VAS-enabled Unix hosts. The following sections describe how to perform this setup. Vintela Authentication Services (VAS) Vintela Authentication Services (VAS) allows Unix and Linux users to be authenticated using Active Directory. It provides integration with the Unix Pluggable Authentication Modules (PAM) and Name Service Switch (NSS) systems. A system administrator will enable VAS on a Unix host by joining it to the Active Directory domain using the vastool utility. This creates a computer account object in Active Directory along with a HOST principal and keytab that can be used to authenticate service tickets that are presented to Kerberos/VAS-enabled applications. VAS Configuration The VAS Configuration file is usually installed in /etc/opt/quest/vas/vas.conf. The configuration is in the form of an MIT krb5.conf file, for example:

30 20 VSJ (WebSphere Edition) 3.2 Deployment Guide [libdefaults] default_realm = EXAMPLE.COM dns_lookup_kdc = true ticket_lifetime = default_keytab_name = /etc/opt/quest/vas/host.keytab default_etypes = arcfour-hmac-md5 default_etypes_des = des-cbc-crc default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc [domain.realm] j2ee.example.com = EXAMPLE.COM The configuration file defines information such as the default realm, and the location of the server keytab. VAS Keytabs VAS keytab files are created in the /etc/opt/quest/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/quest/vas/host.keytab file. VAS keytab files are stored using the standard MIT-style and may be used by third party applications including VSJ. vastool vastool is a command line program that allows you to configure various components of VAS, access information stored in Active Directory; and perform a variety of tasks such as the creation of user accounts and keytabs. vastool is located at /opt/quest/bin/vastool. It has been designed to be script-friendly and allows 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. While vastool supports a wide variety of commands, the following will be of most use when installing VSJ with VAS: create create a user, group, or computer object in Active Directory delete delete users, groups, computer objects, or NIS Map objects in Active Directory service manage service accounts in Active Directory

31 Chapter 2 Installing VSJ (WebSphere Edition) 21 Using the VAS HOST Service Principal Name to Install VSJ One of the simplest ways to configure VSJ to run on a VAS enabled host is to set up your configuration so that the Application Server can authenticate using the HOST principal installed when you join a VAS enabled machine to the Active Directory domain. To do this, you will need to perform the following steps: 1. Run the application server with sufficient permissions to access the host keytab /etc/opt/quest/vas/ host.keytab (usually root). 2. Configure the realm used by VSJ to be the same as the realm/domain to which the VAS enabled host has been joined. This can be determined by running the command: /opt/vas/bin/vastool info domain 3. Configure VSJ to use the host keytab (located in /etc/opt/quest/vas/host.keytab). 4. If you are using Active Directory sites you should configure VSJ to use the correct site for this server. You can discover this by using the command: /opt/vas/bin/vastool info site 5. Configure VSJ to use the HOST principal. This should be set to: HOST/fully.qualified.host.name Creating a HTTP Service Principal Using vastool It is also possible to use vastool to add a service account for VSJ rather than using the HOST principal. The major benefit of this approach is allows you to run the application server as an unprivileged user. To do this you will require VAS or better. 1. To create the service, run the following command: $ vastool -u <Administrative User> service create HTTP/fully.qualified.host.name Where <Administrative User> is a domain user with sufficient permissions to create accounts. This will generate output similar to the following: Successfully created service HTTP/[email protected] Update the permissions on the service keytab for the application using the service. and generate a keytab /etc/opt/quest/vas/http.keytab. 2. Modify the permissions on /etc/opt/quest/vas/http.keytab so it is readable by the process running the application server. For example: $ chown appserverowner /etc/opt/quest/vas/http.keytab 3. Configure the realm used by VSJ to be the same as the realm/domain to which the VAS-enabled host has been joined. This can be determined by running the command: $ /opt/vas/bin/vastool info domain 4. If you are using Active Directory sites you should configure VSJ to use the correct site for this server. You can discover this by using the command: $ /opt/vas/bin/vastool info site 5. Configure VSJ to use the HTTP principal above (HTTP/fully.qualified.host.name). See Table 1, VSJ Parameters for IBM WebSphere, on page 23.

32 22 VSJ (WebSphere Edition) 3.2 Deployment Guide Post-Installation Setting Up IBM WebSphere to Use VSJ This section describes how to configure the VSJ TAI and VSJ User Registry for IBM WebSphere. Before you perform this activity you must have already installed the VSJ components. You must also ensure that you have set up Active Directory for SSO. Setting Up the VSJ TAI To configure the VSJ TAI: 1. Go to the Security section of the WebSphere Administration console and enable LTPA and Trust Association. 2. Add the VSJ Trust Association interceptor (class name com.vintela.vsj.websphere.tai.vsjntai) and click OK. 3. Enter VSJ custom properties as required. For a list of the available parameters see VSJ Parameters for IBM WebSphere on page 23. In particular, if you are running VSJ on z/os, be sure to configure the jcsi.kerberos.nameservers system property. 4. Finally, enable security and Set the Active Authentication Mechanism to LTPA. 5. Click OK. Setting up the VSJ User Registry The VSJ User Registry is designed to work much better with Active Directory than WebSphere's LDAP User Registry does. The LDAP User Registry only really supports a single Active Directory domain, whereas the VSJ User Registry effortlessly supports more complex Active Directory environments (crossrealm and cross-forest scenarios). Even for a single Active Directory domain, the VSJ User registry has many advantages over the LDAP User registry: performance, security, DNS auto-discovery of domain controllers, load-balancing / failover, site support, and simple configuration. The VSJ User Registry can be used either with the VSJ TAI or independently of the VSJ TAI. Note If you intend to use the VSJ TAI with the VSJ User Registry in an environment with multiple Active Directory domains, you need to update your VSJ TAI configuration and set the custom property idm.ad.qualifyuserprincipal to true. Before you configure the VSJ User Registry, it is advisable to check that Active Directory is correctly configured for VSJ and that the VSJ configuration parameters for the user registry are correct. If you have already successfully configured the VSJ TAI, then the same parameters that you used for the TAI will also work correctly for the user registry. A number of custom properties are used to configure the user registry. Many of these properties are the same as the custom properties for the VSJ TAI, but some are peculiar to the user registry. The user registry must be configured separately from the TAI, so in some cases the same property must be configured twice: once for the TAI and once for the user registry.

33 Chapter 2 Installing VSJ (WebSphere Edition) 23 The following custom properties for the VSJ User Registry are the same as custom properties for the VSJ TAI. Please see VSJ Parameters for IBM WebSphere below for descriptions of these properties: Required idm.realm Required idm.princ Required one of the following: idm.keytab idm.password com.wedgetail.idm.sso.password (this is a Java system property, not a user-registry custom property) Optional idm.ad.site The other VSJ TAI custom properties are not relevant to the user registry. The following custom properties are peculiar to the VSJ User Registry: Optional idm.ad.userlistattribute (default: samaccountname) Optional idm.ad.grouplistattribute (default: cn) WAS allows deployers to search for users by specifying a search pattern. The VSJ User Registry implements this as an LDAP search request in Active Directory's Global Catalog for the LDAP attribute named by idm.ad.userlistattribute matching the specified search pattern. You may wish to specify an alternative LDAP attribute to use for the search, e.g. 'displayname', 'cn' or 'userprincipalname' Similarly, WAS allows deployers to search for groups, and idm.ad.grouplistattribute can be used to specify the LDAP attribute that the user registry will use for these searches. Optional idm.websphererealm (default: VSJ) This value is returned by UserRegistry.getRealm(). This is not related to the AD domain. It is not used by VSJ and can generally be left at its default value. To configure the VSJ User Registry, go to the Security section of the WebSphere Administrative Console and set up a Custom Registry with the class name com.vintela.vsj.websphere.registry.vsjuserregistry. Set the necessary custom properties as listed above. Go back to the initial screen and set the custom registry to be active. Save your configuration, log out of the administration console and restart the server. WAS should now be set up to use the VSJ user registry. See the simple example for instructions on how to use the registry to do authorization. VSJ Parameters for IBM WebSphere Table 1 provides a comprehensive list of VSJ parameters for IBM WebSphere. Table 1: VSJ Parameters for IBM WebSphere Parameter Default Description idm.realm (required) none The Active Directory domain to be used for authentication, ie. EXAMPLE.COM.

34 24 VSJ (WebSphere Edition) 3.2 Deployment Guide Table 1: VSJ Parameters for IBM WebSphere (continued) Parameter Default Description idm.princ "HTTP/ localhost" The Kerberos service principal to use. This should be in the form HTTP/fully-qualified-host, i.e., HTTP/example.quest.com. It defaults to HTTP/localhost. idm.keytab none The file containing the keytab that Kerberos will use for user-toservice authentication. If unspecified, VSJ will default to using an in-memory keytab with a password specified in the com.wedgetail.idm.sso.password custom property or the idm.password parameter. idm.allowntlm false Specifies whether to allow fallback to NTLM authentication. This is required if you wish to use the VSJ solution with pre-windows 2000/XP Internet Explorer browsers which do not support SPNEGO. The default is false. In addition to setting this to true, complete NTLM support requires the FauxNtlmFilter to be configured. See the section Enabling NTLM authentication for a VSJ Web Application in Chapter 3 for more details. idm.password none The password of the Kerberos service principal. VSJ will create an in-memory keytab using this password. NOTE: This parameter is required if the idm.keytab parameter or com.wedgetail.idm.sso.password property is not set. See Keytabs and Passwords on page 46. idm.allowfallback false Specifies whether to allow fallback to Basic authentication. This is required if you wish to use the VSJ solution with non-internet Explorer browsers. The default is false. idm.allowunsecured false Specifies whether to allow authentication over an unsecured channel. If you do not have SSL enabled on your Web Server, you must set this to true. The default if not set is false. idm.kdc automatic discovery The Active Directory against which secondary credentials should be validated This can be used for BASIC fallback, or credential delegation. By default the KDC will be discovered automatically and this parameter should only be used if automatic discovery fails, or if a different KDC to the one discovered automatically should be used. idm.fallbackcrossrealm false If this parameter is set, VSJ will attempt to guess the client's realm from domain part of the hostname returned by ServletRequest.getRemoteAddr(), and the user is not required to append the realm to their username. By default this is false. idm.supportmultiple SPN false Whether to support multiple service principal names. If this option is set to true then the server will use the service name in the ticket to determine which key to use for decryption. The default is false. (See Manually Creating Keytab Files.) idm.ad.site none The Active Directory site in which this server should be placed. idm.tai.include / This parameter defines the URLs that will be included in the VSJ TAI authentication checking. It defaults to /. idm.tai.exclude /admin /ibm This parameter defines the URLs that will be excluded from the VSJ TAI authentication checking. It defaults to /admin.

35 Chapter 2 Installing VSJ (WebSphere Edition) 25 Table 1: VSJ Parameters for IBM WebSphere (continued) Parameter Default Description idm.ad.userprincipalattribute none This parameter can be set to the name of an Active Directory attribute. If set, the value of this attribute will be made available to web applications rather than the user name that was authenticated. This could be used to allow a user to login normally with username and password but then be known to the web application by perhaps an employee id, which is stored and managed in Active Directory. This property takes precendence over idm.ad.qualifyuserprincipal but is preceded by idm.ad.userprincipalformatterclass. com.wedgetail.idm.sso.password none The password of the Kerberos service principal. VSJ will create an in-memory keytab using this password. NOTE This property is required if idm.keytab or idm.password parameters are not set. This is a system property. Configure this property in the Custom Properties in the Java Virtual Machine section. See Keytabs and Passwords on page 46. jcsi.kerberos.nameservers automatic discovery A colon-separated list of one or more DNS servers that VSJ should use to look up DNS SRV records for Active Directory domain controllers. Specify each DNS server as either a hostname or as an IPv4 address. Normally VSJ automatically discovers DNS servers by querying the JVM and/or the operating system. However, in some circumstances (such as when VSJ is running on z/os), VSJ s auto-discovery logic comes up empty-handed and so the list of DNS servers must be specified explicitly. This is a system property. Configure this property in the Custom Properties in the Java Virtual Machine section.. idm.ad.qualifyuserprincipal false Fully qualify the authenticated user name returned by VSJ i.e. append the Active Directory domain name. The idm.ad.userprincipal attribute and idm.ad.userprincipalformatterclass properties take precedence over this one. This property should be set to true if you are using the VSJ User Registry in an environment with multiple Active Directory domains. idm.ad.userprincipalformatterclass none The class name of a UserPrincipalFormatter implementation to use for formatting principal names returned by VSJ. This property takes precendence over both idm.ad.userprincipalattribute and idm.ad.qualifyuserprincipal. idm.ntlm.signing.username none The NTLM logon name of a user account that VSJ can use for NTLM signing. idm.ntlm.signing.domain none The NTLM domain (not the AD domain) to which the above user account belongs.

36 26 VSJ (WebSphere Edition) 3.2 Deployment Guide Table 1: VSJ Parameters for IBM WebSphere (continued) Parameter Default Description idm.ntlm.signing.password none The password for the above account. See Keytabs and Passwords in Security Issues. idm.ntlm.signing.always false True means that VSJ should always use these signing parameters. False means that VSJ should only use these signing parameters if it got an exception while trying to authenticate a user without using these signing parameters. The default value is recommended. Setting Up Internet Explorer for SSO This section describes how to set up Internet Explorer for SSO. This includes: Windows Integrated Authentication (page 26) Troubleshooting your Internet Explorer configuration (page 26) Windows Integrated Authentication To take full advantage of VSJ, you must enable Windows Integrated Authentication. To use Windows Integrated Authentication, clients must be running Internet Explorer 5.5 or 6.0 on Windows 2000/2003/XP. You should also ensure that the High Encryption Pack (see downloads/recommended/128bit/default.mspx) is installed. You can confirm that the High Encryption Pack is installed by selecting About Internet Explorer from the Help menu in Internet Explorer. If it is installed, Cipher Strength: 128-bit will be shown on the About Internet Explorer dialog box. Windows Integrated Authentication is enabled by default on Internet Explorer 5.5. If you are using Internet Explorer 6.0 you will also need to do the following: 1. In Internet Explorer, on the Tools menu, click Internet Options. 2. Click the Advanced tab. 3. Scroll down to the Security section, and select the Enable Integrated Windows Authentication (requires restart) setting. 4. Click OK. 5. Restart your Internet Explorer by closing all the browser windows and then clicking on the Windows icon or Windows menu item. Troubleshooting Your Internet Explorer Configuration To use Internet Explorer for Windows Integrated Authentication you must ensure that the IBM WebSphere server on which you installed VSJ is in the Intranet Zone (on the Internet Explorer Security tab).

37 Chapter 2 Installing VSJ (WebSphere Edition) 27 This should be the case for most default setups, but may not be if one of the following is true: The domain name of the server on which VSJ is installed is different from the domain name of your desktop machine. You have modified the Intranet Zone settings. If your server is not part of the Intranet Zone then Windows Integrated Authentication will fail and you will be presented with a login dialog box. If this occurs, perform the following steps: 1. In Internet Explorer, on the Tools menu, click Internet Options. 2. Click the Security tab. 3. Click the Local intranet icon, and then click Sites. 4. Click Advanced. 5. Enter the name of your server and click Add. 6. Click OK. If you are sure that your server is part of the Intranet Zone, but a login dialog box is still displayed, do the following to check that Windows Integrated Authentication is being used in the Intranet Zone. 1. In Internet Explorer, on the Tools menu, click Internet Options. 2. Click the Security tab. 3. Click the Local intranet icon, and then click Custom Level Scroll down the Security Settings to the User Authentication section, and then select the Automatic logon only in Intranet Zone option. If Windows Integrated Authentication is still failing then you may have incorrectly set up the SPN for VSJ (See Map a Service Principal Name (SPN) on page 18). See Chapter 6 - Maintenance and Troubleshooting for other possible problems. Setting up Firefox and Mozilla for SSO on Linux and Unix Modern versions of Firefox and Mozilla (above 1.0 and respectively) support the SPNEGO protocol and can be configured to work with VSJ. Note: this support is NOT enabled by default and also depends on you having the Personal Security Manager component installed. To configure your browser carry out the following steps: 1. In a blank browser window type the following URL into the address box. about:config A list of all configuration parameters is shown in alphabetical order. 2. Scroll down to the following parameter and select it by clicking on the name. network.negotiate-auth.trusted-uris 3. Once selected you can modify this parameter by right clicking on the selected item. This brings up a menu from which you can select the modify option which now displays the editing window. 4. Use the editing window to add a comma separated list of values which are the base uris of the protected resource or web application, eg. to add the simple example web application the value entered would look like the following.

38 28 VSJ (WebSphere Edition) 3.2 Deployment Guide 5. Now that your browser is configured you must make sure that you have the security credentials for your domain. These credentials are used by the browser when authenticating with the VSJ and the application server. These credentials are obtained by logging into your domain with one of several methods. i You can use the jkinit.sh command which is supplied as part of the VSJ distribution. for example. $ jkinit.sh [email protected] Password for [email protected]: **** $ ii If the your host has been VAS enabled (see Installing VSJ on a VAS-Enabled Host on page 19) then when you login your credentials will be created automatically. To locate them the variable KRB5CCNAME will be set to the filename. iii $ ls -l ${KRB5CCNAME} -rw fred example 2264 May 23 08:06 /home/fred/.krb5cc $ jklist.sh -e -f ${KRB5CCNAME} TicketCache: FILE:/home/fred/.krb5cc Default principal: [email protected] Valid starting Expires Service Principal 05/23/ :06:23 05/23/ :06:23 krbtgt/[email protected] Flags: Etype: (skey) rc4-hmac 05/23/ :06:23 05/23/ :06:23 host/[email protected] Flags: Etype: (skey) rc4-hmac If the MIT kerberos client distribution is installed on your platform then you can also use the kinit command from this in a similar manner to the jkinit.sh command mentioned in item 1. Note These setting will also configure these browsers on the Windows 2000 and Windows XP operating systems. Also note that step 6 is not necessary as the login credential from the Windows Integrated Authentication is used.

39 Chapter 2 Installing VSJ (WebSphere Edition) 29 Advanced Installation Manually Creating Keytab Files VSJ supports two mechanisms for storing key information required to authenticate users setting a password via the com.wedgetail.idm.sso.password system property, and using keytab files. The password option is recommended, as this is the easiest option to initially setup. Once familiar with VSJ, Kerberos and keytabs then the keytab option is recommended. It is important to note, however, that the password option has some limitations. You can only set one password for the entire application server using this property. This is adequate in the majority of cases, because each HTTP server instance can only have one Service Principal Name (SPN) associated with it, and each SPN must be mapped to exactly one user. However, if you have a single application server with multiple virtual hosts, you could set up multiple accounts, one for each HTTP server. Alternatively, you may wish to use a file to store the Kerberos key rather than use the system property. In either case, you can create a keytab file containing the key and use this to initialize VSJ. To manually create a keytab file and use this with VSJ: 1. Generate keytab files for each service that requires authentication. This can be done with the tools included with the VSJ release. The following examples show how to create a keytab using the tools on Windows and Unix. The keytab will contain two keys, one RC4 and one DES for the SPN of HTTP/host.domain@realm with a key version number of -1 (a value which acts as a wildcard). Example of creating a keytab on Unix: /opt/vsj-3.0/bin $./jkutil.sh jktutil (type '?' for help): add_entry -password -p HTTP/host.domain@REALM -k 255 -e rc4-hmac Password for HTTP/host.domain@REALM: jktutil (type '?' for help): add_entry -password -p HTTP/host.domain@REALM -k 255 -e des-cbc-crc Password for HTTP/host.domain@REALM: jktutil (type '?' for help): list Slot KVNO Principal HTTP/host.domain@REALM HTTP/host.domain@REALM jktutil (type '?' for help): write_kt -o host.keytab jktutil (type '?' for help): quit /opt/vsj-3.0/bin $./jklist.sh -e -k host.keytab Keytab name: FILE:host.keytab KVNO Principal EncType HTTP/host.domain@REALM rc4-hmac -1 HTTP/host.domain@REALM des-cbc-crc /opt/vsj-3.0/bin $

40 30 VSJ (WebSphere Edition) 3.2 Deployment Guide Example of creating a keytab on Windows: C:\VSJ_3.0\bin> set JAVA_HOME=C:\jdk-1.4 C:\VSJ_3.0\bin> jktutil.bat jktutil (type '?' for help): addent -password -p HTTP/host.domain@REALM -k 255 -e rc4-hmac Password for HTTP/host.domain@REALM: jktutil (type '?' for help): addent -password -p HTTP/host.domain@REALM -k 255 -e des-cbc-crc Password for HTTP/host.domain@REALM: jktutil (type '?' for help): list Slot KVNO Principal HTTP/host.domain@REALM HTTP/host.domain@REALM jktutil (type '?' for help): wkt host.keytab jktutil (type '?' for help): quit C:\VSJ_3.0\bin> jklist.bat -e -k host.keytab Keytab name: FILE:host.keytab KVNO Principal EncType HTTP/host.domain@REALM rc4-hmac -1 HTTP/host.domain@REALM des-cbc-crc V:\VSJ_3.0\bin> 2. Once you have a keytab file, use the IBM WebSphere console to set the idm.keytab parameter for the VSJ TAI Interceptor. This parameter should contain the filename of the keytab file generated for this service. 3. Copy the generated keytab from Step 1 to the location specified by the Keytab parameter. Note The password you use in the above example must be the same password that is used for the user account mapped to the SPN. The new keytab contains sensitive information that could be used to subvert the security of your VSJ installation, so ensure that you set appropriate access permissions on this file, and do not send it over unsecured networks unencrypted. VSJ support keytabs with multiple SPNs which can be used to support virtual hosting scenarios. To enable this, set the SupportMultipleSPN option, and include an entry for each service principal you wish to support in your keytab.

41 Chapter 2 Installing VSJ (WebSphere Edition) 31 Upgrading VSJ To upgrade VSJ carry out the following steps. 1. Shutdown the IBM WebSphere application server. 2. Remove any jar files listed below that may exist in the WAS_HOME/java/jre/lib/ext and/or WAS_HOME/lib directories from previous versions. jcsi*.jar (excluding vsj-license.jar or its predecessor, jcsi_license.jar) vsj*.jar jcifs jar jldap.jar log4j jar 3. Install the new VSJ JAR files. 4. Restart the IBM WebSphere server. Uninstalling VSJ Before uninstalling VSJ remove any configuration that has been added to your IBM WebSphere application server. Now carry out the following steps. 1. From the WebSphere Administration Console, delete the VSJ TAI from the list of Trust Association Interceptors. 2. If you are using VSJ's FauxNtlmFilter in any of your web applications, edit the deployment descriptors of those web applications to remove the FauxNtlmFilter. (Alternatively, do NOT uninstall vsj-faux-ntlm.jar and jcifs jar below). 3. If you are using the VSJ User Registry, configure WebSphere to use a different user registry. 4. Now shutdown the IBM WebSphere server. 5. Remove the VSJ jars installed in the WAS_HOME/lib directory. These files are: vsj*.jar jldap.jar jcifs jar 6. You can now restart your IBM WebSphere server. We also recommend that as a precaution you remove the Service Principal Name (SPN) used for SSO from Active Directory. The SPN used for SSO may clash with the service principal used by IIS, preventing IIS integrated Windows authentication from functioning properly. The easiest way to remove the SPN is to remove the user account created for the service.

42 32 VSJ (WebSphere Edition) 3.2 Deployment Guide

43 Chapter 3 Deploying VSJ for Web Applications Overview Adding VSJ Authentication to a Web Application Enabling NTLM Authentication for a VSJ Web Application Setting Up Logging

44 34 VSJ (WebSphere Edition) 3.2 Deployment Guide Overview This chapter describes how to build SSO solutions using VSJ-protected Servlets and JSPs. It also explains how to set up audit logging. Adding VSJ Authentication to a Web Application Adding VSJ authentication to a Web application is easy. 1. Define a <security-constraint> directive for the URL(s) you wish to protect by adding the following XML fragment to the <web-app> definition in the web application s deployment descriptor (web.xml), for example: <security-constraint> <display-name>security Constraint with Authorisation</display-name> <web-resource-collection> <web-resource-name>authenticatedpages</web-resource-name> <url-pattern>/authenticated</url-pattern> <http-method>get</http-method> <http-method>post</http-method> </web-resource-collection> <auth-constraint> <role-name>all Role<role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>none</transport-guarantee> </user-data-constraint> </security-constraint> The <auth-constraint> directive allows you to specify role names which are used by the container to configure authentication. In addition to defining the <auth-constraint> you must declare any roles used in a <security-role> element. For example: <security-role> <description>all authenticated users</description> <role-name>all Role</role-name> </security-role> For a prepared example of a Web application that uses VSJ for authentication and authorization, see the examples directory of your installation. Enabling NTLM Authentication for a VSJ Web Application To add VSJ support for NTLM authentication to a Web application (in addition to setting the idm.allowntlm to true) the FauxNtlmFilter must be configured in the web.xml descriptor. To define the new filter you must add the following XML fragment: <filter> <filter-name>fauxntlmfilter</filter-name> <filter-class>com.quest.vsj.ntlm.fauxntlmfilter</filter-class> </filter>

45 Chapter 3 Deploying VSJ for Web Applications 35 Next, the filter must be set up to intercept all HTTP requests to your Web component, as follows: <filter-mapping> <filter-name>fauxntlmfilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> For an example of how to put this all together, view the deployment descriptor (web.xml) for the simple example in the distribution. Setting Up Logging VSJ can use the logging mechanism provided with IBM WebSphere. To take advantage of this, carry out the following steps: 1. Make sure that WebSphere is configured to log all messages, login to the admin console and check that in the Servers --> Application Servers -->... --> IBM Service Log page, the "Message Filtering" choice is set to "Log all messages". 2. Click on the "+" sign next to the "Troubleshooting" menu item in the left window. The node will be expanded to three selections and select "Logs and Trace". 3. In the next page click the name of your server. It will take you to the logging and tracing options panel. 4. Click on "Diagnostic Trace". The diagnostic trace configuration panel displays. This is where you can manage the trace output. To adjust the trace output, you can either type in your new values in the "Trace Specification" text box, or you can click on the "Modify" button to bring up a wizard that will walk you through your changes. You can select either the "Configuration" or "Runtime" tabs on this screen. The "Configuration" tab will allow you to change the configuration, which will only take effect after the WebSphere Application Server has been restarted. Selecting the "Runtime" tab allows you change the trace level immediately and also to save the changes by selecting the "Save runtime changes to configuration as well" checkbox The wizard displays all known WebSphere facilities that utilize trace logging, and in version 5.0, your implementation will appear under the category UNKNOWN (once you have logged at least one message). Click on each of the items listed that start with either com.wedgetail, com.dstc, com.vintela, or com.quest and a menu will be displayed. Select the "all enabled" item at the bottom of the choices. If you cannot find the category UNKNOWN, you can manually configure debugging by typing the following line into the "Trace Specification" field to enable all the debug messages. com.wedgetail.*=all=enabled:com.dstc.*=all=enabled:com.vintela.*=all=enabled :com.quest.*=all=enabled Select the "Apply" button at the top of the screen to transfer the configuration to the main screen. Select "OK" or "Apply" at the bottom of the main screen to commit these changes You can also change the name of the trace log file in the Trace Output section of the panel. Once you have made your changes, click OK and follow the instructions to save the master configuration.

46 36 VSJ (WebSphere Edition) 3.2 Deployment Guide 5. You can also use the administrative console to view the trace log. Click on the "Runtime" tab on the configuration panel to access this option In the "Trace Output" section of the panel, click the "View" button. This will take you to the trace log view screen The default display behavior is to show the total number of lines and the first 250 lines of the log, but you can specify any range of lines and refresh the screen to get to the portion of the log that you would like to see. You can also tail the log files (the default is trace.log) which is located in the WAS_HOME/logs/ server1 directory (where server1 is the node name of your IBM WebSphere instance.) The Standard Output (StandardOut.log) and Standard Error (StandardErr.log) output streams are also located under the WAS_HOME/logs/server1 directory.

47 Chapter 4 Using the JKTools Overview The JKTools jkinit jklist jktutil Examples Authenticate and Request a Default Credential List the Default Credential Cache Showing the Key Encryption Type Create a Keytab with an rc4-hmac Key List a Keytab Showing the Encryption Types Merge Two Keytabs

48 38 VSJ (WebSphere Edition) 3.2 Deployment Guide Overview VSJ (WebSphere Edition) includes several tools which enable you to create, manipulate and display Kerberos credential caches and keytab files: jkinit authenticate and request a network credential jklist display credential cache or keytab contents jktutil create, manipulate and display keytabs The JKTools The tools are Java-based and will therefore run on z/os, Linux, and Unix computers as well as Microsoft Windows platforms. When the jkinit and jklist tools are run on a Windows platform they operate on the Windows LSA (Local Security Architecture) credential cache, while under Unix they operate on standard files in the filesystem. The tools also operate on files created by utilities from the MIT Kerberos distribution, an implementation commonly found on Linux and Unix installations. Each tool has help embedded so that invoking the tool with the -help parameter will display summary information about the parameters the tool supports. The manual pages are included in the distribution and contain detailed information about the use of each of these tools. jkinit The jkinit tool is used to request and store a credential from a Microsoft Active Directory. This is located on the Domain Controller responsible for the requested domain (or realm). After a successful authentication a credential is returned which is then stored in a credential cache. The credential can then be used in later operations. jklist The jklist tool is used to display the contents of credential caches and keytabs including the key enycryption types, the ticket flags and principal name. jktutil The jktutil tool allows the user to create keytab entries specifying the principal name, encryption type and key version number. The entries can then be saved or appended to a keytab file. jktutil can also read and write keytab files, which enables merging of keytabs and their entries.

49 Chapter 4 Using the JKTools 39 Examples Authenticate and Request a Default Credential $ jkinit.sh [email protected] Password for [email protected]: ****** Authenticate and Request a forwardable and proxyable credential $ jkinit.sh -f -p [email protected] Password for [email protected]: **** List the Default Credential Cache Showing the Key Encryption Type $ jklist.sh -e TicketCache: FILE:/tmp/krb5cc_1000 Default principal: [email protected] Valid starting Expires Service Principal 02/14/ :25:23 02/14/ :25:23 krbtgt/[email protected] Etype: (skey) rc4-hmac List the Default Credential Cache Showing the Ticket Flags $ jklist.sh -f TicketCache: FILE:/home/alice/.krb5cc Default principal: [email protected] Valid starting Expires Service Principal 05/26/ :11:01 05/26/ :08:55 HTTP/[email protected] Flags: OA 05/26/ :29:34 05/26/ :29:33 krbtgt/[email protected] Flags: FPIA Create a Keytab with an rc4-hmac Key $ jktutil.sh jktutil (type '?' for help): add_entry -password -p [email protected] -k 255 -e rc4-hmac Password for [email protected]: ****** jktutil (type '?' for help): list Slot KVNO Principal [email protected] jktutil (type '?' for help): write_kt [email protected] jktutil (type '?' for help): quit

50 40 VSJ (WebSphere Edition) 3.2 Deployment Guide List a Keytab Showing the Encryption Types $ jklist.sh -e -k [email protected] Keytab name: FILE:[email protected] KVNO Principal EncType [email protected] rc4-hmac Merge Two Keytabs $ jktutil.sh jktutil (type '?' for help): rkt [email protected] jktutil (type '?' for help): wkt -o [email protected] jktutil (type '?' for help): rkt [email protected] jktutil (type '?' for help): wkt -a [email protected] jktutil (type '?' for help): rkt [email protected] jktutil (type '?' for help): list Slot KVNO Principal [email protected] 2-1 [email protected] jktutil (type '?' for help): quit

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

52 42 VSJ (WebSphere Edition) 3.2 Deployment Guide Overview Like any security software, VSJ requires that it be configured and deployed correctly to be secure. VSJ is designed with a secure by default policy. However, developers should be aware of certain issues that need to be addressed to achieve this in practice. This section outlines the mechanisms in VSJ used to achieve secure operation, and outlines some areas that may need special attention. Note This chapter assumes familiarity with basic security concepts, Kerberos, the HTTP protocol and J2EE application configuration. Summary of Basic Recommendations Limit the use of basic fallback where possible (disabled by default). Limit the lifetime of sessions, and ensure that session IDs are "unguessable". Ensure that the authorization rules limit users to their least privilege. If using basic fallback, configure Active Directory to lock out users after some specified number of failed logins. Do not use basic fallback where there is a high risk of Denial of Service attacks, or provide other countermeasures to prevent them. Enable logging to at least the WARN level. Client Issues Cookies Unlike some Web SSO implementations, VSJ does not use cookies to store encrypted passwords. Instead it relies on the caching of Kerberos tickets to provide SSO functionality. For Microsoft Windows clients, these credentials are stored in memory, and never written to disk, so the chance of compromise is very low. However, cookies are commonly used to store session ID state (see Session IDs on page 44). Because authentication in VSJ is bound to the session state, these cookies present a security risk if they are leaked or sent in clear across the network. This means that communication between the browser and application server should always be done via SSL to protect these session IDs. Most application servers use transient cookies for tracking session state that are only stored in memory by the browser, and will not be written to disk. This means there is a low risk of compromise of the session ID information from the client. Alternatively, you could develop your applications to use URL rewriting instead of cookies for session state, which has the advantage that it will work for all browsers, regardless of whether they have cookies enabled or not.

53 Chapter 5 Security Issues 43 Caching of Passwords for Basic Fallback For non-internet Explorer clients, or clients that do not support Kerberos, VSJ provides a mechanism for authenticating via the standard basic HTTP authentication mechanism. This sends a password in clear over HTTP, which is then used by the VSJ-protected Filter/Servlet to perform a standard Kerberos authentication. Because most clients support password managers and/or caching of passwords when using basic authentication, care should be taken to ensure that this information is not leaked or sent over the network. Again, this means ensuring that the password is not saved on a network volume, and that authentication should be done over SSL (see Basic Fallback on page 46). Consult your browser documentation to ensure that it is configured appropriately. SPNEGO/Windows Integrated Authentication VSJ uses the SPNEGO protocol to perform Windows Integrated Authentication via HTTP. This protocol uses the Kerberos GSS-API protocol to mutually authenticate clients and servers via HTTP headers. While the GSS-API protocol itself is secure, this protocol does not ensure that the content of the HTTP request is securely bound to the message. This means that a man-in-the-middle attack could be used to modify the HTTP content while keeping the authentication headers intact. For this reason, unless the risk is very low, you should ensure that authentication is done over SSL. Lifetime of Authentication Because SPNEGO requires two round trips to authenticate requests, it would be too expensive to perform an authentication for each request. Instead, applications supporting SPNEGO will bind the authentication to a session or a connection. Note that authentication and reauthentication is performed transparently by Internet Explorer, and the user is not required to reenter their password. When Windows Integrated Authentication is done to IIS using Internet Explorer, the authentication is done once per connection (HTTP 1.1 allows multiple requests to performed over the same connection). As long as a connection is kept open, the user will not have to reauthenticate. For VSJ, authentication is bound to a J2EE session (that is, once authenticated for a particular session, the user is not required to authenticate for the lifetime of that session, or until their service ticket expires). The session has a lifetime defined by the J2EE configuration. While this means that a user will have to reauthenticate for each application (and each new session), the lifetime of these authentications may be potentially longer. In practice, this will make little difference as the connections should be protected by SSL, meaning that there is little opportunity for an attacker to obtain a session ID or hijack a TCP connection. However, the distinction needs to be considered when thinking about the appropriate lifetime of J2EE session IDs (see Session IDs below).

54 44 VSJ (WebSphere Edition) 3.2 Deployment Guide Session IDs VSJ binds the authentication of a user to a J2EE session ID. It does this by authenticating the user via SPNEGO (or the basic fallback mechanism) and then storing the user's Kerberos ticket and other associated information in the J2EE session information. For subsequent requests that use this session ID, VSJ checks that the information is still valid and lets the request through without requesting reauthentication. This means that an attacker who is able to sniff the session ID, or obtain it by "guessing" will be able to subvert the security of VSJ. For this reason, SSL should always be used to protect the session, and you should ensure that the session IDs used by your application server are random and large enough that they cannot be guessed by brute force. In addition, you should ensure that the mechanism that your application server uses to ensure persistence of session information does not involve sending the session ID in the clear over the network. This could be the case, for example, if JDBC to a database on another machine or a network file system is being used for persistence. Lastly, because of the sensitivity of session ID information, VSJ ensures that it does not log session IDs, but instead logs the MD5 hash of the ID. This allows events to be correlated across sessions, without the risk of the session ID being leaked (for example, if you are logging over a network, or to a network volume). See Auditing on page 48 for more details on logging. Active Directory Permissions VSJ requires read access to a number of attributes in Active Directory. This section details which attributes and permissions are required. Note Access to these elements is enabled by default in Active Directory. Setting these permissions is only required if you have modified these defaults. The following containers are examined: RootDSE Configuration Partitions User/Group The RootDSE container is examined for the following attributes: rootdomainnamingcontext defaultnamingcontext configurationnamingcontext supportedsaslmechanisms The Configuration container is examined for the following attributes: objectclass=crossrefcontainer The Partitions container is examined for the following attributes: netbiosname=${domain} dnsroot

55 Chapter 5 Security Issues 45 The top-level domain container is examined for the following attributes: ntmixeddomain User/Group Accounts are examined for the following attributes: useraccountcontrol grouptype userprincipalname serviceprincipalname distinguishedname objectclass cn samaccountname name lastlogon badpwdcount objectsid sidhistory primarygroupid The property sets for the attributes listed above are as follows: Table 2: Active Directory Attributes and Property Sets Attribute userprincipalname serviceprincipalname distinguishedname objectclass cn samaccountname member grouptype useraccountcontrol ntmixeddomain rootdomainnamingcontext defaultnamingcontext configurationnamingcontext supportedsaslmechanisms name Property Set PublicInformation PublicInformation PublicInformation PublicInformation PublicInformation GeneralInformation Membership N/A N/A N/A N/A N/A N/A N/A N/A

56 46 VSJ (WebSphere Edition) 3.2 Deployment Guide Table 2: Active Directory Attributes and Property Sets (continued) Attribute lastlogon badpwdcount objectsid sidhistory primarygroupid dnsroot netbiosname Property Set User-Logon User-Logon GeneralInformation GeneralInformation GeneralInformation N/A N/A For the normative reference on Active Directory property sets, see: property_sets.asp Basic Fallback The basic fallback mechanism is provided to allow support for non-kerberized browser clients. It allows a simple username and password to be entered and a Kerberos login to be performed on the server. Some issues to do with caching of passwords on clients are described on page 43. The basic challenge uses the Active Directory domain in the realm part of the request, meaning that for browsers that cache passwords, the user will not have to reenter their password for the lifetime of the cached password for any application that is using that Active Directory domain. However, unless the browser is running a password manager the cached password will disappear when the user closes their browser. This will result in them having to reenter their password the next time they connect to an application. Once VSJ has used the password to obtain the Kerberos ticket on the server, the password is disposed of. This limits the risk of a server compromise compromising a large number of passwords. It should be noted that the basic fallback mechanism provides an opportunity for an attacker to try to guess passwords for Kerberos users. VSJ does not do any checking for a number of bad logins (although it is possible to obtain the number of bad logins since the last login if a request is successful programmatically). For this reason you should consider configuring Active Directory to lock out users after a number of bad login attempts (see page 48 for Denial of Service risks associated with this approach). Keytabs and Passwords VSJ requires that the application be associated with a user account and provided with either a password, or a keytab file (see Manually Creating Keytab Files on page 29 for details) stored on the server. idm.password and com.wedgetail.idm.sso.password are intended to be convenient for initial setup and debugging in a test environment. Once VSJ is up and running happily with the password, we recommend using a keytab instead.

57 Chapter 5 Security Issues 47 Similarly, while the keytab file location is specified by a parameter in the deployment descriptor, it must be stored at an absolute location on the server, and not in the EAR/WAR file. This is because commonly there may be multiple copies of EAR/WAR files created by developers/deployers lying around with sensitive passwords in them, or they may be deployed in the clear over unsecured links. In all cases, care must be taken to ensure that applications that should not have access to this information are either not deployed on the same server, or access is prevented by enabling the Java security manager. If you choose to do the latter you will need to configure your Java security policy file to grant various permissions. Authorization Do You Need Authorization? Many J2EE developers are used to deploying applications and just creating a username and password for those users who need to access the application. However, with VSJ, unless you want everyone with a desktop login in your organization to access the application you will need to define some authorization groups to control access. Securing LDAP VSJ uses group information in the PAC of the service ticket to authorize users. However, this group information only lists the SIDs and not the names of the groups which are specified in the authorization policy. To resolve names, VSJ needs to contact Active Directory via LDAP. In most cases it only needs to do this once at load time, however if you are using some of the programmatic functions to access group information, this may also happen at run time. The information in the PAC is securely authenticated as part of the ticket. However, the mapping between SIDs and the group names they represent must be done securely. Otherwise, an attacker could substitute their own name for SID mappings and subvert the authorization mechanism. For this reason the connections between VSJ and the Active Directory LDAP servers need to be secured. By default, connections to Active Directory are secured using the standard SASL/GSS-API mechanism. Using the "Principle of Least Privilege" The Principle of Least Privilege is a security maxim stating that users should only be given the least amount of privilege required, and no more. We recommend that you apply this principle when creating authorization policies using VSJ. Allocate a role to each task and map this to one or more groups managed in Active Directory. It is useful to use groups which are specific to your application to prevent the risk of a user inadvertently being added to a group so they may access an entirely different application.

58 48 VSJ (WebSphere Edition) 3.2 Deployment Guide Denial of Service VSJ has a number of mechanisms to prevent Denial of Service (DoS) attacks. The most important is that no state information is stored on the server until the client has authenticated. In addition, VSJ limits the amount of communication that is required with back-end servers, and in most cases authentication and authorization can be performed locally without having to contact Active Directory. However, there are some issues that need to be considered to increase resistance to DoS attacks. These are discussed below. Basic Fallback Unlike Windows Integrated Authentication, the basic fallback mechanism requires communication with Active Directory to be performed by the server. Because of this, it can be exploited to mount a DoS attack by saturating the number of outgoing connections. A number of application servers can also be used to "amplify" an attack on Active Directory using this feature. For this reason, basic fallback should be disabled in situations where there is a high risk of DoS attacks, or other measures should be undertaken (such as using a firewall that drops a large number of connections, or increasing capacity). Session State Once authenticated, each VSJ session will store security information associated with the connection, including the user's ticket and delegated credential. It could be possible for an attacker who obtains a legitimate user's account to saturate the memory of an application server by making a large number of new requests to an application. However, this is a fairly low risk. Such an event would be indicated by a large number of logins from the same account in the audit logs, and could be effectively stopped by disabling the offending account. Auditing VSJ provides an auditing capacity with several different levels allowing effective diagnosis and recovery for security events. Setting Up Logging on page 35 describes how to enable this logging facility. We recommend that the logging level be set to "WARN", which covers security sensitive events such as bad logins. If there is sufficient capacity and a low risk of a DoS attack on your logging system, you will also find INFO to be useful, as this logs information about successful requests. The audit logs contain the date, source IP, URL being accessed and, if appropriate, the MD5 hash of the session ID to allow effective correlation of events.

59 Chapter 6 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

60 50 VSJ (WebSphere Edition) 3.2 Deployment Guide Overview 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. Maintenance This section discusses the maintenance issues relating to a VSJ deployment. Logging VSJ supports logging at different levels (see Setting Up Logging on page 35). For maintenance purposes, logging at WARN level is recommended, along with regular inspection of the generated log file. Regular inspection should alert the administrator to potential problems within VSJ. If any aspect of logging needs to be changed (for example, to enable or disable logging, or to change the information level), then the relevant sections of the web.xml file or the error log file must be modified, a new WAR file created and the Web application redeployed. New Users / Groups Adding a new user or group to Active Directory should not impact upon the performance of VSJ so long as existing policy settings remain unchanged (see Access Policy Changes below). Once a new user or group has been added to Active Directory, that user may be authenticated by VSJ through the existing mechanisms. Account Settings VSJ may cache information about user / group accounts for efficiency. For example, the groups that a user belongs to may be cached once that data has been obtained, and the authorization policy may be determined based on this (cached) data. If the group membership details of that user are updated dynamically, this may not be reflected in VSJ's cache, and subsequent authorization determinations may produce incorrect results. Access Policy Changes VSJ supports authorization using a policy file that specifies which users and/or groups may access resources. For example, access to a particular Web page may be restricted to all members of the group "Managers". If this policy needs to be changed (for example, to allow "Developers" as well as "Managers" to access the resource), then the policy.xml file for the Web application must be modified, a new WAR file created and the Web application must be redeployed.

61 Chapter 6 Maintenance and Troubleshooting 51 Network Topology Changes VSJ performs dynamic lookups when resolving services (such as finding the KDC for a realm, or domain controller for a domain) to hosts. Modifying the underlying network topology should therefore not present a problem for VSJ, although it should be noted that a lag between the time the topology has been modified and the time that dynamic lookups reflect this new topology may cause some connection timeouts. Changes to domain names, etc, that also require changes to VSJ's configuration (in particular, to the underlying web.xml file) require the creation of a new WAR file and redeployment of the Web application. Troubleshooting This section provides solutions to some common problems which may be experienced when configuring and deploying applications using VSJ. General Problem: When connecting to the servlet an Error page is displayed indicating an Internal Server error. This error is due to either a configuration problem on the server, a misconfiguration of the client browser, or some other internal failure such as an incorrect response returned from a KDC. Depending on your application server, a more detailed message may be displayed in the error page, or you may need to look at the application server log files for the root cause. The following causes are noted below: Cause 1: Could not get service ticket for <principal>@<realm> This error will be shown in the application server's logs as: CryptoException: Integrity Check Fail It is indicative of a keytab that has been created with an incorrect password. To resolve the problem you should regenerate the keytab using the correct password. Cause 2: Cause 3: Error 500: Filter [authfilter]: com.wedgetail.idm.sso.authfilter was found, but is missing another required class. Java 2 Security has been enabled without a suitable policy file. Either disable Java 2 Security or contact us for help building a suitable security policy file. [Servlet Error]-[Filter [authfilter]: could not be initialized]: com.dstc.security.kerberos.kerberosexception: key type mismatch This problem only occurs on Microsoft Windows 2003 when a service request is sent in an ENC type that is different from the service ticket returned. It is only a problem with Memory keytabs. One solution is to change the Active Directory user account for the service so that the Use DES Only option is checked. Alternatively, you could use a file keytab.

62 52 VSJ (WebSphere Edition) 3.2 Deployment Guide Cause 4: ConfigException: Unable to resolve Domain Controller for NTLM This problem occurs when VSJ cannot automatically establish the NTLM domain controller using the DNS. One possible solution to this problem is to manually specify the domain controller to be used. You can do this by adding the jcifs.http.domaincontroller parameter to the Web application s deployment descriptor (web.xml), i.e.: <init-param> <param-name>jcifs.http.domaincontroller</param-name> <param-value>mydomaincontroller</param-value> </init-param> Active Directory Problem: I created a new service principal, but then I received an "Integrity check failure" message. Cause: Sometimes Active Directory doesn't set the keys properly for a newly created service principal until you log in to that account once. Log in as that user, log out and then restart your application server software. Browsers Problem: VSJ returns the following HTTP error response codes: 401 (UNAUTHORIZED) -- request is not authorized 403 (FORBIDDEN) -- access to requested resource is forbidden 500 (INTERNAL SERVER ERROR) -- internal server error. Cause: Error responses from VSJ will typically return no content, and display on the client browser as an empty page. If you wish to display different content for such errors, or to take some other action based on such errors, add an <error-page> element to web.xml. For example: <error-page> <error-code>401</error-code> <location>/errors/401.html</location> </error-page>

63 Chapter 6 Maintenance and Troubleshooting 53 Internet Explorer Browsers Problem: When using Internet Explorer, you are presented with a username and password dialog box rather than being automatically logged in. Cause: This occurs when Internet Explorer does not recognize the hostname as being part of the Intranet Zone. You may have not configured Internet Explorer to use Windows Integrated Authentication. Do the following: For SPNEGO, check that your Internet Explorer version is 5.5 or greater. Follow the steps in Troubleshooting Your Internet Explorer Configuration on page 26 to ensure that Internet Explorer has been correctly configured to support SPNEGO. Problem: The following error is encountered when authenticating against the server: [ERROR]: Provider protocol error: com.wedgetail.idm.spnego.server.spnegoexception: java.lang.securityexception: Unsupported keysize or algorithm parameters Cause: This problem is encountered when using a version of Internet Explorer that does not have the High Encryption Pack installed. There are two workarounds: Install the appropriate High Encryption Pack for your Internet Explorer browser (see Setting Up Internet Explorer for SSO on page 26 for more information). Install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files (US_export_policy.jar and local_policy.jar). You can download them from java.sun.com/j2se/1.4/download.html.internet Explorer 5.5 displays DNS error page. Cause: If the user account is disabled at any time, Kerberos will be unable to renew credentials for the user. Problem: Internet Explorer 6 displays a blank page Cause 1: Cause 2: Windows Integrated Authentication is not enabled. See Setting Up Internet Explorer for SSO on page 26. You are going through a proxy that does not support session-based authentication. Disable the proxy in your browser.

64 54 VSJ (WebSphere Edition) 3.2 Deployment Guide Non-Internet Explorer Browsers Problem: When using a non-internet Explorer browser, rather than presenting a username and password dialog box, the browser gives an error message indicating that the authentication mechanism is not supported. Cause: The filter has not been configured to allow fallback authentication for non-internet Explorer browsers. You need to ensure that the filter is configured with the idm.allowfallback option set to true. Otherwise, non-internet Explorer browsers will not be supported. Authentication Problem: Servlet/JSP configured with AuthFilter fails to start. This is commonly caused by a configuration problem with the AuthFilter filter. You will need to check your application servers log file to determine the root cause. Possible log entries are: Cause 1: Cause 2: Cause 3: Cause 4: ServletException: Need to set idm.realm. The idm.realm parameter determines the Kerberos realm that will be use by the SSO solution to authenticate clients. It must be set in the deployment descriptor. ConfigException: Only one of "idm.keytab" or "idm.ccache" or "com.wedgetail.idm.sso.password" should be specified. The SSO solution supports either user-to-service mode (using a keytab), or user-to-user mode (using a credential cache). Only one of idm.keytab or idm.ccache or com.wedgetail.idm.sso.password may be specified. In most cases you will want userto-service. ConfigException: Must configure either idm.ccache or idm.keytab or com.wedgetail.idm.sso.password. The deployer must specify either the credential cache or keytab to use. Config Exception: Must use a keytab if idm.allowfallback configured. The idm.allowfallback parameter allows the deployer to specify whether the AuthFilter filter should allow users to authenticate using basic authentication and act as an authentication proxy to perform a Kerberos login to the KDC on the user's behalf. If fallback mode is enabled, then user-to-service mode must be used, and hence a keytab must be specified via the idm.keytab parameter, or the keytab password specified by the com.wedgetail.idm.sso.password system property.

65 Chapter 6 Maintenance and Troubleshooting 55 Cause 5: Cause 6: ConfigException: <keytab> not found The keytab specified by idm.keytab could not be loaded. The keytab must be at the path specified. Ensure that the file is present and that the correct path and file name is specified in the idm.keytab parameter. ConfigException: No keytab entries for <principal>@<realm> in <keytab> The specified keytab did not contain any keys for the principal that was configured using idm.principal and idm.realm. If idm.principal was not specified then entry will be of the form: HTTP/<host.domain>@<realm> Where <host> is the fully qualified name of the host on which the filter is deployed. You can use the Kerberos klist command to check the keytab entries. Under UNIX this command is supplied as part of the Kerberos distribution and under Windows is supplied with JDK 1.4. Ensure that there is an entry for the specified principal. Cause 7: Cause 8: Cause 9: ConfigException: Could not load keytab "<keytab>" The keytab could not be loaded for some reason. Possibly this was due to corruption, or an incorrectly formatted file. ConfigException: Invalid KDC host "<kdc>" The hostname for the KDC specified by the parameter idm.kdc is invalid. Ensure that the correct hostname is supplied. ProtocolException: Could not get service ticket for principal name [caused by: com.dstc.security.kerberos.cryptoexception: Integrity check failure] The realm specified in idm.realm is case-sensitive and is usually uppercase. If the case does not match, the DES keys for the service will be incorrect, as they are derived from the fullyqualified principal name. Cause 10: Filter could not be loaded: com.dstc.security.util.licensing.invalidlicense: Error verifying license: Cannot open resource jcsi.licensing.cert.pem The licensing code can not find a license, either because it has not been installed, or Java 2 Security has been enabled, without a suitable policy file. Problem: Why is Internet Explorer trying to do NTLM? Cause: VSJ is designed to work with Windows Integrated Authentication using Kerberos. However, if your browser or Active Directory is not configured correctly this will fail, and Internet Explorer will attempt to fallback to NTLM authentication. If you have NTLM disabled in VSJ, or if you are using JCSI SSO for BEA WebLogic SSPI, then you may be presented with a username/password dialog, and you will see the following message in the error log: Could not authorize request: com.wedgetail.idm.sso.ntlmnegotiatedexception

66 56 VSJ (WebSphere Edition) 3.2 Deployment Guide Generally, fallback to NTLM will occur for one of the following reasons: 1 You are using a Microsoft Windows 95, 98 or ME browser which does not support Kerberos. 2. You are not logged in to the domain. 3. You are trying to connect from a browser on the same host as that on which the application server is running. 4. The Service Principal Name (SPN) is not correctly mapped to the service account used by VSJ. 5. Internet Explorer is not configured properly. In particular, the site you are connecting to is not considered part of the Intranet Zone. You also need to ensure that Windows Integrated Authentication is enabled. One way to test whether it is cases 4 or 5 is to install a packet sniffer. We recommend Ethereal ( If case 4 has occurred, Ethereal should provide the following output: 1. HTTPresponse 401 Unauthorized 2. KRB_AP_REQ 3. KRB_AP_REP (Indicating a Kerberos Error) 4. HTTP request with the broken negotiate header. If you are certain that the SPN has been correctly set up, send the Ethereal trace to [email protected] and one of our experienced support engineers will assist you in identifying the problem. If case 5 has occurred, no Kerberos traffic will be visible in the Ethereal trace. Keytabs Problem: When using a keytab I get "Could not verify PAC in auth data" Cause: When generating a keytab using ktpass the default key type is DES-CBC-CRC. There is a known problem using these types of keys. You must specify -crypto DES-CBC-MD5 when generating the keytab. Problem: I am getting a "No keytab entry for decrypting. Data encrypted with key type 23..." message. Cause: This error is caused when the keytab used contains only DES keys but the account is not set to 'Use DES only'. This can be fixed by either adding an RC4 key to the keytab, or setting the user account to Use DES only.

67 Chapter 6 Maintenance and Troubleshooting 57 Network Connections Problem: When attempting to connect to a URL protected by the filter you receive an error message: 403 Forbidden This Connection Must be secured. Cause: By default, VSJ requires that communications be performed securely (for example using HTTPS). This is for two reasons: Once a session is authenticated, the filter does not require authentication for subsequent requests using the same session ID. If it were, this would require an extra round-trip (or in some cases, two) to authenticate each request. However, this means an attacker who is able to sniff the session ID would be able to hijack an authenticated session. Note: even if every request was authenticated, the SPNEGO protocol does not tie any of the content in the HTTP request to the authentication information, so an active attacker could still hijack session requests. If the fallback mechanism is supported for non-internet Explorer browsers, Kerberos usernames and passwords will be sent unprotected over the network. We strongly recommend using SSL to secure communications for these reasons. However, should you wish to use the SSO solution to authenticate clients over unprotected connections (for example, for testing, or where there is a very low risk of attackers hijacking sessions), then you may set the idm.allowunsecured option to true. Credential Delegation Problem: Servlet authenticates but there are no delegated credentials (or deleg example displays message "Expected delegated credential but didn't get any") Cause 1: Cause 2: The service account is probably not trusted for delegation See Create a User Account on page 17. The user may have their account configured so that delegation is not allowed. Check the user's account properties in Active Directory. Problem: Delegation to IIS fails, with a MIC check problem. Cause: This is because IIS seems to send back a clone of the mechtoken in the MIC field, which causes MIC-checking to fail. Setting the system property idm.spnego.nomiccheck to true will disable MIC checking.

68 58 VSJ (WebSphere Edition) 3.2 Deployment Guide Debugging Problem: How do I get more debug information out of VSJ? At the lowest level setting the Java system properties jcsi.kerberos.debug to the value true and idm.spnego.debug to the value true should produce logging to the standard error output stream. VSJ Servlet Filter is configured on a per web application basis. This configuration is based upon log4j and defined in the Web applications web.xml deployment descriptor. VSJ WebLogic Edition is configured through the BEA WebLogic administration console by creating and adding the Default Audit Provider in the Realms -> Providers -> Auditing menu. VSJ WebSphere Edition logging is configured through the IBM WebSphere administration through the Troubleshooting -> Logs and Trace -> servername -> Modify menu.

69 Glossary Active Directory access control authentication authorization A hierarchical directory service that comes with Windows It is LDAP compliant and built on the Internet's Domain Naming System (DNS). Active Directory can function in a heterogeneous, enterprise network and encompass other directories including NDS and NIS+. A set of procedures performed by hardware, software and administrators to monitor access, identify users requesting access, record access attempts, and grant or deny access. Compare with authorization. Authentication is the process of determining whether someone or something is, in fact, who or what it is declared to be. In private and public computer networks (including the Internet), authentication is commonly done through the use of logon passwords. Knowledge of the password is assumed to guarantee that the user is authentic. Each user registers initially (or is registered by someone else), using an assigned or self-declared password. On each subsequent use, the user must know and use the previously declared password. The weakness in this system for transactions that are significant (such as the exchange of money) is that passwords can often be stolen, accidentally revealed, or forgotten. Logically, authentication precedes authorization (although they may often seem to be combined). Authorization is the process of giving someone permission to do or have something. In multi-user computer systems, a system administrator defines for the system which users are allowed access to the system and what privileges of use (such as access to which file directories, hours of access, amount of allocated storage space, and so forth). Assuming that someone has logged in to a computer operating system or application, the system or application may want to identify what resources the user can be given during this session. Thus, authorization is sometimes seen as both the preliminary setting up of permissions by a system administrator and the actual checking of the permission values that have been set up when a user is getting access. Logically, authorization is preceded by authentication. DeMilitarized Zone (DMZ) A middle ground between an organization's trusted internal network and an untrusted, external network such as the Internet. 57

70 58 VSJ (WebSphere Edition) 3.2 Deployment Guide Enterprise JavaBeans (EJB) A software component in Sun's J2EE platform, which provides a pure Java environment for developing and running distributed applications. EJBs inherently provide future scalability and also allow multiple user interfaces to be used. Generic Security Service API (GSS-API) A C API for distributed security services. Described in IETF RFC Java Authentication and Authorization Service (JAAS) A package that enables services to authenticate and enforce access controls upon users. It implements a Java version of the standard Pluggable Authentication Module (PAM) framework, and supports user-based authorization. Java Cryptography Architecture (JCA) An umbrella term from Sun for implementing security functions for the Java platform. It includes Sun's Java Security API as well as the Java Cryptography Extension (JCE), which adds more programming interfaces for encryption and key exchange. It also provides a mechanism for adding third-party security packages such as algorithms and digital signatures into Java applications. Java DataBase Connectivity (JDBC) Kerberized application A programming interface that lets Java applications access a database via the SQL language. Since Java interpreters (Java Virtual Machines) are available for all major client platforms, this allows a platform-independent database application to be written. A software application that requires or performs Kerberos authentication. Kerberos Kerberos is a secure method for authenticating a request for a service in a computer network. Kerberos was developed in the Athena Project at the Massachusetts Institute of Technology (MIT). The name is taken from Greek mythology; Kerberos was a threeheaded dog who guarded the gates of Hades. Kerberos lets a user request an encrypted ticket from an authentication process that can then be used to request a particular service from a server. The user's password does not have to pass through the network. Lightweight Directory Access Protocol (LDAP) A software protocol for enabling anyone to locate organizations, individuals, and other resources such as files and devices in a network, whether on the public Internet or on a corporate intranet. LDAP is a lightweight version of Directory Access Protocol (DAP), which is part of X.500, a standard for directory services in a network. Netscape includes it in its latest Communicator suite of products. Microsoft includes it as part of what it calls Active Directory in a number of products including Outlook Express. Novell's NetWare Directory Services interoperates with LDAP. Cisco also supports it in its networking products.

71 Glossary 59 Secure Sockets Layer (SSL) The Secure Sockets Layer (SSL) is a commonly-used protocol for managing the security of message transmission on the Internet. SSL uses a program layer located between the Internet's Hypertext Transfer Protocol (HTTP) and Transport Control Protocol (TCP) layers. SSL is included as part of both the Microsoft and Netscape browsers and most Web server products. Developed by Netscape, SSL also gained the support of Microsoft and other Internet client/server developers, becoming the de facto standard until evolving into Transport Layer Security (TLS). The sockets part of the term refers to the sockets method of passing data back and forth between a client and a server program in a network or between program layers in the same computer. SSL uses the public/private key encryption system from RSA, which also includes the use of a digital certificate. Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) Single Sign-On (SSO) A GSSAPI mechanism that allows the secure negotiation of the mechanism to be used by two different GSSAPI implementations. In essence, SPNEGO defines a universal but separate mechanism, solely for the purpose of negotiating the use of other security mechanisms. SPNEGO itself does not define or provide authentication or data protection, although it can allow negotiators to determine if the negotiation has been subverted, once a mechanism is established. An authentication process in a client/server relationship where the user, or client, can enter one name and password and have access to more than one application or access to a number of resources within an enterprise. Single sign-on removes the need for the user to enter further authentications when switching between applications.

72 60 VSJ (WebSphere Edition) 3.2 Deployment Guide

73 Index A access policy files, 50 Active Directory about, 4 7 groups, 5 logon process, 6 scopes, 5 types, 5 installation, 15 LDAP integration, 4 permissions, 44 Public Key Infrastructure (PKI) support, 4 sites, 6, 27 smartcard support, 4 VSJ, 7 Windows native credential cache, 4 Apache Tomcat, 2 application server Apache Tomcat, 2 BEA WebLogic, 2 IBM WebSphere, 2 Oracle, 2 application servers, supported, 2 audit logging, 35 authentication, 8 9, 42 44, 48, 57, 57 adding to Web application, 34 basic, 9, 16, 43, 54 Kerberos, 43 NTLM, 55 B PKI, 4 smartcard, 4 SPNEGO, 9 user, 17 Windows-integrated, 15 16, 26 27, 43, 48, 53, basic fallback, 9, 16, 42 44, 46, 48 BEA WebLogic, 2 C client machine, 15 browser, 16 client operating system, 15 cookies, 42 credential cache, native Microsoft Windows, 4 D Denial of Service attack, 42, 46 deployment descriptor, 52, 54 deployment risks, replication interruptions, 17 resource security, 17 service unavailability, 16 time sychronization, 16 Domain Name Service (DNS), G groups, Active Directory, 5 61

74 62 VSJ (WebSphereEdition) 3.2 Deployment Guide I IBM WebSphere, 2, 15 configuring, 22 TAI framework, 8 using with VSJ, 2 VSJ parameters, 23 Web-based console, using, 2 installation Active Directory, 15 client machine, 15 VSJ components, 19 VSJ examples, 16 Internet Explorer and SPNEGO, 8 J jkinit, 38 jklist, 38 JKTools, 38 examples, 39 jkinit, 38 jklist, 38 jktutil, 38 K Kerberos, 2, 4 authentication, 2 4, 43 LDAP integration, 4 MIT, 2 4, 58 Privilege Attribute Certificates (PAC), 4 keytab, L LDAP, vii, 4, 6, 47, Active Directory integration, 4 Kerberos integration, 4 logging, 35, 50 M maintenance, access policy changes, 50 account settings, 50 logging, 50 network policy changes, 51 new users/groups, 50 Microsoft Windows, 15 credential cache, native, 4 integrated authentication, 15 16, 26 27, 43, 48, 53, MIT Kerberos, 2 4, 58 N NTLM, 55 authentication, 55 O operating system, client, 15 Oracle, 2 P PAC, see Privilege Attribute Certificate (PAC) permissions, Active Directory, 44 PKI, see Public Key Infrastructure (PKI) Privilege Attribute Certificate (PAC), 4, 6, 47, 56 Public Key Infrastructure (PKI) Active Directory, support in, 4 R RC4, 56 S SASL, 47 sites, Active Directory, 6 smartcard Active Directory, support in, 4 SPNEGO, 9, 43 44, 53, 57, 59 and Internet Explorer, 8

75 Index 63 T TAI, IBM WebSphere interceptor, 8 Time synchronization service, 14 troubleshooting authentication, AuthFilter, 54 blank page, Internet Explorer 6, 53 ConfigException, 52, credential delegation, 57 CryptoException, 51 debug information, 58 DNS error, 53 error 401, 52 error 403, 52, 57 error 500, IIS delegation, 57 integrity check failure, 52 InvalidLicense, 55 keytab, 56 MIC-checking, 57 no keytab entry, 56 NTLM, 55 ProtocolException, 55 SecurityException, 53 Servlet Error, 51 ServletException, 54 Trust Association Interceptor. See also TAI. V VSJ about, 2 Active Directory, and, 7 applications servers, 2 deployment environment, deployment risks, examples, 16 how it works, 8 9 installation requirements, Java application servers, 2 maintenance, parameters for IBM WebSphere, 23 uninstalling, 31 upgrading, 31 W WebSphere, see IBM WebSphere Windows, see Microsoft Windows

76 64 VSJ (WebSphereEdition) 3.2 Deployment Guide