IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0

Front cover

Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0

Learn how to install and configure the major components

Plan an enterprise single sign-on deployment project

Read about best practices and troubleshooting

Axel Buecker Steve Lay Dirk Rahnenfuehrer Frank Sommer ibm.com/redbooks

International Technical Support Organization

Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0

June 2009

SG24-7350-01 Note: Before using this information and the product it supports, read the information in “Notices” on page ix.

Second Edition (June 2009)

This edition applies to Version 8.0 of IBM Tivoli Access Manager for Enterprise Single Sign-On

© Copyright International Business Machines Corporation 2007, 2009. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents

Notices ...... ix Trademarks ...... x

Preface ...... xi The team that wrote this book ...... xi Become a published author ...... xiii Comments welcome...... xiv

Part 1. Architecture and design ...... 1

Chapter 1. Business context ...... 3 1.1 The single sign-on paradigm ...... 4 1.2 Enterprise single sign-on today ...... 4 1.2.1 Solve the password security paradox ...... 5 1.2.2 Manage passwords in a security-rich fashion ...... 6 1.2.3 High performance ...... 6 1.2.4 Easy to deploy...... 6 1.2.5 Reduce help desk costs by empowering the user...... 6 1.2.6 Integrate with an enterprise identity management system ...... 7 1.2.7 Bring single sign-on to kiosk machines ...... 7 1.2.8 Audit and reporting ...... 8 1.3 Considerations for deployment ...... 8

Chapter 2. Single sign-on architecture and component design ...... 11 2.1 Overview ...... 12 2.2 Logical component architecture ...... 13 2.2.1 AccessAgent ...... 14 2.2.2 Terminal Server or Citrix Presentation Server AccessAgent ...... 32 2.2.3 IMS Server ...... 32 2.2.4 IMS database ...... 35 2.2.5 AccessAdmin ...... 35 2.2.6 AccessStudio ...... 37 2.2.7 Provisioning bridge ...... 38 2.3 Additional components ...... 40 2.4 Security requirements ...... 41 2.4.1 Securing Wallets ...... 42 2.4.2 Recovering Wallets ...... 43 2.4.3 Strengthening the protection of Wallets ...... 44 2.4.4 How the private desktop feature ensures security ...... 44

© Copyright IBM Corp. 2007, 2009. All rights reserved. iii 2.5 Physical component architecture ...... 46 2.5.1 AccessAgent ...... 46 2.5.2 IMS Server ...... 47 2.5.3 IMS database ...... 48 2.5.4 Organization directory ...... 49 2.5.5 Initial deployment scenario ...... 51 2.5.6 IBM Tivoli Identity Manager integration...... 52 2.5.7 Server deployment architectures ...... 54 2.6 Conclusion...... 58

Chapter 3. Planning for customer engagement ...... 59 3.1 Services engagement preparation ...... 60 3.1.1 Implementation skills...... 60 3.1.2 Available resources...... 61 3.2 Basic solution definition...... 62 3.3 Services engagement overview ...... 63 3.3.1 Executive assessment ...... 64 3.3.2 Demonstration system set up ...... 65 3.3.3 Analyze solution tasks...... 65 3.3.4 Create a contract...... 66 3.4 Defining solution tasks ...... 67 3.4.1 Deployment time estimation ...... 68 3.4.2 General assumptions ...... 68 3.4.3 Deployment tasks ...... 69 3.5 Conclusion...... 70

Part 2. Customer environment...... 71

Chapter 4. Tivoli Austin Airlines, Inc...... 73 4.1 Company profile ...... 74 4.1.1 Geographic distribution of TAA ...... 74 4.1.2 Organization of TAA ...... 78 4.1.3 HR and personnel procedures ...... 79 4.2 Current IT architecture ...... 80 4.2.1 Overview of the TAA network ...... 80 4.2.2 TAA’s e-business initiative ...... 84 4.2.3 Security infrastructure for the e-business initiative ...... 84 4.2.4 Secured e-business initiative architecture...... 86 4.2.5 User account management and emerging issues...... 86 4.3 Corporate business vision and objectives ...... 88 4.4 Project layout and implementation phases ...... 89 4.5 Conclusion...... 90

iv Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Chapter 5. Enterprise single sign-on solution design ...... 91 5.1 Business requirements ...... 92 5.2 Functional requirements ...... 93 5.3 Design approach ...... 96 5.4 Implementation overview...... 97 5.4.1 About project phases and deployment stages ...... 97 5.4.2 Project phases ...... 98 5.5 Conclusion...... 99

Chapter 6. Base installation and configuration ...... 101 6.1 Design considerations ...... 102 6.1.1 System requirements ...... 103 6.1.2 Deployment architecture ...... 103 6.2 Installing and configuring base components ...... 105 6.2.1 Create administrative users ...... 105 6.2.2 Install the database software ...... 106 6.2.3 Create the IMS database ...... 120 6.2.4 Install the IMS Server ...... 126 6.2.5 Initial IMS Server configuration ...... 131 6.2.6 Install the AccessAgent...... 135 6.2.7 Interacting with AccessAgent ...... 139 6.2.8 Install AccessStudio ...... 144 6.3 AccessProfile configuration ...... 144 6.3.1 E-mail application ...... 145 6.3.2 Web application...... 155 6.3.3 Mainframe application ...... 180 6.4 Managing the deployed environment ...... 180 6.4.1 Managing policies ...... 180 6.4.2 User management...... 181 6.4.3 Backing up the database...... 182 6.4.4 Logging ...... 182 6.5 Conclusion...... 183

Chapter 7. Password self-services implementation...... 185 7.1 TAA business requirements ...... 186 7.2 Password self-service architecture ...... 186 7.3 Password self-service implementation ...... 187 7.3.1 Set up the self-service questions ...... 187 7.3.2 Enable the password self-service function ...... 192 7.3.3 User enrollment interview ...... 197 7.3.4 Execute a password reset...... 201 7.4 Conclusion...... 215

Contents v Chapter 8. Shared desktop implementation ...... 217 8.1 TAA business requirements ...... 218 8.2 Overview of the shared desktop features ...... 219 8.2.1 Distinction between users ...... 219 8.3 Windows configuration steps...... 220 8.4 AccessAdmin configuration steps ...... 221 8.5 Conclusion...... 228

Chapter 9. Tivoli Identity Manager implementation ...... 229 9.1 TAA business requirements ...... 230 9.2 Implementation overview...... 230 9.2.1 What does the adapter do...... 231 9.2.2 Technical environment details...... 232 9.3 Install and configure the adapter ...... 241 9.3.1 Update the RMI Dispatcher...... 241 9.3.2 Install the TAM E-SSO connector ...... 245 9.3.3 Install the SQL Server JDBC driver...... 245 9.3.4 Install the adapter profile in Identity Manager ...... 248 9.3.5 Configure the IMS Server ...... 254 9.3.6 Configure SSL between RMI Dispatcher and IMS Server ...... 259 9.3.7 Create the TAM E-SSO Service in Tivoli Identity Manager...... 266 9.3.8 Verify the configuration ...... 272 9.4 Configure the workflow extensions ...... 283 9.4.1 Add workflow extension to Identity Manager...... 284 9.4.2 Define workflow for Service Add Account operations ...... 289 9.4.3 Define workflow for Change Password Operation ...... 297 9.4.4 Define workflow for Delete Account Operation ...... 303 9.4.5 Define workflow for preventing multiple accounts (IMS) ...... 307 9.4.6 Modify workflow to disable Change Password Operation ...... 317 9.5 Test the provisioning operations ...... 323 9.5.1 Create authorization service for Self-Service Console ...... 323 9.5.2 Modify the TAM E-SSO Service ...... 339 9.5.3 Service prerequisites for provisioning accounts ...... 353 9.5.4 Create a new Identity Manager user and required accounts . . . . . 364 9.5.5 Test single sign-on to the Identity Manager Self-Service ...... 384

Chapter 10. Strong authentication...... 391 10.1 Meeting TAA business requirements ...... 392 10.2 Using a USB key for strong authentication ...... 392 10.2.1 Design considerations...... 393 10.2.2 Installing USB key software ...... 394 10.2.3 Configuring a self-service registration policy...... 407 10.2.4 Setting up an AccessAgent machine policy ...... 412

vi Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 10.2.5 Assigning an AccessAgent machine policy...... 416 10.2.6 Initializing a USB key ...... 419 10.2.7 USB key enrollment process...... 421 10.3 Conclusion...... 429

Part 3. Appendixes ...... 431

Appendix A. Troubleshooting ...... 433 AccessAgent issues ...... 434 AccessAgent logs ...... 434 AccessAgent log level ...... 434 AccessAgent cryptoboxes...... 434 Machine Wallet download problem ...... 435 Synchronization with IMS Server ...... 436 Logon user interface failed to load ...... 436 AccessAgent does not display the correct domain ...... 437 Cannot return to EnGINA from Windows GINA ...... 437 Web automatic sign-on fails on Internet Explorer settings ...... 437 Automatic sign-on does not work properly for Windows applications . . . . 438 Automatic sign-on does not work properly for Microsoft GINA ...... 438 Modification to Winlogon AccessProfile does not take effect ...... 439 Application does not work properly after AccessAgent is installed ...... 439 Cannot log on to Wallet after AccessAgent is installed...... 439 Cannot log on to cached Wallets ...... 440 Downloading the IMS Server certificate ...... 440 Unable to connect to the IMS Server ...... 440 Spontaneous termination of sync.exe ...... 441 IMS Server issues ...... 442 IMS Server logs...... 442 IMS Configuration Utility cannot be accessed...... 442 IMS Server cannot issue certificate for an application ...... 442 IMS Server diagnostic information ...... 443 IMS Server console startup...... 443 IMS Server database housekeeping problems ...... 443 Installation issues ...... 444 Anti-virus software can interfere with AccessAgent or IMS Server ...... 444 MSDE installation problem ...... 445 IMS Server installation problem as a result of database configuration . . . 445 Failure to connect to named instance of SQL Server 2000 database. . . . 446 RFID reader RDR-7172AKU problem ...... 446 AccessAgent displays incorrect icons after an installation upgrade . . . . . 447 AccessAgent fails to install ...... 447 Issues concerning Microsoft Operations Manager ...... 447

Contents vii Other issues ...... 448 AccessStudio logs...... 448 Unable to log on to AccessAdmin ...... 448 SOCIAccess.exe failure caused by RFID readers ...... 449 Application is slower when automatic sign-on is enabled...... 449 Missing labels in state engine view of AccessStudio ...... 449 Back button does not always work correctly ...... 450 GINA conflict with ThinkPad fingerprint software ...... 450 Performance data is not available in MOM reports ...... 450 Security logs are full ...... 450 Documenting a PMR ...... 451 Documentation of AccessAgent errors ...... 451 Documentation of IMS Server errors...... 452

Appendix B. Advanced profiling ...... 453 Introduction...... 454 Use case: Configure a trigger to match properties...... 454 Use case: Start a program from the command line ...... 463 Use case: Create a host emulator ...... 472 Define the requirements ...... 473 Understand user interaction with the application ...... 475 Create the advanced profile ...... 475

Appendix C. Statement of work ...... 523 Environment analysis service...... 524 Executive summary...... 524 Solution description...... 524 Assumptions ...... 524 IBM Business Partner responsibilities...... 525 Customer responsibilities ...... 525 Staffing estimates ...... 525 Project schedule and milestones ...... 526 Testing methodology...... 526 Deliverables ...... 526 Completion criteria ...... 526

Related publications ...... 527 IBM Redbooks ...... 527 Other publications ...... 527 Online resources ...... 528 How to get Redbooks ...... 529 Help from IBM ...... 529

Index ...... 531

viii Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Notices

This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. These and other IBM trademarked terms are marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:

AS/400® Notes® Solid® DB2® OS/390® System i® IBM® PartnerWorld® Tivoli® Lotus Notes® Redbooks® WebSphere® Lotus® Redbooks (logo) ®

The following terms are trademarks of other companies: Acrobat, and Portable Document Format (PDF) are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, other countries, or both. Novell, the Novell logo, and the N logo are registered trademarks of Novell, Inc. in the United States and other countries. Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation and/or its affiliates. Java, JavaScript, JDBC, JMX, JVM, Sun, Sun Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Active Directory, Excel, Internet Explorer, Microsoft, Outlook, SQL Server, Visual Basic, Visual Studio, Win32, Windows Server, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.

x Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Preface

Everyone feels the pain of too many passwords to remember, and everyone can relate to the security exposure of weak passwords, chosen for convenience or passwords placed in proximity to the workstation for a quick reminder that, unfortunately, can allow more than the intended user into the system and network. The average user today often has four or more passwords, and security policies that focus on password complexity and password-change frequency can cause even more difficulty for users.

This IBM® Redbooks® publication introduces IBM Tivoli® Access Manager for Enterprise Single Sign-On 8.0, which provides single sign-on to many applications, without a lengthy and complex implementation effort. Whether you are deploying strong authentication, implementing an enterprise-wide identity management initiative, or simply focusing on the sign-on challenges of a specific group of users, this solution can deliver the efficiencies and security that come with a well-crafted and comprehensive single sign-on solution.

This book is a valuable resource for security officers, administrators, and architects who want to understand and implement an identity management solution in a medium scale environment.

The team that wrote this book

This book was produced by a team of specialists from around the world working at the International Technical Support Organization (ITSO), Austin Center.

Axel Buecker is a Certified Consulting Software IT Specialist at the ITSO, Austin Center. He writes extensively and teaches IBM classes worldwide in Software Security Architecture and Network Computing Technologies. He holds a degree in Computer Science from the University of Bremen, Germany. He has 22 years of experience in a variety of areas related to Workstation and Systems Management, Network Computing, and E-business Solutions. Before joining the ITSO in March 2000, Axel worked for IBM in Germany as a Senior IT Specialist in Software Security Architecture.

© Copyright IBM Corp. 2007, 2009. All rights reserved. xi Steve Lay is a Support Engineer with the Global Response Team, based in Austin, TX. For over 3 years, he has supported IBM Tivoli Security products at customer locations across the Americas. He attended the University of Texas at Austin, and joined IBM in 2000. He frequently performs and documents customer assessments and resolves critical situations in the Tivoli Security space.

Dirk Rahnenfuehrer is a Systems Management Specialist at IBM. He has 9 years of experience in the IT industry and holds a degree in Physics from RWTH Aachen University. He has worked at IBM for 7 years. His areas of expertise include Systems Management and Security products, focusing on identity management since 2003 and single sign-on since 2005.

Frank Sommer is an IT Security Specialist at IBM Tivoli. He has 13 years of experience in IT security. Working as a Technical Sales Consultant, his areas of expertise include, amongst others, e-business security, systems management, and project management. His special area of interest is the design of integrated security architectures. A resident of Rhein-Main area, Germany, Frank Sommer holds a degree in Electrotechnics from Niederrhein University of Applied Science, Krefeld, Germany. He was a co-author of the IBM Redbooks publication Enterprise Business Portals with Tivoli Access Manager, SG24-6885.

The team (left to right): Steve, Dirk, Frank, and Axel

xii Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Thanks to the following people for their contributions to this project:

Diane Sherman International Technical Support Organization, Austin Center

Rob Alfieri, Chiang Kai Er, Sharad Ganesh, Greg Gaskill, Brian Goldsmith, Eng Kiat Koh, Grey Thrasher, Peter Wolf IBM

Roxana Sapoiu, Dr. Holger Wilken Charismathics GmbH 47 Sendlinger St Munich, Germany 80331

Thanks to the authors of the previous edition of this book, Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On, published in March 2007:

Jose Fermaintt and Norman Field

Become a published author

Join us for a two- to six-week residency program! Help write a book dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You will have the opportunity to team with IBM technical professionals, Business Partners, and Clients.

Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you will develop a network of contacts in IBM development labs, and increase your productivity and marketability.

Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.html

Preface xiii Comments welcome

Your comments are important to us!

We want our books to be as helpful as possible. Send us your comments about this book or other IBM Redbooks in one of the following ways: Use the online Contact us review Redbooks form found at: ibm.com/redbooks Send your comments in an e-mail to: [email protected] Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400

xiv Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Part 1

Part 1 Architecture and design

In this part, we discuss the business context of the IBM Tivoli Access Manager for Enterprise Single Sign-On (TAM E-SSO). We then describe how to technically architect the overall solution into an existing environment and introduce the logical and physical components.

Chapter 1. Business context

In this chapter, we discuss the business context for Tivoli Access Manager for Enterprise Single Sign-On (TAM E-SSO). After a short description of the single sign-on paradigm, we describe the factors that influence why and how Tivoli Access Manager for Enterprise Single Sign-On can be implemented in a given business context. Finally, we explain the challenges that you can expect to encounter when deploying a single sign-on solution in a large enterprise.

It is easy to become confused when trying to relate the variations of single sign-on that exist today. Web single sign-on, federated single sign-on, and desktop single sign-on all represent different types of secure single sign-on. They each resolve a separate but related security risk and likewise provide a separate but related return on investment. The overlapping relationships can blur the line between their functions and benefits.

Web single sign-on provides single sign-on between a Web security server, like Tivoli Access Manager for e-business WebSEAL component, and back-end Web applications. Web single sign-on eliminates the need to log in twice when a client attempts to access a Web resource on a server that requires authentication from its own user registry. Federated single sign-on provides single sign-on between trusted Web applications using separate user registries, often between an organization and its business partner.

The definition of desktop single sign-on relevant to this document is also called enterprise single sign-on. Enterprise single sign-on allows for a seamless, transparent single sign-on experience to much more than just Web applications. Also included are arbitrary fat client applications such as e-mail clients, Java™ applications, host and mainframe applications, custom business applications, and more.

From the user perspective, Tivoli Access Manager for Enterprise Single Sign-On is an application that runs on their Windows® desktop. Users only have to remember a single password in order to log on to any protected application on the desktop. Tivoli Access Manager for Enterprise Single Sign-On securely stores the login information for each application and replies automatically to any credential challenges. It also provides centralized policy management and backup of user credentials.

Combining Tivoli Access Manager for Enterprise Single Sign-On and Tivoli Access Manager for e-business with a comprehensive identity management strategy allows companies to greatly reduce maintenance costs and security risks.

1.2 Enterprise single sign-on today

The number of logins that employees must manage on a daily basis continue to be sources of frustration and lost productivity. Employees must remember login information for numerous applications, many of which often require different user names and passwords, different password strength requirements, and constant

4 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 forced password changes. The number of logins an employee must manage grows with the deployment of each additional business application. The corporate help desk often bears the brunt of restoring an employee’s lost or forgotten login information. These factors together contribute to security risks that few companies can afford not to address.

So how can Tivoli Access Manager for Enterprise Single Sign-On benefit your organization? In this section, we discuss how Tivoli Access Manager for Enterprise Single Sign-On addresses these serious security risks in a centrally managed solution.

1.2.1 Solve the password security paradox

A frequent user complaint is the requirement to remember multiple passwords, and a major security weakness in computer security is weak password selection. Security breaches as a result of weak passwords or insecure management of passwords are very common. Allowing weak passwords can create security threats such as hackers being able to easily guess passwords or using brute force scripts to gain access to passwords. Forcing users to remember several complex strong passwords can also create security threats such as users writing down their passwords on a sticky note or saving them in a text file because they have so many passwords that frequently change and are not easily remembered. The paradox is clear. You must enforce strong passwords to eliminate threats created by weak passwords, but you must also provide a mechanism so users do not have to manage multiple complex passwords.

Tivoli Access Manager for Enterprise Single Sign-On can help you solve this paradox. Users must remember only one password and they no longer have to deal with strong passwords for all corporate applications. They authenticate once, and Tivoli Access Manager for Enterprise Single Sign-On does the rest.

In most cases this solution is implemented without having to modify any of the business applications including their password requirements. Additionally, Tivoli Access Manager for Enterprise Single Sign-On allows for increased security through second-factor authentication mechanisms such as fingerprint readers, RFID badges, SMS messaging, building badge, and USB1 smart cards.

It detects and responds to all password-related events to automate every password management task for the user, including login, password selection, password change, and password reset. Tivoli Access Manager for Enterprise Single Sign-On delivers single sign-on for Windows, Web, Java, UNIX®, command line, in-house developed, host-based mainframe applications, and custom business applications.

1 Radio Frequency Identification (RFID, Short Message Service (SMS), Universal Serial Bus (USB)

Chapter 1. Business context 5 1.2.2 Manage passwords in a security-rich fashion

Tivoli Access Manager for Enterprise Single Sign-On secures passwords and related data wherever they are located: in your directory, in transit from the directory to the client, in the client local disk cache, and in client memory. It uses the strongest cryptography currently available, including AES and Triple DES.

Tivoli Access Manager for Enterprise Single Sign-On also offers second-factor authentication to further increase security as mentioned previously. It allows for mixing and matching different factors depending on the user or machine. This means that if these factors are already in place, they can be leveraged by Tivoli Access Manager for Enterprise Single Sign-On.

1.2.3 High performance

In all private, shared, and roaming desktop environments2, Tivoli Access Manager for Enterprise Single Sign-On can deliver uncompromising speed while consuming minimal resources when providing a single sign-on experience for end-users to their applications. With its event-specific resource use, the impact of Tivoli Access Manager for Enterprise Single Sign-On on both the client and the network is minimal. No additional hardware or software is required.

1.2.4 Easy to deploy

Implementing and managing Tivoli Access Manager for Enterprise Single Sign-On is made effective with a Web-based administrative console, superior directory integration, and easily deployable client-side software. All administrative functions are performed from a centralized Web administrative console (AccessAdmin), and point and click wizards in the AccessStudio application walk an administrator through the tasks of profile configuration. An administrator can access the AccessAdmin console from anywhere a Web browser is able to connect to the server. Tivoli Access Manager for Enterprise Single Sign-On utilizes a pre-existing user repository without the need to modify the directory schema or any other aspect of the user repository.

1.2.5 Reduce help desk costs by empowering the user

The Tivoli Access Manager for Enterprise Single Sign-On password reset functionality can eliminate or reduce the costs associated with forgotten passwords and account lockouts. Forgotten passwords and account lockouts, as

2 More information about private, shared, and roaming desktop environments can be found in “Session management” on page 30.

6 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 a result of too many failed attempts can burden the company help desk. Tivoli Access Manager for Enterprise Single Sign-On provides configurable functions to allow users to perform password self-service in ways that meet a variety of security requirements.

How users interact with password changes, resets, and account lock-out and unlock functions can be customized and allowed or disallowed based on configurable policies. Tivoli Access Manager for Enterprise Single Sign-On grants companies the flexibility to decide whether these password and account service functions stay with the help desk, the user, or any combination of the two.

The password reset function enables you to reset your Tivoli Access Manager for Enterprise Single Sign-On password in order to regain access to your desktop environment; it does not reset any application-specific passwords.

1.2.6 Integrate with an enterprise identity management system

The Tivoli Access Manager for Enterprise Single Sign-On Provisioning Bridge extends the benefits generated by Tivoli Access Manager for Enterprise Single Sign-On through the automation of the credential distribution process. The Tivoli Access Manager for Enterprise Single Sign-On Provisioning Bridge uses its API libraries to allow identity management software to automatically provision Tivoli Access Manager for Enterprise Single Sign-On user credentials. This way, users never have to know their user name or password for their applications because it can be managed transparently to them.

If users need to know their user name and password for a particular application, they are able to obtain that information by accessing the credential store (Wallet). This is possible only if they are authenticated to Tivoli Access Manager for Enterprise Single Sign-On. If they are not working at a workstation with an AccessAgent they can access that information by using the AccessAssistant Web browser based interface. Even if not integrated with identity management software, Tivoli Access Manager for Enterprise Single Sign-On allows for a highly available and secure password-reveal process through these components.

1.2.7 Bring single sign-on to kiosk machines

The convenience of allowing others to share a workstation unfortunately does not come without risks. Too often users walk away from a kiosk3 machine without logging off, potentially exposing sensitive data. Tivoli Access Manager for Enterprise Single Sign-On addresses this threat by providing the ability to

3 Kiosk machines are also referred to as shared or roaming desktops. More information about shared and roaming desktop environments can be found in “Session management” on page 30.

Chapter 1. Business context 7 automate termination of inactive sessions and application shutdown. That automation even includes features such as automatic walk away logouts through RFID proximity keys, or USB smart card removal.

Tivoli Access Manager for Enterprise Single Sign-On provides robust session management support for roaming desktop implementations such as Windows Terminal Services and Citrix MetaFrame, and shared desktops or kiosk machines as well as private desktops. This allows users to roam easily and securely from one workstation to another. Additionally Tivoli Access Manager for Enterprise Single Sign-On includes thin client and client-less access through roaming desktop mode and through Web Workplace.

1.2.8 Audit and reporting

Tivoli Access Manager for Enterprise Single Sign-On includes built in auditing and reporting. It can record audits events including user log in and log out of applications. The audit mechanism can be customized to capture other relevant information. The product ships with several included reports, but custom reports are easily generated because all audit data resides in single database.

1.3 Considerations for deployment

Although Tivoli Access Manager for Enterprise Single Sign-On provides user-friendly tools for deploying and managing the product, there are a number of factors to consider before embarking on the deployment. As with any deployment, a planning document should be written that outlines the scope, the phases, and the time line of the deployment. At a minimum, the planning document should include the following factors: Deployment approach Because Tivoli Access Manager for Enterprise Single Sign-On involves deploying software to user workstations, the deployment should be carefully planned to avoid adversely impacting users. Rollout to the enterprise should be taken in phases, starting by using Tivoli Access Manager for Enterprise Single Sign-On to secure the common desktop applications and then gradually adding new capabilities, such as other custom applications. Distribution of the software to the desktops Tivoli Access Manager for Enterprise Single Sign-On is a Windows-based application referred to as the AccessAgent. The AccessAgent communicates with the IMS Server4 to synchronize data changes with the server. However, the AccessAgent can cache data locally (on disk) based on policy. As such, it

8 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 is able to perform most of its functions even if it is not connected to the IMS at any point in time. Another aspect to consider is user education. After the AccessAgent has been distributed to the desktop the user is initially prompted to sign up for use of Tivoli Access Manager for Enterprise Single Sign-On. This can be a forced action, but it can be configured so the user has the choice to sign up. The uninformed user might be confused about how to make the decision. Sometimes, users also have to interact with the client software if they want Tivoli Access Manager for Enterprise Single Sign-On to manage their password for a new application. A good practice is to announce upcoming deployments well in advance and to offer a simplified step-by-step help guide to support users through the sign-up process. Corporate security policies Some configuration parameters in Tivoli Access Manager for Enterprise Single Sign-On will likely be governed by corporate security policies. The administrative configuration console (AccessAdmin) provides flexible configuration of security policies for users, machines, application, and authentication mechanisms. You should work closely with security officers to ensure the policy is correctly represented in the solution. Password reset strategy The ability for users to reset their own password on their own desktop machine is a powerful tool for the enterprise. However, care must be taken when formulating the series of questions users must answer in order to reset their password. Issues of privacy and cultural sensitivity should be taken into account. You should review your security questions with your legal department before going forward with your deployment to ensure the questions are in compliance with local privacy laws.

In the following chapter we explain the overall architecture of Tivoli Access Manager for Enterprise Single Sign-On including the logical and physical components.

4 The Tivoli Access Manager for Enterprise Single Sign-On Integrated Management System (IMS) is one of the central components of the overall solution. More information can be found in Chapter 2, “Single sign-on architecture and component design” on page 11.

Chapter 1. Business context 9 10 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 2

Chapter 2. Single sign-on architecture and component design

In this chapter we discuss the logical and physical architecture of Tivoli Access Manager for Enterprise Single Sign-On (TAM E-SSO) and its most fundamental components. First, we give a general overview of the product. Next, we introduce the logical components within Tivoli Access Manager for Enterprise Single Sign-On and how they relate to each other. In the physical architecture section, we finally describe how to deploy the components that make up Tivoli Access Manager for Enterprise Single Sign-On.

Tivoli Access Manager for Enterprise Single Sign-On provides its single sign-on functionality by introducing a layer that authenticates a user once and then automatically detects and handles subsequent requests for user credentials. Figure 2-1 depicts an overview of the solution.

Figure 2-1 Product overview

Tivoli Access Manager for Single Sign-On can be divided into the following four functions: Authentication factors Tivoli Access Manager for Enterprise Single Sign-On supports various authentication factors to authenticate the user. Besides the standard user name/password based authentication, the user can be authenticated by means of a proximity or building badge like active or passive RFID, a fingerprint, a one-time password provided by SMS or OTP1 token, or a USB token. AccessAgent The AccessAgent runs on every Windows desktop endpoint, Microsoft® Windows Server® Terminal Services session, and Citrix MetaFrame

1 OTP stands for one-time password.

12 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Presentation Server session. The AccessAgent is responsible for authenticating the user2. It can automate single sign-on into Windows and to the set of applications that are defined in AccessProfiles. The AccessAgent can extend the Windows Graphical Identification and Authentication (GINA) DLL chain to provide additional functions for self-service or strong authentication. Identity wallet The identity wallet (or Wallet) holds the user credentials that are required for single sign-on. It is loaded from the IMS Server into the AccessAgent after successful authentication of the user so that it is available even when the endpoint is disconnected from the computer network. To protect the credentials against tampering or stealing, the identity wallet is encrypted with a strong encryption mechanism. IMS Server The Integrated Management System Server (IMS Server) is the central repository for user data, AccessProfiles, identity wallets, and machine profiles. The IMS Server provides a Web based interface to administrate users and policies.

2.2 Logical component architecture

In this section we introduce a logical component model of the product and discuss every important component.

The logical component model illustrates the software components that are being used to build a system. Tivoli Access Manager for Enterprise Single Sign-On consists of the following logical components: AccessAgent Terminal Server or Citrix MetaFrame AccessAgent IMS Server IMS Database AccessAdmin AccessStudio Provisioning Bridge

2 At this time, AccessAgent does not support an SMS or OTP token as second-factor authentication; it is supported for Web Assistant and Web Workplace only.

Chapter 2. Single sign-on architecture and component design 13 In the following sections, we discuss every logical component in more detail. Figure 2-2 depicts the overall logical component architecture.

Figure 2-2 Logical component architecture

2.2.1 AccessAgent

The AccessAgent is the client software that is installed onto all Windows workstations and Terminal Servers or Citrix MetaFrame and configured to connect to the designated IMS Server. Figure 2-3 on page 15 depicts the architecture of the AccessAgent.

14 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 2-3 AccessAgent architecture

Let us take a closer look at the following AccessAgent’s function blocks: Authentication Data synchronization Wallet manager GUI Self-service GUI AccessAgent Observer module Workflow session management

Chapter 2. Single sign-on architecture and component design 15 Authentication Authentication defines how the system validates users so they gain access to Tivoli Access Manager for Enterprise Single Sign-On, for example, using a password, biometrics, token, and so on.

Tivoli Access Manager for Enterprise Single-Sign-On supports the concept of a separation of the authentication of the user itself and the authentication against the Windows desktop. Let us describe what this means.

Introduction to desktop authentication and single sign-on Tivoli Access Manager for Enterprise Single Sign-On maintains its own user repository and performs user authentication using various forms of authentication credentials stored in this repository. First, the user has to be successfully authenticated using Tivoli Access Manager for Enterprise Single Sign-On. Next, Tivoli Access Manager for Enterprise Single Sign-On is responsible for authenticating the user against the Windows desktop based on the user’s Windows password. This means that the authentication against the Windows desktop can already be considered as a single sign-on from the Tivoli Access Manager for Enterprise Single Sign-On client to the user’s Windows desktop. The authentication method used for Tivoli Access Manager for Enterprise Single Sign-On can be a typical user name and password credential, but it can also be an RFID or USB token, for example, that is usually not supported by a standard Windows installation.

The authentication component, depicted in Figure 2-3 on page 15, consists of two layers: Authentication factors Authentication Device Manager

Authentication to Tivoli Access Manager for Enterprise Single Sign-On involves two steps: 1. The user provides credentials with the authentication factors. 2. The authenticator, for example a smart card or RFID reader, validates the user with the Authentication Device Manager.

Authentication factors Authentication factors come in different forms and functions. With the exception of password and fingerprint, users can access systems and applications with a device that works like a key.

16 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Let us first look at the basic factors: Password The password is used to secure access to a Wallet. The user specifies this password upon signing up with the Tivoli Access Manager for Enterprise Single Sign-On AccessAgent. Signing up with the AccessAgent means registering the user with the IMS Server and creating a Wallet. Secret The user is asked to enter a secret when signing up for a Wallet. A secret is like a second password or a backup password. The secret should be something that the user will not forget, even if it is not used for a long time and it is not likely to change. When the user signs up, the user selects a question from a list, and then provides the answer to that question. See Figure 2-4 for an example of providing a secret.

Figure 2-4 User enrollment secret question and answer

If a user forgets a password, the secret enables them to set a new password. The user can also use the secret, along with an authorization code, to gain temporary access to the Wallet. An authorization code is generated by a help desk employee or an administrator. If self-service is enabled, users might have to specify a number of challenge-and-response questions during sign-up. Users can provide a subset of these challenge-and-response questions to perform password resets without using an authorization code.

Chapter 2. Single sign-on architecture and component design 17 Second authentication factors The password can be fortified by a second authentication factor. The combination of the password and a building badge or USB key, for example, strengthens the user’s computer security because both authentication factors must be presented to access the computer. Based on the organization’s security policy, using one of the following second authentication factors can be either mandatory or optional: Mobile ActiveCode The ActiveCodes are short-term authentication codes that are controlled by the Tivoli Access Manager for Enterprise Single Sign-On system. The Mobile ActiveCode is a randomly-generated and event-based one-time password. The Mobile ActiveCode is generated on the IMS Server and delivered through a secure second channel, such as text services (SMS) on mobile phones or e-mail. It is used to provide second-factor authentication in lieu of using key fob security devices. RFID card The RFID card contains authentication information that can be retrieved through the use of an Radio Frequency Identification (RFID) reader. RFID works on the concept of proximity; the user taps the RFID card on the RFID reader to gain access to credentials. The RFID reader is an additional piece of hardware that has to be installed on every machine where the RFID card is used for authentication. Unlike the USB Proximity key, the RFID card does not have any storage capacity. An RFID card also allows for unified access. It can be used to access the computer, and for physical security (to access doors, elevators, and so on). Most companies today already use RFID cards for building and garage access. Now, the cards can also be used to authenticate users to the workstation. Active proximity badge The active proximity badge works almost identically as the regular RFID card, except that it contains a battery to enable the card to actively transmit security information to the associated reader. The active proximity badge can work over a greater range because of the active radio transmitter it contains. With the regular RFID card, the card has to be in very close proximity with the reader. With the active proximity badge, the distance can be specified. For example, the active proximity badge can be two meters away from the reader, yet it is recognized. The reader automatically detects the user’s presence. For example, when the user leaves the workstation, the AccessAgent locks the window, or logs the user off, depending on the policy setting.

18 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Fingerprint identification The fingerprint identification system recognizes a fingerprint as an authentication factor. The fingerprint reader translates the fingerprint into encrypted codes, which in turn logs the user on to the AccessAgent. USB key The USB key is a removable USB drive that combines the utility and storage capacity of Flash-RAM, the security of a smart card, and the universal connectivity of a Universal Serial Bus (USB) into one device. The USB key can store user names, passwords, certificates, encryption keys, and other security credentials. The USB form factor is cost-effective. No additional hardware is required for the key to work. Internally, the USB key stores the following information: – Serial number The serial number is a unique number embedded in the USB key during manufacturing. It is also printed on the casing of the USB key. The number is unique for each USB key and cannot be changed. – Common symmetric key The common symmetric key (CSK) is used to encrypt information that is communicated to the IMS Server for backup. Each user has a different and unique CSK. – Identity wallet If a USB key is used for authenticating the user, the identity wallet can be stored on the USB key. – USB key software and drivers The computer cannot communicate with a USB key until the required driver is installed. The required drivers can be found in the USB key, and are detected and installed automatically. The files required for installing the AccessAgent on the computer can also be installed from the USB key. USB proximity key A USB key can be equipped with RFID technology (Radio Frequency Identification), an electronic device that uses radio frequency signals to read identification information stored within. The USB key with RFID integration is called a USB proximity key. The USB proximity key requires a proximity reader to work. The proximity reader can be installed with the AccessAgent. For example, the office front door or elevator of an organization can have a proximity reader so that access is restricted to those with an RFID built into their USB key.

Chapter 2. Single sign-on architecture and component design 19 Table 2-1 lists examples of a use-case scenario and a particular target group for each authentication factor.

Table 2-1 Authentication factor scenario examples Authentication factor Use case scenario Targeted user group

Building access badge Users tap their building This solution is best suited access badge on the reader for business users working and enter a password to log within corporate premises. in to Tivoli Access Manager for Enterprise Single Sign-On and gain access to the network or applications.

Active RFID Users are identified as they This solution is best suited approach the workstation. for staff requiring fast They simply enter a logons and logouts. password to log on. Unlike building access badges, users do not have to tap their badges on the readers to identify themselves. This solution is more convenient, but also has a higher total cost of ownership.

Mobile device Users receive a Mobile This solution is best suited ActiveCode on their for remote users who need SMS-enabled or a second factor to log on e-mail-enabled mobile remotely. device. Users use this code with their Tivoli Access This solution frees the Manager for Enterprise remote users from having to Single Sign-On user name carry additional devices and password to log on. while still maintaining access security. Mobile ActiveCode is also more cost efficient compared to traditional one-time password tokens.

20 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Authentication factor Use case scenario Targeted user group iTag Users leverage any This solution is an personal device or photo alternative to conventional badge with smart labels or token based two-factor sticker labels to enable authentication. two-factor authentication. With iTag, users do not incur the inconvenience of carrying a separate token for authentication. By leveraging what users already have for authentication, enterprises can minimize the cost and complexity of two factor authentication projects.

Biometrics Users use their fingerprints This solution is an to log on to Tivoli Access alternative to building Manager for Enterprise access badges or Active Single Sign-On. RFID badges for clinical staff.

This solution removes the need to enter a password. However, building access badges and Active RFID are technically more robust.

USB smart token Users insert a USB smart This solution is best suited token and enter a password for business users or mobile to log on to Tivoli Access computer users who require Manager for Enterprise a higher level of security Single Sign-On. protection.

One-time password Users carry an This solution is best suited tokens authentication token, which for remote users who is used to generate a require a second factor to one-time password. Users login remotely to corporate use this password with a pin networks. they remember to login to corporate networks.

Strong passwords Users enter a Tivoli Access This solution is suited for Manager for Enterprise any group whose risk Single Sign-On user name profiles does not warrant a and a strong password to second factor, or where a log on. second factor is not viable.

Chapter 2. Single sign-on architecture and component design 21 By supporting building access badges, iTag, and mobile devices for authentication, Tivoli Access Manager for Enterprise Single Sign-On is well equipped to leverage what you already have as a second-factor. For example, Tivoli Access Manager for Enterprise Single Sign-On enables the use of building access cards, such as the HID Prox, HID iClass, Mifare, and Indala cards, as second-factors for logical access. This approach reduces the cost of acquisition, the cost of provisioning, and also the cost of support. It provides greater user convenience, relieving users from having to carry additional devices. User adoption is high and training costs are minimized because existing personal devices are leveraged to secure access to corporate networks.

Tivoli Access Manager for Enterprise Single Sign-On also enables secure remote access by combining two-factor authentication with leading SSL-VPN platforms. With the solution, users can access Web, desktop, and host-based applications through an SSL-VPN connection and ensure two-factor authentication with one-time password (OTP) tokens or OTP delivered to smart phones, PDAs, e-mails, or other mobile devices.

Regardless of the choice of authentication factors, administrators may centrally manage all authentication policies through the AccessAdmin interface. In addition to multi-factor authentication, administrators may also enforce application password policies through Tivoli Access Manager for Enterprise Single Sign-On.

Refer to the Tivoli Access Manager for Enterprise Single Sign-On Administrator Guide Version 8.0, SC23-9951 regarding policy settings for authenticators.

Authentication Device Manager The Authentication Device Manager is used to integrate the authentication user interface with the main Tivoli Access Manager for Enterprise Single Sign-On AccessAgent. The Authentication Device Manager validates the credentials provided by the authenticator against a system authentication service, such as a Windows domain, Radius Server, LDAP repository, and so on. The Authentication Device Manager serves as a conduit between the authentication factors and the AccessAgent.

Data synchronization The data synchronization component synchronizes AccessProfiles, a user's identity wallet and various policy settings with the IMS Server and submits user's application access audit events to the IMS Server. The AccessAgent contacts the IMS Server upon start up, upon each user login, as well as on periodic intervals, to synchronize data changes with the server. However, the AccessAgent can cache data locally (on disk) based on a policy. As such, it is able to perform most of its functions even if it is disconnected from the IMS Server.

22 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Wallet Manager GUI The Wallet Manager GUI enables the user to manage the application credentials stored in the personal identity wallet. See Figure 2-5 for an example of the Wallet Manager GUI.

Figure 2-5 Wallet Manager GUI

Self-service GUI A GINA extension is used to implement the self-service user interface for the user to manage the desktop password and authentication factors.

AccessAgent Observer module The AccessAgent Observer module is one of the core elements of Tivoli Access Manager for Enterprise Single Sign-On. The module is hooked into various applications, and consults the appropriate AccessProfile (created using the AccessStudio application) to perform the necessary logon/logoff and automation actions. When an application presents a request for credentials the observer module is responsible for the appropriate action. The Observer module architecture is depicted in Figure 2-6 on page 24.

Chapter 2. Single sign-on architecture and component design 23 Figure 2-6 AccessAgent Observer module architecture

The AccessAgent Observer module is composed of a core module and a number of agent instances that are hooked (through Windows APIs) into every launched Windows application, for example, IBM Lotus® Notes® application, Microsoft Outlook®, Microsoft Internet Explorer®, and so on. The behavior of the AccessAgent Observer agents within each application is driven by a set of behavioral specifications called an AccessProfile. Each AccessProfile is an XML-structured file (based on a custom XML language) that provides a declarative set of pre-conditions. Figure 2-7 is a graphical view of the resulting state machine of an AccessProfile.

Figure 2-7 Workflow definition of a simple AccessProfile

24 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Each AccessProfile entails a set of definitions for the AccessAgent Observer agent module to watch for and execute accordingly: For Windows applications, the name of the executable A set of behavioral states, like pre-logon or post-logon States represent specific situations where the state machine must look for certain triggers to occur (similar to a flowchart). A state can have multiple triggers. For example, in the after_application_launched state, you can look for the login window to appear or for a change-password window to appear. One trigger can have multiple actions. When a login window appears, you can inject user credentials and press the OK button. A profile writer can define as many states in a state machine as required. The state definitions and with each state: – A set of workflow triggers (blue): when – Signatures that belong to a specific trigger: where – A set of workflow actions (red): what

The agent retrieves the required AccessProfiles as well as user credentials from the AccessAgent Observer core module, which in turn communicates with the rest of the AccessAgent for data synchronization and workflow session management services.

A default set of AccessProfiles is provided with the Tivoli Access Manager for Enterprise Single Sign-On installer. However, each organization can create additional AccessProfiles for its own unique set of applications using the AccessStudio tool. The Observer architecture consists of the following modules: Workflow trigger module Workflow action module Windows application observer agent Mainframe and host application observer agent Web application observer agent Java application observer agent

Workflow trigger module The AccessAgent Observer agent module detects requests for credentials but not restricted to, in a variety of ways, depending on application type (Web, Windows, and Mainframe/Host). Triggers cause transitions between states in the state engine. At the end of the day a trigger defines when a condition is true.

Chapter 2. Single sign-on architecture and component design 25 Examples of a trigger are: wnd_create_trigger (Windows executable window is created.) web_document_complete_trigger (Web document completes loading). web_click_item_trigger (HTML element is clicked.) wnd_command_bn_click_trigger (Windows executable button is clicked.)

Each trigger has a next-state defined. For example, when a login window is presented, the state machine could move to the after_login_window_popped_up state. Approximately 40 predefined triggers exist.

Signature A trigger is specified by an equation where a specific trigger condition, such as a specific Web URL or inside a specific application, has to occur so that a condition is true.

Workflow action An action can be performed in response to a trigger. That is, a workflow action defines what has to be done if a trigger becomes true. Examples of an action are: acc_data_inject_action (Injection of credentials into defined fields) acc_data_capture_action (Capture of credentials from defined fields) wnd_click_action (Clicking a button in a Windows application) acc_data_save_action (Saving credentials to the Wallet)

Approximately 30 predefined actions exist.

Tivoli Access Manager for Enterprise Single Sign-On includes observer agents for different kinds of applications such as: Windows applications Mainframe and host applications (3270, 5250, and TTY) Web applications Java applications and applets

In the following list, we look more closely at the various kinds of applications and their respective observer agent modules: Windows application Observer agent Tivoli Access Manager for Enterprise Single Sign-On responds to requests for user credentials from Windows applications. It works without any special configuration after you install it with the most widely used applications. In addition, you can configure it to work with any other individual application.

26 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 All credential requests in Windows have specific attributes: application name, window name, the control ID of the input field, and so on. Tivoli Access Manager for Enterprise Single Sign-On looks for the specific attributes of each application’s logon and password change dialog boxes and responds to these accordingly. The attributes are stored in application profiles. Refer to the Tivoli Access Manager for Enterprise Single Sign-On AccessStudio for additional information. The Tivoli Access Manager for Enterprise Single Sign-On AccessAgent Observer agent captures standard OS-level Windows messages and sends them to the Tivoli Access Manager for Enterprise Single Sign-On Observer core. When a specified application creates a dialog, Tivoli Access Manager for Enterprise Single Sign-On looks at the window title and other attributes as defined in the application profile. If Tivoli Access Manager for Enterprise Single Sign-On recognizes the required AccessProfile it informs the observer module to start the required actions. Tivoli Access Manager for Enterprise Single Sign-On submits credentials to most Windows applications through secure, standard, OS-level Windows messages. Thus, keyboard-sniffing utilities cannot intercept the credentials. Furthermore, because Tivoli Access Manager for Enterprise Single Sign-On does not use keystrokes, users cannot confuse the response by selecting and working in another application. Mainframe and host application Observer agent Tivoli Access Manager for Enterprise Single Sign-On responds to requests for user credentials from mainframe and host applications. It works without modification with the most popular mainframe and host emulators. In addition, you can configure it to work with others. All requests for credentials in mainframe and host applications have specific attributes: window title and various blocks of text (at specific coordinates for Mainframe applications), user name and password field text, and so on. Tivoli Access Manager for Enterprise Single Sign-On looks for the specific attributes of each application’s logon and password-change windows and responds accordingly. The attributes are stored in the application profiles as well. See the Tivoli Access Manager for Enterprise Single Sign-On AccessStudio for additional information. The Tivoli Access Manager for Enterprise Single Sign-On Mainframe application observer agent monitors emulators, looking for the defined matches. When a new panel is presented, Tivoli Access Manager for Enterprise Single Sign-On reviews the text for matching fields. If all attributes match, the observer module submits the user credentials. Tivoli Access Manager for Enterprise Single Sign-On submits credentials to most emulators through HLLAPI. Thus, keyboard-sniffing utilities cannot intercept these credentials. Furthermore, because Tivoli Access Manager for

Chapter 2. Single sign-on architecture and component design 27 Enterprise Single Sign-On does not use keystrokes for these emulators, users cannot confuse the response by selecting and working in another application. Web application Observer agent Tivoli Access Manager for Enterprise Single Sign-On responds to requests for user credentials from Web applications, whether in a form or through a pop-up dialog. Unlike most single sign-on products, Tivoli Access Manager for Enterprise Single Sign-On supports access to all Web applications, not just intranet applications. Most Web applications are supported without modification and new applications can be added. All credential requests in Web applications are either in forms or in dialog boxes. The Tivoli Access Manager for Enterprise Single Sign-On Web Browser observer agent responds to the specific events of a Web dialog box opening or of a Web page rendering. Because the observer does not use keystrokes for Web browsers, users cannot confuse the response by selecting and working in another application. Java application and applet Observer agent Tivoli Access Manager for Enterprise Single Sign-On responds to login and password change requests for virtually all Java applications and applets built on the Sun™ Java™ Runtime Engine 1.4.1 or higher. New Java applications or applets can be supported by using the Tivoli Access Manager for Enterprise Single Sign-On AccessStudio.

AccessAgent Plug-In The AccessAgent Plug-In is a block of VBScript or JavaScript™ code that performs some custom action needed as part of a workflow trigger or workflow action inside an AccessProfile. This block of code can make calls into the Windows OS as well as into an AccessAgent Plug-In API, using the user’s Windows and Tivoli Access Manager for Enterprise Single Sign-On privileges (Figure 2-8 on page 29).

28 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 2-8 AccessAgent Plug-In

Administrators typically use this extension facility to implement customized authentication, access control, or workflow automation for a specific application, such as to: Retrieve application credential (for the current application) from user's Wallet. Retrieve a user policy setting from user's Wallet. Look up user's group membership or attribute from the user directory. Read or store data from a central fileshare. Look up the time from the host system clock. Perform an additional checksum or check the installation path on a target application prior to single sign-on. Call an external application or process. Make an HTTPS call to a third-party service.

Chapter 2. Single sign-on architecture and component design 29 Session management Tivoli Access Manager for Enterprise Single Sign-On supports two main usage configurations: personal workstations and shared workstations. The personal workstation configuration is typically used in organizations where users are assigned their own workstations. The shared workstation configuration, for example, can be found in health care organizations where doctors and nurses share workstations that are deployed throughout the hospital. Tivoli Access Manager for Enterprise Single Sign-On supports fast user switching through any of the following schemes: Shared desktop Private desktop Roaming desktop

Let us shed some more light into the supported modes for shared workstations: Fast user switching through shared desktop Shared desktops allow multiple users to use one generic Windows desktop in a workstation. Because each user does not have to log on to Windows, the switching of users is quicker. However, after switching from user A to user B, the application contexts for user A will be lost. If user A returns later and switches the workstation back to user A’s account, the user must re-launch the applications. For the scheme, AccessProfiles must be created to automatically log off enterprise applications when user switching occurs. Fast user switching through private desktop Private desktops allow multiple users to have their own Windows desktops in a workstation. The scheme uses the local user session management feature of the AccessAgent, which allows users to retain the existing user’s desktop session during switching of users. When a user A returns to the workstation to unlock it, AccessAgent switches to user A’s earlier desktop session, allowing user A to resume the previously incomplete or interrupted work. However, an existing desktop can be logged off if the workstation runs out of resources (for example, memory) to accept a new user logon. If the user logs on at another workstation, the user still needs to re-launch the applications. Because security is very important for the private desktop operation, refer to 2.4.4, “How the private desktop feature ensures security” on page 44. Fast user switching through roaming desktop Roaming desktops provide users with Windows virtual desktops to roam to their points of access, from workstation to workstation. With roaming sessions, a user can disconnect from the current virtual desktop or application session at a client, log on to another client, and continue the desktop or application session at a new client. The scheme requires the use

30 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 of either a Microsoft Windows Server Terminal Services session or Citrix MetaFrame Presentation Server session.

If the AccessAgent is configured for shared workstation operation, the workflow session management module is responsible for the desktop switching between the different users.

The best desktop operation mode possible for a given deployment situation depends on several conditions, like amount of memory available at every desktop or whether the required applications support more than one instance. Table 2-2 provides an overview of configuration modes and their advantages and disadvantages.

Table 2-2 Comparison of different desktop operating modes AccessAgent Advantage Disadvantage configuration

Personal desktop Easy integration Only basic SSO One PC, one user, SSO to every standard SSO application possible

Shared desktop Easy user switching Application context One PC, many users, gets lost during user one desktop switching, the required applications must be restarted after a user switch

Private desktop Applications remain Not all applications One PC, many users, open even during user support more than one many desktops switching instance and must be Very fast switching closed during a user possible switch All applications stay in memory, which can consume a lot of memory

Roaming desktop User can move a Requires Windows session from one Terminal services or desktop to another Citrix Presentation Server

Chapter 2. Single sign-on architecture and component design 31 2.2.2 Terminal Server or Citrix Presentation Server AccessAgent

The AccessAgent includes a server mode that is automatically enabled when deployed on a Microsoft Windows Terminal Server or a Citrix Presentation Server. A separate instance of the server-side AccessAgent is launched for each terminal session. When a new terminal session is started, the server-side AccessAgent looks for the client-side AccessAgent across a virtual channel established between the terminal server and its Remote Desktop Protocol (RDP) client. Subsequently, Wallet changes and logon/logoff events from either side are communicated to each other over the virtual channel. For example, if the user captures a new application credential on the server session (and synchronizes it to the IMS Server), the server AccessAgent notifies the client side AccessAgent, which then separately performs a synchronization with the IMS to retrieve the new application credential. To enable the virtual channel communication feature, a service engagement is necessary to provide the applicable software.

2.2.3 IMS Server

The IMS Server provides a central point of administration and control. It enables centralized management of user identities, AccessProfiles, and authentication policies. It also provides loss management of authentication tokens, certificate management, and audit management.The IMS Server interfaces with other applications through IMS Connectors and IMS Provisioning Bridges. The IMS Server can be configured with AccessAdmin. Lower-level configuration settings for the IMS Server can be configured with the IMS Configuration Utility, which is accessible by administrators. IMS exposes an internal SOAP API that is used by AccessAdmin, AccessStudio, and AccessAgent.

Figure 2-9 on page 33 shows the IMS Server architecture.

32 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 2-9 IMS Server architecture

The IMS Server is a Web-based applications developed in Java and runs on top of a Tomcat application server. During installation of the IMS Server software the applications server gets installed as well.

In this section, the following IMS Server components, shown in Figure 2-9, are discussed: Identity Management Authentication Auditing Other Services

Identity management The IMS Server provides basic identity management functions like user enrollment and password management for users and administrators. Supported by a self-service module, users are able to manage their own credentials, for example, resetting their password.

Chapter 2. Single sign-on architecture and component design 33 Authentication The IMS Server provides a one time password mechanism called ActiveCode. This ActiveCode is a strong authentication mechanism to authenticate users online or when their desktop has no connection to the IMS Server. To allow VPN servers to authenticate with a one-time password, the IMS also provides a RADIUS interface.

Auditing The auditing framework captures identity information and events in the database to allow administrators to generate reports for identity auditing, such as: List of application accounts for a user Policy changes performed on a user by an administrator or help desk Successful and failed application logons and logoffs Summary table of the number of times each user logs on to each application within a period of time

In addition to the standard events listed, users can create custom events to track application-specific events. For details, refer to BM Tivoli Access Manager for Enterprise Single Sign-On AccessStudio Guide Version 8.0, SC23-9956. Particularly see the information about generating custom audit logs in the section about automating tasks with AccessProfiles.

To analyze the audit log administrators can generate identity auditing reports using an SQL query tool (for example, Microsoft Excel®, Microsoft SQL Query Analyzer, Crystal Reports, and so on).

Other services Tivoli Access Manager for Enterprise Single Sign-On uses policies to control the behavior of its components. These policies are configurable through various means. Policies have different visibility and scope and can be applicable system-wide, or only to certain groups of users. The applicability of a policy is determined by its scope, which can be System, User, or Machine.

The provisioning automates the user credential distribution process so that identity management solutions such as IBM Tivoli Identity Manager (ITIM) can provision and remove user involvement in the credential provisioning and management process. See the 2.5.6, “IBM Tivoli Identity Manager integration” on page 52 for details about the integration of Tivoli Access Manager for Enterprise Single Sign-On and Tivoli Identity Manager.

The provisioning bridge Java API can be installed on a third-party provisioning system to communicate with IMS to perform user provisioning operations.The third-party system communicates to the IMS using JMX™.

34 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 2.2.4 IMS database

The IMS relies on an external relational database to store its system data and user data. It also stores all its audit logs into the same or a separate database instance. The IMS application communicates with the database using JDBC™.

2.2.5 AccessAdmin

The AccessAdmin component is the Web based management console used by administrators and help desk employees to manage users and policies on an IMS Server (Figure 2-10 on page 36). Different access rights are granted to the administrator and help desk roles. Certain configurations (for example, system policies) can only be viewed but not modified by the help desk staff.

The AccessAdmin GUI provides the following functions: User search and administration (to modify user policies, issue authorization code, unlock a locked Wallet, revoke user, and so on) Creating and maintaining policy templates (can only be created and maintained by an administrator, but help desk staff can view and apply) Setting system and application policies (can only be modified by an administrator, but help desk staff can view) Accessing logs and status information

Chapter 2. Single sign-on architecture and component design 35 Figure 2-10 Web based Administration AccessAdmin

Authorization and access management Role-based access control is used to protect access to operations in the AccessAdmin, Web Workplace, and AccessAssistant applications. Users are classified into three roles: User Administrator Helpdesk

36 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 A new user is granted the user role by default, when the user first registers to the IMS Server through AccessAgent or AccessAssistant.

Only users with the administrator role have full access to the AccessAdmin and AccessStudio applications. For example, only administrators can modify AccessProfiles at the IMS Server and can modify system through AccessAdmin. The very first administrator user is provisioned during IMS configuration, using the IMS Web configuration. Subsequently, an administrator user can attach any user the administrator or help desk role through the AccessAdmin interface.

Help desk members are responsible for user administration tasks like managing of user policies, revocation of second factor token like USB token or smart cards and issuing of authentication token for password reset or second factor registration.

2.2.6 AccessStudio

The AccessStudio application is used by administrators to create AccessProfiles required to support sign-on/sign-off and custom workflow automation. This component can run on Windows only (Figure 2-11 on page 38).

The AccessStudio application provides: A wizard mode is for administrators to easily generate AccessProfiles for most applications, by walking through the set of application windows and mapping selected fields/controls used for logon, logoff, and other application behaviors. An advanced mode is for administrators to create AccessProfiles for complex applications or where complex workflow automation is required. A test mode is for administrators to test a generated AccessProfile against the target application. When the AccessProfile is finished, it can be uploaded to the IMS Server with AccessStudio.

The AccessStudio must be installed on an existing AccessAgent installation. The user must have an administrator role and must have an active AccessAgent session before downloading from or uploading to the IMS Server is possible.

Chapter 2. Single sign-on architecture and component design 37 Figure 2-11 AccessStudio application

2.2.7 Provisioning bridge

The provisioning bridge automates the user credential distribution process so that identity management solutions such as Tivoli Identity Manager can provision and remove user involvement in the credential provisioning and management process. It enables an administrator to automatically provision Tivoli Access Manager for Enterprise Single Sign-On with a user’s ID and password by using an external provisioning system. An administrator is able to add, modify, and delete IDs and passwords for particular applications within the provisioning system and have the changes reflected in Tivoli Access Manager for Enterprise Single Sign-On.

From the provisioning system, all user names and passwords in Tivoli Access Manager for Enterprise Single Sign-On can also be deleted so that a user’s access to all protected applications is revoked. Figure 2-12 on page 39 illustrates the provisioning bridge architecture.

38 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 2-12 Provisioning bridge architecture

In most organizations, users have to know, remember, and enter their application credentials. This is a particular hassle on the first day a user begins work or takes on a new set of responsibilities and permissions. But when an organization uses the Tivoli Access Manager for Enterprise Single Sign-On provisioning bridge, application credential provisioning and deprovisioning between Tivoli Identity Manager and Tivoli Access Manager for Enterprise Single Sign-On are automated. Consequently, organizations no longer have to physically distribute credentials to users who must enter them manually into Tivoli Access Manager for Enterprise Single Sign-On.

Instead, administrators directly create, edit, and delete user credentials through Tivoli Identity Manager. Users can enjoy single sign-on from day one and are no longer responsible for keeping track of their own application credentials, while helping to maximize security. When users no longer need access to systems, the integration between the Tivoli applications enables Tivoli Identity Manager to remove or revoke the users’ systems and application access and also delete their credentials automatically from the Tivoli Access Manager for Enterprise Single Sign-On data store. Controlling the appropriate level of access helps maximize security and assists with compliance initiatives by demonstrating enforcement of internal controls to auditors.

Chapter 2. Single sign-on architecture and component design 39 Note: In this context, a best practice is to always revoke a Tivoli Access Manager for Enterprise Single Sign-On account instead of deleting it. The reason for this is to keep the audit log information available for later audits. After a Tivoli Access Manager for Enterprise Single Sign-On account has been revoked, it cannot be re-activated.

Furthermore, the Tivoli Access Manager for Enterprise Single Sign-On provisioning bridge provides a high level of administrative control. For example, when application passwords are reset in Tivoli Identity Manager, Tivoli Access Manager for Enterprise Single Sign-On is simultaneously updated so that it always has the correct password. Additionally, it extends audit and reporting capabilities to include information about applications and use of applications that are configured in Tivoli Access Manager for Enterprise Single Sign-On but that fall outside the Tivoli Identity Manager umbrella. The provisioning bridge receives instructions from Tivoli Identity Manager that contain credential data, it informs individual Tivoli Access Manager for Enterprise Single Sign-On agents about application configurations that have been added, deleted, or changed by: Normalizing these instructions into a format that Tivoli Access Manager for Enterprise Single Sign-On can understand. Placing the instructions into the directory object for the appropriate user.

2.3 Additional components

Tivoli Access Manager for Enterprise Single Sign-On also includes the following additional modules: Provisioning Agent The Provisioning Agent is an application that monitors an Active Directory® periodically for deletion of users to trigger a corresponding deletion or revocation of the user's account or Wallet on the IMS Server. This application is intended for deployments in which a user provisioning system (like Tivoli Identity Manager) is not deployed, because it helps save the administrator from having to separately revoke a user's Tivoli Access Manager for Enterprise Single Sign-On account when the administrator deletes the user from Active Directory. AccessAssistant The AccessAsistant is a Web-based interface that enables users to manage their identity wallet. They can reset their Tivoli Access Manager for Enterprise Single Sign-On password, change the reset questions-and-answers, and view, add, edit, or delete user names and passwords inside their wallet.

40 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Web Workplace The Web Workplace component provides a Web-based interface that enables the user to log on to enterprise Web applications by simply clicking on links, without the need to remember the passwords for individual applications. Users can also access applications hosted on Citrix MetaFrame or Terminal Servers through the Web Workplace without further logins. To securely implement this functionality, you should use SSL VPN connections.

2.4 Security requirements

To better understand how Tivoli Access Manager for Enterprise Single Sign-On implements operational security, we first have to identify which information assets and procedures must be secured. Tivoli Access Manager for Enterprise Single Sign-On handles the following types of sensitive data: Application credentials These credentials are stored on behalf of a user to provide automated access to enterprise applications. Encryption keys These cryptographic keys are used to protect the user credentials. Authentication factors This secret data provided by a user is for proving one’s identity to the system. This includes the user’s Tivoli Access Manager for Enterprise Single Sign-On password, biometric data, onetime passwords, and so on. Audit logs Audit logs must be protected against tampering.

All the sensitive data items listed above must be protected as they flow through the system. Thus, the security requirements for Tivoli Access Manager for Enterprise Single Sign-On can be specified as follows: Secure storage If sensitive data has to be stored, either on the server or the clients, it must be stored in an encrypted form. Secure processing Sensitive data must be in an unencrypted form while it is being used. The system should prevent other user programs from accessing the unencrypted data while it is held in memory.

Chapter 2. Single sign-on architecture and component design 41 Secure communication Sensitive data must be protected from eavesdroppers as it travels between the components.

2.4.1 Securing Wallets

In this section we discuss how Tivoli Access Manager for Enterprise Single Sign-On protects all sensitive data items in the different components.

Secure storage When a user signs up with Tivoli Access Manager for Enterprise Single Sign-On, a random cryptographic key, called the Common Symmetric Key (CSK), is generated. This CSK is unique to the user and is used for encrypting the user's credentials in the Wallet. The CSK, in turn, is encrypted using a key derived from either the user's Tivoli Access Manager for Enterprise Single Sign-On password or secret question-and-answer. The user’s authentication factors, such as the password, are not stored anywhere in the system. The CSK can be obtained in unencrypted form only when users authenticate themselves by providing their correct Tivoli Access Manager for Enterprise Single Sign-On password. The CSK can then be used to decrypt the credentials and is discarded when the user logs off.

Secure storage on the server The IMS Server stores only the encrypted forms of the user’s credentials and CSK in its database, so even breaking into the database does not reveal the CSK nor the credentials. Moreover, the access controls on the database are configured in such a manner that only an IMS Server-specific database account and the database administrators are granted access to the data.

Secure storage on the clients On client workstations the AccessAgent stores a copy of the encrypted credentials and CSK in a secure data file called Cryptobox. Data is stored in an encrypted format. The design of the Cryptobox makes it impossible to read or enumerate the stored data items without knowing their access keys. The access key for the credentials stored in a Cryptobox is derived both from the user's CSK and a secret known only to the AccessAgent. Therefore, the credentials can be extracted from the Cryptobox only after the AccessAgent has authenticated the user and has access to the user's CSK. The AccessAgent can be configured to delete Cryptoboxes if they have not been used for a specified number of days. This approach can minimize the risk of exposure to brute-force attacks on user credentials stored in Cryptoboxes.

42 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Secure processing The AccessAgent also protects sensitive data while the data resides in the computer’s memory. A user’s Tivoli Access Manager for Enterprise Single Sign-On password is held in the computer memory in a scrambled form. It is unscrambled only when it is used. This foils any attempt from other user programs to scan the password from the agent’s memory. Similarly, memory locations that temporarily hold a user’s credentials and the CSK are wiped clean after use to prevent object reuse attacks.

Secure communication When a user logs on to Tivoli Access Manager for Enterprise Single Sign-On, the user’s password is sent to the IMS Server. In addition, when the user captures new credentials or updates them, the credentials are synchronized between the IMS Server and the AccessAgent. The communication channel that carries this sensitive data is protected by using SSL. After the AccessAgent verifies the SSL certificate issued to the server, the communication is encrypted using temporary session keys. This approach prevents eavesdroppers from extracting the sensitive data from network packets.

Secure audit logs The audit log records stored in the database can optionally be made tamper-evident through the use of hash chains and signatures. A log verification utility script can be run on demand or on schedule to verify the hash chains and signatures.

2.4.2 Recovering Wallets

As mentioned in the previous sections, a user's Wallet is protected by the CSK, which in turn is protected by the Tivoli Access Manager for Enterprise Single Sign-On password. If the user forgets the password, the credentials stored in the Wallet will not be available, preventing the user from accessing enterprise applications. Tivoli Access Manager for Enterprise Single Sign-On provides the user with a means to recover the Wallet, even if the password is forgotten. During registration, a user is allowed to register one or more personal secrets. These secrets are responses to questions only the user is likely to know. The system also stores the user's CSK in an encrypted form with the personal secrets. If the user forgets the password, the user must provide a specified number of correct personal secrets in order to reset the password and recover the Wallet. In this process, Tivoli Access Manager for Enterprise Single Sign-On re-encrypts the user's CSK with the new password provided by the user.

Chapter 2. Single sign-on architecture and component design 43 2.4.3 Strengthening the protection of Wallets

Because logging on to Tivoli Access Manager for Enterprise Single Sign-On provides the user with the credentials to log on to multiple enterprise applications, the authentication to Tivoli Access Manager for Enterprise Single Sign-On should be strengthened. Tivoli Access Manager for Enterprise Single Sign-On provides several ways to strengthen the authentication, which are discussed in this section.

Use of password policies An enterprise can ensure that its users use strong passwords to log on to their systems by enforcing Tivoli Access Manager for Enterprise Single Sign-On password policies. These policies include password aging, password complexity, and lockout policies that can be centrally configured on the IMS Server.

Use of authentication factors Access to the Wallet can also be strengthened by enforcing the use of additional authentication factors such as RFID badges, biometrics, and USB smart card tokens. The use of such authentication factors increases security, as an attacker now needs to obtain both a physical token and the Tivoli Access Manager for Enterprise Single Sign-On password of a user to gain access to a Wallet. Tivoli Access Manager for Enterprise Single Sign-On can use RFID-enabled facility access badges as authentication factors. Users must present their RFID access badge, as well as the password to log on to their systems. To log on using a USB smart card token, the users supply the smart card PIN, which is verified by the smart card itself. The private data on the smart card is protected by the PIN, which is locked out after a pre-configured number of successive failed attempts. Users with USB smart card tokens can have their credentials stored securely on the smart card instead of on a computer's hard disk. Tivoli Access Manager for Enterprise Single Sign-On uses Public Key Cryptography to authenticate the USB tokens to the IMS Server using 2048-bit RSA keypairs stored on the smart cards.

2.4.4 How the private desktop feature ensures security

The private desktop feature is provided by the AccessAgent. It utilizes the Windows operating system support to create multiple Windows desktops for different user accounts, using the user’s own Windows privileges, and facilitates the switching between these desktops. This way the private desktop is only visible to the individual user, no other user (including the administrator) can access it.

44 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 When a new user logs on from the AccessAgent GINA, the private desktop first verifies that the user is a valid user, and then creates a Windows desktop for that user. It then loads the user's Windows profile, and creates the user's shell (starting Windows Explorer, and so on) for the user to interact with the desktop. The private desktop also provides Global Policy Object (GPO) support by invoking the client side extensions to apply the group policies applicable to the user. Next, the user shell in the user's security context is created and therefore, all applications run from the desktop are executed in the user's own security context.

With the private desktop session, each desktop runs with the rights of the user's Active Directory account, and so, access to each user's desktop/resources remains protected by Windows access control. This means that as long as each user account does not have administrative rights on the machine, a user cannot possibly access another user's data.

When users log off from their desktop, the private desktop gracefully logs off the users’ applications by sending end session messages to each open window on the users’ desktops. Just as a normal Windows logoff when an application is not ready to end, the private desktop displays a notification to the users and lets them terminate the logoff processes. In the event of a system restart or shutdown, all private desktops are logged off gracefully before the system restarts or shuts down.

The private desktop is designed to prevent malicious software or some other desktop management software from switching between a current desktop to another user's desktop. If a third-party software tries to perform desktop switching, AccessAgent immediately locks the workstation. If the component of AccessAgent that implements this security measure is somehow terminated by the administrator, the computer is restarted automatically.

This functionality also prevents the clipboard content on one desktop being accessed from another desktop session. Anything copied onto the clipboard from one desktop is prevented from being pasted into another desktop.

Windows 2000 does not support Fast User Switching (FUS) although Windows XP support for FUS is limited to non-domain logons. With the Tivoli Access Manager for Enterprise Single Sign-On private desktop, Active Directory users can use FUS with domain level security across Windows 2000 and Windows XP.

Chapter 2. Single sign-on architecture and component design 45 2.5 Physical component architecture

In this section, we describe the physical components that are assembled for Tivoli Access Manager for Enterprise Single Sign-On. Figure 2-13 shows a simple, base deployment architecture. For a detailed discussion of different server deployment scenarios, refer to 2.5.7, “Server deployment architectures” on page 54.

Figure 2-13 Physical base deployment architecture

2.5.1 AccessAgent

The AccessAgent gets deployed on user and administrator workstations either manually or using software distribution mechanisms. Because the AccessAgent features can be configured afterward, specifying any options during the AccessAgent software installation is not necessary. Although several configuration parameters like the IMS Server URL or whether the GINA extension should be installed can be predefined.

AccessAgent and GINA chaining For AccessAgents installed with GINA option enabled, a user logs on to the AccessAgent GINA first, with the required authentication factors, whereupon the

46 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 AccessAgent will auto-logon the user into Windows using the user’s Windows account. The Windows GINA is not replaced and is still available as needed.

For AccessAgents installed without the GINA option enabled, the user usually logs on to Windows manually first, and then logs on separately to AccessAgent with the required authentication factors. But, this approach is not always the process, for example, for password-sync single-factor deployments, we can use the EnNetworkProvider to avoid the second login.

Availability constraints If the AccessAgent has network connection to the IMS Server, it will authenticate a user against the IMS Server by passing along the authentication credentials over HTTPS to IMS. However, if the AccessAgent is offline to the IMS, it will then authenticate the user's presented credentials against cached authentication data stored on the disk. The data volume for each class of data cached at the clients is estimated at: System data up to 300 KB to 400 KB User data estimated 50 KB to 100 KB per user

Support for terminal services As described in 2.2.2, “Terminal Server or Citrix Presentation Server AccessAgent” on page 32 the AccessAgent has a server mode for Microsoft Windows Terminal Server and Citrix Presentation Server. To use the single sign-on features on one of these systems the AccessAgent simply has to be deployed on the server.

Hardware and software requirements The AccessAgent requires a computer with a Windows operating system installed. For detailed hardware requirements, refer to the product documentation.

2.5.2 IMS Server

The IMS (Integrated Management System) serves as the central repository and management point for all system and user data consumed by the AccessAgents. The IMS performs the following functions: Serves as a central repository and distribution point for AccessProfiles and other system data. Serves as a central repository for all user data, including the credential Wallet and various authentication and access policies.

Chapter 2. Single sign-on architecture and component design 47 Provides a SOAP API for AccessAgents, as well as AccessAssistant and Web Workplace servers, to authenticate users, and to retrieve and synchronize system and user data. Provides a SOAP API for AccessStudio to upload new or updated AccessProfiles for distribution to AccessAgents. Provides a SOAP API for Tivoli Identity Manager to provision application credentials into user's Wallets and users into IMS. Provides SOAP and RADIUS APIs for third-party software, like VPN, to authenticate users through one-time passwords. Provides a Web based interface for administrators to manage users, machines and system policies, as well as to query audit logs. The Web based interface is named AccessAdmin.

The IMS Server consists of a group of Web-based applications developed in Java and run on top of an Apache Tomcat3 application server. During installation of IMS Server software, the applications server is also installed. Administration of the Tomcat application server is not necessary during IMS operation.

Hardware and software requirements For requirements, refer to the product documentation.

2.5.3 IMS database

The IMS Server stores all its data within a relational database. The IMS database contains these classes of data: System data The class of system data includes AccessProfiles, system policies, user and machine policy templates, and other system configuration data. User data The class of user data includes application credentials and user policies. Machine data The class of machine data includes any machine policies and information about deployed machines. Audit logs Every user and administration activity is stored in the database and even the SOAP call logs are stored in the IMS database.

3 More information about the Apache Tomcat application server can be found at: http://tomcat.apache.org/

48 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Expected data volume The expected data volume is important for the sizing of the IMS database server. Based on the architecture and database design, the data volume for each class of data stored on IMS is estimated at: System data is expected not more than 10 MB. User data can reach approximately about 200 KB per user. Audit logs requires no more than 7 GB per 1000 users for a log retention period of one year.

Supported database engines The following types of relational databases are currently supported: Microsoft SQL Server® 2000 Microsoft SQL Server 2000 Desktop Engine (MSDE) Microsoft SQL Server 2005 Microsoft SQL Express Oracle® Database 9i Oracle Database 10g IBM DB2® 9.5 (available in the installation CD, but must be installed separately)

Hardware requirements Although the IMS Server and the IMS database can share one physical machine, the preferred deployment model is to separate the functions on two physical or virtual servers. Refer to 2.5.7, “Server deployment architectures” on page 54.

2.5.4 Organization directory

An enterprise directory can be used to manage user accounts, including those maintained by the IMS Server.

The integration of organization directories An organization directory is an entity that validates user credentials for Tivoli Access Manager for Enterprise Single Sign-On users. It can be used for validating users during signup and also during logon, if the password is set up to synchronize with the enterprise directory password. In short, it can be a directory of user accounts that define Tivoli Access Manager for Enterprise Single Sign-On users. An example for an enterprise directory can be an Active Directory forest, as depicted in Figure 2-14 on page 50.

Chapter 2. Single sign-on architecture and component design 49 Figure 2-14 Organization directory integration

An organization directory may contain several authentication services, or none at all. An Active Directory forest with multiple domains can be an enterprise directory that contains multiple authentication services, with each authentication service representing one domain. Such a definition, coupled with the password synchronization feature, allows enterprise directory passwords to be used for both logon to Wallet and automatic sign-on to applications.

Use of existing user registries Tivoli Access Manager for Enterprise Single Sign-On uses existing user registries (for example, Microsoft Active Directory or IBM Tivoli Directory Server) to identify and validate a user when they register or sign up. After this step, it creates an account for this user in its own user repository (stored on the IMS database), and thereafter only this database is consulted during runtime when the user accesses the Tivoli Access Manager for Enterprise Single Sign-On functions. Additionally, user accounts can be provisioned into Tivoli Access Manager for Enterprise Single Sign-On using user provisioning products such as Tivoli Identity Manager as described in 2.5.6, “IBM Tivoli Identity Manager integration” on page 52.

For deployments where the IMS is configured to use Microsoft Active Directory (AD) as its user repository, Tivoli Access Manager for Enterprise Single Sign-On can be configured to perform password synchronization with Active Directory. In this configuration, users can always log on to the AccessAgent with their latest Active Directory credentials; if this AD password is reset out-of-band, the AccessAgent and IMS will verify the new AD password against the Active

50 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Directory server, and re-sync the Tivoli Access Manager for Enterprise Single Sign-On password to this new value.

Additionally, for Active Directory deployments, the IMS can additionally lookup the directory for attributes of Windows workstations joined to the domain, and use these attributes to select a machine group policy template to apply onto the machine.

2.5.5 Initial deployment scenario

Now is the time look more closely at a possible initial deployment scenario for Tivoli Access Manager for Enterprise Single Sign-On. Figure 2-15 shows a step-by-step layout picture.

Figure 2-15 Initial deployment overview

Let us walk through the steps as illustrated in this figure: 1. We assume that a working organization directory like Windows Active Directory already exist and is operating. 2. The administrator configures a database on the IMS database server. The administrator installs the IMS Server software. This step should be done before any AccessAgents are installed.

Chapter 2. Single sign-on architecture and component design 51 3. If the administrator wants to manage SSO profiles from his machine, the AccessAgent and AccessStudio software must be installed. 4. With the help of the AccessAdmin Web console the administrator configures the IMS Server with the organization directory for authenticating the user. At this step the initial AccessProfiles and machine policies are defined. 5. All configuration items belonging to the profiles, like AccessProfiles or machine policies, are stored in the IMS database. 6. When the IMS Server is running and the initial profiles are defined, the AccessAgent can be deployed onto the Windows clients. 7. During the installation phase, the AccessAgent registers itself at the IMS Server and downloads the required machine policy. 8. If manual sign-up for new Tivoli Access Manager for Enterprise Single Sign-On users is configured, the user has to authenticate with the organization directory credentials. Usually these are the Active Directory credentials. 9. The IMS Server checks the sign-up credentials always against the organization directory that is configured into the IMS Server. For more information about this step, refer to “Introduction to desktop authentication and single sign-on” on page 16. 10.During the user sign-up, a new Wallet for the user is created, stored in the IMS database, and downloaded to the AccessAgent together with the required UserProfile.

From this point forward the user is operating as usual. 11.During normal operation the user authenticates against the AccessAgent. 12.The IMS Server proofs the user credentials provided by any authenticator against the IMS Server. 13.If the authentication was successful, the AccessAgent loads any modified AccessProfiles or UserProfiles from the IMS Server.

2.5.6 IBM Tivoli Identity Manager integration

The provisioning bridge can receive and process provisioning requests initiated by Tivoli Identity Manager. The integration between the provisioning bridge and Tivoli Identity Manager is accomplished by using a workflow extension that Tivoli Identity Manager uses to communicate with the provisioning bridge Web service.

Figure 2-16 on page 53 illustrates the necessary physical components.

52 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 2-16 Identity Manager integration architecture

Tivoli Identity Manager has to communicate with the IMS Server to populate and manage credentials in the Wallet. The Tivoli Access Manager for Enterprise Single Sign-On provisioning bridge and workflow extension are the interface engines that act as intermediaries between the IMS Server and Tivoli Identity Manager.

Tivoli Identity Manager connects to the IMS Server with the Tivoli Access Manager for Enterprise Single Sign-On workflow extension to add account credentials to users’ Wallets. To perform tasks, such as creating an IMS user, deleting an IMS user, and searching for IMS users, the workflow extension invokes operations on the provisioning bridge using the provided Tivoli Directory Integrator4 AssemblyLines. After the workflow extension has been added to Tivoli Identity Manager, and the provisioning bridge configured on Tivoli Identity Manager, all application accounts provisioned through IBM Tivoli Identity Manager will be provisioned to Tivoli Access Manager for Enterprise Single Sign-On as well.

Tivoli Identity Manager and the IMS Server communicate with each other: When Tivoli Identity Manager provisions a new user, it raises an event in the configured Tivoli Access Manager for Enterprise Single Sign-On service, which in turn invokes a corresponding Tivoli Access Manager for Enterprise Single Sign-On adapter AssemblyLine in IBM Tivoli Directory Integrator.

4 IBM Tivoli Directory Integrator ships with IBM Tivoli Identity Manager. For more information, consult Enterprise Security Architecture Using IBM Tivoli Security Solutions, SG24-6014.

Chapter 2. Single sign-on architecture and component design 53 The AssemblyLine then communicates with the IMS Server using SOAP over HTTPS to create the new IMS user. The Tivoli Access Manager for Enterprise Single Sign-On workflow extension is inserted into the workflow of each application’s creation workflow. When Tivoli Identity Manager provisions a new account for the user, the workflow extension is invoked. The workflow extension passes the account data to the Tivoli Access Manager for Enterprise Single Sign-On adapter, which passes the data to the IMS Server using SOAP over HTTPS, thus populating the user’s Wallet with the new account data. The workflow extension is also inserted into the workflow of each application’s password-reset workflow. In the event of a password reset for users, the workflow extension is invoked and passes the new password information to the IMS Server, which updates the credentials in the user’s Wallet. When Tivoli Identity Manager deprovisions users, it raises an event to the Tivoli Access Manager for Enterprise Single Sign-On adapter, which communicates with the IMS Server to delete the users. For this to happen, the workflow extension is inserted into the workflow of each application’s deletion workflow. When Tivoli Identity Manager deprovisions an enterprise application account, the workflow extension is invoked and sends the command to the IMS Server, which in turn deletes the application record from the users’ Wallets.

At this point, the new application is fully available to the user without the user ever knowing the provisioned password, and the user is able to access the application immediately after logging in to the Windows workstation using the Tivoli Access Manager for Enterprise Single Sign-On AccessAgent.

2.5.7 Server deployment architectures

The IMS adopts a two-tier server architecture, with a front tier of application servers and a back-end database. As such, deploying the IMS and its database is possible in a number of configurations, ranging from low end to high end.

The IMS and its database, as well as any underlying support infrastructure can be configured to achieve the availability and scalability requirements of the tangible environment. In this section, we describe three different deployment models covering different deployment sizes and availability requirements.

Pilot deployments Pilot deployments with no high availability requirements typically involve a single server machine hosting both the IMS and its database.

54 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 For instance, a single 4-processor (dual-core) 3.1 GHz processor blade server running a Windows operating system configured in this mode is expected to support up to 40000 users, assuming each user has an active AccessAgent session with the IMS Server. The picture in Figure 2-17 documents a proposal for a pilot deployment architecture.

Figure 2-17 Pilot deployment architecture

However, this single-box configuration is not horizontally scalable and does not provide high-availability. The only way to support more users is to upgrade its processor capability. If this single box fails, all IMS services become unavailable.

Small scale deployments Smaller environments with up to 10000 users typically deploy a two-box clustered configuration, where each box hosts the IMS Server and the database.

In this configuration, a clustering solution like Microsoft Cluster Server is required to maintain an active-passive pair of IMS Server and IMS Database. Usually, this configuration requires that the two database hosts share a common external disk array, and that the cluster-aware versions of the database must be deployed.

Chapter 2. Single sign-on architecture and component design 55 This configuration provides high-availability, because an automatic failover will be initiated when the active node fails. See Figure 2-18 for an example.

Figure 2-18 small scale deployment architecture

However, this configuration is typically limited to an active-passive pair and is thus not horizontally scalable. To support heavier loads, the hardware must be upgraded.

Large scale deployment model Medium- to large-scale architectures with, for example, up to 500000 users will adopt the standard two-tier architecture, with multiple IMS Servers in the front-tier and a clustered IMS database in the back end. See Figure 2-19 on page 57.

56 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 2-19 Large scale deployment architecture

The IMS Servers must be fronted by a session aware load-balancer. The IMS tier is thus horizontally scalable. An estimation is that each server, assuming a 2-processor dual-core 3.6 GHz Windows machine, can support up to 40000 concurrent AccessAgent sessions. As such, a deployment expecting 100000 concurrent AccessAgent sessions requires three such servers at the IMS tier to share the load.

The database tier can only be scaled vertically by default. As such, an important point is that the database host be sized correctly in accordance to the number of IMS Servers it is expected to service. A typical guideline, based on load test experiments, is to double the processor and memory capacity of the database host for every five additional IMS Servers.

Chapter 2. Single sign-on architecture and component design 57 2.6 Conclusion

This concludes the architecture and component design for Tivoli Access Manager for Enterprise Single Sign-On. We have taken a close look at the internal data flow between the different logical components. By using physical component diagrams, we provided descriptions of how to deploy the physical components, and a step-by-step workflow. We also introduced an integration scenario for enterprise identity management and provisioning using Tivoli Identity Manager.

58 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3

Chapter 3. Planning for customer engagement

In this chapter, we discuss a general service engagement for Tivoli Access Manager for Enterprise Single Sign-On (TAM E-SSO). This chapter is directed towards IBM Global Business Service agents and IBM Business Partners who assist customers in deploying Tivoli Access Manager for Enterprise Single Sign-On.

This section describes resources that are available to help you successfully deliver a solution.

3.1.1 Implementation skills

To develop and deploy a Tivoli Access Manager for Enterprise Single Sign-On solution successfully requires the following specialized skills: General skills – Operating system administration skills on Windows – Client/server application communication concepts – Methods for distributing Windows applications to large numbers of workstations Directory and database skills – Active Directory implementation and administration skills – Database installation and configuration skills – LDAP based user registry skills if Active Directory is not used Tivoli Access Manager for Enterprise Single Sign-On skills – Understanding of Tivoli Access Manager for Enterprise Single Sign-On component architecture – Ability to troubleshoot Tivoli Access Manager for Enterprise Single Sign-On configuration issues – Basic skills in configuring policies and profiles

Depending on the target environment, you might need additional skills to understand the whole application environment. You might be able to acquire these skills from the resources that we list in the next section.

60 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3.1.2 Available resources

The prerequisite skills that we list in the previous section are those required to customize or develop the solution. For each of these skills a variety of resources are available to help acquire the necessary skill level.

The educational resources available are: Online Help Tivoli Access Manager for Enterprise Single Sign-On provides online help and product manuals at the following Web site: http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliAccess ManagerforEnterpriseSingleSignOn.html Classroom Training IBM PartnerWorld® provides current information about available classes, their dates, locations, and registration. Additionally, check the Partner Education Web site, which serves as a single point of contact for all Business Partner education and training. IBM Technical Education Services (ITES) ITES offers a variety of classes at all knowledge levels to help you achieve any of the offering's prerequisite skills. IBM Tivoli Software Support Technical Exchange (STE) Webcasts Technical experts share their knowledge and then answer your questions: http://www.ibm.com/software/sysmgmt/products/support/supp_tech_exch. html New STEs are frequently added, use My Notifications to stay informed of the latest STEs: http://www.ibm.com/support/mynotifications IBM Redbooks Web site You can access various practical and architectural information regarding IBM hardware and software platforms. You can download PDFs of IBM Redbooks from the following Web site: http://ibm.com/redbooks

Chapter 3. Planning for customer engagement 61 Tivoli Access Manager for Enterprise Single Sign-On forum The Tivoli Access Manager for Enterprise Single Sign-On forum is to support the technical community responsible for demonstrating, performing proof of concepts, and implementing this solution. The emphasis is on supporting the questions of customizing or developing AccessProfiles, as well as other deployment topics. The goal is to provide the guidance, suggestions, and recommendations to ensure a successful implementation. Visit the following Web site: http://www.ibm.com/developerworks/forums/forum.jspa?forumID=1592 Tivoli Access Manager for Enterprise Single Sign-On Wiki This wiki provides best practices, education materials, example AccessProfiles, and other documents to enable and support IBM Business Partners, practitioners, and customers with developing AccessProfiles, deploying the product, and learning of the many capabilities of this solution. Visit the following Web site: http://www.ibm.com/developerworks/wikis/display/tivoliaccessmanagerf oresso/Home

3.2 Basic solution definition

The solution allows an enterprise to extend capability to allow employees to single sign-on from private, shared, and roaming desktops as well as personal desktops for applications using the basic profiling wizard. It also should include basic password reset and self-service functionality.

There are several variations of the solution: Basic single sign-on solution The basic solution includes an AccessAgent that is deployed to each user workstation and a single IMS Server to centrally manage users, policies, and configuration parameters through AccessAdmin. In this solution, the user is able to rely on Tivoli Access Manager for Enterprise Single Sign-On to log them into Windows applications, Web applications, and other applications configured into Tivoli Access Manager for Enterprise Single Sign-On. You should also expect to configure user, machine, and authentication policies. Basic single sign-on solution with session management Mobile employees can enjoy the benefits of single sign-on by accessing their applications from Windows Terminal Services clients or Citrix MetaFrame clients. You should expect to configure Terminal Services or Citrix

62 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 MetaFrame prior to deploying the AccessAgent, as well as configure the Terminal Services or Citrix MetaFrame policy settings in AccessAdmin. Single sign-on solution with deprovisioning Tivoli Access Manager for Enterprise Single Sign-On user credentials can be deprovisioned automatically when the user’s Active Directory account is deleted. This requires configuration of an Provisioning Bridge and deprovisioning parameters in combination of an identity management solution such as IBM Tivoli Identity Manager (ITIM). Single sign-on with two-actor authentication Configure a strong second authentication factor for one or more users and machines.

These solutions can be intermixed throughout an enterprise to match the requirements of various corporate entities.

3.3 Services engagement overview

You routinely rely on your skills and previous experience as a guide, but there are always several issues that might require some educated guesswork. The section provides information to help you minimize the guesswork that is involved in planning and implementing a solution by providing a framework and time estimates for the major tasks.

A typical services engagement consists of: Building an executive assessment Setting up a demonstration system or proof of technology Analyzing solution tasks Creating a contract or commonly known as statement of work

The representative tasks and the time involved for custom solution execution are included in the following section. Because each customer has a unique set of requirements, the actual set of tasks to accomplish and the time involved can vary. However, this list should help you understand the implementation details, size the solution more accurately for the customer, and ensure a profitable engagement for yourself.

Working with your customers to understand their expectations is important. When you have gathered this data, document the tasks, deliverables, and associated costs in a statement of work. The statement of work acts as your contractual agreement with the customer for the duration of the project.

Chapter 3. Planning for customer engagement 63 Therefore, a detailed and well-defined statement of work is advantageous both to you and to your customer.

A good overall understanding of the solution scope is a crucial prerequisite to successfully selling, developing, and implementing it. As a solution provider, you must understand what is involved in developing such a solution before you can discuss it with your customer and size it for a cost estimate.

3.3.1 Executive assessment

The Executive Assessment is a billable service that you can offer to your prospective clients. It offers a process designed to help you evaluate the business needs of a company that is planning to deploy a solution for e-business. It was created for IBM Business Partners to help you close a higher ratio of opportunities. It has been field-tested in markets all over North America and Europe and has received enthusiastic feedback.

The benefits of using the Executive Assessment in your sales process include: Earning additional service fees More effectively qualifying prospective clients Shortening the sales cycle Streamlining the development process Closing a much higher ratio of potential engagements

This toolset helps you ask the right people the right questions so that you get the information that you need to propose the appropriate solution. This assessment then helps you create a compelling business case that will persuade your prospect to buy the required hardware, software, and services from you in the shortest possible time.

This is a business-case assessment, not a technical assessment, so your audience should be business owners, line-of-business executives, marketing and sales managers, and finally, the IT manager. The business owner or line-of-business executive is likely to be the decision-maker.

For their initial investment, your clients get: A business assessment prepared by a professional (you) A competitive analysis A prototype solution for their review A strategic and tactical proposal for justifying and implementing their solution for e-business

64 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Over the course of the Executive Assessment, you determine who will be involved in the project, what they want to accomplish, when they plan to deploy, what plays a mission-critical role in their business, and how the project will be funded. Armed with this information, a competitive analysis and a prototype solution, you will be able to justify their investment, build perceived value, present your recommendations in a way that is almost irresistible, and successfully close the contract.

Having the ability to recommend the correct course of action to your client has tremendous value. In a market where it is difficult for companies to find qualified consultants, the Executive Assessment and resulting presentation gives you a chance to prove conclusively that you have the right technology and the right people to do the job.

3.3.2 Demonstration system set up

A demonstration system is typically set up in advance to show your customers the attributes of the solution. The demonstration system should be set up with a limited number of machines that are separate from the system that will be used in production.

You can set up Tivoli Access Manager for Enterprise Single Sign-On on a notebook computer that meets the minimum hardware requirements. It is common to set up several VMWare images in advance of the customer visit, which together demonstrate all of the available adapters.

The demonstration system allows your customers to evaluate whether the solution suits their particular needs. The starting point is assumed to be two VMWare images with the operating system installed. The tasks of demonstrating the solution are listed here: Install IMS Server with supported back-end database. Configure IMS Server to use Microsoft Active Directory. Install and configure an AccessAgent for single sign-on. Install and configure AccessStudio for application profiling. Profile up to five applications for enterprise single sign-on. Demonstrate to customer.

3.3.3 Analyze solution tasks

After the customer agrees to use the solution in their environment, you next decide on what effort you must perform to implement it. These estimates are then collected and implemented into a contract or statement of work. We discuss these tasks in detail in 3.4, “Defining solution tasks” on page 67.

Chapter 3. Planning for customer engagement 65 The tasks that we list are our suggested tasks, and we list them in the order that we consider you should run them. You might complete the tasks in a different order or might omit or add tasks depending on the environment in which you implement the solution. The overall success of the tasks and the required time can be influenced by the amount of skill and experience that you or your team have on the solution.

The required general skills include: Working knowledge of the Operating System Solid understanding of client/server communication concepts Understanding of security concepts, such as Secure Socket Layer (SSL), directory authentication, password management and certificate usage Working knowledge of Tivoli Access Manager for Enterprise Single Sign-On

For the detailed task break down, see 3.4, “Defining solution tasks” on page 67.

3.3.4 Create a contract

A contract or statement of work is a binding contractual agreement between you and your customer that defines the service engagement that you must perform and the result that the customer can expect from the engagement. The contract should leave nothing in doubt.

A statement of work has to include the following information: Executive summary of the solution, which is typically a short (less than a page) summary of the solution and its benefit. You must specify any major restriction of the implementation, such as: – The solution is only implemented for finance application servers. – The solution will be implemented in phases. Solution description, which includes the major components and solution building blocks that will be implemented. It should cover conceptual architecture of the solution and solution scope in general. This description is aimed for technical personnel to understand the implementation scope. Assumptions, which lists all the assumptions that is used to prepare the contract and provide task estimation. Any deviation to the assumptions that is used will definitely impact the scope of engagement and must be managed using the change management procedure. Typical changes would include cost changes or scope changes. Business partner responsibilities, which lists all the responsibilities or major tasks that will be performed by you or your team to implement the solution.

66 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Customer responsibilities, which lists all the responsibilities or items that the customer must provide for you or your team to perform the engagement. If you cannot obtain any item in the customer responsibilities, then a change management procedure can be invoked. Staffing estimates, which lists the estimated personnel that must implement the solution. Project schedule and milestones, which shows the major steps, schedule and achievement calendar that can be used to check the project progress. Testing methodology, which lists the test cases to ensure that the project implementation is successful. Deliverables, which provides tangible items that the customer will get at the end of the service engagement, including: – Machine installation – Documentation – Training Completion criteria, which lists the items when provided to the customer, indicates that the engagement is successfully completed. For most of services engagement, this is probably the most delicate to define. Completion criteria can be too general that you will be tied up to provide the customer an on-going support for life. Alternatively, an inadequate completion criteria is often rejected by the customer fearing that you might back away from the engagement in an incomplete state.

We provide a sample statement of work in Appendix C, “Statement of work” on page 523.

3.4 Defining solution tasks

The key to a successful services engagement is to identify the tasks that you must perform and to allocate the necessary time to perform them. This section guides you on the tasks that you might need to perform for a Tivoli Access Manager for Enterprise Single Sign-On solution implementation.

Chapter 3. Planning for customer engagement 67 3.4.1 Deployment time estimation

Your estimates for timing depend largely on the following factors: Number and types of users and desktops The size of the deployment is directly proportional to the number of users and desktops. As the number of users increases, the more dependent the system is on performance tuning. As part of those numbers, consider the number of total roaming desktop sessions potentially active at any one time. Consider how many total workstations will require an AccessAgent to be installed. Number and type of applications The number of applications plays a lesser role in estimating the size of the deployment than does considering the types of applications. As the number of applications increases, so do the design and test phases of the deployment. However, consider the number of applications that will require advanced profiling techniques. Profiling complex applications can increase the overall time of deployment. Advanced deployment requirements Advanced deployment tasks such as incorporating an identity management system for provisioning of Tivoli Access Manager for Enterprise Single Sign-On user credentials, and IMS clustering are two example that increase the overall complexity of the deployment. These and advanced profiling requirements should be factored into the overall time estimations and necessary deployment skills.

3.4.2 General assumptions

Before we describe the deployment tasks, we make the following general assumptions: You have a dedicated customer engineer that is available for the duration of the project. You have identified the pilot environment and defined the test criteria for the solution. In addition, the customer has signed off on the pilot environment and test criteria. You have defined supported versions of platforms and middleware to be used for the deployment. You have set up user IDs and physical access for consultants prior to the kick off meeting.

68 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3.4.3 Deployment tasks

This section lists the required tasks for a Tivoli Access Manager for Enterprise Single Sign-On deployment. You can use these tasks when creating a statement of work. Separate tasks are included for single sign-on and second-factor authentication.

Single sign-on only The tasks for the single sign-on deployment are: Gather requirements and interview the stakeholders. Plan, schedule, and configure Tivoli Access Manager for Enterprise Single Sign-On back end platform components, including directory and database configuration. Develop application profiles for the applications included as part of the statement of work. Deploy Tivoli Access Manager for Enterprise Single Sign-On components to the number of servers, and workstations specified in the statement of work. Define, configure, and manage policies for machines, system, and users. Manage deployment and communication. Provide a deployment summary document. Facilitate knowledge transfer and customer acceptance testing. Set up training for administrators, users, and help desk personnel with level of involvement specified in the statement of work.

Second-factor authentication In addition to the single sign-on tasks stated previously, consider the following points if second-factor authentication is included: Strong authentication hardware and software should be in place before the start of the project. Strong authentication hardware should be fully tested and functioning as intended prior to Tivoli Access Manager for Enterprise Single Sign-On integration. The customer is responsible for biometric, RFID, and physical building badge driver/software installation.

Chapter 3. Planning for customer engagement 69 3.5 Conclusion

Thorough planning of services engagements is one important part of the Tivoli Access Manager for Enterprise Single Sign-On deployment picture. The other major component is the technical design and implementation of the product in a customer environment. In the next sections, we discuss in detail the necessary steps to successfully deploying Tivoli Access Manager for Enterprise Single Sign-On in a customer environment.

70 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Part 2

Part 2 Customer environment

In this part, we discuss how you can use IBM Tivoli Access Manager for Enterprise Single Sign-On (TAM E-SSO) in a particular customer situation.

Chapter 4. Tivoli Austin Airlines, Inc.

To illustrate the concepts that we discuss in this book, let us introduce a scenario about a fictional airline called Tivoli Austin Airlines, Inc. We provide an introduction to the overall structure of Tivoli Austin Airlines, Inc., including its business profile, current IT architecture and infrastructure, as well as its medium-term business vision and objectives.

Note: All names and references for company and other business institutions used in this chapter are fictional. Any match with a real company or institution is coincidental.

Tivoli Austin Airlines (TAA) is a major airline within the continental United States. It has been in business for 12 years and operates over 600 daily flights nationwide. The airline’s motto is “To fly anything, anywhere.”

The following sections describe: The geographic distribution of TAA The company organization Human resources and personnel procedures

Note: The following sections describe company information that is relevant only to a desktop single sign-on solution that uses an existing identity management implementation. The provided details are not intended to be a complete description of the company.

4.1.1 Geographic distribution of TAA

TAA is based in Austin, Texas, with the corporate head office and the central IT data center located near the Austin International Airport. TAA also operates the following regional centers: RW Regional center West (San Francisco) RA Regional center Austin (Austin, within the central IT data center) RE Regional center East (New York)

These regional data centers service the IT needs of the region, such as help desk support and user administration. The corporate IT staff, such as systems programmers and developers, are located at the Regional center Austin.

TAA also runs multiple Customer Service Centers (CSCs) in the major airports that service front-office functions, such as ticketing, member lounges, baggage management, and staff HR systems. The CSCs have no local IT staff, so they contact the regional centers for technical support.

74 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 TAA regional centers that also each have a Customer Service Center are: Austin, TX This is the IT center that houses the core IT infrastructure and staff. It is also the Regional Center for the Austin region and includes the technical support staff for the Central region. San Francisco, CA This site is the Regional Center for the West region. It includes the technical support staff for the West region. New York, NY This site is the Regional Center for the East region. It includes the technical support staff for the East region.

Additional TAA Customer Service Centers are: Seattle, WA This site includes a Customer Service Center, is part of the West region, and is supported by the regional center in San Francisco. Los Angeles, CA This site includes a Customer Service Center, is part of the West region, and is supported by the regional center in San Francisco. Denver, CO This site includes a Customer Service Center, is part of the Austin region, and is supported by the regional center in Austin. St. Louis, MO This site includes a Customer Service Center, is part of the Austin region, and is supported by the regional center in Austin. Detroit, MI This site includes a Customer Service Center, is part of the East region, and is supported by the regional center in New York. Raleigh, NC This site includes a Customer Service Center, is part of the East region, and is supported by the regional center in New York.

Chapter 4. Tivoli Austin Airlines, Inc. 75 Figure 4-1 shows the geographic distribution of TAA in the three regions, West, Central, and East.

New York (Regional Center Seattle East) CSC

Detroit CSC San Francisco (Regional Denver Center West) CSC St Louis CSC

Raleigh CSC

Los Angeles CSC Austin, TX IT Center

Figure 4-1 TAA geographic distribution

TAA’s expansion “To fly anything, anywhere” is the motto for TAA. Because this motto represents the business purpose of the company, TAA has recently opened a new CSC outside of the United States of America in Mexico City, inside the Mexico City International Airport, to provide services to customers from Mexico. These services include online ticket sales and account management for the TAA

76 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 frequent passenger benefits. This expansion effort complies with the business objective of TAA becoming one of the premiere airlines in the world. Figure 4-2 depicts the location of the new CSC.

Mexico City CSC

Figure 4-2 TAA expansion in Mexico City, Mexico

The CSC in Mexico City provides the same services as the U.S. locations, such as servicing front-office functions, ticketing, member lounges, baggage management, and staff HR systems. This CSC has no local IT support staff. The CSC contacts the Regional Center, Austin, for technical support.

Because the official language in Mexico is Spanish, TAA has implemented language support on most IT systems to provide Spanish local support to messaging services, including e-mail, alerts, and self-service Web pages.

Chapter 4. Tivoli Austin Airlines, Inc. 77 4.1.2 Organization of TAA

Figure 4-3 shows that the company is split into four key areas: the three regions and a core services division.

Executive

Region Region Region Core West Austin East Services

Figure 4-3 High-level organization chart

Each of the regions is responsible for the operation of the local services in that region, including customer service, baggage handling, ground services, airport liaison, and staffing. The three regions have the same structure. Figure 4-4 shows the organization chart for the central region (Austin).

Region Austin

Ground IT Customer Services Center

Airport Tech Baggage Catering Cleaning HelpDesk HR Liaison Support

CSC01 CSC02 CSC03 (Denver) (StLouis) (Mexico City)

Figure 4-4 Central region organization chart

78 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 The core services division acts on a company-wide scale. It is split into three departments: Sales, Support, and Flights. Figure 4-5 shows the teams for each of these departments.

Core Services

Sales Support Flights

Central IT TAAMiles Marketing HR Accts Crews Maint. DataCenter

Systems HelpDesk IT Dev

Figure 4-5 Core services organization chart

Each team within a department has a unique business code identifying the team and its location.

4.1.3 HR and personnel procedures

Personnel are managed locally within each region for the regions, and by the Core Services HR team in Austin for all Core Services staff. The following procedures apply to personnel management: When a new employee joins the company, the employee is added to the HR system. The HR system invokes the Tivoli Identity Manager workflow to create accounts on the Tivoli Identity Manager server for each service the employee is allowed to access. Tivoli Identity Manager then provisions the accounts automatically. The employee is given an e-mail account and initial password that allows the employee to find the e-mail that includes the login information for the other accounts, as needed. When an employee requires additional access to resources, that employee goes to the appropriate HR Web site and requests access. This action kicks off a Tivoli Identity Manager workflow that results in the creation of the requested account as long as the approvals are met.

Chapter 4. Tivoli Austin Airlines, Inc. 79 When an employee forgets a Windows password or has an account locked as a result of invalid passwords, the employee goes to a kiosk to use the Web browser and accesses the Tivoli Identity Manager self-serve password reset functionality. When an employee leaves the company, the employee is removed from HR, and Tivoli Identity Manager automatically deletes all user accounts that are associated with that employee.

4.2 Current IT architecture

In this section, we describe the current IT environment at TAA. We discuss: Overview of the TAA network Recently implemented e-business application Security infrastructure deployed for the e-business application Secured e-business initiative architecture User administration issues

4.2.1 Overview of the TAA network

TAA’s central IT data center has implemented a back-end datastore that is based on DB2 running on an IBM System i®. TAA uses an MQ Series infrastructure for asynchronous transactions between the central IT data center, the CSCs, and the regional data centers.

80 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 4-6 shows the high-level network diagrams of TAA’s network.

New York (Regional Center Seattle East) CSC

T1 (1.54Mbps) T1 (1.54Mbps) Detroit CSC San Francisco (Regional Denver Center West) CSC T1 (1.54Mbps) St Louis CSC T3 (45Mbps) Raleigh CSC T3 (45Mbps) T1 (1.54Mbps) T1 (1.54Mbps) T1 (1.54Mbps)

Los Angeles CSC Internet Austin, TX IT Center T3 (45Mbps)

Figure 4-6 The TAA network

Chapter 4. Tivoli Austin Airlines, Inc. 81 Figure 4-7 shows a high-level network diagram for the CSC in Mexico City.

to Central

T1 (1.54Mbps)

Mexico City CSC

Figure 4-7 Mexico City CSC connectivity diagram

82 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 4-8 shows the location of firewalls. All external access to the TAA network is channeled through the firewalls and routers in Austin. There are also firewalls between the regional centers and the IT data center, as well as between the regional centers and the CSCs.

Central IT Center Central IT Center IBM System i (DB2,MQSeries)

Web IBM Application Server F I R E Customer W Access Tivoli A Manager Identity Linux L Policy Manager L Server Servers

F LDAP I Replica R LDAP WebSEAL F E Master I W R A E L W F I R E W A L L L A L Regional Center , West, Central, East L Production DMZ

Linux Web LDAP Application WebSEAL Replica Server

F I R E W A L L Internet Internet DMZ CSC site Windows Active application data flow Directory Domain access control flow Intranet Controler

Figure 4-8 TAA architecture

All T1 and T3 links are leased services. TAA relies on the service provider to ensure the necessary uptime, as agreed in the service-level agreement. Therefore, the diagrams in Figure 4-6 on page 81 and Figure 4-7 on page 82 are logical and do not show redundant or standby links or triangulation of the network. TAA relies on the service provider for this.

TAA uses Lotus Notes as its e-mail system, which is available in the CSC.

Chapter 4. Tivoli Austin Airlines, Inc. 83 4.2.2 TAA’s e-business initiative

Several years ago, TAA embarked on a long-range e-business initiative to reign in IT support costs, improve user experience, and increase attract new customers. At this point, TAA had implemented the following solutions: Most of the business applications have been migrated to a distributed IBM WebSphere® Application Server implementation that is based on Linux® systems, which is located in every regional center. All these systems communicate with the back-end database through the high-speed network. IBM Tivoli Access Manager for e-business has consolidated user accounts for Web applications into one user repository. In addition, it provided an authorization infrastructure to control access to many different kinds of enterprise applications. The implementation of Tivoli Identity Manager brought tremendous efficiencies to TAA’s provisioning processes. It is able to provision to operating systems (for native MQ), IBM Tivoli Access Manager, the Active Directory server, as well as the e-mail system based on Lotus Notes. It reduced the cost of managing identities stored in different directories and simplified password management.

The two applications that have not yet been implemented using the WebSphere model are the Gate Terminal Application and the TicketMeister: The Gate Terminal Application runs on a Windows Active Directory based network on Windows terminals in each CSC (that is, the CSC employees cannot use a browser to access this application). It uses MQ Series calls to check the appropriate passenger data. Although a risk assessment has highlighted this MQ area as being in need of some work, particularly because messages can sit on queues in an unencrypted form, TAA decided that other risks were of a higher priority. The Gate Terminal Application requires user authentication to access its functions. The Gate Terminal Application uses its own authentication mechanism and user repository. The TicketMeister host-based application runs on an IBM System i environment, which must be accessed using a terminal emulator. Users must log in to TicketMeister with their System i account.

4.2.3 Security infrastructure for the e-business initiative

In the past, TAA’s application system experienced many unauthorized access attempts to critical business data. Recently, TAA deployed a security solution that implements a centralized access control mechanism enforcing authentication and authorization of users before they actually access the applications and critical data through their Web browser. This solution is implemented based on

84 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 IBM Tivoli Access Manager for e-business with the access control point being the WebSEAL reverse Web proxy.

Note: In this book, we omit any detailed description of the IBM Tivoli Access Manager for e-business and Tivoli Identity Manager solutions, because our focus is on the desktop single sign-on system. For further details, consult the following IBM Redbooks publications: Enterprise Security Architecture Using IBM Tivoli Security Solutions, SG24-6014 Enterprise Business Portals with IBM Tivoli Access Manager, SG24-6556 Enterprise Business Portals II with IBM Tivoli Access Manager, SG24-6885 Identity Management Design Guide with IBM Tivoli Identity Manager, SG24-6996

A typical user access with WebSEAL controls looks similar to the following process: 1. A user in a CSC logs on to the Windows domain specifying a Windows user ID and password. 2. The user starts the Web browser and accesses a login page for a specific application. The user logs in with an application user ID and password. A credential is used for access control by WebSEAL in the regional centers the CSC belongs to. 3. WebSEAL accepts or denies the login. WebSEAL works as a reverse proxy between the user’s Web browser and the application hosting Web server, controlling whether a user can access the requested resource or not. 4. WebSEAL’s access control decisions are based on the information held within the Access Manager Policy Server and the relevant LDAP repository. The Policy Server stores the access control information used by WebSEAL and distributes access control information database replicas to all defined WebSEAL servers while the LDAP server has the user credential information created and used by Access Manager. The Policy Server is located in the Austin site, but WebSEAL and LDAP replica servers are made available in each regional center. The LDAP server in Austin is the master server, which can be modified; the LDAP replica servers are read-only.

Only the Web applications can be secured by WebSEAL using Web user accounts, but there are other types of accounts necessary to run standard operations, such as the Gate Terminal Application and TicketMeister. These accounts have their own user store and hence users must remember these login accounts. That is why TAA puts the employees under an obligation to follow

Chapter 4. Tivoli Austin Airlines, Inc. 85 additional security policies to strengthen the levels of security, such as a periodical password change and other password policies for all types of accounts.

Tivoli Identity Manager provisions new users to applications, synchronizes all application passwords with the user’s Windows password and allows users to manage their personal accounts on the Web.

A typical user access to the Gate Terminal Application or TicketMeister looks similar to the following process: 1. A user in a CSC logs on to the Windows domain specifying a Windows user ID and password. 2. The user starts the application. For Gate Terminal Application, the user starts the Windows application and is prompted to login. For TicketMeister, the user starts the terminal emulator, connects to the System i, and is prompted to login. 3. After logging in, the user can use the application.

4.2.4 Secured e-business initiative architecture

Figure 4-8 on page 83 shows the TAA architecture. Customers can access only Internet-facing applications through the WebSEAL server, which exclusively secures the Web applications. WebSEAL offers those users single sign-on access to all of the services offered by TAA to its customers.

Tivoli Identity Manager provisions new accounts into the IBM System i, IBM Tivoli Access Manager Policy Server, Linux machines, and Microsoft Active Directory Domain Controllers at each CSC.

Intranet users log in to their workstations with their Active Directory account and use WebSEAL to access the Web applications. However, intranet users must also access Lotus Notes e-mail and TicketMeister, which are Windows-based and terminal-based applications, respectively.

This secure implementation helps build and maintain a positive company image, but there are other emerging issues, particularly in the area of password management.

4.2.5 User account management and emerging issues

Emerging issues are related to user administration and password management. Before we describe the emerging issues in detail, we give an overview of the current user and password management.

86 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Current user and password management TAA uses many different platforms with user accounts in their system. The CSC staff have their accounts in a Windows domain, the Tivoli Access Manager LDAP directory (for WebSEAL-controlled Web application access), and the Gate Terminal Application. The regional center administrators have their accounts on Linux systems, the Windows domains in their region, the Tivoli Access Manager LDAP directory, and on the TicketMeister System i-based application. Managing these accounts has been greatly simplified since the implementation of the Tivoli Identity Manager solution.

TAA has configured Tivoli Identity Manager to control the following user account management features: Provisions new application accounts (Windows, Tivoli Access Manager, Lotus Notes, and others) Provides a self-service Web page that allows the user to change their password and modify their account information. Allows the user to reset a forgotten password using a series of challenge and response questions

User experience has been positive, and TAA has seen a reduction in their IT support costs.

Emerging issues Despite Tivoli Identity Manager’s positive impact on TAA’s user community and the IT department’s bottom line, TAA has found that there are still inefficiencies in the system as well as new security policies to consider. The following issues have been identified: The CIO’s office has mandated that user passwords on different systems must be different. The reasoning is that if the single password is compromised, then a hacker could access all of the applications from anywhere in the network. Users still complain about having to log in to multiple applications throughout the course of a day’s work. If a user forgets a Windows password, the user cannot log into the computer and must locate another computer to do the self-service password reset offered by Tivoli Identity Manager. At the very least, finding a computer to use for this purpose is a distraction from work.

Chapter 4. Tivoli Austin Airlines, Inc. 87 TAA mobile employees such as pilots and stewardesses often find themselves in airport employee lounges, where they would like to check e-mail while waiting for the next flight. The only way to check their corporate e-mail is to have their own notebook computer with Lotus Notes installed. Most do not carry notebook computers and, thus, cannot check their e-mail. In general, the CIO office is not content with the security level that can be achieved with username/password authentication and wants to implement strong authentication for all of the employees over the next years.

TAA believes that these issues are significant enough to warrant a new IT solution to address them. In particular, the CIO mandate would force users to have to manage their various passwords again and the IT department does not want to go back to the point where they had to support password resets on all of the applications.

TAA has now decided to implement an additional security management solution focusing on password management. Based on its positive experience with Tivoli Identity Manager, TAA has decided to go with Tivoli Access Manager for Enterprise Single Sign-On solution.

4.3 Corporate business vision and objectives

To increase the employee’s productivity, meet requirements of the CIO’s office, and reduce IT support costs, password management must become transparent to the user and to the IT support team.

The TAA mid-term vision is as follows: TAA wants to deploy a corporate wide user password management system to be operated efficiently and correctly, following the corporate security policies. To lessen administrative cost, automating management operations where possible is desirable. The new system should integrate into their existing user and identity management system and should be implemented with minimum development cost, making full use of the existing resources. The new system should support strong authentication as an alternative to classic username/password authentication to tighten the access security when using corporate desktop computers.

88 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 4.4 Project layout and implementation phases Based on the corporate business vision, TAA decided to implement the new solution in four phases. Each phase will be rolled out in four stages: development, test, pilot, and production.

The phases are: 1. Tivoli Access Manager for Enterprise Single Sign-On base setup and provisioning system integration The first phase focuses on addressing the password management issue raised by the CIO’s office. The objective is to get Tivoli Access Manager for Enterprise Single Sign-On deployed to the employee’s client machines and have it take over the password management and sign-on operations. 2. Password self-service The second phase addresses the password-reset issue by allowing users to reset forgotten desktop passwords from their own workstation. 3. Shared desktop The third phase enables the mobile TAA employees to access their Lotus Notes e-mail from shared machines that are located in airport employee lounges. 4. Two-factor authentication The fourth phase deals with the rollout of USB token to enforce strong authentication against the employees desktops.

Chapter 4. Tivoli Austin Airlines, Inc. 89 4.5 Conclusion

Like many other large, dispersed companies, TAA has been battling the identity management and single sign-on problem for years. In the last few years, TAA’s e-business initiative has taken a systematic approach to addressing these problems. This approach resulted in the following phased progression: Phase 1: Deployment of Tivoli Access Manager for e-business consolidated user accounts for Web applications into one user repository. In addition, it provided an authorization infrastructure to control access to many different kinds of enterprise applications. Phase 2: Deployment of Tivoli Identity Manager reduced the cost of managing identities stored in different directories and simplified password management. Phase 3: With the deployment of Tivoli Access Manager for Enterprise Single Sign-On, TAA will have addressed the desktop single sign-on problem with a solution that takes advantage of the Tivoli Identity Manager infrastructure. Password management will utilize self-service components from the user’s own desktop. Mobile employees will have access to secured corporate resources. Strong authentication can be implemented over time. IT support costs will be reduced, passwords will be more secure, and user satisfaction will increase.

90 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5

Chapter 5. Enterprise single sign-on solution design

In this chapter, we describe the business requirements and functional requirements for an enterprise single sign-on foundation based on Tivoli Access Manager for Enterprise Single Sign-On (TAM E-SSO).

Most implementations are done in a multiple phases. The content of each phase is decided by analyzing the priorities of the business requirement and mapping these through their functional requirements to Tivoli Access Manager for Enterprise Single Sign-On’s capabilities. The earlier phases are dedicated to satisfying those requirements that are associated with high-priority business requirements and low-cost implementation.

As described in Chapter 4, “Tivoli Austin Airlines, Inc.” on page 73, Tivoli Austin Airlines, Inc. (TAA) has implemented Tivoli Access Manager for e-business to provide single sign-on to Web applications and enterprise application authorization. TAA also implemented Tivoli Identity Manager to automate user account provisioning and to provide self-service account management to its employees. However, employees still must log in to multiple accounts over the course of a work day, and the CIO now requires that users choose different passwords for different user registries. This requirement is not enforced but comes as a strong recommendation to prevent exposing multiple applications by compromising one password.

The following business requirements (which are numbered here for subsequent reference purposes) are derived from the business scenarios that we outline in Chapter 4, “Tivoli Austin Airlines, Inc.” on page 73: 1. Reduce the workload on employees with respect to password management. The CIO would like to see improvements in the following areas: – The time and effort required by employees who have to log into many different applications over the course of a work day. – The time spent managing password resets, especially the Windows desktop password. 2. Corporate security policy should be enforced for all user accounts and their attributes, access rights, and password rules. In particular, the new policy that passwords in different registries should be different must be addressed. 3. Keep the labor costs of administering users and their accounts as low as or lower than the existing Tivoli Identity Manager solution provides. 4. The solution must be easy to deploy and integrate with the existing identity manager infrastructure. 5. Mobile employees must be able to access their corporate applications from shared desktops available at airport employee lounges and because of increased security requirements should use strong authentication mechanisms like two-factor authentication 6. User and administrative historical data, such as application logins and password resets respectively, must be kept for auditing purposes.

92 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5.2 Functional requirements

We extract functional requirements by mapping business requirements to their underlying reasons. Our functional requirements then tie these reasons for a business requirement to the Tivoli Access Manager for Enterprise Single Sign-On capability that fulfill that business requirement.

Let us examine every business requirement and search for reasons and the functional requirements: Functional requirements that are associated with business requirement #1: Reduce the workload on employees with respect to password management. Although Tivoli Identity Manager can manage all the user accounts and even keep all the passwords synchronized, employees must still log in to each application. Also, the new security policy of prohibiting the same password on different user repositories means Tivoli Identity Manager will no longer synchronize the passwords. Therefore, the employees have to remember the passwords for the different registries. To address these concerns the new system should address the requirements that are listed in Table 5-1.

Table 5-1 Functional requirements Requirement Description

A Employees have to memorize only their desktop password.

B Employee is logged in to all applications that require authentication automatically.

C Employees can reset their own desktop password using the self-service functions.

Functional requirements that are associated with business requirement #2: Corporate security policy should be enforced for all user accounts. Each desktop application with user accounts stores the user passwords in its own way, and thus, has its own set of supported password policies. Several of these policies might not meet corporate standards and, even if all applications can meet the standards, managing the policies on all the various applications becomes expensive as the number of applications grow.

Chapter 5. Enterprise single sign-on solution design 93 TAA requires password policy to be managed easily and securely in an enterprise setting, as listed in Table 5-2. Table 5-2 Functional requirements continued Requirement Description

D Enforce corporate password policies, even for applications that do not enforce it themselves.

E User credentials are encrypted in any persistent storage location.

F Passwords stored in different registries are different.

G Maintain user accounts and their attributes, access rights, and password rules from a central location.

Functional requirements that are associated with business requirement #3: Keep the administrative labor costs low. Password management accounts for a large portion of the IT support costs. System administrators must make sure various registries conform to corporate security policies and users consume help desk resources with forgotten password reports. The solution must reduce password management costs according to the requirements as listed in Table 5-3. Table 5-3 Functional requirements continued Requirement Description

G Maintain user accounts and their attributes, access rights, and password rules from a central location.

H Application passwords are generated and managed automatically.

I Employees can reset their own desktop password when they are in the office or even when they are travelling and have no access to the corporate IT network.

Functional requirements that are associated with business requirement #4: The solution must be easy to deploy and to integrate with the existing identity manager infrastructure.

94 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 TAA has extensive experience with enterprise software distribution and management. TAA wants to use its existing provisioning tools and procedures to keep the deployment simple and familiar, as listed in the requirements in Table 5-4. Table 5-4 Functional requirements continued Requirement Description

G Maintain user accounts and their attributes, access rights, and password rules from a central location.

J Client software is distributed using TAA’s software distribution mechanisms.

K Credentials and application templates are provisioned by the existing Tivoli Identity Manager system.

Functional requirements that are associated with business requirement #5: Mobile employees must be able to access their corporate applications from shared desktops available at airport offices and because of increased security requirements should use strong authentication mechanisms like two-factor authentication. TAA’s mobile employees require access to the corporate applications and might not always have a notebook computer with them. They use machines that are located in the airports and other locations to access the applications and must be presented with the same level of service as employees accessing applications from the internal network, as listed in Table 5-5. Table 5-5 Functional requirements continued Requirement Description

L Shared desktop computers located in airport employee lounges support single sign-on to corporate applications.

M Employees must be able to use two-factor authentication.

Chapter 5. Enterprise single sign-on solution design 95 Functional requirements that are associated with business requirement #6: Availability of audit information. TAA uses historical data to evaluate the effectiveness of security solutions and to gather usage statistics. Such data can also be used to troubleshoot problems. TAA must be able to access this data quickly when necessary, as listed in Table 5-6. Table 5-6 Functional requirements continued Requirement Description

M Audit logs from SSO clients must be consolidated on a central system.

5.3 Design approach

Here, we consider how the security design objectives can be realized using Tivoli Access Manager for Enterprise Single Sign-On. Our goal is to produce a plan that includes a set of smaller implementation steps where the end result satisfies the functional requirements. and therefore, also satisfies the original business requirements.

Although business and functional requirements are the main parts of the security design objectives, we also have to consider other non-functional requirements and constraints. These can include objectives that are necessary to meet general business requirements, or practical constraints on constructing security sub-systems. Tivoli Access Manager for Enterprise Single Sign-On implementations often involve non-functional requirements relating to: Backup and recovery Performance and capacity Change management Budget and staffing

Because we focus on the security architecture of single sign-on with Tivoli Access Manager for Enterprise Single Sign-On software in this book, we do not look in detail at all of these non-functional requirements. The steps involved in producing an implementation plan are: 1. Prioritize the requirements. 2. Map the requirements to Tivoli Access Manager for Enterprise Single Sign-On features. 3. Define the tasks that are involved in using those features to satisfy the requirements, and estimate the effort that is required for each task.

96 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 After mapping the requirements to Tivoli Access Manager for Enterprise Single Sign-On features and creating a list of implementation tasks, a certain task might possibly require a longer implementation time. It is typical to have Tivoli Access Manager for Enterprise Single Sign-On deployed in a one-week project. However, also common is to have a custom adapter built from scratch with a technical complexity that can be translated to a development phase of several weeks for just one adapter. Even if this situation occurs, it is possible to have Tivoli Access Manager for Enterprise Single Sign-On in production, helping the company to meet its goals, while you are executing lower priority and more difficult tasks.

5.4 Implementation overview

This section applies the design approach that we describe in 5.3, “Design approach” on page 96 to the specific requirements of TAA. We do not describe the details of the implementation tasks here. Instead, we describe them in the following technical implementation chapters of this book: Chapter 6, “Base installation and configuration” on page 101 Chapter 7, “Password self-services implementation” on page 185 Chapter 8, “Shared desktop implementation” on page 217 Chapter 9, “Tivoli Identity Manager implementation” on page 229 Chapter 10, “Strong authentication” on page 391

5.4.1 About project phases and deployment stages

Based on the priorities of its business requirements and the levels of effort of the different implementation tasks, TAA decided to split the project into four logical phases that will be executed sequentially, described in 5.4.2, “Project phases” on page 98. Each phase will be deployed in four stages, described in this section.

Deployment stages Most companies use a staged approach to deploying new solutions into their IT infrastructure. We describe four stages here, although some companies might have more and might use different terminology for the stage names. The deployment stages are: 1. Development The development stage is the stage where the deployment procedures for the current stage are created. This stage involves installing and configuring the product based on the goals of the phase. Procedures are automated when possible or documented.

Chapter 5. Enterprise single sign-on solution design 97 2. Test During the test stage, the test group receives the software and procedures from the development group and executes the documented deployment procedures. The test group reports any issues that it encounters to the development group, who updates the procedures. This cycle continues until the test team is satisfied with the reliability of the deployment procedures. 3. Pilot The pilot stage involves deploying the solution to a relatively small number of users to address any issues in the configuration and deployment procedures. The software is deployed into a production environment and, thus, is typically performed by a group other than the test group. Solutions involving software distribution to clients can be particularly costly to redeploy to a large number of seats. So, the pilot stage is important in those types of solutions. This stage can flush out issues that are not discovered during the test stage. 4. Production In the production stage, deployment takes place when the pilot phase has proven the viability of the solution. The same procedures used in the pilot phase are used in the production deployment. However, production deployment includes the entire scope of users of the solution.

5.4.2 Project phases

Finally, let us take a brief look at the five separate project phases.

Phase 1: Base setup and provisioning system integration The first phase addresses the password management issue that was raised by the CIO’s office. The objective is to get Tivoli Access Manager for Enterprise Single Sign-On deployed to the employee’s client machines and free the employees from having to log in to the following applications: Windows application single sign-on to Lotus Notes Single sign-on to a Web application Host terminal emulator single sign-on to the TicketMeister application

Preceding the deployment, employees require education about the upcoming changes to their account management.

Phase 2: Password self-service The second phase addresses the password reset issue by allowing users to reset their forgotten desktop password from their own workstation.

98 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 The Tivoli Access Manager for Enterprise Single Sign-On password self-service function will be configured in this phase. Employees need to be educated on how to reset a password using this feature.

Phase 3: Shared desktop The third phase enables the mobile TAA employees to access their Lotus Notes e-mail from shared desktop machines that are located in airport employee lounges.

The Tivoli Access Manager for Enterprise Single Sign-On shared desktop feature is configured in this phase. Mobile employees need education on how to use the shared desktop.

Phase 4: Tivoli Identity Manager integration The existing provisioning system based on IBM Tivoli Identity Manager (ITIM) is enabled to provision and manage user accounts including Tivoli Access Manager for Enterprise Single Sign-On.

Phase 5: Two-factor authentication The last phase deals with the implementation of two-factor authentication. Employees can use USB token to authenticate themselves against the desktop instead of using user name and password.

Tivoli Access Manager for Enterprise Single Sign-On is configured to support a USB token key. Employees should be trained on how to enroll and use a USB token key.

5.5 Conclusion

This concludes the discussion about the business and functional requirements for TAA as well as the design approach. With the implementation overview finished we proceed to the next chapters that include the actual implementation.

Chapter 5. Enterprise single sign-on solution design 99 100 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 6

Chapter 6. Base installation and configuration

In this chapter, we describe the technical implementation of the Tivoli Access Manager for Enterprise Single Sign-On (TAM E-SSO) base environment. First, we explain how to install the necessary components. Then, we discuss how to deploy the enterprise single sign-on setup. Finally, we tell you how to manage and maintain the deployed solution.

In this section, we focus on the concepts of a base level implementation of Tivoli Access Manager for Enterprise Single Sign-On, and the components you must be aware of when designing the deployment architecture. Consider the existing infrastructure at Tivoli Austin Airlines (TAA), described in 4.2, “Current IT architecture” on page 80.

The following components are required for a base-level implementation of Tivoli Access Manager for Enterprise Single Sign-On: Central user repository/directory The central user repository can be one of several supported repositories, including Active Directory, Novell®, and generic LDAP. The central user repository must be in place prior to installing any Tivoli Access Manager for Enterprise Single Sign-On components. In the TAA environment, the central user repository is Active Directory. IMS Server The IMS Server is installed on either an existing or dedicated server. The IMS Server is a Java-based application that runs on its own instance of Apache Tomcat, which is automatically installed with the IMS Server software. IMS database The IMS database stores all of the Tivoli Access Manager for Enterprise Single Sign-On configuration, policy, and user data. This database can be created on an existing database server, or it can be installed on the same system where the IMS Server resides. Supported databases include IBM DB2, Microsoft SQL, and Oracle. AccessAgent An AccessAgent is installed on each client system, Windows Terminal Server, and Citrix MetaFrame server that is to be managed by Tivoli Access Manager for Enterprise Single Sign-On. AccessStudio AccessStudio is an administrative tool used to create AccessProfiles. It only has to be installed on one workstation, normally on that of one or more IMS administrators.

102 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 6.1.1 System requirements

The Tivoli Access Manager for Enterprise Single Sign-On base components can be integrated onto existing servers as long as the servers have sufficient resources.

For specific software and system requirements, refer to the IBM Tivoli Access Manager for Enterprise Single Sign-On Deployment Guide Version 8.0, SC23-9952.

6.1.2 Deployment architecture

The deployment architecture for a Tivoli Access Manager for Enterprise Single Sign-On-based installation is straightforward. It consists of a client-side application (AccessAgent) communicating with a central server-side application (IMS Server). Deployments can become more complex with the integration of optional advanced components like identity management software and external data sources. Even so, the client-server model remains the same for the core Tivoli Access Manager for Enterprise Single Sign-On components.

Client-side components Tivoli Access Manager for Enterprise Single Sign-On consists of two client-side applications: AccessAgent and AccessStudio.

The AccessAgent is installed on user workstations and Microsoft Terminal or Citrix MetaFrame servers. Its main function is the recognition and interception of user authentication and change password dialogs. It acts on these dialogs for authentication and password change automatically depending on how policies are configured. The AccessAgent is comprised of several underlying components that also perform tasks such as: Data synchronization with the IMS Server for updating policies and profiles, and retrieving user Wallets. Securely storing credentials in the Wallet on the local workstation.

The underlying components and their architecture are discussed in detail in 2.2.1, “AccessAgent” on page 14.

AccessStudio is a tool that allows administrators to configure or create AccessProfiles, profiles that facilitate the automatic log on, log off, and password change for applications that require authentication. AccessStudio must be installed only on one administrative workstation.

Chapter 6. Base installation and configuration 103 Server-side components The server-side components consist of the IMS Server and the IMS database.

The IMS Server is the central point of administration for user identities, AccessProfiles, authentication policies, and authentication factors. Administration is performed through a Web interface called AccessAdmin where administrators can create and modify policies, and manage users.

The IMS database stores all Tivoli Access Manager for Enterprise Single Sign-On configuration and user objects such as policy templates, user credentials, authentication services, and AccessProfiles. How user credentials are securely stored on the database and in local user Wallets is described in detail in 2.4.1, “Securing Wallets” on page 42.

The AccessAgent synchronizes with the IMS Server on a regular interval to retrieve policy updates.

Target applications The target applications can typically be grouped into the following categories: Windows client/server Typical application with a client component that is locally installed on the user’s workstation. The client component requests user authentication and communicates with an application component running on a back-end server, for example Lotus Notes. Java-based The authentication dialog for this type of application was developed in Java and is sent to and executed on the user’s workstation at application launch time. Web-based Applications running on a Web server that requests users to authenticate from a Web browser. Terminal emulators Terminal emulators are installed and executed locally on client workstations and are configured to communicate with back-end applications emulating a specific terminal type. Examples are 3270 terminal emulators to access host-based applications, Telnet to access UNIX systems, and so on.

104 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 In the first phase of our scenario, TAA has decided to implement support for the following applications: Lotus Notes client Web application for user self-service AS/400® terminal emulator

6.2 Installing and configuring base components

In this section, we discuss the installation and initial configuration of Tivoli Access Manager for Enterprise Single Sign-On. The steps involved in installing and configuring the base components include: 1. Installing and configuring a database for use by the IMS Server, and adding the necessary administrative users for the database and initial IMS Server configuration. 2. Installing and performing an initial configuration of the IMS Server. 3. Installing and configuring AccessStudio. 4. Using AccessStudio to create AccessProfiles. 5. Configuring policies to enable single-sign on capabilities for TAA employees. 6. Installing and configuring the AccessAgent on a client workstation. 7. Users then log in and create their Tivoli Access Manager for Enterprise Single Sign-On accounts and begin the single sign-on process for the configured applications.

6.2.1 Create administrative users

To prepare for our base component installation and configuration, two administrative users must be created: Database administrator The IMS Server will perform all database operations on behalf of the user-defined as the database administrator. Active Directory lookup user Tivoli Access Manager for Enterprise Single Sign-On uses the lookup-user to retrieve user attributes from the Active Directory enterprise repository. The user defined as the lookup-user should not be the primary user account for any employee, because password change or account lockout can cause problems with authentication for all users. A good practice is to create a system account specifically for the purpose of acting as the lookup-user.

Chapter 6. Base installation and configuration 105 Important: Remember that if the lookup-user’s password must change, then the IMS administrator must be aware of this and set the new password in the IMS Server configuration.

6.2.2 Install the database software

In this section, we perform a database software installation and configuration of a database instance for use by the IMS Server. We install and configure IBM DB2 9.5, but if you already have a supported version of DB2 installed, skip to 6.2.3, “Create the IMS database” on page 120.

Tivoli Access Manager for Enterprise Single Sign-On supports several database platforms; if you want to use one of the other supported platforms, follow the installation instructions provided by the vendor.

To install the IBM DB2 server software: 1. Locate the DB2 installation executable and double-click it. 2. When prompted with the DB2 Setup Launchpad, read the note in the section named Install a Product and then click Install New, as shown in Figure 6-1.

Figure 6-1 Install New DB2 Server

106 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. Read the terms of the License agreement (Figure 6-2), and if you agree to them, select I accept the terms in the license agreement, and click Next.

Figure 6-2 DB2 License Agreement

Chapter 6. Base installation and configuration 107 4. For the installation type (Figure 6-3), select Typical and click Next.

Figure 6-3 Select the DB2 installation type

108 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. The dialog, shown in Figure 6-4, gives you the choice to either install DB2, only create a response file, or both. We choose to do both by selecting Install DB2 on this computer and save my settings to a response file. Unless you are sure you will not need a response file later, having one created for you just in case is the safest choice.

Figure 6-4 Select the installation, response file creation, or both

Chapter 6. Base installation and configuration 109 6. As shown in Figure 6-5, choose the DB2 installation directory and click Next.

Figure 6-5 Choose the installation directory

110 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 7. Enter the user information for the DB2 Administration Server (DAS), as shown in Figure 6-6. This is the account that the DAS will use to start up and perform operations. For simplicity’s sake, we use the same user we created for administering the IMS database.

Figure 6-6 Set user information for the DB2 Administration Server

Chapter 6. Base installation and configuration 111 8. Select Create the default DB2 instance as shown in Figure 6-7.

Figure 6-7 Create the default DB2 instance

112 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 9. Select Single partition instance and click Next, as shown in Figure 6-8.

Figure 6-8 Set up partitioning options for the default DB2 instance

Chapter 6. Base installation and configuration 113 10.Prepare the DB2 Tools Catalog so that database backups can be scheduled using the Task Center and scheduler. We select the Prepare the DB2 tools catalog check box and use the drop-down menu to select the instance we created in Step 8 on page 112. Retain the default values for the Database and Schema fields as shown in Figure 6-9.

Figure 6-9 Prepare the DB2 tools catalog

114 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 11.Next, we have to select whether to set up SMTP notifications. We choose not to enable notifications in this scenario, however, if you require database notifications you may do so as part of the post install configuration. For now, clear the check box Set up your DB2 server to send notifications, and click Next as shown in Figure 6-10.

Figure 6-10 Set up notifications

Chapter 6. Base installation and configuration 115 12.Next, we set up security for the DB2 objects. Select the check box to Enable operating system security for the DB2 objects. Retain the default values for the Group Name fields, and select Use local group from the Domain drop-down menu as shown in Figure 6-11. Click Next to continue.

Figure 6-11 Enable operating system security for DB2 objects

116 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 13.Review the installation parameters at the final window (Figure 6-12) and click Finish to begin the installation.

Figure 6-12 Start copying installation files

14.After installation completes, the Setup is Complete window opens. Click Next, and at the next window that opens (Install Additional Products), click Finish.

Chapter 6. Base installation and configuration 117 15.At the next window, you are presented with the Welcome to First Steps (for DB2), as shown in Figure 6-13). Select Exit.

Figure 6-13 DB2 First steps

16.When the DB2 installation wizard initialized, you should have seen a window open in the background, as shown below in Figure 6-14. Now that the installation is complete, click Next and then Finish.

Figure 6-14 After installation

118 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 17.Now that DB2 has been installed, you must apply a DB2 license. For instructions, refer to the Applying DB2 Licenses section of the DB2 9.5 Information Center, found at: http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.d b2.luw.qb.server.doc/doc/t0023608.html 18.Ensure that the database administrator account is a member of the proper administrative groups: Administrators and DB2ADMNS as depicted in Figure 6-15. You can check this by going to Start → Administrative Tools → Active Directory Users and Computers, and double-clicking on the database administrator account that you created in section 6.2.1, “Create administrative users” on page 105.

Figure 6-15 Check DB2 administrator group membership

Chapter 6. Base installation and configuration 119 6.2.3 Create the IMS database

Now that we have completed the DB2 installation, our next task is to create the database for use by the IMS Server. This database serves as the central repository for all Tivoli Access Manager for Enterprise Single Sign-On system and user data. To create the database: 1. Navigate to the DB2 Control Center by selecting Start → Programs → IBM DB2 General Administration Tools → DB2 Control Center. 2. Right-click All Databases, and select Create Database → Standard, as shown in Figure 6-16.

Figure 6-16 Create a standard database

This brings up the Create Database Wizard. as shown in Figure 6-17 on page 121.

120 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. Enter your Database name, Default path, and Alias. Select 8 K from the Default bufferpool and table space size drop-down menu, as shown in Figure 6-17. Click Next to continue.

Figure 6-17 Enter the database information and select 8k for page size

Chapter 6. Base installation and configuration 121 4. Specify where on the disk you want DB2 to store the data. Ensure that sufficient free space exists for the specified drive (or drives). In this example, we choose the default location of C:\. Select the Use the database path as the storage path check box and click Next to continue (Figure 6-18).

Figure 6-18 Specify where to store your data

122 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. Next, we specify the locale and code set parameters for the database. As shown in Figure 6-19, specify US for the Territory and select UTF-8 for the Code set. Click Finish to create the database.

Figure 6-19 Specify the locale (US) and Code set (UTF-8)

Note: If you want to add the database by using the DB2 command line, use the following command: CREATE DATABASE imsdb AUTOMATIC STORAGE YES ON 'C:\' DBPATH ON 'C:\' USING CODESET UTF-8 TERRITORY US COLLATE USING SYSTEM PAGESIZE 4096;

Chapter 6. Base installation and configuration 123 6. Next, we ensure that the database administrator is added to the DB Users group of the IMS database itself. Open the DB2 Control Center and expand the All Databases folder. Expand the IMS database you created and expand the User and Group Objects folder. Right-click the DB Users folder and select Add, as shown in Figure 6-20.

Figure 6-20 Adding the database administrator to DB Users group

124 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 7. As depicted in Figure 6-21, select the database administrator from the User drop-down menu. Check all of the Authorities boxes except Security Administrator Authority. Click Apply, then OK to complete this step.

Figure 6-21 Add user with sufficient authority

Chapter 6. Base installation and configuration 125 6.2.4 Install the IMS Server

Next, we install the IMS Server. For platform requirements, refer to the IBM Tivoli Access Manager for Enterprise Single Sign-on Deployment Guide Version 8.0, SC23-9952.

To install the IMS Server: 1. Locate the Tivoli Access Manager for Enterprise Single Sign-On IMS Server executable program and double-click it. 2. After the installation package has completed unpacking, you see the License Agreement (Figure 6-22). If you agree with the terms, accept the agreement and click Next.

Figure 6-22 License agreement

126 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. You are now presented with three choices of installation type: Express, Custom, and Upgrade as shown in Figure 6-23. Select Custom Install and click Next.

Figure 6-23 Type of installation

Chapter 6. Base installation and configuration 127 4. Specify the fully qualified domain name of the IMS Server, and click Next (Figure 6-24).

Note: The fully qualified domain name entered here is the same that has been assigned to the certificate used for secure communication between the AccessAgent and the IMS Server. This name cannot be reset later. If you must change that name at a later time, another installation of the IMS is necessary.

Figure 6-24 Server configuration

128 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. You are now required to specify the supported database type to be used by the IMS Server. Select Use existing DB2 Server and click Next as shown in Figure 6-25.

Note: If the IMS Server and database server are on different systems, we suggest that the clocks of both systems be synchronized. This can be achieved by configuring the Windows Network Time Protocol (NTP).

Figure 6-25 Select database type

6. After selecting DB2 for the database, you are required to enter the following database connection parameters (Figure 6-26 on page 130): – Database host name Enter the fully qualified host name where the database is installed. In this example, the database is on the same system as the IMS Server. – Database instance (optional) Optionally enter the name of the database instance. If you chose to install the default DB2 instance as depicted in Figure 6-7 on page 112, then the instance name is DB2.

Chapter 6. Base installation and configuration 129 – Database port Enter the TCP port that was specified during the DB2 install. In our case we chose the default port of 50000, which is automatically entered into this field. Leave this as the default value. – Database name Enter the name of the database entered in 6.2.3, “Create the IMS database” on page 120; here it is imsdb. – Administrator user name and password Enter the database administrator user name and password that you created in 6.2.1, “Create administrative users” on page 105.

Figure 6-26 Database configuration

130 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 7. To complete the IMS Server installation, click Done (Figure 6-27).

Figure 6-27 Installation complete

6.2.5 Initial IMS Server configuration

In this section, we configure the IMS Server for initial use. Immediately after the IMS Server installation has completed, the IMS Server configuration page is automatically opened1 so that an initial configuration can be completed.

The initial configuration consists of the following tasks: Specify the domain of the enterprise directory to connect to, and enter the lookup-user name and password. Decide whether to synchronize the enterprise directory password and Tivoli Access Manager for Enterprise Single Sign-On password (this option is available only for Active Directory). Assign an enterprise directory user to act as the IMS administrator.

1 If the configuration page does not open or you want to revisit this step later, select Start → Programs → TAM E-SSO IMS Server → TAM E-SSO IMS Configuration Utility or manually use a Web browser on the IMS Server and point it to http://localhost:8080.

Chapter 6. Base installation and configuration 131 Synchronizing the passwords and assigning an IMS administrator can be done later, but in our scenario, we perform all of these tasks along with the initial configuration tasks, as follows: 1. First, we enter the domain information for one domain, and add it to the configuration as shown in Figure 6-28: – DNS domain name Enter the DNS domain of the enterprise directory. – Lookup-user name and password Enter the lookup-user name and password that you created in 6.2.1, “Create administrative users” on page 105. Click Next.

Figure 6-28 Add domain and lookup user information

132 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 2. Next, we decide whether to synchronize the Active Directory password with the Tivoli Access Manager for Enterprise Single Sign-On password. Select the Use Active Directory password as the TAM ESSO password check box, as shown in Figure 6-29, and click Next.

Figure 6-29 Password synchronization

3. As the last step of the initial configuration for the IMS Server, provide the credentials of the enterprise directory user that will be the IMS administrator. You can provision additional IMS administrators after this step by clicking the link Provision IMS administrator. Enter the user name and password, and click the drop-down list to select the domain you specified in Step 1 of this section as shown in Figure 6-30 on page 134. Click Next.

Chapter 6. Base installation and configuration 133 Figure 6-30 Enter credentials for the IMS administrator

4. At the IMS Server configuration Summary page, confirm your settings and click Finish. 5. When the success window opens, stop and start the IMS Server by using the following paths: a. Start Menu → Programs → TAM E-SSO IMS Server → Stop IMS Service b. Start Menu → Programs → TAM E-SSO IMS Server → Start IMS Service

134 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 6.2.6 Install the AccessAgent

The next step in our basic deployment is to install the AccessAgent on all workstations that require single sign-on.

Note: In a typical deployment, you would now use the AccessAdmin interface to configure user, machine, and system policies before you install the AccessAgent. However, in the context of this book we discuss these steps in 6.4.1, “Managing policies” on page 180.

The AccessAgent performs the following primary functions: It monitors for applications that are configured for single sign-on, and takes action on them. It communicates with the IMS Server to obtain configuration data and retrieve user Wallets. It allows users to access their Wallets and manage their credentials.

In our scenario, we pre-configure several AccessAgent setup parameters by modifying the SetupHlp.ini file found in the AccessAgent Config installation directory, prior to running the AccessAgent installer. The SetupHlp.ini contains three categories of parameters: Options available only at setup time Options that are available at setup and AccessAgent runtime that map to multiple registry values each Options that are available at setup and AccessAgent runtime that map to one registry value each

The options that map to registry values can be modified after the AccessAgent setup, but the options only available at setup time cannot be set or changed after the AccessAgent install. If those options are required post-install, you must first uninstall the AccessAgent, then reinstall with the setup time only parameters set as needed. Carefully review each option and determine whether it is necessary to modify the values based on your deployment.

The next configuration option is important if you have to enable single sign-on for Java applications. In order for the Tivoli Access Manager for Enterprise Single Sign-On Java Observer module to trigger for Java applications, you must specify the paths to the Java Virtual Machine (JVM™) directories installed on the workstation. Instructions for modifying this option are listed in “Modifying the SetupHlp.ini file and install AccessAgent” on page 1362.

Chapter 6. Base installation and configuration 135 Note: Modifying the options in SetupHlp.ini can assist in streamlining the deployment of AccessAgent to multiple workstations using Windows supported software distribution tools. In this scenario, we are manually installing the AccessAgent to a single Windows XP workstation.

Modifying the SetupHlp.ini file and install AccessAgent To modify the SetupHlp.ini file and install the AccessAgent: 1. Copy the entire AccessAgent installation directory to your workstation. 2. Locate the SetupHlp.ini file in the Config directory inside the AccessAgent installation directory. Double-click SetupHlp.ini to edit it with a text editor. 3. Modify the address to the IMS Server. Locate the line: ImsServerName= Change the value of to the fully qualified host name of the IMS Server: ImsServerName=ims.encnetwork.local 4. Add the JVM directories. Locate the line: ;JVMInstallationDirectories=|| Change the value to include paths to all installed JVMs. It is very important to make sure that you remove the semi-colon (;) symbol from the start of the line and to separate each of the directories with the vertical bar (|) symbol: JVMInstallationDirectories=C:\Program Files\Java\jre1.6.0_01|C:\Program Files\Java\jre1.5.0_03 5. Save and close SetupHlp.ini. 6. From the AccessAgent installation directory, double-click the AccessAgent-8.0.0.13.msi package to begin the AccessAgent installation.

Note: At the time of writing, the AccessAgent version is 8.0.0.13. Future versions will change the name of the MSI package to reflect the version number. The format is AccessAgent-8.x.x.xx.msi.

2 You can also set the paths to the JVMs after your initial installation by using C:\Program Files\Encentuate\JavaSupport\JSupportInstaller.bat. Refer to “Chapter 5. AccessAgent setup” → “Setting automatic sign-on for Java applications” in the IBM Tivoli Access Manager for Enterprise Single Sign-on Deployment Guide Version 8.0, SC23-9952.

136 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 7. At the Welcome window, click Next (Figure 6-31).

Figure 6-31 Welcome window

8. Read the license agreement and if you accept the terms, select I accept the terms of the license agreement, and click Next, as shown in Figure 6-32.

Figure 6-32 License Agreement

Chapter 6. Base installation and configuration 137 9. Keep the default installation directory, and click Next (Figure 6-33).

Figure 6-33 Choose the installation directory

10.After the AccessAgent install completes, you are presented with the successful installation window. Click Finish.

Note: If during the installation you are prompted to enter the IMS Server connection information, the reason is probably that the IMS Server address entered in SetupHlp.ini is incorrect. For a single workstation installation, this is not an issue because you can enter the correct address at the dialog box. If the installation is to be completed on multiple workstations, then cancel the installation, correct the IMS Server address in SetupHlp.ini, and restart the AccessAgent installer.

11.You are now asked to restart the system. Click Yes to restart now (Figure 6-34). You may also configure Setuphlp.ini in a way that you can hide this prompt and not force the user to restart immediately.

Figure 6-34 Restart after AccessAgent installation

138 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Note: Sometimes, two restarts are necessary, because after the first restart, the AccessAgent synchronizes with the IMS Server and retrieves the machine policies. Certain machine policies require a reboot before they can take effect.

This completes the AccessAgent installation.

6.2.7 Interacting with AccessAgent

Now that we have installed the AccessAgent, we are ready to familiarize with the basic functions. In this section, we discuss how you sign up for a Tivoli Access Manager for Enterprise Single Sign-On account, and modify how it signs you in to Windows.

First, notice that the Windows Logon window has changed as shown in Figure 6-35.

Figure 6-35 The TAM E-SSO AccessAgent Logon window

Several things have changed from the default Windows Logon window. The options you can now select are: Log On Selecting this will log you in using your Tivoli Access Manager for Enterprise Single Sign-On password. If you have not yet signed up, you will be prompted to sign up. This is the default behavior, that can be changed.

Chapter 6. Base installation and configuration 139 Sign Up Signing up creates your Tivoli Access Manager for Enterprise Single Sign-On account and password, and prompts you to provide an answer to a challenge question of your choice. Reset Password Reset your Tivoli Access Manager for Enterprise Single Sign-On password. How the password gets reset depends on the configuration in AccessAdmin. Options include responding to a challenge question, entering an authorization code provided by the help desk, or both. Go to Windows to log on If you do not want to log in to Tivoli Access Manager for Enterprise Single Sign-On, you can bypass it and log on to Windows. If you do this, the AccessAgent does not know who you are, and single sign-on functionality will be disabled until you log in to the AccessAgent.

In our scenario, we sign up to use Tivoli Access Manager for Enterprise Single Sign-On and modify the action to take when the credentials are injected into the Windows Logon window. 1. Click Sign Up, and enter your domain user name and password (Figure 6-36).

Figure 6-36 Sign up a new user

Note: Immediately after this step, you are not prompted to enter a new password for your Tivoli Access Manager for Enterprise Single Sign-On account. This is because we enabled Active Directory Password Synchronization in 6.2.5, “Initial IMS Server configuration” on page 131.

140 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 2. Next, you are asked to enter your secret answer to a question of your choice. Select a question and enter and answer that you will not forget. Click Finish (Figure 6-37).

Note: You can customize the questions presented for the secret in AccessAdmin → System Policies → Sign up Policies.

Figure 6-37 Question and secret answer

3. Next you are asked whether or not to store the Wallet credentials on the system after log off. Click Yes (Figure 6-38).

Figure 6-38 Store the Wallet on the workstation after log off

Chapter 6. Base installation and configuration 141 Note: You want to consider security and convenience implications here; in a stationary workstation environment, a best practice is not to store the credentials locally for security reasons. If you work on a mobile workstation, consider keeping local credentials available for the times when you are not connected to the server/network.

4. The user name and password are injected automatically into the Windows user name and password fields. Notice how you are still required to click OK to continue the log on process. In the next steps, we change the click action so it is performed automatically (Auto-logon). For now, click OK to log on to Windows (Figure 6-39).

Figure 6-39 Credentials are automatically injected

Observe the AccessAgent icon in the system tray, as shown in Figure 6-40.

Figure 6-40 AccessAgent tray icon

5. Right-click the AccessAgent tray icon, and then select Manage Wallet, shown in Figure 6-41 on page 143.

142 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 6-41 AccessAgent tray menu

6. Click the drop-down list below Password Entry and select Automatic logon. Then, click Close (Figure 6-42). This behavior can also be globally set in the AccessAdmin for the authentication service.

Figure 6-42 Change log on action for the Windows authentication service

7. Log off Windows and log back in with the same user. Notice how AccessAdmin automatically logs you in.

Chapter 6. Base installation and configuration 143 6.2.8 Install AccessStudio

AccessStudio is used by administrators to create AccessProfiles that contain instructions for handling automation for an application. AccessProfiles can be created and saved to a file or existing AccessProfiles on the IMS Server, or AccessAgent can be downloaded into AccessStudio and modified. After a profile is created, it can be uploaded to the IMS Server to publish the data to the server for use in the corporate environment.

The installation of AccessStudio is a short process: 1. Locate the AccessStudio-8.x.x.x.msi installation binary and double-click it. 2. You are presented with the License Agreement window. If you agree to the terms, select the I accept the terms in the license agreement and click Next. This begins the installation of AccessStudio. 3. After the install wizard completes, click Finish.

6.3 AccessProfile configuration

Now that we have installed and configured the base components, we have to configure Tivoli Access Manager for Enterprise Single Sign-On so that users can begin using the single sign-on functionality for their applications. As described in Chapter 2, “Single sign-on architecture and component design” on page 11, TAA pilots and flight attendants use three primary applications that we will be configuring for single sign-on: Lotus Notes (TAA e-mail) Internet Explorer (Web application for user self-service) AS/400 mainframe client (Ticketmeister mainframe application)

The high-level steps for configuring applications for single sign-on are the same for any enterprise application: 1. Configure an authentication service if one does not already exist. 2. Configure an AccessProfile if one does not already exist. 3. Move the application profile to the enterprise authentication services. 4. If using more than one user template, define which applications are assigned to each user template.

Understanding the relationship between AccessProfiles, applications, and authentication services is important. AccessProfiles consist of an authentication service and the logical reference to an application. The application is a logical

144 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 reference to an .exe file or a Web site. An authentication service defines how user credentials are submitted to the application. Multiple applications can use the same authentication service. For more information, read the IBM Tivoli Access Manager for Enterprise Single Sign-On AccessStudio Guide Version 8.0, SC23-9956.

Authentication services can be configured as either an enterprise authentication service, or a personal authentication service. Administrators can change a service to be personal or enterprise through AccessAdmin.

Enterprise authentication services allow for greater administrative control over the user interaction with the service. Users are not allowed to delete an enterprise service account from their Wallet, and they cannot set Never as an option for the password entry. Additionally, audit logs are stored and generated on the IMS Server for enterprise authentication services only.

Personal authentication services allow the user more control over how they want the AccessAgent to interact with the authentication service. Users may have an unlimited number of accounts per service; there is no ability for administrators to grant or deny access to specific users. The administrator has the ability to disallow all personal authentication services, but not specific personal authentication services.

Note: For all corporate-related authentication services, we recommend setting them to enterprise authentication services because of the enhanced administrative control and the audit logging.

In the following sections we configure three applications for single sign-on, each with a different level of effort involved.

6.3.1 E-mail application

TAA uses Lotus Notes for its corporate e-mail application. Tivoli Access Manager for Enterprise Single Sign-On comes with an authentication profile and application profile that is pre-configured for Lotus Notes, so you do not have to use AccessStudio to create an AccessProfile for Notes.

Lotus Notes, by default, is defined as a personal authentication service. For users to utilize single sign-on to Lotus Notes, we would not have to take any further action. However, we want to enforce a strict policy for the Lotus Notes authentication service, so we make it an enterprise authentication service. We also configure additional policy settings for the Lotus Notes authentication service. The following steps take you through this configuration.

Chapter 6. Base installation and configuration 145 To configure e-mail settings: 1. Log in to AccessAdmin as an administrative user. 2. On the left panel under System, click Authentication service policies (Figure 6-43).

Figure 6-43 Authentication service policies

146 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. Select the check box for Lotus Notes and click Move to enterprise authentication services. When complete, the result should look like Figure 6-44.

Figure 6-44 Move Lotus Notes to enterprise authentication service

Chapter 6. Base installation and configuration 147 4. We now want to make sure that the default sign-on action for Lotus Notes is set to Automatic Logon, and to close the application when the user logs off AccessAgent. Under System, click Application policies. Select Lotus Notes (Figure 6-45).

Figure 6-45 In Application policies, select Lotus Notes

148 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. In the drop-down menu (Default automatic sign-on password entry option for the application), select Automatic logon (Figure 6-46).

Figure 6-46 Set automatic logon as the default action for all users

6. In the drop-down menu (Action for the application, when the user logs off AccessAgent), select Close the application (Figure 6-47).

Figure 6-47 When a user logs off AccessAgent Lotus Notes needs to close

7. Click Update to apply the changes.

Now that we have made these changes, the Tivoli Access Manager for Enterprise Single Sign-On AccessAgents have to synchronize with the IMS

Chapter 6. Base installation and configuration 149 Server in order to receive the changes. Then, the AccessAgents take action when a user launches and logs in to Lotus Notes. The next steps illustrate this process: 1. After the user logs in to Windows and launches Lotus Notes, the password dialog box opens as usual (Figure 6-48).

Figure 6-48 Lotus Notes password prompt

150 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 2. To show that Tivoli Access Manager for Enterprise Single Sign-On will not attempt to save incorrect credentials, the user enters an incorrect password (Figure 6-49).

Figure 6-49 An incorrect password is manually entered, no action is taken by AccessAgent

Note: The default AccessProfile for Lotus Notes is already configured to detect when an incorrect password has been entered. When creating new AccessProfiles, this functionality must be configured manually.

Chapter 6. Base installation and configuration 151 3. The user now enters the correct password, the AccessAgent detects it, and prompts the user to save the credentials in the Wallet (Figure 6-50).

Figure 6-50 AccessAgent prompts user to save user’s Lotus Notes credentials

152 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 4. The user is now authenticated and logged in to Lotus Notes (Figure 6-51).

Figure 6-51 User is authenticated and logged in to Lotus Notes

5. To see that the credentials have been saved to the Wallet, right-click the AccessAgent icon in the system tray, and select Manage Wallet (Figure 6-52).

Figure 6-52 Manage Wallet

Chapter 6. Base installation and configuration 153 6. The user now has Lotus Notes credentials saved in the Wallet, it is an enterprise authentication service, and the default log on action is set to Automatic Logon (Figure 6-53).

Figure 6-53 Wallet contains the Lotus Notes authentication service and credentials

From this point forward, when the user opens Lotus Notes, Tivoli Access Manager for Enterprise Single Sign-On automatically enters and submits the user credentials. Because Lotus Notes is already included with Tivoli Access Manager for Enterprise Single Sign-On as an authentication service and profile, only a few steps are required to configure it for user single sign-on.

Next, we use AccessStudio to create an AccessProfile using the profile creation wizard.

154 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 6.3.2 Web application

TAA uses a self-service Web application to manage its identities. We use the Assistant wizard to generate the AccessProfile for the Web application, as follows: 1. Because we want to create an AccessProfile for our Web application, we open AccessStudio and select New → New AccessProfile (using Assistant), as shown in Figure 6-54.

Figure 6-54 Create a new AccessProfile using Assistant

Chapter 6. Base installation and configuration 155 2. At the AccessProfile Generator welcome window, click Next (Figure 6-55).

Figure 6-55 AccessProfile Generator window

156 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. Enter a name for your profile and select an application type. In the Application Name field, enter a name of your choice that accurately reflects the application. For application type, select Web application, then click Next (Figure 6-56).

Figure 6-56 Enter an application name and select the application type.

Chapter 6. Base installation and configuration 157 4. Now, we have to select the task that we want to automate: Logon, Change password, Logoff, or other custom tasks. We can add more tasks later, so we start with the task we have to automate first: Logon. Select Logon and then click Next (Figure 6-57).

Figure 6-57 Select Logon to automate filling of user name and password

In the next steps, we identify fields in the Web application. Bring up a browser and navigate to the Web application that you are configuring the profile for. The Web application in this scenario is shown in Figure 6-58 on page 159.

158 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 6-58 Web application logon window

Chapter 6. Base installation and configuration 159 5. You are prompted to identify the fields for logon, as shown in Figure 6-59.

Figure 6-59 Identify the fields for logon

160 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 6. The wizard allows you to click and drag the crosshairs to each corresponding window or field. Start by clicking and dragging the Username/Id crosshair directly onto the User ID field on the Web application (Figure 6-60).

Figure 6-60 Drag the finder tool for Username/Id to the User ID field on the Web application

Chapter 6. Base installation and configuration 161 7. Repeat the process for Password. Click and drag the Password crosshair to the corresponding Web application Password field (Figure 6-61).

Figure 6-61 Drag the finder tool for Password to the Password field on the Web application

162 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 8. Finally click and drag the OK button crosshair to the corresponding button, which is Login on this Web application. After you are finished, click Next (Figure 6-62).

Figure 6-62 Drag the finder tool for OK button to the login button on the Web application

9. As shown in Figure 6-63 on page 164, you have the option to add additional windows, and to select an auto-fill option for subsequent logons. Some Web applications have more than one window for the logon process, so the AccessProfile wizard includes the ability to configure for multiple logon windows. In the case of our Web application, there is only one window where we enter our logon information. Select Ask user from the drop-down menu, and click Next.

Chapter 6. Base installation and configuration 163 Figure 6-63 Identify additional windows and select auto-fill for subsequent logons

At the next window you are asked if you want to identify successful logon and if so, how a successful login is identified. In this scenario, we do no detect successful logon. In other words, when a user enters credentials, that user is prompted to save the credentials in the Wallet even if the password is incorrect. If a user accidently enters the incorrect password, the user can access the user Wallet and change to the correct password for the Web application.

164 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 10.At the Identify Successful Logon window, select No (Figure 6-64).

Figure 6-64 Select the option to identify the window after successful logon

Chapter 6. Base installation and configuration 165 11.Next you are asked to create or identify an authentication service. Because we do not yet have an authentication service defined, select Create one for me automatically, and click Finish (Figure 6-65).

Figure 6-65 Create an authentication service for the profile

166 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 12.We are brought back to the AccessStudio profile editor. Notice how Logon is now set as one of the Tasks captured as shown in Figure 6-66. Now we want to add a task so the AccessProfile is configured to act when a user is forced to change a password. Under Tasks captured, click Add.

Figure 6-66 Logon task is now captured

Chapter 6. Base installation and configuration 167 13.The Select Task to Automate window opens again, this time with the Logon radio button is disabled, because we have already created that task. Select Change password and click Next, as shown in Figure 6-67.

Figure 6-67 Automate the change password task

168 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 14.Now we have to identify the fields for the change password task. Click and drag the finder tool crosshairs to each corresponding field on the Web application, as shown in Figure 6-68. When finished, click Next.

Figure 6-68 Click and drag the finder tool for each corresponding field

Chapter 6. Base installation and configuration 169 15.At the next window, we can add more change password windows. Our Web application has only one password change window, so click Next (Figure 6-69).

Figure 6-69 Click Next because we do not require an additional change password window

170 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 16.As shown in Figure 6-70, click and drag the Finder tool crosshairs to an object on the Web page that identifies the page as the one shown after a successful password change. In our case, the success page is the user’s self-service page.

Figure 6-70 Drag the finder tool to an object that identifies the page after successful password change

17.Verify the signature of the object you selected with the finder tool to make sure it is exactly what you intended to choose: a. Click Edit signature to check the signature for accuracy, as shown in Figure 6-71 on page 172. b. Click Highlight control to highlight the object you selected as the signature. c. After you have verified the signature, click Next to continue.

Chapter 6. Base installation and configuration 171 Figure 6-71 Check the control signature for the success condition

18.The General Properties tab now shows both required tasks, Change password and Logon, as shown in Figure 6-72.

Figure 6-72 Logon and Change password tasks captured

19.Now we have to test the profile. Close all open Web browsers and in the AccessStudio menu, select Test → Start.

172 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 20.Double-click the AccessAgent in the system tray. Click Manage Wallet, and notice that it is empty, as shown in Figure 6-73. This is because during test mode, AccessStudio is using a temporary Wallet that is active only for that test session.

Figure 6-73 Temporary Wallet, active during test mode

Chapter 6. Base installation and configuration 173 21.Open a browser to the Web application we just configured. Enter the credentials and click Login. Notice how you are asked to save the credentials in the Wallet. Click Yes (Figure 6-74).

Figure 6-74 AccessAgent asks to save credentials during test mode

22.If you now close the browser and reopen it, the user credentials should be automatically filled. You can check that the temporary Wallet (active only during test mode) contains the user credentials, as shown in Figure 6-75 on page 175.

174 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 6-75 Test Wallet shows credentials saved during the test

While still in test mode, assume we force the Web application password to expire for user Janepilot. This means, the next time we log in as Janepilot, we will be presented with the Web application password expiration page.

Chapter 6. Base installation and configuration 175 23.Open a new browser to the Web application. Because test mode is still active, and the credentials are saved in the temporary Wallet, the credentials are automatically injected, as shown in Figure 6-76. Click Log in.

Figure 6-76 AccessAgent automatically injects the User ID and Password

24.Now that the password has expired for Janepilot, the password expiration page is presented. Notice how the AccessAgent automatically fills in the old password, as shown in Figure 6-77 on page 177. This feature is important when policy is set to generate random passwords, and the user does not know the old randomly generated password.

176 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 25.In our scenario, we do not have random passwords enabled. Specify a new password in the New password and New password (Confirm) fields. Click OK.

Figure 6-77 The old password is automatically injected into the correct field

The new password is accepted, and the page is generated that we defined as a successful password change in step 16 on page 171 (Figure 6-78 on page 178).

Chapter 6. Base installation and configuration 177 Figure 6-78 Password change is successful

26.We have to make sure that, while still in test mode, the new password is automatically injected into the log on window. Close the browser and open up another browser to the Web application. 27.Notice that the User ID and Password are injected once again as shown in Figure 6-79 on page 179. Click Log in. The user’s home page is generated again, because the new password was saved in the user’s Wallet. Our test is successful.

178 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 6-79 The new password is injected

28.Now that we have successfully tested the profile, in AccessStudio select Test → Stop. 29.Save the profile to a local file by selecting File → Save as. 30.Upload the profile to the IMS Server by right-clicking the profile, as shown in Figure 6-80, and selecting Upload to IMS. The profile, authentication service, and application is now uploaded to the IMS Server where it represents an active authentication service. After using AccessAdmin to optionally configuring policy for the authentication service, users will be able to save their Web credentials into their Wallets.

Figure 6-80 Upload the profile to the IMS Server

Chapter 6. Base installation and configuration 179 6.3.3 Mainframe application

Tivoli Access Manager for Enterprise Single Sign-On provides single sign-on functionality to host and mainframe applications through host emulators that: Implement high-level language application programming interface (HLLAPI) Have a built-in scripting language that can display a dialog

The host emulator enables a user to connect the Windows workstation to a mainframe, AS/400, IBM OS/390® system, UNIX, or other host-based session.

Host emulators can be configured with standard profiles, by using the AccessStudio wizard. However, sometimes advanced customization to the profile is required so the AccessAgent interacts with the emulator exactly as intended. We will build from scratch an advanced profile for an HLLAPI-based host emulator so that you can better understand how to customize advanced profiles for host emulators. To begin creating an advanced profile, refer to Appendix B, “Advanced profiling” on page 453.

6.4 Managing the deployed environment

After the installation and configuration of the base components, we can take a closer look at managing and administering a deployed Tivoli Access Manager for Enterprise Single Sign-On environment.

The tasks to manage and administer the system are: Managing policies User management Backing up the database Logging

In a typical deployment scenario, you want to configure your policy before the AccessAgent installation, which was covered in 6.2.6, “Install the AccessAgent” on page 135.

6.4.1 Managing policies

Tivoli Access Manager for Enterprise Single Sign-On uses policies to control the behavior of its components. Administrators have full control over policies, and users assigned to the help desk role have more limited control over policies. Refer to Table 6-1 on page 181.

180 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Table 6-1 Policies and their scopes Policy Type Administrator Help desk Policy scope permission permission

System policies Full read/write Read only System-wide

Machine policies Full read/write Read only Machines

User policies Full read/write Full read/write Users

System, machine, and user policies each have unique and overlapping policy parameters. Certain policies such as AccessAgent lock/unlock, desktop inactivity, and logon/logoff can be defined in more than one policy type. In deployment where many policies are defined, it is possible that several of the granular policies will overlap. In this case, use the managepolicypriority.bat command-line utility to manage policy priorities. For more information, refer to the “Setting policy priorities” section in the IBM Tivoli Access Manager for Enterprise Single Sign-On Administrator Guide Version 8.0, SC23-9951.

Policies are created and modified to enforce the rules set by the business. Prior to production deployment, you should have all of your policies clearly defined as direct translations of the business security requirements. Modifying policy after deployment might be unavoidable, but best effort should be made to define policies before deployment to production.

6.4.2 User management

Administrators have full control over users, and help desk officers have limited control over users assigned to their particular help desk. The help desk role is essentially delegated administration based on group membership. You can assign users to help desks individually or by assigning a user policy to one or more help desks. Any user that is a member of the user policy will automatically be under the delegated control of the help desks assigned to that policy. When planning for policy design, make sure you clearly define which help desks should have control over which groups of users.

Another aspect of user management is managing the revocation of users or their Wallets. When a user leaves the company, an administrator can revoke the user Wallet, the user’s second authentication factor, or the actual user. Revoking the user permanently disables the user account and prevents any user with the same name from being created. When a user is revoked all of their audit data is retained in the database. Only when a user is deleted, is all of their audit data also deleted from the database. Keep this in mind when defining administrative policy, so important audit data is not accidentally deleted.

Chapter 6. Base installation and configuration 181 Note: When a user leaves an organization, a common practice is to rename the user's Tivoli Access Manager for Enterprise Single Sign-On account and then revoke the user. This approach allows for the user name to be re-used.

6.4.3 Backing up the database

Backing up and restoring the IMS database should be an integral part of your maintenance plan. The IMS database holds all configuration, user, and audit data. Any loss or corruption of this data can be devastating if no backup plan is executed on a regular basis. Refer to section “Backing up the database” in the IBM Tivoli Access Manager for Enterprise Single Sign-On Administrator Guide Version 8.0, SC23-9951 for more information.

6.4.4 Logging

Three types of logs are available to the IMS Server: user, system, and administrator. User and administrator logs track user, administrator, and help desk activity. The user and administrator logs are considered the audit logs, and are written to the IMS database. Administrators and help desk officers can access the audit logs for individual users. Only administrators can run full queries on audit logs, access the help desk logs, and generate reports on help desk and user activity.

The system logs are message and error logs for the IMS Server itself, primarily used for troubleshooting server issues and monitoring the system health. Keep in mind that when troubleshooting IMS Server issues, always make a copy of the system logs before restarting the IMS Server. Restarting the IMS Server clears the system logs.

For additional information, refer to Appendix A, “Troubleshooting” on page 433.

182 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 6.5 Conclusion

Tivoli Access Manager for Enterprise Single Sign-On provides single sign-on to a great variety of a customer's applications without a lengthy and complex implementation effort. Tivoli Access Manager for Enterprise Single Sign-On provides users with one password to log on to many applications on both the company network and the Internet.

AccessAdmin simplifies administration by recognizing and configuring applications for sign-on automatically with minimal effort by the administrator. Enterprise users gain single sign-on while connected to or disconnected from the corporate network.

Chapter 6. Base installation and configuration 183 184 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 7

Chapter 7. Password self-services implementation

In this chapter, we describe more details about the technical implementation of the Tivoli Access Manager for Enterprise Single Sign-On (TAM E-SSO) environment.

First, we give an introduction into the password self-service feature. After covering the technical prerequisites, we describe how to configure the password self-service. Finally, we tell you how to manage and maintain the deployed solution.

As described in “Emerging issues” on page 87, if a user forgets a Windows password, the user cannot log into the computer and must locate another computer to perform the self-service password reset offered by Tivoli Identity Manager. With Tivoli Access Manager for Enterprise Single Sign-On, this problem can be overcome by providing the password self-service function of the product.

7.2 Password self-service architecture

The Tivoli Access Manager for Enterprise Single Sign-On password self-service enables users to reset their primary authentication (Tivoli Access Manager for Enterprise Single Sign-On password or desktop password) from any workstation based on a challenge-response process. All questions are customizable and configurable. When the Tivoli Access Manager for Enterprise Single Sign-On password self-service is configured (no additional components must be installed), there is no need to call the help desk or technical support and no waiting for an administrator to reset the password. Instead, the users have to provide second secrets that they have set up during the sign-up phase of the AccessAgent.

As mentioned previously, no additional components have to be installed to use the password self-service function. Therefore, the architecture of the solution appears nearly the same as the basic architecture in 6.1.2, “Deployment architecture” on page 103, utilizing the AccessAgent on the Windows workstations.

Let us now look into the configuration details for the TAA deployment, in particular, two common workflows for passwords self-services. We assume that you have already deployed Tivoli Access Manager for Enterprise Single Sign-On.

186 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 7.3 Password self-service implementation

When using the Tivoli Access Manager for Enterprise Single Sign-On password self-service, different workflows may occur. Depending on whether the IMS Server is available on executing the password self-service request or not the workflow differs. When the password self-service feature is disabled but the user still wants to reset the password, another workflow is triggered.

Before enabling the password self-service functionality we have to take of some prerequisites, here, setting up the self-service secret questions.

7.3.1 Set up the self-service questions

When the user wants to use the password self-service function, a series of questions must be answered in preparation. The questions are predefined and managed by the administrator using the AccessAdmin console.

A list of predefined questions are part of the standard installation of the IMS Server, as follows: What's your favorite color? What's your favorite fruit? What's your mother's maiden name? Who's your favorite author? Who's your favorite composer? Who's your favorite person from history?

Configuring challenge-response questions Challenge-response questions are prepared by the administrator. When you have determined the set of questions, you have to configure them into Tivoli Access Manager for Enterprise Single Sign-On.

For this example, let us assume that we want to include the following question in the Sign up policies: What is your favorite airline?

To configure system questions in the AccessAdmin console: 1. Open a Web browser and enter the following Web address: http://ims.encnetwork.local If IMS Server is installed, this address navigates you to the IMS Server start page as shown in Figure 7-1 on page 188. Click AccessAdmin to proceed.

Chapter 7. Password self-services implementation 187 Figure 7-1 AccessAdmin start page

2. You are presented with the AccessAdmin portal as depicted in Figure 7-2 on page 189. Self-service-related configuration items are system policies, therefore click System policies (under System on the left side of the window).

188 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 7-2 AccessAdmin portal page

The System policies are listed, as shown in Figure 7-3 on page 190.

Chapter 7. Password self-services implementation 189 Figure 7-3 AccessAdmin System policies

3. Click the triangle beside Sign Up Policies to expand the list. The secret questions are listed, as shown in Figure 7-4.

Figure 7-4 AccessAdmin self-service questions

190 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 4. In the text box, enter the following new question and then click Add, as shown in Figure 7-5: What’s your favorite Airline?

Figure 7-5 AccessAdmin self-service question configuration

The new question is added to the current Question set for secret, as shown in Figure 7-6.

Figure 7-6 AccessAdmin self-service question configuration 2

Chapter 7. Password self-services implementation 191 5. If not already done, set Prompt user to register additional secrets for self-service during sign-up? to Yes, as shown in Figure 7-7.

Figure 7-7 AccessAgent Sign-up Policy

6. If necessary, you can add many more questions. After the self-service questions are configured, remember to click Update to apply any changes to the IMS Server.

Now, that we have configured our challenge-response questions we are ready to enable the password self-service functionality.

7.3.2 Enable the password self-service function

As mentioned previously, the password self-service can be disabled or enabled by system policy using the AccessAdmin GUI. Depending on the status of the self-service feature, the password workflow is different.

192 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 To enable the password self-service function: 1. Open a browser window and enter the Web address: http://ims.encnetwork.local Again, if IMS Server is installed, this address navigates you to the IMS Server start page, where you click AccessAdmin as shown in Figure 7-8.

Figure 7-8 AccessAdmin start page

Chapter 7. Password self-services implementation 193 2. The AccessAdmin portal opens, as shown in Figure 7-9. Self-service related configuration items are system policies, therefore click System policies (under System on the lower left side of the window).

Figure 7-9 AccessAdmin portal

The list of System policies is displayed; see Figure 7-10 on page 195.

194 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 7-10 AccessAdmin self-service policies

3. Click Self-service Policies to expand the list.

Chapter 7. Password self-services implementation 195 The panel expands and offers three choices, as shown in Figure 7-11.

Figure 7-11 Self-service policies

4. Click Self-service Password Reset Policies to expand the section.

196 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. Ensure that Enable self-service password reset is set to Yes, as shown in Figure 7-12. The other fields are self explanatory. Modify the values appropriately. Sample values that came with the default installation of the IMS Server are also shown in the figure.

Figure 7-12 Self-service password reset policies definition

6. Now the password self-service functionality is active. Click Update to apply the changes to the IMS Server.

7.3.3 User enrollment interview

Before the user can use the password self-service when necessary, the user has to provide the correct answers to the questions that are asked. The questions in the enrollment interview are used to create the reset quiz that users take if they ever have to reset the Tivoli Access Manager for Enterprise Single Sign-On password. The answers provided in the interview are the answers that are used to verify the user’s identity.

The easiest way to complete the enrollment interview is during the sign-up phase for a new user.

Chapter 7. Password self-services implementation 197 An example of the enrollment interview is demonstrated in the following steps: 1. On a Windows workstation with AccessAgent installed, go to the logon window as shown in Figure 7-13.

Figure 7-13 AccessAgent logon dialog

2. Click Sign Up to start enrollment of a new user, and enter the user ID and password for the new Tivoli Access Manager for Enterprise Single Sign-On user (Figure 7-14 on page 199). The, click Next.

198 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 7-14 AccessAgent user enrollment

3. The list of predefined secret questions that the administrator previously defined is displayed, as shown in Figure 7-15. In our example we selected What is your favorite airline? as the first question. We provide our answer in the Answer text box, and then click Next.

Figure 7-15 AccessAgent first secret question

Chapter 7. Password self-services implementation 199 4. Answer the second question. In our example, we decide to answer What’s your favorite color? (Figure 7-16).

Figure 7-16 AccessAgent second secret question

5. If you want to register more question, select Register more questions. In our example, we want to use two questions, therefore we do not select this option. 6. Finally, click Next to finish the enrollment interview. The AccessAgent continues to start and after a few seconds the Windows desktop is displayed (Figure 7-17 on page 201).

200 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 7-17 Windows desktop after Login

7.3.4 Execute a password reset

As we have mentioned before, several different workflows may occur during a password self-service situation. If the user is using user name and password for primary authentication, the two resulting workflows for password reset are: Online access to the IMS Server exists and password self-service enabled No access to the IMS Server, or password self-service disabled

Let us take a closer look at both these workflows.

Online access to the IMS Server exists and password self-service enabled If the AccessAgent can contact the IMS Server and the password self-service function is enabled, the user can process a password-reset without contacting the help desk staff by providing the self-service credentials. Because the IMS Server can be contacted by the AccessAgent, a password-reset also updates the Wallet in the IMS Server.

Chapter 7. Password self-services implementation 201 To reset the password, follow these steps: 1. Go to the Windows workstation logon GUI and click Reset Password as shown in Figure 7-18.

Figure 7-18 AccessAgent logon GUI

2. In the Reset Password dialog, as shown in Figure 7-19, enter your user name. In our test case, we use itsouser2. Then, click Next.

Figure 7-19 AccessAgent reset password

202 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. You are presented with a list of questions that we have selected in 7.3.3, “User enrollment interview” on page 197. Select the first question and enter the answer, which, presumably, only you know (Figure 7-20).

Figure 7-20 AccessAgent first secret answer

4. Click Next and answer the second question (Figure 7-21).

Figure 7-21 AccessAgent password reset second question

Chapter 7. Password self-services implementation 203 5. Click Next, and if everything works fine, that is, the answers are correct, the password change dialog is presented, as shown in Figure 7-22.

Figure 7-22 AccessAgent self-service password change

6. Click Finish. The AccessAgent acknowledges the password-reset, as shown in Figure 7-23.

Figure 7-23 AccessAgent successful password reset

204 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 No access to the IMS Server or password self-service disabled If the AccessAgent cannot contact the IMS Server to process a password self-service request, the user has to contact the help desk to get an authorization code. There is no difference whether the password self-service is enabled or not. In offline mode, the AccessAgent can access only local computer resources, in our case, the locally cached identity wallet of the user. If the IMS Server can be contacted by the AccessAgent, as discussed in our scenario, a password-reset updates both the Wallet on the IMS Server as well as the local one.

In case the access to the IMS Server is severed, the involved parties, user and help desk, should work in collaboration to reset the user’s password. In the following example, we show an offline password-reset workflow involving both sides, user activities and help desk activities.

User activities The workflow is as follows: 1. Go to the Windows Workstation login dialog. Remember, a cached Wallet must exist. Click Reset Password and fill in the user name as shown in Figure 7-24.

Figure 7-24 AccessAgent reset password

Chapter 7. Password self-services implementation 205 2. Click Next. If AccessAgent has no connection to the IMS Server the message shown in Figure 7-25 appears and must be acknowledged; click OK.

Figure 7-25 AccessAgent password reset with no IMS connection

3. The AccessAgent creates a request code that must be passed to the help desk in order to create a password reset authorization code. Call your help desk and tell them your request code, which in this case is 3CZKKAER, as shown in Figure 7-26.

Figure 7-26 AccessAgent password reset request code

4. After you have received the authorization code from the help desk, enter it in the appropriate text field, as shown in Figure 7-27 on page 207.

206 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 7-27 AccessAgent password reset authorization code

5. Click Next and answer the secret question. In our case the system asks for our favorite airline, which is (do you remember?) taa. See Figure 7-28.

Figure 7-28 AccessAgent password self-service secret

Chapter 7. Password self-services implementation 207 6. Click Next and, if everything has been entered correctly, you can specify a new password as shown in Figure 7-29. Because your AccessAgent has no connection to the IMS Server, this password is temporary.

Figure 7-29 AccessAgent password self-service new password

7. Click Finish to submit your new password. If your password is valid only for a short time (approximately one day to one month), the AccessAgent tells you how long you may work with the temporary password; see Figure 7-30.

Figure 7-30 AccessAgent temporary password

8. Click OK. The AccessAgent immediately starts up your desktop as you can see in Figure 7-31 on page 209.

208 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 7-31 Windows desktop after password reset

Help desk activities To support a user in resetting a Wallet password, the help desk staff must create an authorization code using the AccessAdmin Web GUI.

Follow these steps to create an authorization code: 1. Open a Web browser and enter this URL: http://ims.encnetwork.local If IMS Server is installed, this address navigates you to the IMS Server start page as shown in Figure 7-32 on page 210.

Chapter 7. Password self-services implementation 209 Figure 7-32 IMS Server Web GUI

2. Click AccessAdmin to proceed. You see the AccessAdmin Web GUI (Figure 7-33 on page 211).

210 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 7-33 AccessAdmin portal page

3. To proceed with any user-related administration activities, enter the user’s name itsouser2 in the text box, as shown in Figure 7-34 on page 212.

Chapter 7. Password self-services implementation 211 Figure 7-34 AccessAdmin User administration activities

4. Click Search to see the user information for itsouser2, shown in Figure 7-35 on page 213.

212 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 7-35 AccessAdmin user information

Chapter 7. Password self-services implementation 213 5. Click Helpdesk Authorization (Figure 7-36).

Figure 7-36 AccessAdmin Helpdesk authorization

6. To create an authorization code for a password-reset, select an expiration time (between one day and one month) and enter the request code that appears on the AccessAgent GUI on the users desktop. In our example, the request code is 3CZKKAER. Finally, click Issue authorization code (see Figure 7-37, and also Figure 7-26 on page 206).

Figure 7-37 AccessAdmin authorization request

After several seconds, an authorization code is issued by the IMS Server (see Figure 7-38 on page 215). This authorization code has to be transferred to the user. The user needs the code to continue the password-reset self-service workflow.

214 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 7-38 AccessAdmin issued authorization code

7.4 Conclusion

The password self-service functionality enables users to reset their primary logon passwords without having to call the help desk or find a special kiosk set up for that purpose, except when your workstation is not connected to the central IMS Server. The one-time enrollment is the only hurdle for the users before they can reap the benefits of this function. This is one of the reasons you have to educate users before deploying the solution within the enterprise.

Security administrators responsible for deploying the password self-service must be sure to spend adequate time formulating the questions before the initial deployment of the solution. Corporate security officers, human resources, and the CIO’s office are several of the stakeholders that must review the questions.

When you have addressed the questions, the mechanics of deploying the solution discussed in this chapter allow for a smooth deployment of the function.

Chapter 7. Password self-services implementation 215 216 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 8

Chapter 8. Shared desktop implementation

In this chapter, we describe details of the shared desktop component by configuring the required Windows workstation parameters, and the shared desktop features by using AccessAdmin.

First, we explain the business context and give an overview of the shared desktop functionality. Then, we show you how to configure, manage, and maintain shared desktops in the deployed solution.

As described in “Emerging issues” on page 87, Tivoli Austin Airlines (TAA) must enable its pilots and flight attendants to access shared workstations to: Check their Lotus Notes e-mail. Log in to a self-service Web application. Access the Ticketmeister application with a mainframe client.

Allowing crew members to use shared workstations to access business applications saves on the costs of providing personal workstations to all crew members. It also saves crew members the trouble of finding networks to connect to in cities across the world.

From a security perspective, the TAA IT security organization requires that the login process is secure, and that authentication activity for each user is logged for audit and compliance purposes. The Tivoli Access Manager for Enterprise Single Sign-On (TAM E-SSO) shared desktop feature can meet all of these requirements.

TAA’s IT security policy states the requirements for shared desktops as: When Windows starts, it must automatically log in with the shared user and immediately lock the window. The shared desktop Windows user that automatically logs in must have restricted rights, so that the only applications they can access are Internet Explorer, Lotus Notes, and the mainframe emulator used to access Ticketmeister. Tivoli Access Manager for Enterprise Single Sign-On users cannot use the Windows logon window to log in to shared workstations, and must only use the Tivoli Access Manager for Enterprise Single Sign-On window to log in. Desktop inactivity policies must be as strict as possible in order to prevent users from accessing other users’ sessions. All open applications must gracefully log off when the Tivoli Access Manager for Enterprise Single Sign-On user manually logs off, or is automatically logged off because of inactivity.

218 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 8.2 Overview of the shared desktop features

As described in “Session management” on page 30, Tivoli Access Manager for Enterprise Single Sign-On shared desktop allows multiple users to use one generic Windows desktop on a workstation. Tivoli Access Manager for Enterprise Single Sign-On users can generally access a limited number of applications. When each user logs in, the AccessAgent obtains the user’s Wallet and the user is able to use single sign-on to access the user’s applications. When a user logs off in a shared desktop environment, all of the applications the user had open are closed. This process is different from a private desktop environment, where applications are left open as users switch between each other on the workstation. In the TAA environment, security requirements dictate that all applications opened by a user be closed when the user logs off, so we will configure for shared desktop.

The steps to configure Tivoli Access Manager for Enterprise Single Sign-On shared desktop are explained in detail in the following sections: 8.3, “Windows configuration steps” on page 220 8.4, “AccessAdmin configuration steps” on page 221

Before we begin our configuration, let us take a closer look at the distinctions between different users.

8.2.1 Distinction between users

When we discuss users in a shared desktop environment, an important concept is to distinguish between the Windows user being automatically logged in, and the Tivoli Access Manager for Enterprise Single Sign-On user, who actually uses the shared desktop to log in to applications.

The Windows user is the user that is automatically logged in to the domain on the Windows shared desktop workstation. In this scenario, this user is named the TAA-SharedUser. All applications and files that this user can access are restricted at the domain and file system level. In the case of TAA, the Tivoli Access Manager for Enterprise Single Sign-On users are the pilots and flight attendants who will log in to Tivoli Access Manager for Enterprise Single Sign-On to access their Lotus Notes e-mail, the TAA intranet, and the Ticketmeister application. No matter which TAA employee logs in to Tivoli Access Manager for Enterprise Single Sign-On, the applications themselves are being opened under the TAA-SharedUser account because the authorization for the launch of an application is an operating system level task. This is why restricting the rights of the TAA-SharedUser is important, so that when a TAA employee logs in, that employee is only able to access TAA business applications.

Chapter 8. Shared desktop implementation 219 Operating system level activity is logged by using Windows and can be viewed with the Event Viewer; and all TAA employee login activity is logged in Tivoli Access Manager for Enterprise Single Sign-On event and audit logs.

8.3 Windows configuration steps

Several steps must be taken to prepare and secure the Windows workstation for Tivoli Access Manager for Enterprise Single Sign-On shared desktop: 1. Create a domain user to be used for automatic logon to Windows, TAA-SharedUser in our scenario. 2. Restrict, by group membership, the applications and files that this user can access by editing the Global Policy Objects. 3. Enable automatic logon to Windows for TAA-SharedUser by editing the registry on the shared workstation.

After you create the shared user in the Active Directory Users and Computers, restrict the user rights by setting proper group membership and domain-level restrictions on applications, files, and services. You may also use the Global Policy Object editor to further refine what the shared user is allowed to see and do, such as restricting what users can see on the Start menu, and disallowing logoff through the Start menu and Ctrl+Alt+Del sequence. Refer to Microsoft support article KB292504 for more information about policy settings: http://support.microsoft.com/kb/292504

Next, enable automatic logon to Windows for the shared user. Refer to the Microsoft support article KB315231 for detailed instructions of how to enable automatic logon for Windows: http://support.microsoft.com/kb/315231

These steps are generally performed by corporate Active Directory administrators, but you are responsible for collaborating with them to ensure the Windows configuration steps are in place before you begin configuring the shared desktop in AccessAdmin.

Note: As stated in the Microsoft support article, security concerns exist when enabling automatic logon to Windows. An imperative is that you take steps to mitigate these security issues. Along with severely restricting the rights of the shared user, restrict physical access to all shared workstations, and use a password for the shared user that is completely different from any administrative user.

220 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 8.4 AccessAdmin configuration steps

Now that you have configured the necessary Windows settings, you must configure Tivoli Access Manager for Enterprise Single Sign-On shared desktop settings in AccessAdmin. You have the option to use the Setup Assistant, but in our scenario we will manually perform the required steps, so that you have a solid understanding of what is needed to enable shared desktop functionality.

The steps we take to configure shared desktop in AccessAdmin consists of creating a new machine template and setting the necessary parameters in the various policy drop-down menus. Keep in mind that no single shared desktop parameter enables shared desktop. Instead, the combination of your Windows settings, window lock, log off, and lock/unlock policies together make a shared desktop environment that meets the security requirements of your specific environment.

In the following steps, we show how to set up the shared desktop for the TAA environment; the policy settings that are specific to your own environment depend on the individual company security requirements.

To set up the shared desktop: 1. Open an Internet browser and log in to AccessAdmin. 2. We want to enforce our shared desktop policies per machine, so we must first create a machine policy template. Under Machine Policy Templates, click New template, as shown in Figure 8-1 on page 222.

Chapter 8. Shared desktop implementation 221 Figure 8-1 Create a new machine policy template

3. In the panel, shown in Figure 8-2 on page 223: a. Type in a name for your template in the Name field. b. Set the criteria that will determine the machines that this template applies to. We want this template to apply to all shared desktop systems. In the TAA naming convention, all shared desktop host names begin with the letters AA, so we have applied criteria to match, as shown in Figure 8-2 on page 223. c. Click Use only machines matching these criteria, then click the green plus symbol (+) to add a condition. The required conditions typically vary by environment, so use criteria best suited for your implementation.

Note: For details of how to set matching criteria, refer to “Creating a new machine policy template” in the IBM Tivoli Access Manager for Enterprise Single Sign-On Administrator Guide Version 8.0, SC23-9951.

222 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 8-2 Add matching criteria for the machine policy template

4. Expand Shared Workstation Policies → Lock/Unlock Policies, as shown in Figure 8-3. From the drop-down menu under Windows startup actions, select Lock computer.

Figure 8-3 Shared Workstation Policies

Setting this action with lock the computer as soon as Windows starts up. This, together with the Windows configuration discussed in 8.3, “Windows configuration steps” on page 220, fulfills the first TAA security requirement by automatically logging in, and immediately locking the window. 5. Now, we want to make sure that users cannot bypass the Tivoli Access Manager for Enterprise Single Sign-On logon window. We are enforcing this

Chapter 8. Shared desktop implementation 223 so that any TAA employee logging into a shared desktop must sign in through Tivoli Access Manager for Enterprise Single Sign-On. This step also ensures that all application logon activity is logged with Tivoli Access Manager for Enterprise Single Sign-On. Expand AccessAgent Policies → EnGINA policies. Under Allow logon bypass through Windows, select No, as shown in Figure 8-4.

Figure 8-4 EnGINA Policies

6. Next, click Desktop Inactivity Policies. Here we can enforce the strict desktop inactivity requirements stated by TAA (in Figure 8-5 on page 225). – In the Desktop inactivity duration, in minutes field, enter 1. – In the drop-down menu for Desktop inactivity actions, select Log off Wallet and lock computer.

224 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 – We want to give the user a chance to cancel the inactivity action, so in the field for Confirmation countdown duration, enter 10. –Select No action under Locked computer inactivity actions when user is logged on to Wallet. If a user locks the system, we want that user’s session to stay active until that user or another user unlocks the system. This also fulfills the requirement that all applications log off gracefully.

Figure 8-5 Desktop inactivity policies

This section enforces the desktop inactivity requirements. The graceful log off of applications when a user logs off is a combination of setting the desktop inactivity action to Log off Wallet, and using AccessStudio to modify the application profiles to automatically log off when a user logs off the Wallet. More details about this configuration are covered in Appendix B, “Advanced profiling” on page 453. 7. Click Lock/Unlock Policies as shown in Figure 8-6 on page 226. Set the following parameters: – From the drop-down menu under Unlock computer policy, select Any user with or without current desktop account in Wallet can unlock. – For the Confirmation countdown duration, enter 60, which gives the user, who originally locked the system, a chance to resume a session before another user unlocks and logs in. – From the drop-down menu under Option for allowing unlock bypass through Windows, select Disabled. This further enforces the requirement that users cannot log in through the Windows login window.

Chapter 8. Shared desktop implementation 225 Figure 8-6 Lock/Unlock Policies

8. Click Logon/Logoff policies as shown in Figure 8-7 on page 227. Set the following parameters: – From the drop-down menu under User name prefill option, select Prefill with last logged on user name. – From the drop-down menu under User name display option select User name. – From the drop-down menu under Allow user to manually log off AccessAgent, select Yes. Because we do not want users to log off Windows, we must give them the ability to log off the AccessAgent. – From the drop-down menu under Actions on manual logoff by user, select Log off Wallet and lock computer. This will perform the same action that is set for desktop inactivity timeout. – Because certain applications take longer to log off, we have to give an adequate amount of time to allow them to gracefully log off. Enter 15 in the field for Time-out, in seconds, for application logoff. This value might have to be increased or decreased, depending on the applications in your environment.

226 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 8-7 Logon/Logoff Policies

9. Finally, click the Add button at the bottom of the page to add the machine policy template. Under Machine Policy Templates, click Template Assignments to view your policy template, which is shown in Figure 8-8.

Figure 8-8 Shared Desktop template is created

Chapter 8. Shared desktop implementation 227 Now that we have created the shared desktop template and set the criteria, both new and existing machines that meet the criteria will be automatically assigned to the template.

If the policy does not appear to have been successfully applied after the AccessAgent synchronizes with the IMS Server, perform the following tasks: 1. Double-check the criteria that you have set and make sure the rules apply to the machines you want the template to apply to. To verify that the machine is receiving the correct template, use the AccessAdmin to search for the machine. After the machine is found, click on it to see the properties. One of the properties shows the assigned machine policy template. 2. If you are sure the criteria is correct, reboot the AccessAgent client system because certain settings require a reboot of the system in addition to the AccessAgent synchronization.

8.5 Conclusion

As we have shown, a variety of parameters can meet the different requirements in various corporate environments. Shared desktop is often most effective when used with a strong authentication factor like fingerprint, RFID, or USB keys, because users will not have to enter any authentication credentials. Additionally, when using proximity-based strong authenticators, the log on and log off workflows become more efficient for users because it requires no action on their part other than to walk away from the system.

228 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 9

Chapter 9. Tivoli Identity Manager implementation

In this chapter, we describe the integration between IBM Tivoli Access Manager for Enterprise Single Sign-On (TAM E-SSO) and IBM Tivoli Identity Manager.

First, we discuss the TAA business requirements of the integration. Next, we explain how and where to install the necessary components. Then, we describe how to deploy the adapter and workflow extension, and finally, we test the provisioning operations.

As described in “Current user and password management” on page 87, Tivoli Austin Airlines (TAA) uses IBM Tivoli Identity Manager (ITIM) to provision new accounts for Windows Active Directory, Lotus Notes, Tivoli Access Manager, and other applications. With the deployment of Tivoli Access Manager for Enterprise Single Sign-On, TAA now requires that Identity Manager automatically provision Tivoli Access Manager for Enterprise Single Sign-On users and user Wallets.

The integration of Identity Manager with Tivoli Access Manager for Enterprise Single Sign-On enriches the solution to the TAA emerging issues, as described in “Emerging issues” on page 87. The integration adds the following security features: Automatically provisions Tivoli Access Manager for Enterprise Single Sign-On users. TAA employees do not have to manually sign up for Tivoli Access Manager for Enterprise Single Sign-On. Automatically provisions user Wallets, filled with the credentials of all service accounts that Identity Manager manages (Lotus Notes, Identity Manager self-service, Ticketmeister, and so on). TAA employees do not have to interact with the AccessAgent to save or modify their credentials. Automatically synchronizes application passwords with the passwords stored in the user Wallet. Password enforcement and change is centrally managed.

The following sections describe the necessary steps to implement the integration between Identity Manager and Tivoli Access Manager for Enterprise Single Sign-On.

9.2 Implementation overview

In this section, we take a closer look at the integration environment shown in Figure 9-1 on page 231. All the components shown in the figure are discussed in detail in the following sections.

In our lab environment, we have used two distinct machines. The first machine is running both Tivoli Identity Manager and Tivoli Directory Integrator, the second machine hosts Tivoli Access Manager for Enterprise Single Sign-On.

230 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 9-1 Overview of the environment

9.2.1 What does the adapter do

You can use the Tivoli Identity Manager Adapter for IBM Tivoli Access Manager for Enterprise Single Sign-On (in short: adapter), which is located on the Tivoli Directory Integrator, to automate the following administrative tasks: Create new users on the Tivoli Access Manager for Enterprise Single Sign-On server. Delete user accounts on the Tivoli Access Manager for Enterprise Single Sign-On server. Reconcile users on the Tivoli Access Manager for Enterprise Single Sign-On server. Add and change a password, delete credentials in the user’s Tivoli Access Manager for Enterprise Single Sign-On Wallet.

The IBM Tivoli Identity Manager Server needs to communicate with the IMS Server to populate and manage credentials in the user’s Wallet. The adapter and workflow extension provide the interface between the IMS Server and Identity Manager. As depicted in Figure 9-1, the workflow extension uses the Tivoli Access Manager for Enterprise Single Sign-On service information in Tivoli

Chapter 9. Tivoli Identity Manager implementation 231 Identity Manager to connect to Directory Integrator. Directory Integrator (in all cases) communicates with the IMS Server.

After the workflow extensions have been added to Identity Manager and the Tivoli Access Manager for Enterprise Single Sign-On (TAM E-SSO) Service configured on Identity Manager, application accounts provisioned through Identity Manager will be enabled for single sign-on. This step can be configured for all accounts in the system or selected accounts. In this chapter, we configure the workflow to provide this capability for all accounts.

Note: Currently, the adapter does not support a direct password change for the Tivoli Access Manager for Enterprise Single Sign-On (IMS) user.

However, in typical IMS Server configurations, the IMS Server and Active Directory are set to synchronize passwords, so a password change for the AD Account in Identity Manager would also result in a password change for Tivoli Access Manager for Enterprise Single Sign-On.

9.2.2 Technical environment details

In this section, we examine the following details: Required software Configure the adapter Check software prerequisites and if necessary install FP3

Required software In this scenario, we use the following software components. IBM Tivoli Identity Manager Adapter for TAM E-SSO: http://www.ibm.com/support/docview.wss?uid=swg24019481 Tivoli Directory Integrator Fixpack 6.1.1 FP3: ftp://ftp.software.ibm.com/software/tivoli_support/patches/patches_6 .1.1/6.1.1-TIV-TDI-FP0003/ Tivoli Access Manager for Enterprise Single Sign-On AccessAgent 8.0 Tivoli Access Manager for Enterprise Single Sign-On version 8 IBM Tivoli Identity Manager version 4.6 Fixpack 54 and later, or version 5.0. In this scenario, we use Tivoli Identity Manager 5.0 FP3, available from: ftp://ftp.software.ibm.com/software/tivoli_support/patches/patches_5 .0.0.3/5.0.0.3-TIV-TIM-FP0003/

232 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Configure the adapter In 9.3, “Install and configure the adapter” on page 241, we describe the steps required to install and configure the adapter: Check that all prerequisites are installed Install the adapter profile Configure the IMS Server and SSL Create a Service to provision to IMS Reconcile with IMS service Verify IMS account creation

Check software prerequisites and if necessary install FP3 Check for the Tivoli Directory Integrator version in the Identity Manager server image. Tivoli Directory Integrator should be at version 6.1.1 FP3. If this is not the version you have, then you must install FP3. Follow these steps: 1. To check for the Tivoli Directory Integrator version, start the Tivoli Directory Integrator configuration editor by selecting: Start → All Programs → IBM Tivoli Directory Integrator v6.1.1 2. Select Help → About IBM Tivoli Directory Integrator, as shown in Figure 9-2.

Figure 9-2 Show version

Chapter 9. Tivoli Identity Manager implementation 233 3. Figure 9-3 indicates that the fixpack is not installed (version ididev_070207b).

Figure 9-3 IBM Tivoli Director version 6.1.1 without FixPack 3

Exit the Tivoli Directory Integrator Configuration Editor before proceeding, otherwise the fixpack installation might not succeed. The Tivoli Directory Integrator fixpack is located at: ftp://ftp.software.ibm.com/software/tivoli_support/patches/patches_6 .1.1/6.1.1-TIV-TDI-FP0003/6.1.1-TIV-TDI-FP0003.zip Extract the content into any folder. The package contains the file TDI_MAIN_IU.jar, which is required for installation. 4. To install this fixpack, launch the update installer by using the GMI tool. The default location for GMI tools is: C:\Program Files\IBM\Common\ci\gmi\bin. Start the GMI tool by using the gmi command. Ignore the error that is displayed, shown in Figure 9-4 on page 235, while launching GMI tool.

234 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 9-4 GMI tool warning

5. Click Next, in the Welcome to the Update Installer window. 6. In the Update Installer window, select Install maintenance packages such as fixes, fix packs or refresh packs, and click Next. The installer performs an offering query, which can take some time. 7. In the Choose the product to be updated window, shown in Figure 9-5 on page 236, select IBM Tivoli Directory Integrator v6.1.1 and click Next. If you have multiple instances of Tivoli Directory Integrator 6.1.1 on the same machine, select the one you want to apply the fixpack to. You can click the offering record in the list to check the details, such as installation directory and so on.

Chapter 9. Tivoli Identity Manager implementation 235 Figure 9-5 IBM Tivoli Directory Integrator, Update Installer

8. Select the path where you have extracted the Fixpack 3 (FP3) content and click Edit. If you receive the error shown in Figure 9-6, ignore it and click Continue.

Figure 9-6 GMI tool exception

236 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 9. In the left pane, shown in Figure 9-7, navigate to the directory where you extracted the fixpack, and then click Add to add it to the selected search paths. This folder is where GMI searches for applicable fixpacks for the selected offering. Then, click OK.

Figure 9-7 GMI tool, add search path

Chapter 9. Tivoli Identity Manager implementation 237 10.In the next dialog box, shown in Figure 9-8, click Next.

Figure 9-8 GMI tool search paths

11.The next dialog (Figure 9-9) lists the applicable fixpack found in the search directory. Select the check box for FP0003, and click Next.

Figure 9-9 GMI tool, select package to install

238 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 12.Select the check box to install maintenance on this computer and click Next as shown in Figure 9-10.

Figure 9-10 GMI tool, install maintenance package

13.The next dialog (Figure 9-11) displays a summary. Verify that everything is correct and click Install.

Figure 9-11 GMI tool, install now

Chapter 9. Tivoli Identity Manager implementation 239 14.After the fixpack is installed successfully, shown in Figure 9-12, click Finish.

Figure 9-12 GMI tool, finish window

The build number for Tivoli Directory Integrator in the About dialog now reflects the new version as shown in Figure 9-13.

Figure 9-13 IBM Tivoli Director version 6.1.1 with FixPack 3 installed

240 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 9.3 Install and configure the adapter

Four steps must be completed to prepare Tivoli Directory Integrator when installing the Tivoli Access Manager for Enterprise Single Sign-On adapter: 1. Update the RMI Dispatcher. 2. Install the TAM E-SSO connector. 3. Install the SQL Server JDBC driver (if using SQL Server as the IMS Server DB). 4. Install the adapter profile in Identity Manager.

After the Directory Integrator preparations are complete, we have to continue with the following three steps: 1. Configure the IMS Server. 2. Configure SSL between RMI Dispatcher and IMS Server. 3. Create the TAM E-SSO Service in Tivoli Identity Manager.

Finally, we verify our configuration.

Before we can begin our first steps, you have to extract the Tivoli Access Manager for Enterprise Single Sign-On adapter file into a directory. In our scenario, we extracted the adapter to: D:\Software\Adapters\TAME-SSO_Adapter_5.0.1

9.3.1 Update the RMI Dispatcher

We have to update Tivoli Directory Integrator RMI Dispatcher to version 5.008: 1. To check the current version of the RMI dispatcher, look at the Tivoli Directory Integrator adapter log file, ibmdi.log (excerpt shown in Figure 9-14 on page 242) in the following directory: C:\Program Files\IBM\TDI\V6.1.1\timsol\logs For Linux and UNIX, the log is in the directory. In this example, the current version of the RIM dispatcher is version 5.007.

Chapter 9. Tivoli Identity Manager implementation 241 Figure 9-14 Log file showing RMI Dispatcher version 5.007

2. If the installed version is not version 5.008, extract the Adapter-Dispatcher-5.008.zip file to a directory. In our example, this file is located in: D:\Software\Adapters\TAMESSO_Adapter_5.0.1 3. Run the RMI Dispatcher installer for your platform. In this scenario, run DispatcherInstallWin.exe. Accept the defaults for the installer program to install the new version of the dispatcher. 4. In the Welcome window, shown in Figure 9-15, click Next.

Figure 9-15 RMI Dispatcher installation

242 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. If you accept the terms in the license agreement, click Next. 6. Accept the installation path (shown in Figure 9-16) and click Next.

Figure 9-16 RMI Dispatcher installation, choose installation path

7. In the next window, shown in Figure 9-17, click Next.

Figure 9-17 RMI Dispatcher installation, start installation

Chapter 9. Tivoli Identity Manager implementation 243 8. Click Install, as shown in Figure 9-18, to start the installation.

Figure 9-18 RMI Dispatcher installation, install window

9. Verify that the RMI Dispatcher installed successfully and click Finish, as shown in Figure 9-19.

Figure 9-19 RMI Dispatcher installation, finish window

244 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 9.3.2 Install the TAM E-SSO connector

To install the Tivoli Access Manager for Enterprise Single Sign-On (TAM E-SSO) connector: 1. Locate the file TAMESSOConnector.jar file that is shipped with the TAMESSO_Adapter_5.0.1.zip file. In our example, it is copied to directory: D:\Software\Adapters\TAMESSO_Adapter_5.0.1 2. Copy the file to the Tivoli Directory Integrator jars directory at: C:\Program Files\IBM\TDI\V6.1.1\jars\connectors

9.3.3 Install the SQL Server JDBC driver

For this process, be sure you have connection to the Tivoli Access Manager for Enterprise Single Sign-On server. Follow these steps: 1. Map a drive from the Directory Integrator server to the Tivoli Access Manager for Enterprise Single Sign-On server by selecting: Start → Run (Figure 9-20).

Figure 9-20 Start a CMD

Chapter 9. Tivoli Identity Manager implementation 245 2. Enter the server name, which in this example is \\tamesso\C$, and click OK as shown in Figure 9-21.

Figure 9-21 Connect to Tivoli Access Manager for Enterprise Single Sign-On

3. Connect to the domain. Use the credentials with sufficient rights for connection to the domain (Figure 9-22).

Figure 9-22 Log on to the Tivoli Access Manager for Enterprise Single Sign-On

4. Copy the following.jar file, also shown in Figure 9-23 on page 247: \\tamesso\C$\Encentuate\IMSServer8.0.0.12\ims\WEB-INF\lib\sqljdbc.jar Paste it into: C:\Program Files\IBM\TDI\V6.1.1\jars\3rdparty\others

246 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 9-23 Source location of sqljdbc.jar

Restart the RMI Dispatcher

Use the services console to restart the Tivoli Directory Integrator RMI Dispatcher on the Directory Integrator Server, as shown in Figure 9-24. The service is named IBM Tivoli Identity Manager Adapter.

Figure 9-24 Services, restart IBM Tivoli Identity Manager Adapter

Chapter 9. Tivoli Identity Manager implementation 247 9.3.4 Install the adapter profile in Identity Manager

To install the profile: 1. Start Microsoft Internet Explorer and navigate to the IBM Tivoli Identity Manager 5.0 Welcome page, in this example http://winserv as shown in Figure 9-25.

Figure 9-25 IBM Tivoli Identity Manager Welcome page

248 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 2. Click Identity Manager Admin Console as shown in Figure 9-26.

Figure 9-26 Start Identity Manager Admin Console

3. Alternatively, you can open up a browser window and go to the Web address directly, which in our example is: http://winserv:9080/itim/console

Chapter 9. Tivoli Identity Manager implementation 249 4. On the IBM Tivoli Identity Manager server, log in to the Identity Manager administrative console as a user, shown in Figure 9-27, who is a member of the ITIM group Administrators.

Figure 9-27 Log on to IBM Tivoli Identity Manager

250 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. Navigate to Configure System → Manage Service Types (Figure 9-28).

Figure 9-28 Navigate to Manage Service Types

6. In our example, eight service types are currently installed, shown in Figure 9-29 on page 252. Click Import to install the service type for the Tivoli Access Manager for Enterprise Single Sign-On adapter.

Chapter 9. Tivoli Identity Manager implementation 251 Figure 9-29 Show installed Service Types

7. Browse to the location of the TAMESSOprofile.jar file, which is part of the TAMESSO_Adapter_5.0.1.zip file. We have copied it to the following location: D:\Software\Adapters\TAMESSO_Adapter_5.0.1\TAMESSOProfile.jar. 8. Click OK, as shown in Figure 9-30. Importing can take several minutes to complete. it will take a minute or two for the import to complete.

Figure 9-30 Import Service Types - Enter location of .jar file to import

252 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 9. Verify the successful installation by tailing the Tivoli Identity Manager trace.log file. The message dialog shown in Figure 9-31 states that only the import request was successfully submitted. Typically, this window displays immediately after clicking the import's OK button, but the actual profile import might take a while to complete. Click Close.

Figure 9-31 Import Service Type, verification

10.Back on the Manage Service Types window, there should be a new Service Type TAM E-SSO Profile as shown in Figure 9-32. Because this can take some time, you might have to click the Refresh button.

Figure 9-32 Show installed Service Types, including TAM E-SSO Profile

Chapter 9. Tivoli Identity Manager implementation 253 9.3.5 Configure the IMS Server

The adapter must authenticate with the IMS Server. The authentication is done using a shared secret between the adapter and the IMS Server, which we configure in the following steps: 1. Click Log On to log on using the Tivoli Access Manager for Enterprise Single Sign-On GINA.

Figure 9-33 AccessAgent Welcome window

2. Log on to the IBM Tivoli Access Manager for Enterprise Single Sign-On server as a member of the Administrators group. 3. On the IMS Server, use the IMS Configuration Utility to configure these settings. Start the IMS Configuration Utility using the following path: Start → All Programs → TAM E-SSO IMS Server → TAM E-SSO IMS Configuration Utility

254 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 4. Click IMS Bridges (under Advanced settings) as shown in Figure 9-34.

Figure 9-34 Navigate to IMS Bridges

Chapter 9. Tivoli Identity Manager implementation 255 5. Select IMS Bridge from the Add configuration group drop-down menu and click Configure, as shown in Figure 9-35.

Figure 9-35 Configure IMS Bridge

6. As shown in Figure 9-36 on page 257: a. Define a Name and an IMS Bridge password (shared secret) in the available text boxes. Here, TIM2TAMESSO is used as IMS Bridge name. b. Enter an IMS Bridge IP address value. This value should be the IP address of the system where Tivoli Directory Integrator is installed. In our example, it is 192.168.210.10 for the IBM Tivoli Identity Manager server (which is co-located with the Directory Integrator server). Click the Add button, next to the IP address to add the IP address. c. Ensure that the value for IMS Bridge Type is set to Provisioning.

256 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 9-36 Add IMS Bridge IP address

7. Now click the Add button at the bottom of the form as depicted in Figure 9-37 on page 258.

Chapter 9. Tivoli Identity Manager implementation 257 Figure 9-37 Save settings to IMS Bridge

8. Verify that the new IMS Bridge is in the list, as shown in Figure 9-38 on page 259.

258 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 9-38 IMS Bridge verification

9. Restart the IMS service for the changes to take effect by executing the following two paths: Start → All Programs → TAM E-SSO IMS Server → Stop IMSService Start → All Programs → TAM E-SSO IMS Server → Start IMSService

9.3.6 Configure SSL between RMI Dispatcher and IMS Server

To enable secure communication between the adapter and the IMS Server, keystores have to be configured for the RMI Dispatcher.

Create a keystore that contains the IMS Server’s SSL certificates as trusted certificate entries. You can use Internet Explorer to download the IMS Server’s SSL certificate into the Windows certificate store. In this step we have to create a keystore that contains the IMS Server’s SSL certificates as trusted certificate entries. You can use Internet Explorer to download the IMS Server’s SSL certificate into the Windows certificate store.

Chapter 9. Tivoli Identity Manager implementation 259 Follow these steps: 1. Navigate to the following link, (where tamesso is the IMS Server’s host name) and click the SSL lock icon to view the certificate: https://tamesso/ 2. From the IBM Tivoli Directory Integrator server point your browser to Tivoli Access Manager for Enterprise Single Sign-On using https://tamesso. If you get a message as shown in Figure 9-39, click Continue to this website.

Figure 9-39 Open the TAM E-SSO Web site to configure SSL

260 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. At the top of the browser, as shown in Figure 9-40, click Certificate Error to view the certificate details.

Figure 9-40 Certificate Error used to configure SSL

4. In the pop-up window, click View certificates, as shown in Figure 9-41.

Figure 9-41 Certificate status

Chapter 9. Tivoli Identity Manager implementation 261 5. Click the Details tab, as shown in Figure 9-42.

Figure 9-42 Click the certificate Details tab

262 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 6. Click Copy to File, as shown in Figure 9-43.

Figure 9-43 Copy certificate to file

7. In the Certificate Export Wizard Welcome page, as shown in Figure 9-44, click Next.

Figure 9-44 Certificate Export Wizard

Chapter 9. Tivoli Identity Manager implementation 263 8. Save the certificate in Base-64 encoded X.509 (.CER) format and then click Next as shown in Figure 9-45.

Figure 9-45 Certificate export format: Base-64 encoded X,509 (.CER)

9. Save the certificate as ims.cer in the following directory and then click Next, as shown in Figure 9-46: C:\Program Files\IBM\itim\data\keystore

Figure 9-46 Certificate filename

264 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Because we do not have a keystore or truststore configured for Tivoli Directory Integrator, we have to create a keystore file with the IMS Server certificate and use this file for both the keystore and truststore values required for the Tivoli Directory Integrator RMI Dispatcher. Use the keytool utility in the Tivoli Directory Integrator installation directory to create a new keystore. In this example we create a new keystore in the C:\Program Files\IBM\ITIM\data\keystore directory. 10.At a command prompt on the Identity Manager Server, enter the following command to create a new keystore: C:\Program Files\IBM\TDI\V6.1.1\jvm\jre\bin\keytool.exe -import -file "c:\program files\ibm\itim\data\keystore\ims.cer" -keystore "c:\program files\ibm\itim\data\keystore\tdikeys.jks 11.When prompted, enter a password for the keystore. The keystore file is created. The final command line output is depicted in Figure 9-47.

Figure 9-47 Keystore is created

12.Edit the Tivoli Directory Integrator solutions.properties file located in: C:\Program Files\IBM\TDI\V6.1.1\timsol In the current release, only jks-type is supported. Locate the sections in bold in Example 9-1 on page 266, and make the changes. In our example, the password is passw0rd.

Chapter 9. Tivoli Identity Manager implementation 265 Example 9-1 Tivoli Directory Integrator solutions.properties file ## server authentication ## example ## javax.net.ssl.trustStore=d:\test\KeyRings\namtp2.jks ## javax.net.ssl.trustStorePassword=secret ## javax.net.ssl.trustStoreType=jks

javax.net.ssl.trustStore=C:\Program Files\IBM\ITIM\data\keystore\tdikeys.jks {protect}-javax.net.ssl.trustStorePassword=passw0rd javax.net.ssl.trustStoreType=jks

## client authentication ## example ## javax.net.ssl.keyStore=d:\test\KeyRings\namtp2.jks ## javax.net.ssl.keyStorePassword=secret ## javax.net.ssl.keyStoreType=jks

javax.net.ssl.keyStore=C:\Program Files\IBM\ITIM\data\keystore\tdikeys.jks {protect}-javax.net.ssl.keyStorePassword=passw0rd javax.net.ssl.keyStoreType=jks

13.After modifying the solution.properties file, you must restart the Tivoli Identity Manager Adapter Service (RMI Dispatcher) as you did before in “Restart the RMI Dispatcher” on page 247.

9.3.7 Create the TAM E-SSO Service in Tivoli Identity Manager

To create the TAM E-SSO Service: 1. Log in to the Identity Manager Admin Console if you are not already logged in. 2. Navigate to Manage Services, shown in Figure 9-48 on page 267.

266 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 9-48 IBM Tivoli Identity Manager - Manage Services

3. Click Create to create a new service, as shown in Figure 9-49.

Figure 9-49 Create a new service

Chapter 9. Tivoli Identity Manager implementation 267 4. Navigate to page 2, as shown in Figure 9-50, select the service type TAM E-SSO Profile from the service type list, and then click Next.

Figure 9-50 Select TAM E-SSO Profile

268 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. Provide a name for the service and the location of the Tivoli Directory Integrator RMI Dispatcher. Optionally, specify a service owner and service prerequisite. See Figure 9-51.

Figure 9-51 Enter a new service name

Chapter 9. Tivoli Identity Manager implementation 269 6. Click Next to go to the next page of configuration information (Figure 9-52).

Figure 9-52 Adapter Details for Bridge

Here, you provide information about the Bridge Name that you specified in the IMS configuration utility on the IMS Server at step 6 on page 259. a. Use the IP address for the Tivoli Access Manager for Enterprise Single Sign-On server DNS name (192.168.210.120 in our example). b. The Bridge Name we used was TIM2TAMESSO. c. The password we specify in our example is passw0rd. d. Select the check box for Strip domain name from user ID during reconciliation. 7. Complete the Tivoli Access Manager for Enterprise Single Sign-On Database details information (Figure 9-53 on page 271). Click Next to continue. The final set of configuration details for the adapter is to specify the IMS database name, database user, and database password and other information (if default values were not used). In this example, we use the following values: – As the TAM E-SSO Database Name use imsdb0. – As the Database Administrator Account Name use sa.

270 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Note: The default port for Microsoft SQL Server is 1433, for IBM DB2 it is 50000, and for Oracle it is 1701.

Figure 9-53 Adapter Details for Database

For now, we leave the Application Accounts Mapping parameters blank and return to that configuration in the next section where we configure the workflow to provision account IDs and passwords to the users’ Wallets. Now is a good time to test the connection to determine if our connection parameters are correctly defined. Click the Test Connection button. If all is well, you see the message depicted in Figure 9-54 on page 272.

Chapter 9. Tivoli Identity Manager implementation 271 Figure 9-54 Adapter connection test

8. Click Finish, as shown in Figure 9-55, to end this part of the configuration.

Figure 9-55 Save adapter configuration

9.3.8 Verify the configuration

If the test is successful, run a reconciliation to retrieve all the user accounts defined on the IMS Server.

In this section, we use the user account Denis Lacey for further tests.

272 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 To verify the configuration: 1. Navigate back to Manage Services on the left panel. Now, locate the TAM E-SSO IMS Server Service in the right panel and click the arrow next to the name to expand the task list for the service shown in Figure 9-56.

Figure 9-56 Select a service task

2. Select Reconcile Now.

Chapter 9. Tivoli Identity Manager implementation 273 3. Submit the request with base parameters as shown in Figure 9-57.

Figure 9-57 Submit reconciliation

274 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 4. After you have submitted the reconciliation, you may view the status of the request by clicking View the status of the reconciliation request, as shown in Figure 9-58.

Figure 9-58 View reconciliation results

5. Scroll down to view the results as shown in Figure 9-59.

Figure 9-59 Reconciliation success

Chapter 9. Tivoli Identity Manager implementation 275 6. Return to the Manage Services tab and select the Accounts… task (refer to Figure 9-56 on page 273) to view the accounts on the TAM E-SSO IMS Service service. The IMS registered users that have just been reconciled are listed, as shown in Figure 9-60.

Figure 9-60 List currently registered IMS users

7. Go to Manage Users tab and search for the person you want to request new accounts for. In this example, we use Denis Lacey (Figure 9-61).

Figure 9-61 Search a user

276 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 8. Next to Denis Lacey’s name, as shown in Figure 9-62, click the small arrow to access the task list, and select Request Accounts.

Figure 9-62 Request new accounts

Chapter 9. Tivoli Identity Manager implementation 277 9. Click Search search all available service types, as shown in Figure 9-63.

Figure 9-63 Search services

278 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 10.Select the TAM E-SSO IMS Server Service and click Continue, as shown in Figure 9-64.

Figure 9-64 Choose a service

Chapter 9. Tivoli Identity Manager implementation 279 11.In this example, keep user ID dlacey. Click Continue, as in Figure 9-65.

Figure 9-65 Select a user ID for new account

280 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 12.Set the password to passw0rd (in this example, the password is the same as Denis Lacey’s Active Directory password) and click Submit as in Figure 9-66.

Figure 9-66 Set password for new account

13.Click View my requests and check the status for the request, shown in Figure 9-67.

Figure 9-67 Verify requested account

14.If successful, switch to the IMS Server machine.

Note: If still logged in as Administrator, log off to get to the AccessAgent login dialog.

Chapter 9. Tivoli Identity Manager implementation 281 15.Click Log On log in as user dlacey and use the password passw0rd that you specified when you created the account. See Figure 9-68. Tivoli Access Manager for Enterprise Single Sign-On is configured to synchronize passwords with Active Directory. Because this is the first time dlacey has logged in to Tivoli Access Manager for Enterprise Single Sign-On, you have to supply your answer to a secret question to access the Wallet and set a new Wallet password.

Figure 9-68 Log on with new account

16.Because this is the first logon for dlacey, click Yes to confirm first time sign-up; see Figure 9-69.

Figure 9-69 First time sign up

282 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 17.Answer the question What’s your favorite color? and click Finish, as in Figure 9-70.

Figure 9-70 Enter secret answer

We have now verified that the Tivoli Access Manager for Enterprise Single Sign-On IMS account provisioning from Identity Manager is working.

9.4 Configure the workflow extensions

When new accounts are provisioned by Identity Manager for a user that is also a Tivoli Access Manager for Enterprise Single Sign-On registered user, we want to populate the account’s logon ID and password that was provisioned by Identity Manager to the user’s Wallet so it will be enabled for single sign-on. That is, when the user accesses the account or application for the first time, that user is automatically logged in if the user has authenticated to Tivoli Access Manager for Enterprise Single Sign-On. This step is sometimes referred to as zero touch provisioning, because the user does not have to know the user ID or password for new accounts if the user is using Tivoli Access Manager for Enterprise Single Sign-On.

Chapter 9. Tivoli Identity Manager implementation 283 Note: Operational workflows for accounts can be modified in two ways: at the Account Entity Type Level, which would apply to ALL accounts; or at the Entity Level, in which case you select the entity type and the entity (LDAP, Linux, Windows, and so on) you want the workflows to apply.

For our examples, we modify the workflows for the specific account types we wish to participate in single sign-on. We work with Tivoli Access Manager for Enterprise Single Sign-On accounts, Identity Manager accounts, Windows Active Directory, and Windows local accounts. You would follow similar steps to enable other account types for SSO.

In the next sections, we add custom workflow extensions to the account operations for the Identity Manager account to provide these capabilities: Add Account This extension adds the account ID and password to the user’s Wallet. Change Password This extension updates the user’s Wallet with the account’s new password. Delete Account This extension removes the account from the user’s Wallet.

We also modify the operation workflow for the Tivoli Access Manager for Enterprise Single Sign-On account to restrict the user to one Tivoli Access Manager for Enterprise Single Sign-On account and to prevent a password change operation because changing the Tivoli Access Manager for Enterprise Single Sign-On password is not supported.

9.4.1 Add workflow extension to Identity Manager

Several workflow extensions are included with the adapter distribution. To include these extensions in the Identity Manager configuration: The workflowextensions.xml file has to be updated to include the definitions for the new extensions. The .jar file containing the extensions has to be added to the WebSphere classpath.

Note: A best practice is to place this .jar file outside the application path, because a Fixpack that is applied might remove the .jar file.

284 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 The four extensions are: encAddAccount encChangePassword encDeleteAccount hasImsAccount

The following steps describe the configuration details: 1. Locate the file enc_workflow_sample.xml in the following directory: D:\Software\Adapters\TAMESSO_Adapter_5.0.1 2. Copy the contents of this file, as shown in Figure 9-71, to the clipboard. Do not include the Note at the end of this file.

Figure 9-71 Workflow sample contents

3. Open the workflowextensions.xml file in the following directory: C:\Program Files\IBM\itim\data\workflowextensions.xml

Note: You might want to make a copy of the workflowextensions.xml file before you edit it.

Chapter 9. Tivoli Identity Manager implementation 285 4. Paste the clipboard contents of enc_workflow_sample.xml file into the file named workflowextensions.xml just before the end tag labeled , and then save the file, as in Figure 9-72.

Figure 9-72 Paste sample contents to workfloxextensions.xml

5. Copy the TAMESSOWfe501.jar file that is included with the adapter files (TAMESSO_Adapter_5.0.1.zip) to the following WebSphere directory: C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\winser vNode01Cell\ITIM.ear\app_web.war\WEB-INF\lib

Note: Although we are following the documented option to place the .jar file into the application’s lib directory, it is considered best practice to store the .jar file outside the application's path, and register the .jar file in the "ITIM_LIB" shared library in WebSphere. This way, the .jar file is less likely to be removed during Fixpack installations or Tivoli Identity Manager upgrades.

286 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 6. If the lib directory does not exist, create the directory before copying the file. See Figure 9-73.

Figure 9-73 Default destination location of TAMESSOWfe501.jar

7. Restart the Identity Manager application by using the WebSphere administrative console. In our example, the console can be accessed at http://winserv:9060/ibm/console. Click Continue to this website, as shown in Figure 9-74.

Figure 9-74 WebSphere administrative console start-up

Chapter 9. Tivoli Identity Manager implementation 287 8. WebSphere security is enabled, so log in as wasadmin, shown in Figure 9-75.

Figure 9-75 WebSphere Admin Console Welcome window

9. Navigate to Applications → Enterprise Applications. Select ITIM and click Stop to stop the application, as in Figure 9-76.

Figure 9-76 Stop IBM Tivoli Identity Manager application

288 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 10.Verify that the application has stopped, then restart the application again. 11.Verify that the application started successfully, as in Figure 9-77. You can now log out and exit the WebSphere Application Server Admin console.

Figure 9-77 Exit WebSphere Admin Console

9.4.2 Define workflow for Service Add Account operations

We want our users to be able to access the Identity Manager self-service user interface and participate in single sign-on. So, the first application we enable for single sign-on is the Identity Manager Self-Service UI. The user must have an Identity Manager account in order to access the Self-Service console, so we configure the workflow for the Identity Manager account.

Chapter 9. Tivoli Identity Manager implementation 289 To define the workflow: 1. Log in to the Identity Manager Admin console by navigating to http://winserv/ and then clicking Identity Manager Admin Console, as in Figure 9-78.

Figure 9-78 IBM Tivoli Identity Manager Welcome window

290 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 2. Log in as an Administrator, in our example (Figure 9-79), this is mstevens.

Figure 9-79 IBM Tivoli Identity Manager logon window

Chapter 9. Tivoli Identity Manager implementation 291 3. Navigate to Configure System → Manage Operations (Figure 9-80).

Figure 9-80 Manage operations

292 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 4. As shown in Figure 9-81, select Entity Level as the Operation Level, select Identity Manager User as Entity type, and select ITIMAccount as the Entity. In the table, select the add operation check box, and then click the Change.

Figure 9-81 Change operation

The workflow designer is launched, as shown in Figure 9-82 on page 294.

Chapter 9. Tivoli Identity Manager implementation 293 Figure 9-82 Workflow designer - add operation

294 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. In the workflow, make the following changes, shown in Figure 9-83: a. Delete the transition line from CREATEITIMACCOUNT to End. b. Drag a new Extension node on to the workflow and insert it between the CREATEITIMACCOUNT Extension and End.

Figure 9-83 Workflow designer - new extension

Note: As a best practice, consider having transitions for both success and failed requests. The success transition would connect to the Extension node, and the failed transition would connect directly to the End node. This way, you do not end up with credentials in your Wallet for an account that failed to get created.

In our scenario, we have created only the success path.

In a real-life deployment, the failed path should be added to each operation, so passwords do not become out of sync if the CHANGEPASSWORD extension fails.

Chapter 9. Tivoli Identity Manager implementation 295 6. Configure the extension by double-clicking on the node to open the properties for the extension. Enter the parameters shown Figure 9-84. Then, click OK.

Figure 9-84 Workflow designer - edit properties

296 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 7. Scroll to the end of the page and click OK to save the workflow changes. See Figure 9-85. You are returned to the Manage Operations view.

Figure 9-85 Workflow designer - save your changes

Note: Clicking OK is sometimes easy to forget. If you do not click OK here, the workflow is not saved.

8. Verify that the workflow was changed successfully. See Figure 9-86.

Figure 9-86 Operation saved successfully

9.4.3 Define workflow for Change Password Operation

When the user changes an Identity Manager account password, we want the password to also be updated in the user’s Wallet. To do this, we modify the Change Password Operation for the ITIM account.

Chapter 9. Tivoli Identity Manager implementation 297 To define the workflow: 1. Back at Manage Operations, select Entity level as the Operation Level, Identity Manager User as the Entity type, and ITIMAccount as the Entity. Click Add. See Figure 9-87.

Figure 9-87 Add operation

2. Enter the new Operation Name changePassword and click Continue, as shown in Figure 9-88.

Figure 9-88 Enter operation name

298 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 The workflow designer is launched. The standard Account changePassword operational workflow is copied into the designer workspace, as in Figure 9-89.

Figure 9-89 Workflow designer - password change

Chapter 9. Tivoli Identity Manager implementation 299 3. As in a previous step, drag an Extension node to the workflow and connect it between the CHANGEPASSWORD and End nodes. Do not forget to delete the connection between the CHANGEPASSWORD and the End node (Figure 9-90).

Figure 9-90 Workflow designer - new extension

300 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 4. Configure the extension by double-clicking on the node to open the properties for the extension. Enter the parameters shown in Figure 9-91. Set the Extension Name to encChangePassword. Click OK.

Figure 9-91 Workflow designer - extension properties

Chapter 9. Tivoli Identity Manager implementation 301 5. Scroll to the end of the page and click OK to save the workflow changes. See Figure 9-92. You will return to the Manage Operations view.

Figure 9-92 Save workflow

6. Verify the changePassword operation is saved successfully (Figure 9-93).

Figure 9-93 Verify Workflow

302 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 9.4.4 Define workflow for Delete Account Operation

In this step we make a similar modification to the Delete Account Operation.

To define the workflow: 1. Return to Manage Operations, select Entity level as the Operation Level, Identity Manager User as the Entity type, and ITIMAccount as the Entity. Click Add. See Figure 9-94.

Figure 9-94 Add operation

2. Enter Operation Name delete and click Continue, as in Figure 9-95.

Figure 9-95 Enter operation name

Chapter 9. Tivoli Identity Manager implementation 303 The workflow designer is launched. The standard Account delete operational workflow is copied into the designer workspace as shown in Figure 9-96.

Figure 9-96 Workflow designer - delete operation

304 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. As in a previous step, drag in an Extension node and connect it between the DELETEACCOUNT and End nodes. Do not forget to delete the connection between the CHANGEPASSWORD and the End node. See Figure 9-97.

Figure 9-97 Workflow designer - add new extension

Chapter 9. Tivoli Identity Manager implementation 305 4. Configure the extension by double-clicking on the node to open the properties for the extension. Enter the parameters shown in Figure 9-98. Set the Extension Name to encDeleteAccount. Click OK. See Figure 9-98.

Figure 9-98 Workflow designer - edit properties

306 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. Scroll to the end of the page and click OK to save the workflow changes. See Figure 9-99.

Figure 9-99 Save changes

6. You are returned to the Manage Operations view. Verify the operation was saved successfully.

This completes the workflow changes necessary to make to the Identity Manager account provisioning. Next we update the Tivoli Access Manager for Enterprise Single Sign-On account provisioning workflow.

9.4.5 Define workflow for preventing multiple accounts (IMS)

In this step, we modify the workflow for the Add Account Operation for the entity TAM E-SSO account. This workflow ensures that only one TAM E-SSO account gets created for a single person.

Chapter 9. Tivoli Identity Manager implementation 307 To define the workflow: 1. In Manage Operations, select Entity level as the Operation Level, Account as the Entity type, and TAMESSOAccount as the Entity. See Figure 9-100. Click Add to create a new Add operation workflow for the TAM E-SSO account.

Figure 9-100 Add new operation for TAMESSOAccount

2. Enter the operation name of Add. Click Continue. See Figure 9-101.

Figure 9-101 Enter operation name

308 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. In the workflow designer, as shown in Figure 9-102, delete the transition line from Start to CREATEACCOUNT. Right-click the line and delete it. Keep the other connections.

Figure 9-102 Workflow designer - delete existing extension

Chapter 9. Tivoli Identity Manager implementation 309 4. Drag in a new Extension node and connect the nodes (from CREATEACCOUNT to Extension and from Extension to End) as shown in Figure 9-103.

Figure 9-103 Design new add account workflow

310 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. Open the properties of the new extension node and configure it as shown in Figure 9-104.

Figure 9-104 Workflow designer - extension properties

Chapter 9. Tivoli Identity Manager implementation 311 6. In the resulting workflow diagram, click the workflow Properties button, as shown in Figure 9-105, to configure the skipFlag variable.

Figure 9-105 Workflow designer - edit workflow properties

7. In the Properties dialog, shown in Figure 9-106, click Add to define the skipFlag relevant data.

Figure 9-106 Edit workflow properties

312 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 8. Define the ID as skipFlag. The Type is String and Default Value is false as shown in Figure 9-107. Click OK to save.

Figure 9-107 Define skipFlag

9. Back in the Properties dialog, click OK again, shown in Figure 9-108.

Figure 9-108 Save workflow properties

Chapter 9. Tivoli Identity Manager implementation 313 10.Edit the properties for the transition line from HASIMSACCOUNT to End by double-clicking the line, shown in Figure 9-109.

Figure 9-109 Workflow designer - edit transition properties, skipFlag true

11.As shown in Figure 9-110: a. Set the condition by adding JavaScript that evaluates whether skipFlag is true: skipFlag.get() == "true"; b. Click OK.

Figure 9-110 Workflow designer - change transition properties

314 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 12.Edit the properties for the transition line from HASIMSACCOUNT to CREATEACCOUNT as shown in Figure 9-111.

Figure 9-111 Workflow designer - edit transition properties, skipFlag false

13.As shown in Figure 9-112: a. Set the condition to the JavaScript that evaluates whether skipFlag is false: skipFlag.get() == "false"; b. Click OK.

Figure 9-112 Workflow designer - change transition properties

Chapter 9. Tivoli Identity Manager implementation 315 14.The workflow definition is now complete. Click OK (Figure 9-113) and return to the Manage Operations view.

Figure 9-113 Workflow designer - save changes

15.Verify that the operation is saved successfully (Figure 9-114).

Figure 9-114 Workflow designer - verify result

316 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 9.4.6 Modify workflow to disable Change Password Operation

To modify workflow: 1. In Manage Operations, click Add, with the parameters selected as shown in Figure 9-115.

Figure 9-115 Workflow designer - add operation

2. Enter the Operation name changePassword and click Continue (Figure 9-116).

Figure 9-116 Add change password operation

Chapter 9. Tivoli Identity Manager implementation 317 3. The standard Account CHANGEPASSWORD operational workflow is copied into the designer workspace, as shown in Figure 9-117.

Figure 9-117 Workflow designer - change password

318 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 4. Delete the CHANGEPASSWORD extension (right-click the extension) as shown in Figure 9-118.

Figure 9-118 Workflow designer - delete extension

Chapter 9. Tivoli Identity Manager implementation 319 5. Add (by dragging) a Script node and connect it to Start and End, as shown in Figure 9-119.

Figure 9-119 Workflow designer - add script

6. Open the Script Node and name it NOPasswordChange, as in Figure 9-120.

Figure 9-120 Workflow designer - edit Script Node properties

7. Add the JavaScript, shown in Example 9-2 on page 321, to set the Result and ResultDetail for the operation indicating that a password change is not allowed for the TAM E-SSO account. Then, click OK.

320 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Example 9-2 JavaScript for NOPasswordChange WorkflowRuntimeContext.setProcessResult(activity.FAILED); WorkflowRuntimeContext.setProcessResultDetail("Password change is not allowed for TAM E-SSO account");

8. Click OK to save the workflow, shown in Figure 9-121.

Figure 9-121 Workflow designer - save changes

Chapter 9. Tivoli Identity Manager implementation 321 9. Verify that the operation changePassword is saved successfully, (Figure 9-122).

Figure 9-122 Workflow designer - verify result

10.Close the workflow designer.

322 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 9.5 Test the provisioning operations

In our scenario, the requirements for our provisioning process are: 1. A new user is first provisioned with an Active Directory (AD) account. A user must have an AD account before being provisioned with a Tivoli Access Manager for Enterprise Single Sign-On account. 2. The user is then provisioned with a Tivoli Access Manager for Enterprise Single Sign-On account to provide single sign-on to additional applications that are provisioned later. 3. The user is provisioned with an Tivoli Identity Manager account. The SSO profile and user credentials for the Identity Manager account are directly provisioned to the user’s Wallet. 4. Additional accounts are provisioned to the user and the corresponding SSO credentials are also stored in the user’s Wallet.

Identity Manager Service prerequisites will be configured to support these requirements.

9.5.1 Create authorization service for Self-Service Console

We want our new users to be able to use single sign-on to the Identity Manager Self-Service Console so they can manage their accounts and passwords. We have to create an application profile for the Identity Manager Self-Service Console.

Chapter 9. Tivoli Identity Manager implementation 323 To create the profile: 1. On the Tivoli Access Manager for Enterprise Single Sign-On server, click Log On and log on using an Administrator account, as in Figure 9-123.

Figure 9-123 Log On window

2. In the IMS Server, launch AccessStudio by selecting: Start → All Programs → TAM E-SSO AccessStudio → AccessStudio

324 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. Select New → New AccessProfile (using Assistant); see Figure 9-124.

Figure 9-124 Create New AccessProfile

4. On the TAM E-SSO AccessStudio Welcome window, click Next to continue.

Chapter 9. Tivoli Identity Manager implementation 325 5. Open up a browser window and navigate to the URL to the Tivoli Identity Manager Self-Service Console, in our example, shown in Figure 9-125: http://192.168.210.10:9080/itim/self

Figure 9-125 IBM Tivoli Identity Manager Self-Service Console

326 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 6. Return to the AccessProfile Generator window (Figure 9-126). Provide an Application Name, in our example TIMSelfUI. Select Web application as the Application Type, and click Next.

Figure 9-126 AccessStudio - application window

Chapter 9. Tivoli Identity Manager implementation 327 7. On the next page (Figure 9-127) select Logon as the task to automate. Click Next.

Figure 9-127 AccessStudio - task selection window

328 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 8. Match the crosshairs with the fields for logon. As shown in Figure 9-128, drag and drop the Username/Id crosshair into the application’s User ID, the Password crosshair into the Password field, and the OK button crosshair into the Log In button. Click Next.

Figure 9-128 AccessStudio - integrate application credential fields

Chapter 9. Tivoli Identity Manager implementation 329 9. Keep the defaults on the remaining windows (Figure 9-129 and Figure 9-130 on page 331) including the option to Create Authentication Service automatically (Figure 9-131 on page 332). Click Next in each window.

Figure 9-129 AccessStudio - auto-fill option

330 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 9-130 AccessStudio - identify successful logon

Chapter 9. Tivoli Identity Manager implementation 331 10.Click Finish to create the profile.

Figure 9-131 AccessStudio - Finish operation

332 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 11.From the AccessStudio menu, shown in Figure 9-132, select View → AccessProfiles.

Figure 9-132 AccessStudio - view AccessProfiles

Chapter 9. Tivoli Identity Manager implementation 333 12.Select the profile name, under AccessProfiles, as shown in Figure 9-133, and then click the icon on the tool bar (next to the “New” icon) to save to the IMS Server.

Figure 9-133 AccessStudio - upload profile

334 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 13.From the menu, select View → AuthenticationServices; see Figure 9-134.

Figure 9-134 AccessStudio - view AuthenticationServices

Chapter 9. Tivoli Identity Manager implementation 335 14.Click Policies to expand it and view the options shown in Figure 9-135. Select the box for This is an enterprise authentication service. This option allows access to be logged to the IMS Server. Select Automatic logon as the Default sign-on option.

Figure 9-135 AccessStudio - application policies

15.Select the Authentication Service name, as shown in Figure 9-136. Write down the name of your Authentication Service here because you will need it for the next step. In this example, the name is auth_TIMSelfUI.

Figure 9-136 AccessStudio - authentication service name

336 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 16.Click the icon on the tool bar to save to the IMS Server; see Figure 9-137.

Figure 9-137 AccessStudio - upload to IMS Server

17.Click Yes to upload the changes to the IMS Server; see Figure 9-138.

Figure 9-138 AccessStudio - upload

Chapter 9. Tivoli Identity Manager implementation 337 18.Select View → Applications, as shown in Figure 9-139.

Figure 9-139 AccessStudio - view Applications

19.Select the application. Click on the icon on the tool bar to save to the IMS Server, as shown in Figure 9-140.

Figure 9-140 AccessStudio - upload application

20.Exit the AccessStudio. You do not have to save the changes made during this session because they have been uploaded to the IMS Server. 21.Log out of the IMS Server. The next steps are to configure Identity Manager service options.

338 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 9.5.2 Modify the TAM E-SSO Service

In this step, we configure the TAM E-SSO Service prerequisites of Active Directory and also specify the profiles that have to be provisioned for the IMS account.

To modify the TAM E-SSO Service: 1. In the Identity Manager Admin Console, navigate to Manage Services and refresh the display table to get a list of defined services (Figure 9-141).

Figure 9-141 IBM Tivoli Identity Manager - Manage Services

Chapter 9. Tivoli Identity Manager implementation 339 2. Select the TAM E-SSO IMS Server service (Figure 9-142).

Figure 9-142 TAM E-SSO IMS Server service

340 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. On the Adapter Details page, specify an owner for the TAM E-SSO IMS Server Service. Next to Owner, click Search (Figure 9-143).

Figure 9-143 Adapter Details

4. Search for an owner, in our example stevens (Figure 9-144).

Figure 9-144 Search user

Chapter 9. Tivoli Identity Manager implementation 341 5. Select stevens (or the user you searched for) and click OK (Figure 9-145).

Figure 9-145 Select user

342 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 6. Back on the Adapter Details page, specify a Service Prerequisite of the Active Directory Service. Click Search next to Service Prerequisite (Figure 9-146).

Figure 9-146 Add prerequisites

Chapter 9. Tivoli Identity Manager implementation 343 7. Click Search to search for all services (Figure 9-147).

Figure 9-147 Search services

344 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 8. Select the service, in our example Active Directory Account- tamesso.esso.local, and click OK (Figure 9-148).

Figure 9-148 Add Active Directory account

Chapter 9. Tivoli Identity Manager implementation 345 9. Select Debug Logging (Figure 9-149).

Figure 9-149 Set debug logging

10.The user should have been provisioned with an Active Directory account before we provision the user’s IMS account, so we make the Active Directory Service a prerequisite for the TAM E-SSO IMS Server service.

346 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 11.Click on the Application Accounts Mapping for the Service (Figure 9-150). Here we add the mapping of the Identity Manager Service to the Tivoli Access Manager for Enterprise Single Sign-On Authentication Service profile. When you provision a new account or application to a user, this mapping determines if the credentials are to be passed to IMS and stored in the user’s Wallet.

Figure 9-150 Select application accounts mapping

12.To configure the mapping, enter the following information in the Authentication Services Mapping field (Figure 9-151 on page 348): – Identity Manager Service name – A pipe symbol (|), which is called a vertical bar symbol – The Tivoli Access Manager for Enterprise Single Sign-On authentication service name So in our example, the entry would be: ITIM Service|auth_TIMSelfUI

Chapter 9. Tivoli Identity Manager implementation 347 Figure 9-151 Application Account Mapping details

13.Then, click Add to add the entry to the table.

Note: Do not forget to re-enter the passwords on the TAM E-SSO Server Details page and the TAM E-SSO Database Details page before saving the configuration. Click the Test Connection button after re-entering the passwords to verify that you have entered them correctly.

348 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 14.Go to in the Authentication Services Mapping field and enter the password (Figure 9-152).

Figure 9-152 Re-enter TAM E-SSO server password

Chapter 9. Tivoli Identity Manager implementation 349 15.Go to TAM E-SSO Database Details and enter the password (Figure 9-153).

Figure 9-153 Re-enter DB password

350 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 16.Click Test Connection (Figure 9-154).

Figure 9-154 Test connection

Chapter 9. Tivoli Identity Manager implementation 351 17.Verify that a connection to the service could be established (Figure 9-155).

Figure 9-155 Connection verification

352 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 18.Scroll down and click OK to save the changes (Figure 9-156) and verify that they have been saved successfully.

Figure 9-156 Save adapter settings

9.5.3 Service prerequisites for provisioning accounts

The service form for the ITIM Service does not contain a field to enter any service prerequisites. The forms designer does not allow you to add this attribute either.

In order to modify the ITIM Service form to include a service prerequisite, you must modify the form’s XML document that is stored in LDAP.

An LDIF file that contains the modifications to define this attribute must be imported into the directory. In our scenario, this file is located at: D:\Software\Adapters\TAMESSO_Adapter_5.0.1\ITIM50Service_form.ldif

Note: You can modify your LDAP configuration using various tools. In our scenario, we use the LDAP Browser/Editor (LBE) from Argonne National Laboratory. It is commercially available at the following Web site: http://www.anl.gov/techtransfer/Software_Shop/LDAP/LDAP.html

Chapter 9. Tivoli Identity Manager implementation 353 1. Launch the LDAP browser (Figure 9-157).

Figure 9-157 Launch LDAP browser

2. Create a session to connect to your IBM Tivoli Identity Manager server. Configure the session as shown in Figure 9-158.

Figure 9-158 Select LDAP session

354 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. Do not use the Anonymous bind option, or the import might fail. Remove the mark from the Anonymous bind check box and then click Save. The Base DN should point to dc=com (Figure 9-159).

Figure 9-159 Configure LDAP session

4. Connect to the LDAP as shown in Figure 9-160.

Figure 9-160 Connect to LDAP

Chapter 9. Tivoli Identity Manager implementation 355 5. Select the entry dc=com (Figure 9-161).

Figure 9-161 Select LDAP entry

6. Import the LDIF file into the directory. Select LDIF → Import (Figure 9-162).

Figure 9-162 Import LDIF

356 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 7. Browse to locate the .ldif file at the following directory: D:\Software\Adapters\TAMESSO_Adapter_5.0.1\ITIM50Service_form.ldif Select Update only and click Import (Figure 9-163).

Figure 9-163 Update only

Chapter 9. Tivoli Identity Manager implementation 357 8. One entry should be processed as shown in Figure 9-164. Click OK.

Figure 9-164 Import success

358 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 9. Now, in the Tivoli Identity Manager Admin Console, navigate to Manage Services. Click Refresh to update the services list (Figure 9-165).

Figure 9-165 IBM Tivoli Identity Manager - refresh services

Chapter 9. Tivoli Identity Manager implementation 359 10.Select the ITIM Service as shown in Figure 9-166.

Figure 9-166 Select ITIM Service

11.Click Search, next to Service prerequisite (Figure 9-167).

Figure 9-167 Change service prerequisites

360 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 12.Click Search, as shown in Figure 9-168.

Figure 9-168 Search service

13.Select the TAM E-SSO IMS Server service and click OK (Figure 9-169).

Figure 9-169 Add TAM E-SSO IMS Server service as prerequisite

Chapter 9. Tivoli Identity Manager implementation 361 14.Click Search next to Owner (Figure 9-170).

Figure 9-170 Search owner

15.Search for an owner, in our example stevens. Click Search (Figure 9-171).

Figure 9-171 Search owner

362 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 16.Select a user (here we use Mike Stevens) and click OK (Figure 9-172).

Figure 9-172 Add an owner

17.Click OK again to save the changes (Figure 9-173).

Figure 9-173 Save changes

Chapter 9. Tivoli Identity Manager implementation 363 9.5.4 Create a new Identity Manager user and required accounts

1. Create a new user in Tivoli Identity Manager. Navigate to Manage Users as shown in Figure 9-174.

Figure 9-174 Manage users

364 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 2. Click the Create button on the result list (Figure 9-175).

Figure 9-175 Create new user

Chapter 9. Tivoli Identity Manager implementation 365 3. Select Person and click Continue (Figure 9-176).

Figure 9-176 Select user type Person

366 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 4. Use any name you want and click Continue. In this example, the user ID is testuser (Figure 9-177).

Figure 9-177 Add user details

Chapter 9. Tivoli Identity Manager implementation 367 5. Choose a password and click Submit (Figure 9-178). Close this view.

Figure 9-178 Submit new user request

368 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 6. After you have created the user, you have to request an Active Directory account for this user. Back in the Manage Users panel, search by Entire profile for the newly created user (Figure 9-179).

Figure 9-179 Search new user

Chapter 9. Tivoli Identity Manager implementation 369 7. Next to the name of the new user, select the right-triangle button (>) to open the task list for the user. Then, select Request Accounts (Figure 9-180).

Figure 9-180 New user - request new account

370 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 8. Search for the Active Directory service as shown in Figure 9-181.

Figure 9-181 Search for the Active Directory service

Chapter 9. Tivoli Identity Manager implementation 371 9. In the Service Name column, select the service name, in our example Active Directory Account-tam.esso.local, and click Continue (Figure 9-182).

Figure 9-182 Select Active Directory Account-tam.esso.local

372 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 10.Click Continue on the next window (Figure 9-183).

Figure 9-183 Request Active Directory account - continued

Chapter 9. Tivoli Identity Manager implementation 373 11.Choose a password for the account and click Submit (Figure 9-184).

Figure 9-184 Select Active Directory account password

374 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 12.After you create the Active Directory account for the user, you have to request a TAM E-SSO IMS Server account for the user to also set up that user in Tivoli Access Manager for Enterprise Single Sign-On. Click Request another account for the same user (Figure 9-185).

Figure 9-185 Request another account

Chapter 9. Tivoli Identity Manager implementation 375 13.Search for the TAM E-SSO Service as shown in Figure 9-186.

Figure 9-186 Search TAM E-SSO account

376 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 14.Select the TAM E-SSO IMS Server service and click Continue (Figure 9-187).

Figure 9-187 Request TAM E-SSO account

Chapter 9. Tivoli Identity Manager implementation 377 15.Type in the user ID for your user and click Continue (Figure 9-188).

Figure 9-188 Choose a user ID

378 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 16.Select a password and click Submit (Figure 9-189).

Figure 9-189 Select TAM E-SSO account password

Chapter 9. Tivoli Identity Manager implementation 379 17.Finally, we also have to add an account for Tivoli Identity Manager. Search for the Identity Manager service as shown in Figure 9-190.

Figure 9-190 Add Tivoli Identity Manager account

380 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 18.Accept the default user ID and click Continue (Figure 9-191).

Figure 9-191 Request a Tivoli Identity Manager account

Chapter 9. Tivoli Identity Manager implementation 381 19.Set a password for this account and click Submit (Figure 9-192).

Figure 9-192 Set the Tivoli Identity Manager account password

20.After you complete these steps, the user should have three accounts: – For Active Directory – For the Tivoli Access Manager for Enterprise Single Sign-On IMS server – For Tivoli Identity Manager Verify the accounts by returning to the Manage Users panel, searching for your user, and then selecting Accounts from the task list to view the accounts for that user as shown in Figure 9-193 on page 383.

382 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 9-193 Verify all newly created accounts

21.If you do not have three accounts for the user, view the audit trail to verify the status of the request for the account.

Chapter 9. Tivoli Identity Manager implementation 383 9.5.5 Test single sign-on to the Identity Manager Self-Service

To test: 1. On the IMS Server, select Log On and enter user name and password for the user you just created. In this example, the user name is testuser, as shown in (Figure 9-194).

Figure 9-194 Logon to Tivoli Access Manager for Enterprise Single Sign-On

384 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 2. Next, you are prompted to provide your answer to a selected question as shown in Figure 9-195.

Figure 9-195 Answer a selected question

3. Your password has expired. Enter a new password (Figure 9-196).

Figure 9-196 Change password

Chapter 9. Tivoli Identity Manager implementation 385 4. Right-click the red AccessAgent icon in the system tray. This opens the AccessAgent. You may view your Wallet because you have been set up as a registered user (Figure 9-197).

Figure 9-197 Open Wallet

5. Select Manage Wallet to see what is in your Wallet (Figure 9-198).

Figure 9-198 Select Manage Wallet...

386 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 6. You can see that you have also been provisioned with the TIMSelfUI authentication service, as shown in Figure 9-199.

Figure 9-199 View Wallet

Chapter 9. Tivoli Identity Manager implementation 387 7. Close the AccessAgent and start a browser, enter the URL for the Tivoli Identity Manager Self-Service Console. In our example (Figure 9-200), this is: http://192.168.210.10:9080/itim/self. The account information should be automatically provided for you.

Figure 9-200 Start IBM Tivoli Identity Manager Self-Service console - log in

388 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 You are now automatically logged in to the Tivoli Identity Manager Self-Service Console (Figure 9-201).

Figure 9-201 IBM Tivoli Identity Manager Self-Service console

This concludes our configuration and setup of Tivoli Access Manager for Enterprise Single Sign-On and Tivoli Identity Manager.

Chapter 9. Tivoli Identity Manager implementation 389 390 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 10

Chapter 10. Strong authentication

In this chapter, we describe the technical implementation of strong authentication with Tivoli Access Manager for Enterprise Single Sign-On (TAM E-SSO).

First, we give an introduction into the strong authentication feature based on USB key authentication. After covering the technical prerequisites, we describe how to configure Tivoli Access Manager for Enterprise Single Sign-On for USB key authentication. Finally, we tell you how to enroll USB keys as a strong authentication token.

As described in “Emerging issues” on page 87 the CIO office is not content with the security level that can be achieved with username/password authentication and wants to implement strong authentication for all of the employees over the next years. With Tivoli Access Manager for Enterprise Single Sign-On, this problem can be addressed by utilizing the strong authentication function within the product.

In this section, we discuss the integration of Charismathics1 plug’n’crypt USB key token as one example for using strong authentication with Tivoli Access Manager for Enterprise Single Sign-On.

Note: The third-party software and hardware components mentioned in this section are not part of the Tivoli Access Manager for Enterprise Single Sign-On distribution and must be purchased separately.

10.2 Using a USB key for strong authentication

The USB key is a removable USB flash drive that combines the utility and storage capacity of Flash RAM, the security of a smart card, and the universal connectivity of a universal serial bus (USB) into one package. The USB key can store user names, passwords, certificates, encryption keys, and other security credentials. The USB form factor is cost-effective. No additional hardware is required for the key to work, now that USB ports are available on various platforms. The USB key stores more passwords and certificates than any other authentication device in the market. The size of the memory can vary according to the needs of your organization. Depending on company policy, users can be allowed to store passwords for personal applications and Web sites.

Internally, the USB key stores the following data: Serial number The serial number is a unique number embedded in the USB key during manufacturing. It is also printed on the casing of the USB key. The number is unique for each USB key and cannot be changed.

1 More information about the Charismatics plug’n’crypt USB token and other products can be found at http://www.charismathics.com/products.php

392 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Common symmetric key The common symmetric key (CSK) is used to encrypt information that is communicated to the IMS Server for backup. Each user has a different and unique CSK. Digital certificates for each certificate-enabled application Driver for the USB key, and installation files for the AccessAgent The computer cannot communicate with a device until a special program is installed. The program is known as a driver. The USB key requires a driver for it to work with your computer. The required drivers for our example can be obtained from Charismathics.

10.2.1 Design considerations

In this chapter, we assume that you have already deployed Tivoli Access Manager for Enterprise Single Sign-On. In this section, we discuss the design considerations for the software components and the physical architecture for strong authentication based on USB key token.

Software components Table 10-1 indicates which software components get installed on which computer or server. The physical architecture diagram in Figure 10-1 on page 394 presents a visual representation of these components.

Table 10-1 Software installed on involved machines Machine type Software

IMS Server Tivoli Access Manager for Enterprise Single Sign-On IMS Server software

Administrator workstation keyinit_charismathics tool plug’n’crypt driver software CSSI user edition software

User workstation Tivoli Access Manager for Enterprise Single Sign-On AccessAgent plug’n’crypt driver software CSSI user edition software

Chapter 10. Strong authentication 393 Figure 10-1 Strong authentication physical architecture

Let us now start to look into the configuration details for the TAA deployment.

10.2.2 Installing USB key software

Note: The following installation guidelines were valid at the time of writing this publication (June 2009), but do not replace any vendor documentation or recommendations. You should always consult the original documentation for hardware and software requirements or installation recommendations.

In this section, we show you how to prepare the Tivoli Access Manager for Enterprise Single Sign-On environment to work with Charismathics USB keys. This involves the following steps: 1. Installing required components on administrator workstation 2. Installing USB key components on the user workstation

394 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Installing required components on administrator workstation Follow steps in this section to install the USB key driver software on the admin workstation.

Install plug’n’crypt CCID token software To install plug’n’crypt CCID token software on the admin workstation: 1. Close all programs. 2. Locate the plug_n_crypt_CCID_token.exe file on the CD-ROM. Double-click the plug_n_crypt_CCID_token.exe file to begin the installation. 3. The Welcome window opens, shown in Figure 10-2. Click Next.

Figure 10-2 plug’n’crypt CCID token software welcome

Chapter 10. Strong authentication 395 4. The plug’n’crypt CCID token software is ready to install, as shown in Figure 10-3. Click Install.

Figure 10-3 plug’n’crypt Ready to Install

5. Wait for the installation to complete and then click Finish (Figure 10-4).

Figure 10-4 plug’n’crypt installation successful

396 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Install CSSI user edition To install the CSSI software on the admin workstation. 1. Locate the user edition\CSSI 4.7 - user edition.msi file on the CD-ROM and double-click on it to begin the installation (see Figure 10-5).

Figure 10-5 CSSI installation directory

2. The Welcome window opens (Figure 10-6). Click Next.

Figure 10-6 CSSI welcome page

Chapter 10. Strong authentication 397 3. If you agree with the terms, accept the license agreement (Figure 10-7) and then click Next.

Figure 10-7 CSSI license agreement

398 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 4. Select Complete and click Next (Figure 10-8).

Figure 10-8 Ready to install

5. The CSSI software is ready to install (Figure 10-9). Click Install.

Figure 10-9 Installation successful.

Chapter 10. Strong authentication 399 6. Wait for the installation to complete and then click Finish (Figure 10-10).

Figure 10-10 CSSI installation finished

Now the CSSI software is installed.

Install the USB key initialization tool To be accepted by the Tivoli Access Manager for Enterprise Single Sign-On IMS Server, every USB key has to be initialized. During the initialization, unique keys are written to every USB key. These keys are being used by the IMS Server during user authentication and to protect the Wallet.

Note: The IBM Tivoli USB Key Initialization Tool for Tivoli Access Manager for Enterprise Single Sign-On is being provided through the IBM Open Process Automation Library (OPAL). Follow this link to download the package: http://www.ibm.com/software/tivoli/opal?NavCode=1TW10AMBN

To install the USB key initialization tool on the admin workstation: 1. Open a command prompt and create a subdirectory for the key initialization program files, for example, c:\keyinit, as follows: c:> c:\>md keyinit c:\>cd keyinit

400 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 2. Extract the archive USBKeyInit_1.3.0.0.zip file (use any tool to do this). See Example 10-1.

Reminder: The .zip file in the official IBM Tivoli USB Key Initialization Tool for Tivoli Access Manager for Enterprise Single Sign-On is named: USBKeyInit_1.3.0.0.zip

Example 10-1 Extracting the .zip file Extracting from USBKeyInit_1.3.0.0.zip Extracting config_cm.ini OK Extracting config_ds.ini OK Extracting KIController.exe OK Extracting enc_v3.dll OK Extracting KIController.log OK Extracting KIPackage.exe OK Extracting KIProvCharismathics.dll OK Extracting KIProvDigisafe.dll OK Extracting TAMESSO-CKI-1.3.0.0.README OK Extracting V3_TurnOnSC.exe OK

Installing USB key components on the user workstation Follow steps in this section to install the required USB key driver software on the user workstation.

Install plug’n’crypt driver software To install plug’n’crypt driver software on the user workstation: 1. Close all programs. 2. Locate the plug_n_crypt_CCID_token.exe file on the CD-ROM and double-click on it to begin the installation.

Chapter 10. Strong authentication 401 3. The Welcome window opens (Figure 10-11). Click Next

Figure 10-11 Welcome panel

4. The plug’n’crypt CCID token software is ready to install (Figure 10-12). Click Install.

Figure 10-12 Ready to install

402 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. Wait for the installation to complete and then click Finish (Figure 10-13).

Figure 10-13 Installation successful

Install CSSI user edition To install CSSI user edition on the user workstation: 1. Locate the user edition\CSSI 4.7 - user edition.msi file on the CD-ROM and double-click on it to begin the installation (see Figure 10-14).

Figure 10-14 CSSI installation directory

Chapter 10. Strong authentication 403 2. The Welcome window opens (Figure 10-15). Click Next.

Figure 10-15 CSSI welcome page

404 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. If you agree with the terms, accept the license agreement (Figure 10-16), and click Next.

Figure 10-16 CSSI license agreement

Chapter 10. Strong authentication 405 4. Select Complete and click Next (Figure 10-17).

Figure 10-17 Ready to install

5. The CSSI software is ready to install (Figure 10-18). Click Install.

Figure 10-18 Installation successful.

406 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 6. Wait for the installation to complete, and then click Finish (Figure 10-19).

Figure 10-19 CSSI installation finished

Now, the CSSI software is also installed on the user workstation.

10.2.3 Configuring a self-service registration policy

The registration of USB keys by the user requires that the self-service registration feature of Tivoli Access Manager for Enterprise Single Sign-On is enabled.

To configure the registration policy: 1. Open a Web browser and go to (if IMS Server is installed): http://ims.encnetwork.local This brings up the IMS Server start page shown in Figure 10-20 on page 408. 2. Click AccessAdmin to proceed.

Chapter 10. Strong authentication 407 Figure 10-20 AccessAdmin start page

You are presented with the AccessAdmin portal as shown in Figure 10-21 on page 409.

408 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 10-21 AccessAdmin welcome page

3. Self-service-related configuration items are system policies, therefore click System policies, shown on the left in Figure 10-22 on page 410.

Chapter 10. Strong authentication 409 Figure 10-22 AccessAdmin system policies section

4. Click Self-Service Policies to expand the section (Figure 10-23).

Figure 10-23 AccessAdmin self-service polices

410 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. Click Self-service Registration and Bypass of 2nd Factor Policies to expand the section (see Figure 10-24).

Figure 10-24 AccessAdmin self-service policies options

6. Select Yes to enable the self-service registration and bypass of 2nd factor, and then click Update to save the configuration change (Figure 10-25).

Figure 10-25 AccessAdmin enable self-service

Now, the registration self-service is active.

Important: Because there is no confirmation that the registration self-service is active, remember to click the Update button to send any changes to the IMS Server. Otherwise, you have to do your configuration changes again.

Chapter 10. Strong authentication 411 10.2.4 Setting up an AccessAgent machine policy

In order to support USB key authentication, a machine policy must be configured that supports USB keys.

To configure an additional machine policy in the AccessAdmin console: 1. Open a Web browser and enter this URL: http://ims.encnetwork.local This takes you to the IMS Server start page as shown in Figure 10-26. 2. Click AccessAdmin to proceed.

Figure 10-26 AccessAdmin start page

412 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. The AccessAdmin portal opens as shown in Figure 10-27.

Figure 10-27 AccessAdmin welcome page

4. Self-service-related configuration items are located in the Machine Policy Templates section on the left of the page. Click New Template. In the fields, provide the definitions, shown in Table 10-2 and visible in Figure 10-28 on page 414. Table 10-2 Machine policy matching criteria Name USB Key Usage

Use only machines matching Selected these criteria

Match all of these criteria Selected

Host name is TAMESSO

Chapter 10. Strong authentication 413 Figure 10-28 Machine template creation

5. Scroll down the window to the Authentication Polices section and expand it, as shown in Figure 10-29 on page 415.

414 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 10-29 AccessAdmin machine policy supported authentication factor

6. Because we want to use a USB key as a second authentication factor, enter USB into the text box, and click Add. The result is shown in Figure 10-30.

Figure 10-30 AccessAdmin machine policy with USB as authentication factor

Chapter 10. Strong authentication 415 7. To store the entire new profile, click Add below the AccessAgent Policies. Now, the new profile is defined and can be attached to new or existing machines; see Figure 10-31 for reference.

Figure 10-31 AccessAdmin Machine policy assignment

10.2.5 Assigning an AccessAgent machine policy

AccessAgent policies can be assigned at any time by the administrator. The IMS Server together with the AccessAgent updates any machines with new or modified policies if required.

To assign a policy: 1. If you are not already logged in to the AccessAdmin GUI, open a Web browser and enter this URL: http://ims.encnetwork.local

416 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 2. Go to the machines section by clicking Search in the Machines section (on the left in Figure 10-32).

Figure 10-32 AccessAdmin machine policy assignment

3. We want to modify the machine policy for the workstation tamesso. To do this, in the Search for text box, type the name of the machine TAMESSO, and then click Search.

Chapter 10. Strong authentication 417 Because we have only one machine with this name (the text box accepts wildcards), the machine details are displayed as shown in Figure 10-33.

Figure 10-33 AccessAdmin machine details page

418 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 4. To change the machine configuration, select the desired machine policy from the drop-down list below the Machine policy template assignment (in this case select USB Key Usage) and click Assign as shown in Figure 10-34.

Figure 10-34 AccessAdmin changed machine policy assignment

5. If you are sure the configuration is correct, reboot the AccessAgent client system because certain settings require a rebooting of the system.

10.2.6 Initializing a USB key

Every USB key that will be used with Tivoli Access Manager for Enterprise Single Sign-On must be initialized with the tool that has been installed in “Install the USB key initialization tool” on page 400. The installation has to be performed from an administrator’s workstation with the USB key software and the keyinit tool installed.

Chapter 10. Strong authentication 419 To initialize, insert a fresh plug’n’crypt USB key into a free USB slot of the workstation and follow these steps: 1. In the keyinit directory, locate the KIController.exe file and then double-click the file to begin the initialization. 2. The application starts with the default dialog as displayed in Figure 10-35. The tool supports Charismathics and DigiSafe USB tokens, so check your key provider for the correct input (we are using a Charismathics token). Select your device from the upper Device list and click Initialize to start the enrollment process for the USB key.

Figure 10-35 TAM E-SSO USB Key Initialization Tool

3. The key initialization starts immediately, and after several seconds the USB key is ready for operation with Tivoli Access Manager for Enterprise Single Sign-On as depicted in Figure 10-36 on page 421.

420 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 10-36 Initialization successful

10.2.7 USB key enrollment process

When a USB key is enrolled for Tivoli Access Manager for Enterprise Single Sign-On, the user and the help desk staff should closely work together. Because the AccessAgent requests an authorization key from the user when a new USB key is enrolled, the help desk staff has to create this authorization key that the user requires during the enrollment process. The resulting workflow for USB key enrollment includes the authorization code generation by the help desk or an administrator, and the user steps to enroll the USB key.

Authorization code generation by help desk or administrator To generate an authorization code for strong authentication enrollment: 1. Open a Web browser and go to the following URL: http://ims.encnetwork.local This takes you to the IMS Server welcome page as shown in Figure 10-37 on page 422.

Chapter 10. Strong authentication 421 2. Click AccessAdmin to proceed.

Figure 10-37 IMS welcome page

3. If authentication is required, log in as an administrator or help desk staff.

422 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 4. In our case, we enter the user name itsouser2 in the text box and click Search, as shown in Figure 10-38.

Figure 10-38 AccessAdmin user search

5. Scroll down the page to the Helpdesk Authorization section and expand it to see the options (see Figure 10-39). 6. Select Password reset and click the Issue authorization code button.

Figure 10-39 AccessAdmin user administration GUI

Chapter 10. Strong authentication 423 After several seconds, an authorization code is issued by the IMS Server (see Figure 10-40). This authorization code has to be transferred to the user. The user needs the code to enroll a USB key as a strong authentication token.

Figure 10-40 AccessAdmin authorization code

USB key enrollment by the user To enroll a USB key, you must have: A workstation with USB key software installed as described in “Installing USB key components on the user workstation” on page 401 A USB key that has been previously initialized by an administrator

424 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Follow these steps: 1. Because the enrollment of a second factor is only possible when logged off from a workstation, you have to exit any existing session and fall back to the logon window shown in Figure 10-41.

Figure 10-41 AccessAgent welcome

Note: You can easily detect whether USB key support is configured for your workstation because the following message appears on the window:

To log on, insert your USB Key into the USB port now.

Chapter 10. Strong authentication 425 2. Plug your USB key into a USB port. After several seconds, the Welcome message changes (see Figure 10-42). Do not press Ctrl+Alt+Del to insert your user credentials.

Figure 10-42 AccessAdmin Logon dialog

3. Enter the user credentials. In our example, we entered itsouser2 (user name) and smartway (password). Then, click OK, shown in Figure 10-43.

Figure 10-43 AccessAgent user data

426 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 4. The AccessAgent prompts you for the authorization code, which is required for preparing the USB key. Enter the authorization code that was provided by the help desk previously. In our use case, the authorization code was 8365-C5ED-A48E (Figure 10-44). Click OK to confirm.

Figure 10-44 AccessAgent authorization code input

Verification of the authorization code starts, as shown by the progress bar in Figure 10-45, and can take several seconds to complete.

Figure 10-45 AccessAdmin authorization code validation

Chapter 10. Strong authentication 427 When successful the AccessAgent automatically logs the user into the workstation, as shown in Figure 10-46.

Figure 10-46 Successful login

5. To demonstrate that the user has successfully logged into the machine with a USB key, right-click the AccessAgent icon (in the workspace) and select AccessAgent (Figure 10-47).

Figure 10-47 AccessAgent control panel

As you can see, the user itsouser2 is logged in to the workstation using a USB key (see Figure 10-48 on page 429).

428 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure 10-48 AccessAgent logged in with USB key

10.3 Conclusion

The strong authentication capabilities of Tivoli Access Manager for Enterprise Single Sign-On enable users to use second authentication tokens, like a USB key token, an RFID token, and others, for primary authentication against the AccessAgent. The one-time enrollment is the only requirement for the users before they can reap the benefits of strong authentication.

Security administrators responsible for deploying strong authentication throughout the organization, must adequately define the processes before the initial deployment of the solution. Corporate security officers and the CIO’s office are some of the stakeholders that must support such a solution.

When you have properly addressed all the questions, the capabilities of the solution discussed in this chapter allow for a smooth deployment.

Chapter 10. Strong authentication 429 430 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Part 3

Part 3 Appendixes

In this part, we provide information about troubleshooting issues, advanced profiling with use cases, and a sample statement of work contract.

Appendix A. Troubleshooting

In this appendix, we discuss some troubleshooting situations to help you figure out the intricacies and hurdles that you might encounter when deploying Tivoli Access Manager for Enterprise Single Sign-On.

In this first section we focus on issues concerning the AccessAgent.

AccessAgent logs

To help you with troubleshooting AccessAgent problems, view the log files in the C:\Program Files\Encentuate\logs folder. The XML files indicate communications with the IMS Server and are useful for troubleshooting failure because of AccessAgent-IMS Server interaction. The AccessAgent.log records internal AccessAgent processes and is useful for troubleshooting internal failure within AccessAgent. The aa_observer.log records observations of applications for automatic sign-on. For installation problems, the AccessAgent installer logs can be found in the C:\AAInstaller.log file. When reporting a problem, include a.zip file that contains the entire C:\Program Files\Encentuate\logs folder is helpful. You should also provide the approximate local time when the events occurred.

AccessAgent log level

Also useful when you troubleshoot AccessAgent problems, is to increase the log level so that more debugging information can be produced.The log level is specified by the machine policy pid_log_level, which can be set through the registry entry: [HKEY_LOCAL_MACHINE\SOFTWARE\Encentuate\DeploymentOptions]"LogLevel"

Log level 3 is usually enough for most debugging purposes. If more detailed logs are required, the log level can be set to 4.

AccessAgent cryptoboxes

AccessAgent stores user and machine Wallets as hidden files in the C:\Program Files\Encentuate\Cryptoboxes folder. The machine Wallet at C:\Program Files\Cryptoboxes\Wallets\machine.wlt contains system policies and AccessProfiles downloaded from the current IMS Server. To view the Wallet files, make sure that Windows Explorer has been configured to “Show hidden files and folders.” To refresh the user Wallets during testing or troubleshooting, delete the corresponding Wallet files in the folder C:\Program Files\Encentuate\Cryptoboxes\Wallets.

434 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 To refresh the machine Wallet, refer to the following steps. The SOCIAccess service automatically replaces any deleted machine Wallet file, so deleting a folder (as with user Wallets) will not achieve the same result. 1. Log off AccessAgent (if logged on). 2. Kill the AccessAgent processes: AATray.exe, DataProvider.exe, and Sync.exe. 3. Stop the SOCIAccess service by using the command net stop sociaccess. 4. Delete the machine Wallet. 5. Restart the machine.

Restarting the machine with a missing machine Wallet will prompt AccessAgent to re-create the machine Wallet by downloading the latest policies and AccessProfiles from the current IMS Server.

Machine Wallet download problem

When a machine starts up with a missing machine Wallet, AccessAgent attempts to create the machine Wallet by downloading the latest policies and AccessProfiles from the current IMS Server. However, if the IMS Server is inaccessible, AccessAgent uses the policies and AccessProfiles specified in the following file: C:\Program Files\Encentuate\all_sync_data.xml.

To confirm whether the machine Wallet has been downloaded properly, run AccessStudio, load AccessProfiles from AccessAgent, and then click sso_site_web_ims_admin under AccessProfiles. The machine Wallet is correct if the @domain field on the right panel is set to the IMS Server name. If the @domain field is $hostname, the machine Wallet has not been downloaded properly.

If AccessAgent cannot successfully download the policies and AccessProfiles from the IMS Server despite several manual synchronization attempts, you can edit the policies and AccessProfiles directly in the all_sync_data.xml file.

To refresh the machine Wallet follow the steps in “AccessAgent cryptoboxes” on page 434.

For certain deployments, workstations can only connect to the network after a user logs on to Windows. Because AccessAgent has to download system data from the IMS Server during first startup after installation, other workstations will be unsuccessful in connecting at that time. For this reason, AccessAgent is inaccessible on first startup.

Appendix A. Troubleshooting 435 A workaround is for the first user to bypass the Tivoli Access Manager for Enterprise Single Sign-On logon process and log on to Windows directly. After that, subsequent users can log on normally using the Tivoli Access Manager for Enterprise Single Sign-On logon process. Another alternative is to include the IMS Server’s latest all_sync_data.xml file in the installation package.

To include the all_sync_data.xml file in the installation package: 1. Launch AccessStudio. 2. Select Tools → Backup System Data from IMS to File. 3. Click Backup, and save it as all_sync_data.xml file. 4. Place all_sync_data.xml file in the Config folder of the AccessAgent installer package.

Synchronization with IMS Server

AccessAgent performs synchronization with the IMS Server periodically according to the frequency specified by pid_wallet_sync_mins. Sometimes, invoking synchronization manually so the latest policies or AccessProfiles can be downloaded is useful. This is especially useful during troubleshooting or demonstrations. To enable the AccessAgent, right-click the option for Synchronize with IMS, and set machine policy pid_wallet_manual_sync_enabled to 1, which can be set through the registry entry: [HKEY_LOCAL_MACHINE\SOFTWARE\Encentuate\Temp]"WalletManualSyncEnabled"

Logon user interface failed to load

Upon startup, instead of EnGINA1, the following error message appears: Caption: User Interface Failure Message: The Logon User Interface DLL xxx.dll failed to load…..

Either EnGINA has not been properly installed or the Winlogon GINA registry entry was not set correctly after AccessAgent was uninstalled.

To resolve the problem: 1. Restart the computer. 2. Go to Safe Mode by pressing F8 before Windows starts up. 3. Log on as an Administrator.

1 EnGINA is the Tivoli Access Manager for Enterprise Single Sign-On logon user interface.

436 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 4. Modify the following Windows registry value: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]"GinaDLL". 5. If the value was engina.dll, EnGINA was probably not installed correctly and could not load. Change the value to msgina.dll. The default Windows Logon prompt will be displayed on the next startup. To use EnGINA again after fixing the problem, change the value to engina.dll.

AccessAgent does not display the correct domain

For this problem, we look at two separate cases: For IMS Server version 2.x When a user logs on, AccessAgent shows the display name of the authentication service specified by pid_bind_auth_list in the Domain field. To modify the displayed domain, use AccessStudio or the IMS Configuration Utility to modify the display name of the appropriate authentication service. For IMS Server version 3.x and later The policy pid_bind_edir_list replaces pid_bind_auth_list. AccessAgent shows the domains specified in the enterprise directory listed in pid_bind_edir_list.

Cannot return to EnGINA from Windows GINA

Users cannot return to EnGINA from Windows GINA by clicking Cancel if the following domain group policy is set to Enabled: [Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options] "Disable CTRL+ALT+DEL requirement for logon".

To fix this problem, set the value to Disabled or Not Defined.

Web automatic sign-on fails on Internet Explorer settings

Because of a Microsoft problem, Internet Explorer 5.5 with Service Pack 2 and Internet Explorer 6.0 without Service Pack cannot be used with AccessAgent. Information is located at: http://support.microsoft.com/?kbid=316593

Users have to upgrade their Internet Explorer to at least 6.0 with Service Pack 1.

Appendix A. Troubleshooting 437 Web automatic sign-on also fails if the Internet Explorer has been configured to disable third-party browser extensions. To enable third-party browser extensions in Internet Explorer: 1. In Internet Explorer, go to Tools → Internet Options → Advanced. 2. Under the Browsing category, look for Enable third-party browser extensions (requires restart). Mark the option and click OK. 3. Exit Internet Explorer and try Web automatic sign-on again.

Also possible is for some spyware to automatically remove the Tivoli Access Manager for Enterprise Single Sign-On Browser Helper Object. For such cases, Web automatic sign-on might initially work, but then subsequently not work. Install and run an anti-spyware software to clear all spyware in your machine before re-installing AccessAgent.

Automatic sign-on does not work properly for Windows applications

The required services might not have been registered properly during the AccessAgent installation. To register the required services: 1. Launch a command prompt. 2. Go to the Tivoli Access Manager for Enterprise Single Sign-On program directory: cd C:\Program Files\Encentuate 3. Execute the following commands: obsservice -service regsvr32 -i winssoagent.dll net start obsservice

Automatic sign-on does not work properly for Microsoft GINA

For IMS Server versions in the range of 3.1.1.6 - 3.1.7.1, the domain name must be regenerated for the authentication service representing the Windows credentials. When you configure an enterprise directory for an Active Directory server, the IMS Server automatically generates authentication services, one for each Active Directory domain.

To view the auto-generated authentication services in the IMS Configuration Utility, click Authentication Services in the left panel and select the authentication service from the drop-down list.

438 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 For an authentication service representing an Active Directory domain, two domain names are included in the Server locators to be used during injection: DNS domain name (for example, test.ibm.com) NETBIOS domain name (for example, ibm_test)

To perform automatic sign-on using the Microsoft GINA, ensure that the NETBIOS domain is the first item in the list.

Modification to Winlogon AccessProfile does not take effect

The latest AccessProfile of an application is loaded when the application process starts. Because the Winlogon process is only started on machine startup, restart the machine for the new Winlogon AccessProfile to take effect.

Application does not work properly after AccessAgent is installed

Certain Microsoft DLLs are used by AccessAgent when observing applications. If the DLL versions conflict with those used by an application, the application might not work correctly. To check for DLL conflicts: 1. Launch a command prompt. 2. Execute the following command: net stop obsservice 3. Launch the application and check whether the application is working properly.

You can check the application folder to see if it is carrying any Microsoft DLLs, which are usually named ms*.dll (for example, msvcr70.dll, msvcp70.dll).

A fix for the problem is to use the DLL redirection configuration suggested by Microsoft:

http://msdn2.microsoft.com/en-us/library/ms682600.aspx

Another possible fix is to replace the DLL carried by the application with a DLL that is compatible with AccessAgent. However, the application must also be compatible with the same DLL.

Cannot log on to Wallet after AccessAgent is installed

If you are using a version of AccessAgent earlier than 3.3.1.4, a problem prevents users from logging on if the machine Wallet is larger than 2 MB. This problem can happen if there is a large number of AccessProfiles.

Appendix A. Troubleshooting 439 When a user attempts to log on, the following error message is displayed: “You do not have a Wallet stored on this computer. However, you cannot download your Wallet from IMS Server because network connectivity is currently unavailable. Please try again later.”

To resolve this problem, upgrade to AccessAgent version 3.3.1.4 or later. You can also reduce the number of AccessProfiles so the machine Wallet is smaller than 2 MB.

Note that the inability to log on may also be because of any of the problems listed in “Unable to connect to the IMS Server” on page 440.

Cannot log on to cached Wallets

If AccessAgent can log on when the IMS Server is online, but cannot log on to cached Wallets while the IMS Server is offline, the cached Wallets might be corrupted. For such cases, delete all cached user Wallets and try to log on again.

Enable the AccessAgent right-click option for Delete, which can be set through the registry entry: [HKEY_LOCAL_MACHINE\SOFTWARE\Encentuate\Temp]"WalletDeleteEnabled".

Downloading the IMS Server certificate

If configured properly, the AccessAgent installer should download the IMS Server certificate to the client PC. However, this download can fail if the client PC is offline or the IMS Server is not available at that time. The server certificate can be downloaded after installation through either of the following methods: Launch the following command Start → All Programs → TAM E-SSO AccessAgent → Set IMS Server Location Run the C:\Program Files\Encentuate\SetupCertDlg.exe executable.

Unable to connect to the IMS Server

If AccessAgent cannot connect to the IMS Server, it cannot perform certain operations, such as: Logging on to AccessAgent when no cached Wallet exists for the user Changing a Tivoli Access Manager for Enterprise Single Sign-On or USB Key password

440 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Registering a second factor Signing up users

The following situations could prevent AccessAgent from connecting to IMS Server: The client machine is not connected to the network. The client machine has no network connectivity (or has lost connectivity) to the IMS Server. This could be because of an intervening firewall between the client machine and the IMS Server, or because of network configuration issues, such as DNS problems. The client machine has a personal firewall or anti-spyware that is blocking traffic from AccessAgent. To allow AccessAgent to contact the IMS Server while computer is locked, the personal firewall or anti-spyware must also not be blocking traffic from winlogon.exe. The client machine does not have the IMS Server certificates installed, possibly because the client machine was offline during AccessAgent installation (see “Downloading the IMS Server certificate” on page 440). AccessAgent registry settings are corrupted or misconfigured (for example, AccessAgent is pointing to the wrong IMS Server).

Spontaneous termination of sync.exe

The following symptoms might show a problem with sync.exe: After the first reboot, EnGINA does not show up. Instead, it bypasses to Microsoft GINA. When logged on to Windows, the PC appears to be very slow. Stopping ObsService restores the computer to its original speed. sync.exe does not show up in the Windows Task Manager. After starting sync.exe manually, it shuts down within milliseconds.

These symptoms can be caused by anti-spyware, such as the LanDesk software monitoring tool (SoftMon.exe), which might have identified the process sync.exe to be a spyware or malware. The anti-spyware shuts down the process when it is detected. In the AccessAgent logs, sync.exe appears to be failing at different instances.

To remedy this problem, add sync.exe to the LanDesk software monitoring tool’s exclusion list. After making the settings, LanDesk ignores sync.exe and does not shut down the process. For other anti-spyware products, make the same changes to their exclusion lists.

Appendix A. Troubleshooting 441 IMS Server issues

In this section, we deal with IMS Server issues.

IMS Server logs

A useful approach for troubleshooting IMS Server problems is to view the log files in C:\Encentuate\IMSServerx.x.x.x\ims\logs. In general, the stdout.log and stderr.log files are most useful.

It is important to understand that the stdout.log and stderr.log get overwritten when the IMS Server starts up. Therefore, if you have a problem and you want to provide the IMS Server log files, collect them before you restart the IMS Server. Otherwise the log files get lost during the next restart of the IMS Server.

IMS Configuration Utility cannot be accessed

If the IP address of the IMS Server has changed, the IMS Configuration Utility is inaccessible from the following URL unless the new IP address is included in the RemoteAddrValve configuration key of the \conf\server.xml file: http://imsservername:8080/

Restart the IMS Server after the configuration key is modified.

Alternatively, to retain the original configuration key, you can still access the IMS Configuration Utility from: http://localhost:8080/

IMS Server cannot issue certificate for an application

A known bug is that subject fields of IMS certificates must not contain the underscore character ( _ ). This character can cause problems at deployments that use certificate-based authentication for applications.

The result is that the IMS Server cannot issue CSR or CAPI certificates2 for an authentication service with an ID that contains the underscore character. The workaround is to remove all underscore characters from the IDs of authentication services that use certificate-based authentication.

2 Certificate Signing Request (CSR), Microsoft Cryptographic API (CAPI)

442 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 IMS Server diagnostic information

The IMS Server diagnostic information can be obtained at the URL: https://imsserver/ims/ui/diagnostics

Note: You should first log on to AccessAdmin before navigating to this page.

The site contains the list of SOAP services, IMS configuration information, test facilities for IMS Connectors, and descriptions of event and result codes.

IMS Server console startup

By default, the IMS Server runs automatically as a service, IMSService, when the machine starts up. When in this mode, troubleshooting problems with the IMS Server could be difficult. Alternatively, the IMS Server can be run in console mode, so that any error messages are displayed in real-time.

To run the IMS Server in console mode: 1. Stop the IMSService by using the command net stop IMSService. 2. Run the batch file \ims\bin\runserver.bat.

IMS Server database housekeeping problems

For normal database backup operations, the IMS database user must have backup permissions on the IMS database. However, if the Housekeeping RDB System Backup Flag is set to true, the IMS database user also must have administrative privileges, otherwise the following exception appears in the IMS Server standard error logs: java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]BACKUP DATABASE permission denied in database 'master'.

If cleanupRdbLogs is enabled (that is, log table pruning), a log directory should exist in the \bin directory, otherwise the following exception appears in the IMS Server standard error logs: java.io.FileNotFoundException: logs\rdbLogCleanup.log (The system cannot find the path specified)

Appendix A. Troubleshooting 443 Installation issues

In this section, we deal with installation issues.

Anti-virus software can interfere with AccessAgent or IMS Server

Certain anti-virus software has been observed to interfere with AccessAgent or IMS Server, causing the following symptoms: AccessAgent (on user’s PC, Terminal Server, or Citrix server) becomes slow. AccessAgent (on user’s PC, Terminal Server, or Citrix server) fails to start. Logging on to AccessAgent (on Terminal Server or Citrix server) fails intermittently. The IMS Server becomes slow.

At present, these problems have been observed at deployments that use McAfee anti-virus. To resolve the problem, store the following frequently changing Tivoli Access Manager for Enterprise Single Sign-On folders in the anti-virus software’s exclusion list: C:\Program Files\Encentuate\logs for AccessAgent C:\Encentuate for IMS Server

For the particular McAfee example, refer to “Configuration for McAfee antivirus”.

Configuration for McAfee antivirus To include Tivoli Access Manager for Enterprise Single Sign-On folders in the McAfee anti-virus software’s exclusion list: 1. Open the scanner’s property pages. 2. On the Detection tab, under What not to scan, use the exclusions feature. 3. Click Exclusions to open the Set Exclusions dialog box. 4. Add files, folders, or drives, or edit an item in the list. 5. To add an item, click Add to open the Add Exclusion Item dialog box. 6. Under What to exclude, select the folder using By name/location. 7. Under When to exclude, specify all options. 8. Click OK to save these settings and return to the Set Exclusions dialog box. 9. Click OK to save these settings and return to the Detection tab. 10.Click Apply to save these settings.

444 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 MSDE installation problem

If an old release of MSDE3 (before Service Pack 3) is installed on Windows XP (Service Pack 2), errors might not occur during installation. However, because of a security vulnerability of older versions of MSDE, Windows disallows the SQL server to use port 1433. This results in disconnections to the database during IMS Server installation.

Use the Event Viewer in the Applications category to find the logs generated by SQL server. Older versions of MSDE should indicate that port 1433 cannot be used because of a vulnerability in the current version of MSDE.

To resolve this issue, apply MSDE 2000 Service Pack 3 (or a newer version), or just download the latest release of MSDE installer from the Microsoft Support Web site.

IMS Server installation problem as a result of database configuration

The IMS Server installation might fail if the database server has been configured to return No Count. Because the IMS Server uses these counts to determine the success or failure of database operations, this database feature must be disabled.

To disable the database feature: 1. From Enterprise Manager, right-click the database server and select Properties. 2. Go to Connection → No Count, and disable the feature.

The IMS Server installation might also fail if the database has incorrect user privileges. The database user should have public, db_owner rights for the IMS database. The user should not be a DB Administrator account.

To check whether the database user has the correct privileges: 1. Select DB Server → Security → Logins. 2. Right-click DB login and select Properties. 3. Select the Server Roles tab. 4. Privileges are incorrect if the System Administrators and Database Creators roles check boxes are marked. If incorrect, manually prepare the IMS database and refer to the instructions in “Appendix C. Preparing the IMS database” of the IBM Tivoli Access Manager for Enterprise Single Sign-On Administrator Guide Version 8.0, SC23-9951.

3 MSDE stands for Microsoft SQL Server Desktop Engine.

Appendix A. Troubleshooting 445 Failure to connect to named instance of SQL Server 2000 database

If an earlier version of IMS Server is upgraded to version 3.3.1.4 or later, the upgrade can fail if the IMS database is a named instance of an SQL Server 2000 database. The following error message occurs: “There was a problem uploading all_storage_templates.xml” is displayed, since the IMS Server cannot connect to the database.

This problem is the result of a problem in a Microsoft’s SQL Server 2000 JDBC driver used prior to IMS Server version 3.3.1.4, which ignores the database port number field if a named instance is used. In the new SQL Server 2005 JDBC driver used in IMS Server version 3.3.1.4 and later, the port number field is not ignored, and the database connection would fail if the port number is incorrect.

To fix this problem during an IMS Server upgrade, modify the IMS Server configuration file to correct the port number, as follows: Provide the correct port number in the following keys in the ims.xml file (found in \ims\config): ds.ims.rdb.uri ds.ims_log.rdb.uri For example, if the correct port number is 1074, replace the following line: jdbc:microsoft:sqlserver://serverName\instanceName:1433 Replace it with the following line: jdbc:microsoft:sqlserver://serverName\instanceName:1074 To find the port number that is running the instance: –Select Start → Programs → Microsoft SQL Server → Server Network Utility >> Choose TCP/IP. – Click Properties. – Right-click database server and select Properties. For a fresh IMS Server installation, make sure that the port number in the installation wizard is correct.

RFID reader RDR-7172AKU problem

If you are using an RFID reader RDR-7172AKU, card detection issues might be caused by putting a machine into standby or hibernation mode and then resuming from it. This recurring issue is the result of some problems with the RFID reader drivers. To fix this problem, unplug and re-plug the RFID reader.

446 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 AccessAgent displays incorrect icons after an installation upgrade

When upgrading from an older version of AccessAgent to AccessAgent 8.0, the program icons are not updated and continue to display the icons used in the previous version of AccessAgent.

This is a Microsoft Windows icon cache problem. For Windows 2000, the system caches the older icons and re-uses them during an AccessAgent upgrade. A fix for the problem is to rebuild the Windows icon cache. Refer to Microsoft KB 199152 at: http://support.microsoft.com/kb/Q199152/

AccessAgent fails to install

If AccessAgent fails to install, check for the following items: Windows Scripting Host 5.6 and later should be installed. Windows Management Instrumentation (WMI) has to be functional. To verify that it is: a. Go to Computer Management → Services and Applications → WMI Control. b. Right-click Properties and see if the message “Successfully Connected to: ” is displayed. c. If no message is displayed, AccessAgent does not install.

Issues concerning Microsoft Operations Manager

A message, “Microsoft SQL Server 2000 SP3a or above required”, is displayed during installation of install Microsoft Operations Manager (MOM) 2005.

Refer to Microsoft KB 902803: http://support.microsoft.com/kb/902803/enus?spid=2548

A message, “Failed to create data source for data warehouse”, is displayed during installation of Microsoft Operations Manager Reporting.

Refer to Microsoft KB 555533: http://support.microsoft.com/default.aspx?scid=kb;en-us;555533

Appendix A. Troubleshooting 447 A message, “The MOM Server detected that DCOM was disabled on the remote computer”, is displayed during installation of the MOM Agent. To resolve the problem: 1. Open dcomcnfg in Start → Run. 2. Go to Console Root → Component Services → My Computer. 3. Right-click My Computer and select Properties. 4. In the My Computer Properties dialog, select the Default Properties tab. 5. Make sure the Enable Distributed COM on this computer option is marked.

Other issues

In this section, we describe problems that cannot be grouped into any of the previous sections.

AccessStudio logs

A useful approach for troubleshooting AccessStudio problems is to view the log files in the C:\Program Files\Encentuate\AccessStudio\logs folder. When you report a problem, including a.zip file that contains the entire folder is useful. Provide the approximate local times when the events occurred.

Unable to log on to AccessAdmin

If a user cannot log on to AccessAdmin, check the following items: 1. Make sure that the user has an Administrator or Help desk role. 2. If the user is not using a USB Key, ensure that the user’s Wallet has been cached. 3. Make sure that the machine Wallet has been downloaded properly (see “Machine Wallet download problem” on page 435). 4. Make sure that the DNS name of the IMS Server does not contain the underscore ( _ ) character (see “Machine Wallet download problem” on page 435). 5. Make sure that the URL of AccessAdmin is the same URL specified during IMS installation. To check the setting, go to the IMS Server page and double-click the lock icon to view the SSL certificate. The SSL certificate should list the exact host name that you have to use.

448 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 If you are using Windows 2003 Server and the home page of Internet Explorer starts up with the page res://../hardAdmin.htm, the Advanced Security Option might be enabled.

To set the home page to res://../softAdmin.htm, go to the Add or Remove Programs menu in the Windows Control Panel and select to Add/Remove Windows Components. Remove the Internet Explorer Enhanced Security Configuration.

SOCIAccess.exe failure caused by RFID readers

Restart the machine if you experience a SOCIAccess.exe failure when you unplug and re-plug RFID readers from RF Ideas. This issue is the result of problems with the RFID reader drivers.

Do not unplug and re-plug the RFID reader while AccessAgent is still running.

Application is slower when automatic sign-on is enabled.

Certain applications might respond slower when automatic sign-on is enabled, or noticeable delays can occur before credentials are auto-filled or auto-captured. These delays might be because of the use of an inefficient signature comparison in the AccessProfile for the affected application. If a signature where @title is the only predicate checked for top level window (for example, /child::wnd[@title="Logon"]), AccessAgent tries to retrieve the title of each top-level window using Windows messages.

However, for certain applications, many hidden top-level windows might be created during logon, and might take at least 0.5 seconds to respond to Windows messages. The response time in fetching the title of each window adds to the delay. For such cases, use more specific signatures to reduce the number of matching windows. For example, the @class_name predicate can be used in the signature to filter only windows of a certain class so that the title is fetched for fewer windows (fetching of class name does not require Windows messaging).

Missing labels in state engine view of AccessStudio

In certain Windows 2000 machines, the state engine view of AccessStudio might show a graph with the states and connections without any labels. The names of the states, triggers, and actions appear to be missing. This is because of the Arial font not being supported on the machine. The workaround is to install the Arial font.

Appendix A. Troubleshooting 449 Back button does not always work correctly

The browser’s Back button cannot be used when accessing AccessAdmin, AccessAssistant, and Web Workplace. AccessAssistant and Web Workplace are designed this way for security reasons; AccessAdmin is designed this way because of certain implementation constraints.

GINA conflict with ThinkPad fingerprint software

On an IBM Lenovo ThinkPad with a built-in fingerprint reader, EnGINA is not displayed during startup. Instead, the system fails. This issue can be caused because the ThinkPad ThinkVantage fingerprint GINA (vrlogin.dll) conflicts with EnGINA.

As a solution, disable the ThinkVantage fingerprint GINA (by selecting Start → ThinkVantage fingerprint → Control Center) before installing AccessAgent. If AccessAgent is already installed, make sure that the following registry entry is set to blank: [HKEY_LOCAL_MACHINE\SOFTWARE\Encentuate]"PrevGINA"

Performance data is not available in MOM reports

To resolve the problem of unavailable performance data: 1. Open the MOM Administrator console. 2. Select: Console Root → Microsoft Operations Manager (SERVER_NAME) → Administration → Computers → Agent-managed Computers 3. Right-click on the computer with the MOM agent installed, then select: Run → Attribute Discovery Now

Security logs are full

If the security logs are full, problems can occur both in Remote Desktop Protocol (RDP) connections to a private desktop machine, and also during the start-up of any shared workstation (shared desktop, private desktop, roaming desktop), as long as the auto-admin logon account is not an administrator account.

The security logs being full is a limitation that Windows imposes during logon and unlock.

450 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Documenting a PMR

This section provides instructions with check lists to use when a Problem Management Record (PMR) for IBM Tivoli Access Manager for Enterprise Single Sign-On must be opened. Depending on whether the problem exists in the AccessAgent of IMS Server site, different tasks should be performed.

Documentation of AccessAgent errors

The tasks differ slightly depending on whether the error is reproducible or not.

Error is reproducible If the error is reproducible, make sure to perform all tasks in the following checklist: Record the system time and date when the problem happened or when it is reproduced (very important). Take screen captures or record the exact text of any related error messages. Document the issue and steps to reproduce the error and its effects upon the organization. Back up or delete all the logs in the AccessAgent directory (usually C:\Program Files\Encentuate\logs). For most development and testing, you may delete the logs. However, check with management if in doubt. Reproduce the problem documenting the exact actions taken. Compress all the logs in the AccessAgent directory right after the test is finished. Export the profiles through the File → Save As feature of AccessStudio. Export the system data from IMS through the Tools → Backup System data to file feature of AccessStudio, if applicable. Save Windows Event logs, if applicable. Open a PMR. Send all pertinent information to your IBM Support contact.

Error is not reproducible If the error is not reproducible, make sure to perform all tasks in the following check list: Record the system time and date when the problem happened (very important).

Appendix A. Troubleshooting 451 Take screen captures or record the exact text of any related error messages. Document the issue, the steps leading to the failure and its effects upon the organization. Compress all the logs in the AccessAgent directory (usually C:\Program Files\Encentuate\logs). Export the profiles through the File → Save As feature of AccessStudio. Export the system data from IMS through the Tools → Backup System data to file feature of AccessStudio if applicable. Save Windows Event logs if applicable. Open a PMR. Send all pertinent information to your IBM Support contact.

Documentation of IMS Server errors

Perform the following tasks if a problem exists with the IMS Server. Record the system time and date when the problem happened or when it is reproduced (very important). Take screen captures of any related error messages. Document the issue, the steps leading to the failure and its effects upon the organization. Compress all logs in the IMS Server Directory: C:\Encentuate\IMSServer.x.x.x\logs C:\Encentuate\IMSServer.x.x.x\ims\logs Export the profiles through the File → Save As feature of AccessStudio if applicable. Export the system data from IMS through the Tools → Backup System data to file feature of AccessStudio if applicable. Save Windows Event logs if applicable. Open a PMR. Send all pertinent information to your IBM Support contact.

452 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 B

Appendix B. Advanced profiling

Tivoli Access Manager for Enterprise Single Sign-On AccessStudio Assistant is the standard method to create AccessProfiles, integrating an application into the overall single sign-on solution by using this wizard.

This appendix provides several scenarios for using advanced profiling techniques. We show specific examples of how to integrate such applications, using XPath (XML Path Language), a language that facilitates XML document navigation, as well as using Microsoft Visual Basic® Script (VBScript).

Specific applications cannot be integrated with the AccessStudio Assistant only. Some applications might use dynamic IDs. That is, the control ID for the password field can be different with every restart of the applications. Other applications might seem difficult to integrate at first, because the control IDs for user name and password cannot be distinguished from each other with standard methods. Let us discuss three separate use cases of advanced profiling in order to shed more light into this discipline.

Use case: Configure a trigger to match properties

This use case demonstrates how to use Tivoli Access Manager for Enterprise Single Sign-On’s strong XPath implementation to manually configure a trigger that matches several properties of a window, as follows: We implement a profile for Acrobat® Reader in a way that the password can still be captured by Tivoli Access Manager for Enterprise Single Sign-On, directly out of the application’s window password field. We show how to set the application signature to have a profile for a specific PDF file only.

Figure B-1 shows the password dialog for the write-protected file named PressRelease.pdf. Note that this dialog contains the name of the write-protected PDF file. Later in this example, we include this file name in the profile so that it uniquely triggers for this specific PDF file only.

Figure B-1 Write-protected PDF file - logon dialog

454 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 To manually configure a trigger to match properties: 1. As a first step the AccessStudio Wizard can be used to generate a basic profile. Figure B-2 shows the result.

Figure B-2 Wizard generated profile for a write protected PDF file

2. This profile created by the wizard never asks the user to store the password. The reason is that the buttons OK and Cancel in Figure B-1 on page 454cannot be distinguished. To observe the details click Enable state editing. See Figure B-3.

Figure B-3 Enable state editing

3. The highlighted trigger When a left mouse button is clicked on a window in Figure B-4 contains the signature for this trigger. It should trigger when the user clicks the OK button after entering the password.

Figure B-4 Position of trigger - When a left mouse button is clicked on a window

Appendix B. Advanced profiling 455 Figure B-5 shows the trigger’s signature as configured by the wizard.

Figure B-5 Signature for trigger - When a left mouse button is clicked on a window

4. By clicking the crosshair (shown in the lower right corner in Figure B-5), we navigate to the Finder tool. 5. Clicking on Highlight Window while the password window is opened, as shown in Figure B-6 on page 457, proves that this signature cannot trigger. A message box opens, stating that “Multiple windows match the window signature.” Those two windows are the OK button and the Cancel button.

456 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure B-6 Multiple windows match the window signature

The challenge in this use case, and for similar applications, is to find a matching signature so that we do not have to use a fallback-scenario such as using sendkeys, or showing a dialog asking for user’s credentials. In this case, one solution is to distinguish the OK and Cancel buttons by their horizontal position within the logon dialog. Using Tivoli Access Manager for Enterprise Single Sign-On’s strong XPath implementation, this distinction can be achieved by using the attribute @xpos, which contains the horizontal position of the window to the parent window. 6. After adding the string @xpos=330 to the signature, as shown in Figure B-7 on page 458, we can successfully trigger for the user clicking the OK button. Clicking Highlight Window does highlight the OK button.

Appendix B. Advanced profiling 457 Figure B-7 A trigger for the OK button

Note: Go through the whole profile and assure that you change all signatures that should trigger that OK button.

Finding the value @xpos=330 can be done with several tools. Here, we use Microsoft Spy++1. Another possibility is provided by the tool X-Spy2. If you first drag and drop the Spy++ crosshair to the OK button, and then to its parent window, you can calculate the value 330 by subtracting the two x-coordinates from each other.

1 Microsoft Spy++ is provided with Microsoft Visual Studio® 6.0. More information about it can be obtained at: http://msdn.microsoft.com/en-us/library/aa264396(VS.60).aspx 2 For more information about X-Spy, see http://www.x-spy.net/index.php?lang=en&site=index

458 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 7. In Spy++, open the Finder Tool by pressing Ctrl +F, then select Hide Spy++. See Figure B-8.

Figure B-8 Spy++

Appendix B. Advanced profiling 459 8. Drag and drop the crosshair to the OK button of the logon dialog, as shown in Figure B-9.

Figure B-9 Spy++, coordinates of OK button

The first number in the Rect field is the left horizontal position (in pixels) of the OK button. In our example, the value is 1070.

460 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 9. Now drag and drop the crosshair to the area just to the left of the OK button, so you catch its parent window position, as shown in Figure B-10.

Figure B-10 Spy++, coordinates of OK button’s parent window

The Rect value in our example is 740. Subtracting 740 from 1070 leads us to the result 330, which is the input for @xpos in our example. 10.Now, we have to change the triggers “When a window is activated” as shown in Figure B-2 on page 455.

Note: The wizard-generated profile triggers the logon window, but it does this independently of the PDF file to be opened. Also, our example is risky, because the position of the OK button might change with every filename. As a result, the parameter xpos=330 would not trigger any more for the OK button. Consider that this is only an example, and you will have to decide on a case-by-case basis which is the best way to enable an application for single sign-on.

Appendix B. Advanced profiling 461 The original signature for matching the password window is defined by the wizard as: /child::wnd[@title="Password" and @class_name="#32770"] /child::wnd[@class_name="GroupBox"] /child::wnd[@class_name="RICHEDIT50W"] /parent::wnd[@class_name="GroupBox"] /parent::wnd[@title="Password" and @class_name="#32770"] We see the window title Password, the standard window class 32770, but the PDF filename is still missing. 11.First, mark the trigger When a window is activated and click again on the crosshair in the lower right corner, as we did in Figure B-5 on page 456, to navigate to the Finder tool. 12.Then, drag and drop the crosshair to the line in the logon window containing the specific filename (complete text: ‘PressRelease.pdf’ is protected. Please enter a Document Open Password.) as shown in Figure B-11.

Figure B-11 Move the crosshair to the PDF filename line

Now, the captured signature is defined as: /child::wnd[@title="Password" and @class_name="#32770"] /child::wnd[@class_name="GroupBox"] /child::wnd[@title="'PressRelease.pdf' is protected. Please enter a Document Open Password." and @class_name="Static"] This now matches for the specific line, but not for the whole window yet. The parent window information is still missing. 13.Finally, we combine those two signatures, by adding the parent lines from our first example to the end of the example in the previous step. The new signature must be: /child::wnd[@title="Password" and @class_name="#32770"] /child::wnd[@class_name="GroupBox"] /child::wnd[@title="'PressRelease.pdf' is protected. Please enter a Document Open Password." and @class_name="Static"] /parent::wnd[@class_name="GroupBox"] /parent::wnd[@title="Password" and @class_name="#32770"]

462 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Important: For better reading we have added line feeds before each forward slash (/) character in the signatures above. You should not do this in the AccessStudio or the signature will not be functional.

This concludes our first use case on advanced profiling.

Use case: Start a program from the command line

This use case demonstrates how to start an application from a command line of an AccessProfile, as follows: We implement an AccessProfile that captures user name and password. Tivoli Access Manager for Enterprise Single Sign-On starts an application and enters user name and password as additional command line parameters.

Our example includes a fictitious program named “TAA Client” that can be started through the command line, for example: C:\Program Files\TAA\TAA.exe /u:,

The complete AccessProfile is shown in Figure B-12 on page 464. We now describe the details.

Appendix B. Advanced profiling 463 Figure B-12 AccessProfile overview

To start a program from a command line: 1. First, we have to decide when to start this command line. In this use case, we create a short VBScript to set a trigger. The user starts it by double-clicking on a desktop icon. Tivoli Access Manager for Enterprise Single Sign-On detects this action as we define the correct signature in an AccessProfile. Let us assume the application is named “TAA Client” and so we create the following VBScript: Const wshOK = 32 Set objShell = CreateObject("Wscript.Shell") intReturn = objShell.Popup("Starting TAA", 0, "TAA Client", wshOK) The number 0 (zero) in the last line specifies that the window automatically closes after 0 seconds, which means it never closes. The text "Starting TAA" bears no consequence in our case, it only defines a window message and can be seen in Figure B-14 on page 465. Only the text "TAA Client", which defines the title of the pop-up window, triggers in our example.

464 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 We then create a shortcut to this script on the desktop, as shown in Figure B-13.

Figure B-13 The VBScript as desktop icon

Double-clicking this shortcut opens a dialog, as shown in Figure B-14.

Figure B-14 The VBScript pop-up window

This will be our trigger for the AccessProfile. 2. In the AccessStudio, we have to define a signature for the VBScript on the General Properties tab. It includes the executable: /child::exe[@exe_name="wscript.exe"] 3. We have to distinguish our VBscript from any other, so the first trigger in the AccessProfile as shown in Figure B-15 does include more details: /child::wnd[@title="TAA Client" and @class_name="#32770"] We only match for our example VBScript, as we specifically trigger for the title “TAA Client”. The “#32770” is a standard window class.

Figure B-15 Trigger - When a window is activated

Appendix B. Advanced profiling 465 4. The trigger, Fires immediately, in the next state (see Figure B-17 on page 467) includes the condition as shown in Figure B-16 on page 467: NO_ACCOUNT_DATA_FOUND=1, which means that the credentials bag for this AccessProfile is still empty. So, the next actions are to capture the user credentials and to save them. The last action includes a VBScript, built into AccessProfile, and its security context. It starts “TAA Client” from a command line on behalf of the user and includes the credentials user name and password as parameters to sign-on the user to the “TAA Client”. We discuss this script later. 5. The triggers in Figure B-17 on page 467 will never trigger if we do not enter the action Auto-fills user credentials, as shown in Figure B-15 on page 465. The reason is that the property NO_ACCOUNT_DATA_FOUND is not defined yet. So, we create a dummy action that contains no injection fields at all. However, it does initialize the property NO_ACCOUNT_DATA_FOUND and sets it to 1. If this action was not set, the aa_observer.log would include this line: {WScript.exe} [CObsTrigger::TestProperties] Property not in bag, id = NO_ACCOUNT_DATA_FOUND Another essential task is to define an authentication service in this action, in our example the direct authentication service auth_TAAClient. The text asi in the action Auto-fills user credentials - asi shows that we set an authentication service.

466 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure B-16 Condition NO_ACCOUNT_DATA_FOUND

Figure B-17 Trigger When no account data exist

6. The next time that the user starts the VBScript, the property NO_ACCOUNT_DATA_FOUND is not true anymore, and the other trigger as shown in Figure B-18 on page 468 will fire. Here we test the condition NO_ACCOUNT_DATA_FOUND=0.

Appendix B. Advanced profiling 467 Figure B-18 Trigger When account data exist

7. We define the action Shows a dialog to capture user’s logon credentials. We chose the signature of the OK Button, including the string TAA Client: /child::wnd[@title="TAA Client" and @class_name="#32770"]/child::wnd[@class_name="Button" and @ctrl_id=2] The authentication service is auth_TAAClient, and credentials to be saved are defined in Advanced Options as: adt_ciuser_cspwd (default) 8. The next action saves the user credentials. Alternatively we also could have configured the last action to store the captured credentials into the Wallet directly. 9. The next trigger, as shown in Figure B-19, includes the last action. It closes the VBScript pop-up window. This would also close our AccessProfile pop-up window, which has to run a VBScript to start the "TAA Client" because this is a child process. However, the separate "TAA Client" process itself will not be closed, because it is a separate process. We set this trigger to wait two seconds. The signature for this action is: /child::wnd[@title="TAA Client" and @class_name="#32770"]

Figure B-19 Action to close the VBScript pop-up window

468 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 10.Finally, we look at the VBScript to start the "TAA Client": set pc = runtime.GetPropertiesContainer() user = pc.GetAccDataItem("default_capture_bag","aditi_ciuser",1) pwd = pc.GetAccDataItem("default_capture_bag","aditi_cspwd",1)

strCmd = "C:\Program Files\TAA\TAA.exe /u:" & user & "," & pwd

set wsShell = CreateObject ("WScript.Shell") wsShell.run strCmd set wsShell = nothing

‘MsgBox("user: " & user & "; pwd:" & pwd & "; strCmd: " & strCmd) First, we get the runtime variables of our AccessProfile and read user name (ciuser, case-insensitive user) and password (cspwd, case-sensitive password) out of the default capture bag into two variables. Then, we built up our command line as shown at the beginning of this use case: strCmd = "C:\Program Files\TAA\TAA.exe /u:" & user & "," & pwd Finally, we execute the command to start the command line. The next message box (MsgBox) is for debugging purpose only and can be commented.

To finalize this use case we attach the complete AccessProfile TAA.eas in Example B-1.

Example: B-1 Complete AccessProfile TAA.eas

app_TAAClient TAAClient auth_TAAClient TAAClient adt_cspwd

Appendix B. Advanced profiling 469 profile_TAAClient 1 /child::exe[@exe_name="wscript.exe"] app_TAAClient state_start /child::wnd[@title="TAA Client" and @class_name="#32770"] Encentuate AccessAgent 6 81110451141401411940651057312573141110131102 auth_TAAClient 914292150121413139479141183155509611471111153 112611626119151514113891457171117111139946 state_after_set_variables 1531187100820024721291573592111537380103 90251580127089445911227150642511120121110 auth_TAAClient

470 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 /child::wnd[@title="TAA Client" and @class_name="#32770"]/child::wnd[@class_name="Button" and @ctrl_id=2] default_capture_bag 811012446610151413493910971701181186914536 114913291314991410415141396114141076213211149135 1215133691311411441013291115310141171512010134 1 1531187100820024721291573592111537380103 0887711155135842311118022113226107810313 651114121410106071141213483141121553925112824

Appendix B. Advanced profiling 471 0 state_after_program_started 76845101254131424105680451514948201311410 2 /child::wnd[@title="TAA Client" and @class_name="#32770"] 6960137147131213847651113151513911286661411116 741011114321115124431113913411132821514213131110 state_after_window_closed

Use case: Create a host emulator

Before we actually create the advanced profile, we have to define requirements and discuss the user interaction with the application.

Note: This particular scenario is an example of advanced profiling for host emulators. It is important to recognize the requirements and environment of the host emulator in order to determine whether to use HLLAPI or cursor-based triggers to recognize the information on the screen.

472 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Define the requirements

Before we begin using AccessStudio to create a profile for the host emulator, our first step should be to define the requirements for how we want Tivoli Access Manager for Enterprise Single Sign-On to interact with the emulator.

The emulator login window contains several fields, more than just User and Password, as shown in Figure B-20.

Figure B-20 The host emulator login screen

Our first requirement is that Tivoli Access Manager for Enterprise Single Sign-On should only inject the user and password. It is capable of injecting values into all of the presented fields, but we only require user and password for this example.

Our second requirement is that user credentials are automatically submitted only if the user has auto-logon set for the host emulator authentication service in the user’s Wallet. Figure B-21 on page 474 shows the host emulator main menu after login.

Appendix B. Advanced profiling 473 Figure B-21 The host emulator main menu after log in

Our third and last requirement for this profile is that the AccessAgent should automatically log off the active host emulator session when a user logs off from the AccessAgent. Most host emulators require users to sign off by using keystrokes (90 in the case of this emulator, as shown in Figure B-21). If the emulator window is closed without the user signing off, the session can still remain active on the host server, potentially causing issues. We want the AccessAgent to actually sign off the active user before closing the window. This is especially important when the AccessAgent is logged off because of desktop inactivity.

To summarize, we have three high-level requirements for this profile: AccessAgent should automatically inject only the user name and password. AccessAgent should auto-logon only if it is set as a preference in the user Wallet. AccessAgent should automatically sign off the host emulator session before closing the emulator window, when a user logs off the AccessAgent either manually or because of desktop inactivity timeout.

474 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Understand user interaction with the application

To design an accurate AccessProfile you must fully understand how users interact with the application.

For the host emulator application in our scenario, users typically follow this process: 1. Double-click the emulator icon to open it. 2. Enter a user name without having to first click the user name field. 3. Press the Tab key to navigate to the password field. 4. Enter a password. 5. Press the Enter key to submit user credentials. 6. Entering 90 on the command line to log out.

Knowing that these are the steps that the average user takes when logging in and out helps us design an AccessProfile that reflects these exact actions automatically.

Now that we know how users use the application, and we have defined the requirements for the AccessAgent interaction with the host emulator, we can begin to design the AccessProfile.

Create the advanced profile

To create the advanced profile: 1. Create an authentication service for the host emulator. Select New → New Authentication Service (Figure B-22).

Figure B-22 Create a new authentication service

2. Fill in the Id and Display Name fields. These can be names of your choice, but make sure to use a consistent naming convention for the IDs to help you

Appendix B. Advanced profiling 475 identify them more easily when you have many similar authentication services. We also want to select adt_ciuser_cspwd (default) for the Account data template ID, shown in Figure B-23. This host emulator automatically makes the user name uppercase, so we can configure the account data template for case-insensitive user account data. The password is case-sensitive.

Figure B-23 Authentication service fields

476 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. Click in the left frame to see the changes applied to the authentication service name as shown in Figure B-24.

Figure B-24 Authentication service created

4. Now, we have to create a new application. Select New → New Application as shown in Figure B-25.

Figure B-25 Create a new application definition

Appendix B. Advanced profiling 477 5. Fill in the Id and Name fields, shown in Figure B-26. Make sure the fields accurately reflect the application, and stay consistent with the naming convention of other applications.

Figure B-26 Fill in the application Id and Name fields

6. Click in the left frame to apply the application name as shown in Figure B-27.

Figure B-27 Click the left frame to apply the application Id

478 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 7. Next, we begin to create the AccessProfile. Select New → New Advanced AccessProfile, as shown in Figure B-28.

Figure B-28 Create a new advanced profile

8. Fill in a name in the AccessProfile Id field. Click the left frame to apply the name change as shown in Figure B-29.

Figure B-29 Give the AccessProfile an identifier

9. We have to add a signature so that the AccessProfile can identify when it should be loaded. For this scenario, the signature is the .exe file of the host emulator. Click Add (under Signatures identifying web-page or exe where this AccessProfile is to be loaded) as shown in Figure B-30 on page 480.

Appendix B. Advanced profiling 479 Figure B-30 Add a new signature

10.The signature identification window is spawned. Click and drag the crosshairs of the Finder tool directly over the title bar of the host emulator, as identified by the arrow in Figure B-31.

Figure B-31 Click and drag the Finder tool crosshairs to the host emulator title bar

480 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 11.The result of the Generated Signature includes the exe of the host emulator, as shown in Figure B-32. Click Ok.

Figure B-32 The generated signature

The generated signature is added to the AccessProfile, as shown in Figure B-33.

Figure B-33 The generated signature in the General Properties tab

12.Select Advanced Options to expand it, as shown in Figure B-34, and select the application ID that you just created in step 4 on page 477.

Figure B-34 Apply the application ID to the AccessProfile

Appendix B. Advanced profiling 481 13.The host emulator we are using is an HLLAPI-enabled application. We have to enable support for HLLAPI applications in the General properties tab. Select the Extra Support drop-down menu and check the Enable HLLAPI support for mainframe applications check box. Enter the Application type and Dll relative path as shown in Figure B-35.

Figure B-35 Enable HLLAPI support

Design the state engine Now, we can begin to design the state engine for our host emulator AccessProfile. Click the State tab, as shown in Figure B-36.

Figure B-36 The state engine

482 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Designing state engines comprises the majority of the effort involved for creating an advanced profile. This section assumes you have a base-level understanding of states, triggers, and actions. If you do not, then before you continue with this section, refer to the Advanced Concepts section of the IBM Tivoli Access Manager for Enterprise Single Sign-On AccessStudio Guide Version 8.0, SC23-9956.

To design a state engine: 1. Our first step is to help the AccessProfile identify when a host session has started. We do this by triggering from the Start State to a new state, when a new host session is detected. To begin, click New State. This generates a new state object as shown in Figure B-37.

Figure B-37 Create a new state

2. Rename the new state to something that clearly identifies the state that the profile will be in at this point. Type in a new name in the State Name field; see Figure B-38.

Figure B-38 Rename the new state

3. Now, we have to connect the Start State and session_start with an appropriate trigger. Our goal is to identify when a session starts. Click on the state where the trigger should be triggered from (Start State) and then select: New Trigger → Advanced Triggers → When a session starts (HLLAPI)

Appendix B. Advanced profiling 483 This creates a trigger that begins and ends on the state where we created it, as shown in Figure B-39.

Figure B-39 New trigger is created

4. The trigger must end on the state that we just created. On the Form Editor, select the state you just created by selecting it from the drop-down menu under Next state id; see Figure B-40.

Figure B-40 Select the next state ID for the trigger

484 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. AccessStudio needs to know the signature of the window that the trigger is based on. Click the crosshair button under Signature of the HLLAPI-enabled application window, as shown in Figure B-41.

Figure B-41 Identify the signature of the host terminal window for the trigger

Appendix B. Advanced profiling 485 6. The Signature Window opens, as shown in Figure B-42. Click and drag the Finder tool crosshair to the host emulator window title bar.

Figure B-42 Identify the signature window using the Finder tool

486 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 The Finder tool crosshair is on the host window title bar. See Figure B-43.

Figure B-43 Crosshair is placed on the application window title bar

7. You can now see the generated signature of the application window (Figure B-44). Click Ok.

Figure B-44 Generated signature

Appendix B. Advanced profiling 487 8. As shown in Figure B-45, the session start trigger is complete. The next state ID and the signature of the application window are both identified.

Figure B-45 Session start trigger configuration complete

9. Click Advanced Options to expand it, as shown in Figure B-46, and enter the Short name of the host emulator.

Figure B-46 Enter the short name

10.The Short name can be found by opening the host emulator and selecting Options → Advanced → Global preferences. Ensure the short name A is selected with a configuration file, and that Shared among all users is selected as shown in Figure B-47 on page 489.

488 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure B-47 Host emulator global preferences

11.Next, we have to identify the host emulator window by an exact text-matching trigger. This allows identification of the correct host emulator screen if there are more than one that an employee can open, and allows us to place actions on this trigger in the next steps. Right-click on the session_start state and select Add trigger → Advanced → When text is displayed on a window (HLLAPI). 12.Notice the red exclamation mark (!) next to the trigger shown in Figure B-48.

Figure B-48 Form Editor input

The exclamation mark represents an incomplete set of parameters for the trigger, because we have to set the text on which we want the trigger to act.

Appendix B. Advanced profiling 489 13.Select Sections to expand it. Click Add to add a text section. In the Match text (regex) field, enter a regular expression (regex) compatible expression (Figure B-49). We have entered .*library.* to indicate that if the word “library” is seen anywhere on the screen, the state engine should act on the trigger. The word library appears only on the host emulator sign-on screen, so we know this is a valid word for the trigger to act on.

Figure B-49 Set the match text for the match text trigger

14.Create a new state and name it after_text_is_displayed. 15.In the Form Editor tab, for the trigger “When a text is displayed on a window (HLLAPI),” select after_text_is_displayed as the Next state ID, as shown in Figure B-50.

Figure B-50 Select the next state for the match text trigger

490 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 The state engine appears as shown in Figure B-51.

Figure B-51 State engine

Now, we have a trigger that transitions to a state where the application session is known to have started. Transitioning from the session_start state is where either credential injection will begin, or transition to the next state where we can trigger for credential capture. Whether we want injection or caption to happen will depend on whether the user has already saved the application credentials in the user Wallet. This means that from the state, after_text_is_displayed, there will be two defined paths to the end state: – First-time login to the application with AccessAgent active, when AccessAgent asks the user whether to save the application credentials in the Wallet. This is the capture condition, or as you will see in the next steps, when injection of credentials by AccessAgent does not happen. – Subsequent login when the AccessAgent automatically injects the stored user credentials. This is the injection condition, when injection of the credentials does happen. This process requires that each trigger, with an action to either capture or inject credentials, is conditional based on whether or not the injection of credentials has already happened.

Appendix B. Advanced profiling 491 16.We start by building the capture path. Create a new state called after_user_actions, as shown in Figure B-52.

Figure B-52 Create after_user_actions state

Now we have to set a trigger that emulates what a user would do when the application screen appears. As described previously, the user enters a user name and then presses Tab to navigate to the password field. 17.Right-click the after_text_is_displayed state and select Add trigger → Advanced → When a key/keys are pressed on a window (Win32®). In the Form Editor, select after_user_actions as the Next state ID (Figure B-53).

Figure B-53 Form Editor for the trigger, selecting Next state ID

492 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 18.Once again, the Signature Window opens. Click and drag the Finder tool to the application window where the text is displayed. See Figure B-54.

Important: Choose where the text is displayed. Do not choose a signature such as the title bar. We have to select the window where a user enters text, because that is the action we will emulate with this trigger.

Figure B-54 Select the application screen with the Finder tool where text is entered

19.As shown in Figure B-55 on page 494, the crosshair of the Finder tool is in the center of the screen. Notice how the tool also highlights the border of the text screen with a black rectangle.

Appendix B. Advanced profiling 493 Figure B-55 Text area is selected with crosshair; Finder tool borders area in black

20.The generated signature is displayed (Figure B-56). Click Ok.

Figure B-56 The generated signature of the text screen

494 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 21.In the Form Editor, notice that the generated signature is automatically placed in the field. We now have to select the key on which the trigger will fire. From the “Fire trigger on key” drop-down menu, and select tab (Figure B-57).

Figure B-57 Select tab as the key to fire the trigger

Now we have to set the condition for this trigger. Remember, this is the capture flow so we want to set the condition as though the automatic injection has not yet happened.

Appendix B. Advanced profiling 495 22.Click Conditions to expand it. Under Add Conditions, select Check a property value, and then click Add. This generates the Check Property Value Condition menu, shown in Figure B-58. For the property ID, select INJECTION_HAPPENED; for the Test again value field, enter 0 (zero).

Figure B-58 Set the condition for the trigger

23.Click the state engine frame. The state engine now look like Figure B-59.

Figure B-59 State engine after tab key press trigger

Now, we have to add the action for the Tab key-press trigger. Because the user presses Tab after entering the user name, we have to capture the user name when Tab is pressed.

496 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 24.Right-click the trigger When a key/keys are pressed on a window (Win32) {1c}, and select Add action → Captures user credentials. The trigger now shows the action underneath, as in Figure B-60.

Figure B-60 Add action to capture user credentials

25.In the Form Editor for the action we just created (Figure B-61 on page 498): a. Make sure default_capture_bag is selected in the Account data bag ID menu. b. In the Capture fields, select Windows control (using keyboard input) from the Add field of type menu. Click Add. c. Under the newly added Windows control (keyboard input) menu: i. Select adti_ciuser under the Account data item template ID menu. ii. In the Windows signature field, paste in the exact same Xpath text from the signature in the tab key press trigger we created in step 20 on page 494.

Appendix B. Advanced profiling 497 Figure B-61 Configure how the action will capture the user credential

26.Also on the same Form Editor tab, click Authentication-service info to expand it, and then: a. Select Direct Auth Info from the drop-down menu and click Add. b. Under the Authentication service ID, select the authentication service we created in step 1 on page 475, auth_As400. The result looks like Figure B-62.

Figure B-62 Authentication service information in the Form Editor

Next, we have to capture the user’s password in the same manner that we captured the user name. We captured the user name after the Tab key is pressed. Now we have to capture the password after the user presses Enter to submit the credentials.

498 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 27.Create a new state called after_password_actions. 28.Right-click on the after_user_actions state and select Add trigger → Advanced → When a key/keys are pressed on a window (Win32). In the Form Editor as shown in Figure B-63: a. Select after_password_actions as the next state ID. b. In the Windows signature field, paste in the exact same Xpath text from the signature in the tab key press trigger we created in step 20 on page 494. c. Under Fire trigger on key, select Enter from the drop-down menu.

Figure B-63 Form Editor for trigger fired on enter key, after password entered

29.Select Conditions to expand it. See Figure B-64 on page 500. Under Add Conditions select Check a property value from the drop-down menu, and click Add. This generates the Check Property Value Condition menu. Under property ID select INJECTION_HAPPENED, and enter 0 (zero) in the Test against value field.

Appendix B. Advanced profiling 499 Figure B-64 Set condition for the trigger to injection has not happened

30.The new state engine is depicted in Figure B-65.

Figure B-65 State engine after enter key press trigger

500 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 31.Right-click the trigger When a key/keys are pressed on a window (Win32) {1c}, and select Add action → Captures user credentials. The trigger shows the action underneath as in Figure B-66.

Figure B-66 State engine after action added to capture password

32.In the Form Editor for the action we just created (Figure B-67 on page 502): a. Make sure default_capture_bag is selected under the Account data bag ID drop-down menu. b. Under the Capture fields, select Windows control (using keyboard input) from the Add field of type menu. Click Add. c. Under the newly added Windows control (keyboard input) menu: i. Select adti_cspwd under the Account data item template ID drop-down menu. ii. In the Windows signature field, paste in the exact same Xpath text from the signature in the tab key press trigger we created in step 20 on page 494.

Appendix B. Advanced profiling 501 Figure B-67 Form Editor for capture password action

33.Repeat step 26 on page 498 to add the authentication service information for the capture password action. 34.As the final step for our capture flow, we want to set an action for AccessAdmin to ask the user to save the credentials it has captured in the last few steps. Right-click the trigger we created in step 28 on page 499. Select Add action → Saves user credentials as shown in Figure B-68.

Figure B-68 Add action to save user credentials

502 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Editing any fields on the Form Editor for the Saves user credentials action is unnecessary. The state engine should now look like Figure B-69.

Figure B-69 State engine with the capture flow completed

This completes the capture flow.

Add triggers and actions for injection flow We now have to add triggers and actions for the injection flow. We want the AccessAgent to automatically inject the user name as soon as the host emulator screen opens, so we add an action to inject the user name under trigger for when text is displayed and detected on the screen.

Appendix B. Advanced profiling 503 To add triggers and actions: 1. Right-click the trigger When a text is displayed on a window (HLLAPI). Select Add Action → Auto-fills user credentials. The action will appear under the trigger as shown in Figure B-70.

Figure B-70 State engine after adding action to auto-fill user credentials

2. In the Form Editor for the Auto-fills user credentials action we just created, perform the following actions, as shown in Figure B-71 on page 505: a. Make sure default_injection_bag is selected under Account data bag ID drop-down menu. b. Under the Injection fields menu, select Windows control (using keyboard input) from the Add field of type menu. Click Add. c. Under the newly added Windows control (keyboard input) menu: i. Select adti_ciuser under the Account data item template ID menu. ii. In the Windows signature field, paste in the exact same Xpath text from the signature in the tab key press trigger we created in step 20 on page 494. d. Repeat step 26 on page 498 to add the authentication service information for the capture password action.

504 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure B-71 Form Editor for auto-fills user credentials action

Now that the user credentials are injected automatically, we want the AccessAgent to automatically navigate to the password field using the “tab” key, just as a real user would. This requires an automatic trigger. 3. Right-click after_text_is_displayed state and select Add trigger → Advanced → Fires immediately. 4. In the Form Editor for the Fires immediately trigger (Figure B-72 on page 506): a. Change the Next state ID to after_user_actions. b. Click Conditions to expand it, and select Check a property value and click Add. c. Click Check Property Value Condition to expand it and then: i. Select INJECTION_HAPPENED for the Property ID. ii. Enter the value 1 into the field under Test against value.

Appendix B. Advanced profiling 505 Figure B-72 Set conditions for the fires immediately trigger

The new state engine is depicted in Figure B-73.

Figure B-73 State engine after adding the Fires immediately trigger

506 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 5. Right-click the Fires immediately trigger and select Add action → Advanced → Simulates keyboard input. 6. In the Form Editor for the Simulates keyboard input action, perform the following steps (see Figure B-74): a. Paste the exact same Xpath text from the signature in the tab key press trigger we created in step 20 on page 494 into the field for Signature of window where keys are to be sent. b. Select No in the Click window first field. c. Click Keys to expand it. Under Add Keys, select Key and click Add. d. This generates the Key drop-down menu. Click Key to expand it and select tab for the Key to press. e. In the Repeat count field, enter 1.

Figure B-74 Form Editor to automatically press the tab key after filling the user name

7. Now that we have set the automatic tab key press, we have to automatically enter the user’s password. We can do this by injecting the password right after the tab key action. Right-click the Fires immediately trigger and select Add action → Auto-fills user credentials.

Appendix B. Advanced profiling 507 8. In the Form Editor for Auto-fills user credentials action, perform the following steps, as shown in Figure B-75: a. Make sure default_injection_bag is selected under Account data bag ID drop-down menu. b. Under the Injection fields menu, select Windows control (using keyboard input) from the Add field of type menu. Click Add. c. Under the newly added Windows Control (keyboard input) menu: i. Select adti_cspwd under the Account data item template ID menu. ii. In the Windows signature field, paste the exact same Xpath text from the signature in the tab key press trigger we created in step 20 on page 494. d. Repeat step 26 on page 498 to add the authentication service information for the capture password action.

Figure B-75 Form Editor for the action to auto-fill the password

The new state engine is shown in Figure B-76 on page 509.

508 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure B-76 State after action to press tab and auto-fill password

Now that we have set the automatic injection of user and password, the next step is to configure the AccessProfile to automatically submit the credentials that have been injected by the previous triggers and actions, but only if the user has enabled auto-logon. 9. Right-click the after_user_actions state and select Add trigger → Advanced → Fires immediately. 10.In the Form Editor for the Fires immediately trigger (Figure B-77 on page 510): a. Change the next state ID to after_password_actions. b. Click Conditions to expand it, select Check a property value and click Add. c. Under the Check Property Value Condition menu: i. Select INJECTION_HAPPENED under the Property ID menu. ii. Enter the value 1 into the field under Test against value.

Appendix B. Advanced profiling 509 Figure B-77 Form Editor for the Fire immediately trigger after password injection

Now we have to add the action that will be fired immediately after password injection: pressing the Enter key. To do this, we use the copy/paste feature of the state engine. 11.Right-click the Simulates keyboard input action we created in step 5 on page 507, and select Copy, as shown in Figure B-78.

Figure B-78 Copy the action to simulate keyboard input

510 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 12.Right-click the second Fires immediately trigger, that we created in step 9 on page 509. Select Paste, as shown in Figure B-79.

Figure B-79 Paste the action into the second Fires immediately trigger

Appendix B. Advanced profiling 511 The resulting state engine is shown in Figure B-80.

Figure B-80 State engine after paste of simulated keyboard input action

13.Click the pasted action, Simulates keyboard input, and navigate to the Form Editor frame as shown in Figure B-81 on page 513. Make the following changes: a. Select enter as the key to press. b. Click Advanced Options to expand it. Select Yes in the menu Execute only if autologon is enabled.

512 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure B-81 Form Editor for the action to press the enter key automatically after password injection

Save, test, and finalize the profile The capture and injection flows are now complete. Save the profile and click Test → Start to begin the test scenario for the AccessProfile we just created. The state should be similar to Figure B-82 on page 514.

Appendix B. Advanced profiling 513 Figure B-82 State after both capture and injection flows completed

Note: A best practice is to frequently save your profile, and test it at regular intervals. This scenario does not reflect the frequency of testing that is normally performed when creating an advanced profile. When testing and troubleshooting, refer to the messages menu in AccessStudio, and the aa_observer.log file located in ./logs inside the AccessAgent installation directory for detailed messages.

We have one last task to complete before we can fulfill all of the requirements stated in “Define the requirements” on page 473. We must modify the profile so that it automatically signs off and closes the application when the user logs off the AccessAgent. 1. Create a new state called end_state. 2. Right-click the after_password_actions state and select Add trigger → Advanced → On logoff from AccessAgent.

514 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 3. On the Form Editor (see Figure B-83) select end_state as the next state ID.

Figure B-83 Form Editor for the On logoff from AccessAgent trigger

4. The first thing that needs to happen when a user logs off the AccessAgent is to put the cursor in the correct position to enter in the sign-off keys. Right-click the On logoff from AccessAgent trigger and select Add action → Clicks a window (Win32). 5. In the Form Editor as shown in Figure B-84 on page 516, perform the following tasks: a. In the Signature of the window to click field, paste the exact same Xpath text from the signature in the tab key press trigger we created in step 20 on page 494. b. Enter 70 in the X-Pos (in pixels) field, and enter 420 in the Y-Pos (in pixels) field. These coordinates select the window and place the cursor at the beginning of the command field.

Note: The pixel coordinates for where the window is clicked and cursor is placed are specific to the host emulator. You can find the required coordinates by using third-party tools like Microsoft Spy++ or X-Spy as previously mentioned, or by trial and error using the AccessStudio test functionality.

Appendix B. Advanced profiling 515 Figure B-84 Form Editor for action to click on the window in a specific location

6. Now that we have set an action to automatically select the window and place the cursor in the correct location, we have to enter the keys for application sign-off. As shown in Figure B-85 on page 517, specifying “90” on the command line and pressing Enter will sign off the user.

516 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Figure B-85 Sign off is performed by typing 90 in the command field and pressing enter

7. Right-click the On logoff from AccessAgent trigger and select Add action → Advanced → Simulates keyboard input. 8. In the Form Editor for the Simulate keyboard input action, perform the following tasks: a. In the Signature of window where keys are to be sent field, paste the exact same Xpath text from the signature in the tab key press trigger we created in step 20 on page 494. b. From the Click window first menu, select No. c. Select Key to expand it, and under Add Keys, select Key and click Add. d. This generates the Key drop-down menu. Click it and select 9 from the drop-down menu under Key to press. e. In the Repeat count field, type 1. f. Repeat steps c through e, and select 0 for the Key to press. g. Repeat steps c through e, and select enter for the Key to press. This results in three keys being pressed for this single action, as shown by Keys (3) in Figure B-86 on page 518.

Appendix B. Advanced profiling 517 Figure B-86 Form Editor for simulating three keyboard strokes: 9, 0, and enter

9. After the sign-off occurs, the host emulator returns to the login screen. Now, we can set an action to close this screen. Right-click the On logoff from AccessAgent trigger and select Add action → Advanced → Close a window (Win32). 10.In the Signature of the window to close field, shown in Figure B-87, copy and paste the exact value of the signature generated in step 7 on page 487.

Figure B-87 Form Editor for closing a window

518 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 11.When the host emulator window is asked to close, it prompts the user to confirm as shown in Figure B-88.

Figure B-88 Confirmation window pops up when host emulator is asked to close

12.We want the AccessAgent to take automatic action on the confirmation window. Right-click the On logoff from AccessAgent trigger and select Add action → Clicks a window (Win32) 13.In the Form Editor, click the crosshair button under the field for Signature of window to click.

Appendix B. Advanced profiling 519 14.This opens the signature generator. Click and drag the Finder tool to the Yes button as shown in Figure B-89.

Figure B-89 Click and drag the Finder tool to the Yes button

520 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 15.The signature is generated for the Yes button. Click Ok (Figure B-90).

Figure B-90 The generated signature for the Yes button of the confirmation window

We have now completed the advanced profile for our host emulator. The final state is depicted in Figure B-91 on page 522.

Appendix B. Advanced profiling 521 Figure B-91 The final state

16.To finalize the AccessProfile, you must upload it to the IMS Server to add it to the list of applications and authentication services. Right-click on the AccessProfile we created, and select Upload to IMS.

522 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 C

Appendix C. Statement of work

This appendix provides a sample of what you might include in your statement of work contract.

The environment analysis service statement of work can consist of the sections that we list here.

Executive summary

The service engagement provides a high-level assessment of your customer’s single sign-on and identity management requirements. You provide an initial assessment of the customer’s environment, a demonstration for how to secure the customer’s applications with single sign-on, and the resources that are required to implement the solution.

The assessment is conducted over a period of two weeks. At the end of the assessment period, you present the assessment finding, including: A list of applications to be secured with single sign-on Number of AccessAgents to be deployed Integration points into the customer’s existing environment Recommended enterprise deployment strategy

Solution description

In this service engagement, you interview technical and executive personnel to understand single sign-on and identity management requirements for customer. You evaluate integration requirements on all existing applications that have to be secured in the enterprise. Integration with the customer’s existing directory server and provisioning solution are also investigated.

You provide a demonstration of how Tivoli Access Manager for Enterprise Single Sign-On can be used with the customer’s applications to streamline the sign-on experience of users.

At the conclusion of the service engagement, you deliver a recommended solution and enterprise deployment strategy.

Assumptions

You can use the following possible assumptions in the service engagement: Number of applications to be secured Number of people to interview

524 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Note: Insert here any additional assumption about specific security issues that the customer has.

IBM Business Partner responsibilities

In addition to the solution implementation tasks, you might also be responsible for tasks such as project management, purchasing software and hardware, general consulting, and negotiating financing options with the customer.

Customer responsibilities

The customer has the following responsibilities to the IBM Business Partner: Designating a representative who acts as the focal point for all communication with the IBM Business Partner relative to this project and who has the authority to act on the customer's behalf in matters regarding this project. Designating operations personnel to work with the IBM Business Partner as appropriate. Providing all required Web site content in digital form, as specified by the IBM Business Partner. Providing all product data in a format as requested. Providing all data and information required for implementation. Providing suitable workspace with telephone access for the services specialists while working on customer premises. Providing user IDs, passwords, and IP addresses as required, which enables the IBM Business Partner to perform the service. Providing information to allow estimates on current and future system workload and performance expectations.

Staffing estimates

The project is performed using one Tivoli Access Manager for Enterprise Single Sign-On specialist who is on-site as required by the project schedule. The project is estimated to be completed within two weeks.

Appendix C. Statement of work 525 Project schedule and milestones

Figure C-1 shows a sample project schedule.

Jun 18 2006 Jun 25 2006 Jul 2 2006 ID Task Name Start Finish Duration 19 20 21 22 23 24 25 26 27 28 29 30 1 2 3 4 5

1 Perform customer interviews 6/19/2006 6/21/2006 3d

2 Prepare/execute demo 6/22/2006 6/29/2006 6d

3 Write up recommendation 6/30/2006 7/3/2006 2d

4 Close the engagement 7/4/2006 7/5/2006 2d

Figure C-1 Project schedule

Testing methodology

The testing of the solution is shown by demonstrating the user experience with single sign-on, password resets, and personal, shared, or private desktop login. Solutions that incorporate the IBM Tivoli Identity Manager integration must include a demonstration of how to provision user credentials.

Deliverables

The deliverable of this project can be in the following form: A document that describes the proposed enterprise solution and deployment strategy. A demonstration of Tivoli Access Manager for Enterprise Single Sign-On capabilities relative to the customer’s environment.

Completion criteria

You have to list the completion criteria here. You have to engage with the customer to get a proper sign-off of the project with an appropriate completion criteria, for example, the customer’s acceptance of the findings and recommendations.

You can include specific issues and resolutions explicitly in the completion criteria. You have to be aware of these additional specific completion criteria for your customer.

526 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Related publications

The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this book.

IBM Redbooks

For information about ordering these publications, see “How to get Redbooks” on page 529. Note that some documents referenced here might be available in softcopy only. Enterprise Security Architecture Using IBM Tivoli Security Solutions, SG24-6014 Identity Management Design Guide with IBM Tivoli Identity Manager, SG24-6996 Enterprise Business Portals with IBM Tivoli Access Manager, SG24-6556 Enterprise Business Portals II with IBM Tivoli Access Manager, SG24-6885 Deployment Guide Series: IBM Tivoli Identity Manager 5.0, SG24-6477

Other publications

These publications are also relevant as further information sources: IBM Tivoli Access Manager for Enterprise Single Sign-on Deployment Guide Version 8.0, SC23-9952 IBM Tivoli Access Manager for Enterprise Single Sign-On Administrator Guide Version 8.0, SC23-9951 IBM Tivoli Access Manager for Enterprise Single Sign-On User Guide Version 8.0, SC23-9950 IBM Tivoli Access Manager for Enterprise Single Sign-On AccessAgent Release Notes Version 8.0, GI11-8739 IBM Tivoli Access Manager for Enterprise Single Sign-On AccessStudio Guide Version 8.0, SC23-9956 IBM Tivoli Access Manager for Enterprise Single Sign-On AccessStudio Release Notes Version 8.0, GI11-8740

These Web sites are also relevant as further information sources: The National Institute of Standards and Technology (NIST) Computer Security Division: http://csrc.nist.gov/ The NIST Computer Security Division is one of eight divisions within the NIST Information Technology Laboratory. The mission of the NIST Computer Security Division is to improve information systems security by: – Raising awareness of IT risks, vulnerabilities, and protection requirements, particularly for new and emerging technologies – Researching, studying, and advising agencies of IT vulnerabilities and devising techniques for the cost-effective security and privacy of sensitive Federal systems – Developing standards, metrics, tests, and validation programs to: • Promote, measure, and validate security in systems and services • Educate consumers • Establish minimum security requirements for Federal systems – Developing guidance to increase secure IT planning, implementation, management, and operation IBM Tivoli Access Manager for Enterprise Single Sign-On Support Web site: http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliAccess ManagerforEnterpriseSingleSignOn.html?S_CMP=rnav The IBM Tivoli Access Manager for Enterprise Single Sign On Wiki provides best practices, education materials, example AccessProfiles, and other documents to enable and support Business Partners, practitioners, and customers with developing AccessProfiles, deploying the product, and learning about the many capabilities of this solution. Subscribe to RSS feeds for the Wiki: http://www.ibm.com/developerworks/wikis/display/tivoliaccessmanagerf oresso/Home IBM Open Process Automation Library (OPAL) OPAL is an online ecosystem for sharing Tivoli integrations and solutions developed by IBM and IBM Business Partners (ISVs). It is a comprehensive catalog containing hundreds of predefined integration modules such as automation packages, adapters, agents, integration documentation.

528 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 ISVs who list their product integrations in OPAL, use OPAL as a go-to-market tool to generate leads and increase their global visibility because customers using OPAL are looking for integrations to enhance the capabilities of their new or existing management applications. IBM technical sales team uses OPALs integrations to support customer requirements and proposals. The base OPAL Web site link is: http://www.ibm.com/software/brandcatalog/portal/opal The following link takes you directly to the Tivoli Access Manager for Enterprise Single Sign-On page in OPAL: http://www.ibm.com/software/brandcatalog/portal/opal/results?catalog .catalogName=Tivoli+OPAL&catalog.searchTerms=&catalog.c=Software_IBM _TivoliAccessManagerForEnterpriseSingleSignOn&catalog.start=0

How to get Redbooks

You can search for, view, or download Redbooks, Redpapers, Technotes, draft publications and Additional materials, as well as order hardcopy Redbooks, at this Web site: ibm.com/redbooks

Help from IBM

IBM Support and downloads ibm.com/support

IBM Global Services ibm.com/services

Related publications 529 530 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Index

creating of 37, 453 A host emulator 472 access control Lotus Notes 145 customization 29 machine Wallet 434 Access Manager shared desktop 30 Policy Server 85 storage 48 Access Manager for e-business 84 Web application 155 AccessAdmin 9, 32, 35 Winlogon 439 configuration for shared desktop 221 AccessStudio 37, 102–103 password self-service challenge-response ques- installation 144 tions 187 logging 448 troubleshooting 448 Wizard 455 AccessAgent 8, 12, 46, 102–103 account architecture 14 lockout 80 cached Wallet troubleshooting 440 Active Directory cryptobox 42, 434 lookup user 105 DLL version conflict 439 Provisioning Agent 40 installation 135 active proximity badge 18 interacting with 139 ActiveCode 18, 34 local user session management 30 administration log files 434 of deployment 180 log level 434 Administrative Console machine policy 412 installation 126 observer agent 24 administrative requirements 94 observer module 23 administrative user Plug-In 28 create 105 secure storage 42 administrator server mode 32 logging 182 SOAP API 48 advanced profiling 180, 453 synchronization 104 host emulator 472 troubleshooting state engine design 483 automatic sign-on 438 all_sync_data.xml 435 domain name 437 application profile 323 Internet Explorer 437 application template machine Wallet 439 host/mainframe 180 upgrade 447 Rumba 180 unable to connect to IMS Server 440 audit 8 USB proximity key reader 19 Identity Manager credentials 40 Wallet 103 log 96 AccessAssistant 40 logical components AccessProfile 13, 24, 103 auditing 34 central administration 32 management 32 command line application 463 security 41, 43 configuration 144 authentication 16

© Copyright IBM Corp. 2007, 2009. All rights reserved. 531 active proximity badge 18 base components 105 ActiveCode 18, 34 base environment 101 central administration 32 IMS database 120 customization 29 IMS Server 131 device manager 16, 22 ITIM Service 353 factor 12, 16, 44 machine policy 412 fingerprint identification 19 self-service registration policy 407 RFID card 18 service prerequisites 353 security 41 strong authentication 391 service, configuration 144 TAM E-SSO Service 266, 339 USB key 19 workflow extensions 283 USB proximity key 19 connector installation 245 using USB keys 391 corporate security policy 9 authorization code 17 credential 85 for password reset 205 distribution 34, 38 authorization service process 7 Identity Manager self-service console 323 request 27 automatic sign-on performance 449 security 41 transfer security 27 cryptobox 42, 434 B cryptography 6 backup password 17 custom workflow 284 base environment customer engagement 59 configuration 101 behavioral state 25 brute force 5 D business data context 3 expected volume 49 requirements 92 secure processing 41 Identity Manager scenario 230 synchronization 22 shared desktop 218 database 35 scenario 73 administrator 105 backup 182 installation 106 C DB2 certificate management 32 installation 106 challenge-response questions 187 object security 116 Citrix MetaFrame Presentation Server 12, 31 demonstration system 65 client-side components 103 deployment common symmetric key 19, 393 architecture 103 communication architectures 54 security 42–43 considerations 6, 8 company profile 74 managing 180 compliance requirements 94 deprovisioning credentials 39 scenario 51 component architecture 13 stages 97 physical 46 design considerations 102 configuration desktop single sign-on 4 AccessProfile 144 development stage 97 authentication service 144

532 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 directory 102 identity management 33 directory integration 6, 53 integration 7 Directory Integrator 53 Identity Manager TAM E-SSO connector 245 application profile 323 Directory Server credential distribution 34, 38 organization directory 50 custom workflow 284 integration 52, 99 scenario 229 E software prerequisites 233 encryption ITIM Service configuration 353 common symmetric key 19 password updates 40 engagement overview 63 provisioning enrollment of USB key 421 test 323 enterprise authentication services 144 self-service console authorization service 323 executive assessment 64 service prerequisites 353 expected data volume 49 TAM E-SSO Service configuration 266, 339 workflow F configuration 289, 297, 303, 307, 317 fast user switching 30 extension 52, 283 federated single sign-on 4 identity wallet finder tool 456 See Wallet fingerprint identification 19 implementation functional requirements 93 phases 89 skills 60 G IMS GINA 13 auditing 34 Graphical Identification and Authentication authentication 34 See GINA Bridge configuration 255 Configuration Utility troubleshooting 442 H connector 32 help desk database 35, 48, 102, 104 cost 6 creation 120 help resources 61 housekeeping problems 443 HLLAPI 27, 180 identity management 33 host application policy 34 observer agent 27 provisioning bridge 32 host/mainframe Server 13, 32, 102, 104 application template 180 adapter configuration 254 SSL 259 I application certificate 442 IBM DB2 certificate download 440 See DB2 configuration 131 IBM Tivoli Directory Integrator console mode 443 See Directory Integrator deployment architectures 54 IBM Tivoli Directory Server diagnostics 443 See Directory Server installation 126 IBM Tivoli Identity Manager troubleshooting 445 See Identity Manager logging 442

Index 533 physical components 47 IMS Server 32 policy synchronization 22 provisioning bridge 38 secure storage 42 self-service GUI 23 synchronization troubleshooting 436 session management 30 system policy 434 Wallet Manager GUI 23 time synchronization 129 logon troubleshooting 442 Mainframe/Host application 27 unable to connect to AccessAgent 440 user interface 436 SOAP API 32 Web application 28 initialization of USB key 419 Windows application 26 installation logon user interface AccessAgent 135 troubleshooting 436 AccessStudio 144 lookup user 105, 131 Administrative Console 126 password 106 base components 105 loss management 32 database 106 Lotus Notes IMS Server 126 AccessProfile 145 troubleshooting 444 M J machine policy 412 Java template 221 Observer module 135 machine template 221 Java application machine Wallet 434 observer agent 28 troubleshooting 435 Mainframe/Host application logon 27 K Microsoft Spy++ 458 keyboard-sniffing 27 Microsoft Visual Basic Script 453 keystore Microsoft Windows Server Terminal Services 12, IMS Server 259 31 Mobile ActiveCode 18 L mobile employees requirements 95 LDAP replica server 85 local user session management 30 log table pruning 443 N network diagram 81 logging 182 Network Time Protocol 129 AccessAgent 434 non-functional requirements 96 shared desktop 219 logical component architecture 13 logical components O AccessAdmin 35 observer agent AccessAgent 14 for host applications 27 AccessAgent Observer module 23 for Java applications 28 AccessStudio 37 for Web applications 28 authentication 16, 34 for Windows applications 26 data synchronization 22 operational security 41 identity management 33 organization directory 49 IMS database 35 overview diagram 12

534 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 P R password 17 RADIUS API 48 ActiveCode mechanism 34 Redbooks Web site 529 backup 17 Contact us xiv management requirements 93 reporting 8 policy 44 repository 102 reset 17, 80 requirements authorization code 205 administration 94 functionality 6 deployment 94 scenario 201 for base installation 103 security 6 mobile employees 95 self-service 185 password management 93 challenge-response questions 187 security policy 93 synchronization 50, 131, 230 resources updates by Identity Manager 40 support and help 61 performance 6 reverse proxy 85 personal authentication services 145 revocation personnel management 79 of a user 181 physical components 46 RFID AccessAgent 46 card 18 IMS database 48 troubleshooting 446, 449 IMS Server 47 RMI Dispatcher organization directory 49 update 241 pid_wallet_sync_mins 436 roaming desktop 30 pilot stage 98 planning for customer engagement 59 policy S scenario 51, 74 management 180 account management 86 password 44 business requirements 92 requirements 93 current IT environment 80 self-service registration 407 customer sample deployment 73 storage 48, 102 deployment architecture 103 synchronization 104 design objectives 96 post-logon 25 e-business initiative 84 pre-logon 25 emerging issues 87 private desktop 30 functional requirements 93 security 30, 44 Identity Manager integration 229 Problem Management Record implementation phases 89 creation of a 451 objectives 88 production deployment 98 password reset 201 profiling solution design 91 of applications 453 second authentication factors 18 provisioning secret 17 credential distribution 34, 38 secure storage 41 test 323 security 27 Provisioning Agent 40 AccessAgent 42 provisioning bridge 7, 32, 38, 52 audit 43 Java API 34 authentication factors 44 proximity badge 18

Index 535 communication 43 support deprovisioning credentials 39 resources 61 design objectives 96 sync.exe IMS Server 42 program termination troubleshooting 441 policy 9 synchronization requirements 93 of time 129 private desktop 44 system requirements 41 logging 182 Wallet 42, 44 system policy 434 security log system requirements 103 troubleshooting 450 system security requirements 41 self-service challenge-response questions 187 password 185 T TAM E-SSO Service configuration 266, 339 registration policy 407 target application 104 user interface 23 tasks 67 server-side components 104 termination of inactive sessions 8 service engagement test stage 98 overview 63 testing planning 59 create Identity Manager user 364 session management 30 provisioning operations 323 for local user 30 single sign-on to the Identity Manager Self-Ser- SetupHlp.ini 135 vice 384 shared desktop 30, 219 trigger 454 AccessAdmin configuration 221 troubleshooting business requirements 218 AccessAdmin 448 logging 219 AccessAgent 434 machine policy template 221 automatic sign-on 438 user id 219 cached Wallet 440 Windows configuration 220 DLL version conflict 439 shared workstation 30 domain name 437 signature 454 Internet Explorer 437 single sign-on paradigm 4 machine Wallet 439 skills 60 upgrade 447 SOAP API 32, 48 application certificate 442 solution automatic sign-on performance 449 design 91 IMS Configuration Utility 442 overview 62 IMS database 443 tasks 67 IMS Server 442 SSL certificate download 440 RMI Dispatcher 259 console mode 443 state editing 455 IMS Server synchronization 436 state engine installation 444 design 483 logon user interface 436 trigger 25 machine Wallet 435 state machine 25 Problem Management Record 451 statement of work 63, 65–66, 523 RFID 446, 449 strong authentication 92, 95, 391 security log 450 strong password 44

536 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 sync.exe termination 441 Windows Winlogon AccessProfile 439 application logon 26 two-factor authentication 92, 95, 99 Graphical Identification and Authentication See GINA observer agent 26 U Terminal Services 12, 31 USB key 19 Winlogon AccessProfile 439 authentication 391 workflow enrollment process 421 action 26 initialization 400, 419 automation 29, 37 overview 392 configure Change Password Operation 297 software configuration 394 configure Delete Account Operation 303 USB proximity key 19 configure Service Add Account 289 user custom action 28 account provisioning 230 disable Change Password Operation 317 central administration 32 extension 52 credentials 13 configuration 283 data storage 102 modification for TAM E-SSO account 307 logging 182 trigger 25 management 86, 181 repository 102 revocation 181 X User Interface Failure 436 XPath 453 @xpos 457 example 454 V X-Spy 458 Visual Basic Script (VBScript) 453 Z W zero touch provisioning 283 Wallet 7, 13, 103 AccessAssistant self-service interface 40 cryptobox 434 data synchronization 22 Manager GUI 23 protection 44 provisioning 230 recovery 43 revocation 181 secret 17 security 42 troubleshooting 439–440 USB key 19 Web application AccessProfile 155 logon 28 observer agent 28 Web single sign-on 4 Web Workplace 41 WebSEAL 85

Index 537 538 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0

(1.0” spine) 0.875”<->1.498” 460 <-> 788 pages

Back cover ® Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0 ®

Learn how to install Everyone feels the pain of too many passwords to remember, INTERNATIONAL and configure the and everyone can relate to the security exposure of weak major components passwords, chosen for convenience or passwords placed in TECHNICAL proximity to the workstation for a quick reminder that, SUPPORT Plan an enterprise unfortunately, can allow more than the intended user into the ORGANIZATION single sign-on system and network. The average user today often has four or more passwords, and security policies that focus on deployment project password complexity and password-change frequency can cause even more difficulty for users. BUILDING TECHNICAL Read about best INFORMATION BASED ON practices and This IBM Redbooks publication introduces IBM Tivoli Access PRACTICAL EXPERIENCE troubleshooting Manager for Enterprise Single Sign-On 8.0, which provides single sign-on to many applications, without a lengthy and complex implementation effort. Whether you are deploying IBM Redbooks are developed by the IBM International Technical strong authentication, implementing an enterprise-wide Support Organization. Experts identity management initiative, or simply focusing on the from IBM, Customers and sign-on challenges of a specific group of users, this solution Partners from around the world can deliver the efficiencies and security that come with a create timely technical well-crafted and comprehensive single sign-on solution. information based on realistic scenarios. Specific This book is a valuable resource for security officers, recommendations are provided administrators, and architects who want to understand and to help you implement IT implement an identity management solution in a medium solutions more effectively in your environment. scale environment.

For more information: ibm.com/redbooks

SG24-7350-01 ISBN 0738432954