IBM Security Access Manager Appliance Migration Guide:

Transcription

1 IBM Security Systems Access Management May, 2015 IBM Security Access Manager Appliance Migration Guide: Migration Guide for software to appliance Authors Chris Hockings James Darwin Jenny Wong Nick Lloyd Trevor Norvill Special Thanks to Martin Schmidt and Scott Exton Version P age

2 2 P age

3 Note: Before using this information and the product it supports, read the information in "Notices." Edition notice This edition applies to version 8 of IBM Security Access Manager (product number C87) and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright International Business Machines Corporation 2014, Note to U.S. Government Users Restricted Rights - - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. 3 P age

4 4 P age

5 Contents Preface About this document Introduction IBM Security Access Manager appliance Strategy IBM Security Access Manager Components and Capabilities Traditional Deployment Architecture Traditional IBM Security Access Manager Components and Functions The pdadmin tool Authorization Server Appliance Component Configurations Discontinued functions Policy Proxy Server Session Management Server (SMS) Common Auditing and Reporting Service (CARS) Web Security ADK New Capabilities on the Appliance Web application firewall Front- end load balancer Distributed Session Cache User Registry Federated Registries RESTful APIs Local Management Interface Backups Clustering Policy Server High Availability Deployment Pattern P age

6 5.1 Enterprise Deployment Simplified Deployment Appliance TCP/IP Port configurations Planning the migration Important aspects and considerations of migration Supported Migration Paths Migration from IBM Security Access Manager Software to Appliance Migration from 6.0.x, 6.1.x or 7.0 to Appliance Migrating User Registry Updating Security Access Manager Certifications Migrating the policy server software to the appliance Authorization server Migrating WebSEAL Summary...51 Notices P age

7 Table of Contents for Figures and Tables Figure 1 - Traditional IBM Security Access Manager Deployment...14 Figure 2 - Appliance Component Configurations...16 Figure 3 Simplified Deployment...22 Figure 7 Supported IBM Security Access Manager Migration paths...26 Table 1 Access Manager Product Support Overview...13 Table 2 Default ports used for IBM Security Access Manager...22 Table 3 Understand Migration Business Requirements...23 Table 4 Understand Existing Installation and Configuration...24 Table 5 Understand TAM specific features in place...25 Table 6 - Understanding and defining the roles and responsibilities...25 Table 7 Understand support and maintenance process P age

8 8 P age

9 Preface This section provides: Links to Online publications. A link to the IBM Terminology website. The statement of good security practices Access to online publications IBM posts product publications when the product is released and when the publications are updated at the following locations: IBM Security Systems Documentation Central provides an alphabetical list of all IBM Security Systems product libraries and links to the online documentation for specific versions of each product. IBM Knowledge Center ( 01.ibm.com/support/knowledgecenter/) offers customized search functions to help you find all the IBM publications you need. IBM Terminology website The IBM Terminology website consolidates terminology for product libraries in one location. You can access the Terminology website at Statement of Good Security Practices IT system security involves protecting systems and information through prevention, detection and response to improper access from within and outside your enterprise. Improper access can result in information being altered, destroyed, misappropriated or misused or can result in damage to or misuse of your systems, including for use in attacks on others. No IT system or product should be considered completely secure and no single product, service or security measure can be completely effective in preventing improper use or access. IBM systems, products and services are designed to be part of a comprehensive security approach, which will necessarily involve additional operational procedures, and may require other systems, products or services to be most effective. IBM DOES NOT WARRANT THAT ANY SYSTEMS, PRODUCTS OR SERVICES ARE IMMUNE FROM, OR WILL MAKE YOUR ENTERPRISE IMMUNE FROM, THE MALICIOUS OR ILLEGAL CONDUCT OF ANY PARTY. 9 P age

10 1 About this document In this document, it outlines the high- level strategy and actions required to perform a migration from an existing software IBM Security Access Manager deployment to an IBM Security Access Manager 8 Appliance deployment. 10 P age

11 2 Introduction The IBM Security Access Manager product was called Intraverse, Policy Directory, and Tivoli Access Manager in previous releases. In IBM Security Access Manager, Version 8.0, there is no software deployment. The delivery model across the IBM Security Access Manager portfolio, including Security Policy Manager and Federated Identity Manager, is appliance- only solutions. All customers with Tivoli Access Manager and/or IBM Security Access Manager WebSEAL, Version 7.0, must migrate from software to appliances when they use later versions. Note: Customers who deployed IBM Federated Identity Manager Risk Based Access, One Time Password, or OAuth must also consider a migration. This document, however, does not address migrating Federated Identity Manager components. This document provides the information for planning a migration. 11 P age

12 3 IBM Security Access Manager appliance Strategy IBM Security Access Manager is a world- class solution that Helps IT enterprises secure web access to applications. Protects those applications from threats. Reduces the costs and complexity of web application management. Formerly known as IBM Tivoli Access Manager for e- business, the solution was released as software offering over a decade ago. In 2012, IBM Security Access Manager, Version 7.0, was a hybrid release with software maintained and feature enhanced with typical release patterns. Version 7.0 also released the first IBM Security Access Manager appliance solution, IBM Security Access Manager for Web, which was also known as the Web Gateway Appliance Version 7. IBM Security Access Manager for Web An integrated appliance that offers a single solution to provide web access security protection. The Web appliance: Provides web reverse proxy security solution. Provides centralized user access management to deliver highly scalable user authentication, authorization, and audit services to web applications. Defends applications and data against targeted web attacks and vulnerabilities. IBM Security Access Manager for Mobile Added in October 2013, this integrated appliance provides mobile access security protection that addresses mobile security challenges. It proactively enforces access policies for web environments and mobile collaboration channels. Major features include: Policy- based multi- factor authentication Risk- and context- based access using built- in mobile device fingerprinting, geo- location and IP Reputation Mobile application access administration Self- service and integration with IBM WorkLight IBM Security Access Manager, Version 8.0, also enhanced the IBM Security Access Manager for Web offering. Version 8.0 has no software components, except API client supported components. 12 P age

13 Table 1 provides a summary of the current support status for the IBM Security Access Manager: Product Category Product Model Modular Offering/License End of Support Software Virtual Hardware Web Mobile(*) Offering Appliance Appliance Tivoli Access Manager for e- business, Version 6.0.x Yes Yes 30- April Tivoli Access Manager for e- business, Version 6.1.x Yes Yes [*] IBM Security Access Manager for Web (Web Gateway Appliance), Version 7.0 Yes Yes Yes Yes [*] IBM Security Access Manager, Version 8.0 Yes Yes Yes(**) Yes(***) [*] Table 1 Access Manager Product Support Overview (*) IBM Security Access Manager for Mobile, Version 8.0, includes some functions from IBM Tivoli Federated Identity Manager, Version x. [*] Until IBM officially provides an End Of support date, the general support model applies; general support is for a 5- year period plus an additional 3 years for maintenance. (**) Web license provides WebSEAL with Web application firewall capability. (***) Mobile license provide WebSEAL without Web application firewall capability. As shown in Table 1, IBM Security Access Manager moved from software releases to appliance offerings. The IBM Security Access Manager appliance can be either a hardware appliance or a virtual appliance. Both are designed to be highly scalable and configurable and provide deployment flexibility for production and non- production environments. For particular specifications for either the hardware or virtual appliance, see the IBM Knowledge Center: IBM Security Access Manager for Web: 01.ibm.com/support/knowledgecenter/SSPREK/welcome IBM Security Access Manager for Mobile: 13 P age

14 4 IBM Security Access Manager Components and Capabilities This chapter outlines the traditional software deployment architecture and common components in a Tivoli Access Manager environment. It introduces new capabilities in the appliance and discusses what was discontinued. 4.1 Traditional Deployment Architecture The standard deployment for the IBM Security Access Manager for Web before the appliance consisted of several software components that were deployed on several different computers. These computers were located over a number of security zones to provide the traditional 3- tiered model that provided depth in defense. Figure 1 - Traditional IBM Security Access Manager Deployment shows a typical deployment. Figure 1 - Traditional IBM Security Access Manager Deployment A typical IBM Security Access Manager for Web appliance deployment is similar; however each deployment is now an appliance with different, configured components. Before looking at the new Appliance based deployment patterns, it is important to understand the various components that existed in software and what they are in the appliance. 14 Page

15 4.2 Traditional IBM Security Access Manager Components and Functions The following components are in the appliance, but they are enhanced: Reverse Proxy / WebSEAL Authorization Server Policy Server Global Security Kit (GSKit), managed through the local management interface You can also download the following items as software through IBM Fix Central: Runtime for Java Application Development Kit The pdadmin tool The pdadmin command line tool is part of the IBM Security Access Manager run time. In the appliance, access to the command- line interface (CLI) is through a ssh session or the appliance console. The pdadmin tool is part of the run time software installation, which means you can configure IBM Security Access Manager, Version 7.0, software run time against a policy server of the same version Authorization Server The IBM Security Access Manager authorization server is used for remote authorization decisions from calling components. These calling components might be Java Authorization API enabled applications running on software or other policy enforcement solutions. In cases that require the authorization server capability, you can configure an appliance to take on that capability as either stand- alone or co- located with other components. 4.3 Appliance Component Configurations Figure 2 shows the IBM Security Access Manager for Web appliance configured with all available components. The components are abbreviated as follows: RP Reverse Proxy (WebSEAL) with web application firewall (PAM module) capabilities LB Front- end Load Balancer PS Policy Server AZ Authorization Server SC Distributed Session Cache LMI Local Management Interface 15 P age

16 Figure 2 - Appliance Component Configurations This diagram format and the abbreviations are used in subsequent sections to show how you can distribute the components in an environment to support different business needs. 4.4 Discontinued functions This section describes functions that were replaced or discontinued Policy Proxy Server This component is no longer available in an appliance deployment Session Management Server (SMS) The Distributed Session Cache (DSC) now replaces the Session Management Service (SMS) as a service that provides an optionally deployed centralized service for management of user sessions. The Session Management Service web interface is delivered through the local management interface web console. The dscadmin command line tool replaced the Session Management Service command- line interface. The dscadmin tool is integrated with the appliance. You can use it to perform user session administrative operations on the distributed session cache Common Auditing and Reporting Service (CARS) The Common Auditing and Reporting Service is not supportedin the appliance. You can use the remote syslog encrypted with Transport Layer Security (TLS) to centralize and store IBM Security Access Manager logs. QRadar or another syslog consumer can read and process these logs Web Security ADK The Security Access Manager Web Security ADK contained development APIs for the Tivoli Access Manager cross- domain authentication service, the Tivoli Access Manager cross- domain mapping framework, and the Tivoli Access Manager password 16 P age

17 strength module. These types of pluggable modules are no longer supported by the IBM Security Access Manager for Web appliance. The appliance does not deploy in- line programs into the running appliance. 4.5 New Capabilities on the Appliance The appliance can deliver additional components, which includes web application protection and a front- end load balancer Web application firewall This component protects web servers from malicious traffic and blocks attempts to compromise the system through continuous web application protection. It is powered by X- Force research and development. It provides protection from web- based threats, including the top 10 web application risks identified by the Open Web Application Security Project (OWASP) Front-end load balancer The appliance provides a Layer 7 front- end load balancer. This component: Optimizes resource usage and ensures high availability of services. Accepts requests from clients and determines which backend server is the most suitable to handle the request. Forwards each request to the appropriate server. Provides persistence for existing sessions Distributed Session Cache This component is an optional service that acts as a centralized session repository for a clustered IBM Security Access Manager WebSEAL server environment. It replaces the IBM Security Access Manager session management server in IBM Tivoli Access Manager, Version 6.0.0, through IBM Security Access Manager for Web, Version 7.0. The Distributed Session Cache service is there by default, but it is not enabled. As with the session management server, there are only a few very specific requirements for this component. There is a significant performance implication to consider, so do not configure it unless it is absolutely necessary. See the online product documentation for more details. When performing a migration, consider the following aspects: User sessions are not retained across the upgrade. A parallel system migration, where a separate IBM Security Access Manager, Version 8.0, system runs in parallel with the production system, minimizes the down time. You can do detailed system testing of the new solution before going live. Do not perform in place upgrades to minimize downtime during migration. The Version 8.0 Distributed Session Cache is compatible with Version 7.0, servers. Tivoli Access Manager, Version 6.0 and later, is not supported with the Distributed Session Cache. The Distributed Session Cache requires significantly less hardware to deploy a highly available solution. To ensure a successful migration from a session management server enabled environment to Distributed Session Cache, allocate enough resources for the process. 17 P age

18 To better understand the migration from session management server to distributed session cache, see the IBM Security Access Manager, Version 8.0 Distributed Session Cache Architectural Overview and Migration Guide: ntity%20manager/page/isam%20sms%20to%20dsc%20migration User Registry The IBM Security Access Manager appliance is packaged with an internal OpenLDAP Directory Server. It is not an enterprise directory, limit its use to proof of concepts and testing environments. This user registry cannot be accessed external to the applinace; therefore, it cannot be used as a registry for other applications. For an external user registry, the appliance supports the following registries: IBM Security Directory Server IBM Tivoli Directory Server for z/os Microsoft AD LDS (Lightweight Directory Services) Microsoft Active Directory Novell edirectory Oracle Directory Server 11g Enterprise Edition Federated Registries This new feature allows users to authenticate against multiple User Registries within a single ISAM policy domain. The Policy Server must firstly be configured against the either the local Open LDAP Directory, or an external supported LDAP Server as the Primary LDAP Registry. In this setup ISAM meta- data is now stored in the Primary LDAP Registry, meaning that no schema changes are necessary on any of the configured Federated User Registries. Note: Microsoft Active Directory is only supported as a Federated User Registry RESTful APIs A RESTful Web Service API can manage the appliance with external tools. The API provides most of the functionality through the local management interface. Select Web Services, shown in the preceding illustration, to display the following menu of available services. 18 P age

19 See the following IBM developerworks article for further information: Use the REST API to control the IBM Security Web Gateway AMP Local Management Interface Local management interface documentation on the Help menu in the console Backups Back up the appliance frequently to avoid loss of data. To back up the appliance, use the snapshot facility provided by the appliance. A snapshot is a copy of the state of the appliance at a point in time. Take snapshots regularly and download them from the appliance to serve as backups. By using snapshot files, you can restore the appliance to a previous known state. Note: Snapshots can consume disk space; you must manage the disk space. 19 P age

20 4.5.9 Clustering The appliance includes cluster support so that multiple appliances can share configuration and runtime information. The appliance (including IBM Security Access Manager for Mobile) provides the following cluster services: Distributed session cache Configuration database Geolocation database Runtime database IBM Security Access Manager run time SSL keyfiles When data replication occurs, data is replicated from the primary master to all cluster nodes. The function is automatic and managed by the appliance cluster functionality Policy Server High Availability When the IBM Security Access Manager policy server becomes unavailable, administrative functions are lost. This loss includes, for example, updating Access Control Lists (ACLs) or modifying WebSEAL junctions. This situation is also the case for the appliance. Only one (master) policy service is active at one time. What has changed is the ability to configure the appliance to replicate the runtime environment to all nodes in the cluster. This ability effectively means that you can set up all appliances in a cluster as hot stand- by policy servers. Each appliance can have an up- to- date version of the runtime configuration along with the policy database. The master policy server always runs on the appliance that is acting as the primary master for the cluster. If the primary master becomes unavailable, you can manually promote a policy server replicate. All appliances in the cluster are automatically updated with the address information of the new primary master without restarting the configured services in the cluster. 20 P age

21 5 Deployment Pattern 5.1 Enterprise Deployment Figure 3 - Enterprise Deployment This diagram describes the ISAM Appliance enterprise deployment pattern. The ISAM 4 Web Appliance(s) containing the Reverse Proxy (RP) hosted in a Demilitarized Zone (DMZ) is functioning as the Policy Enforcement Point (PEP). The ISAM 4 Mobile Appliance(s) is functioning as the Policy Decision Point (PDP), and the ISAM 4 Web Appliance(s) containing the Policy Server is functioning as the Policy Administration Point (PAP). 5.2 Simplified Deployment With the new appliance clustering support, the ISAM Appliance deployment model can be greatly simplified, though note this introduces significant security risk as the PEP, PDP and PAP are hosted in the DMZ. This pattern may be applicable where this security risk can be accepted or mitigated through other means. 21 P age

22 Figure 4 Simplified Deployment 5.3 Appliance TCP/IP Port configurations IBM Security Access Manager for Web Appliances utilizes a set of TCP and IP port configurations. Table 2 lists the default port numbers that you might need to know when configuring components on the appliance. Component IBM Security Access Manager policy server Cluster configuration Local management interface LDAP server, non- SSL port LDAP server, SSL port WebSEAL HTTP WebSEAL HTTPs WebSEAL listening port (IBM Security Access Manager internal) Port Table 2 Default ports used for IBM Security Access Manager 22 P age

23 6 Planning the migration Several factors influence the decision to perform a migration or not. These factors include business decisions and technical assessments in a constantly changing and challenging IT environment. Consult this document during the early stages of migration. When planning a migration to the latest appliance, there can be multiple phases due to organizational, infrastructure, or business demands. Therefore, it might be helpful to revisit these guidelines several times throughout the deployment. 6.1 Important aspects and considerations of migration The migration process from a software deployment to an appliance deployment requires consideration of the interdependencies among the various IBM Security Access Manager components and other software components in the system. Before carrying out the migration, it is important to assess the existing operational environment and to identify pre- migration activities or considerations required for preparing the environment. It is also important to understand the major architectural and configuration differences, including any deprecated functions when moving to the appliance- based IBM Security Access Manager offerings. The following tables include a set of customer questions that identify some of the high level aspects of the project: Business Requirements Completed? What is motivating the business to make this change? What is the target version of IBM Security Access Manager? What other IBM Security products are involved in this migration? What is the risk to the business if the change cannot be implemented by your target date? By what date must this migration be complete? What is the risk to the business when the environment is not running? What is the risk to the business when the back- end application is not running? Is this migration part of a new release/version? Describe any important milestones for the migration. Include dates for development, QA, and so on. How do you describe a successful migration? Table 3 Understand Migration Business Requirements 23 P age

24 General Information Installation and Configuration Completed? Number of users supported in this environment? What version of Security Access Manager is deployed? What user registry is used? What version? Are the current users in a single repository or multiple? Do testing, pre- production, or production environments exist? Any others? What is the operating system of all the environments? What back- end applications are protected by Security Access Manager? Is the application business critical? How many Security Access Manager WebSEAL instances are there? What domains is Security Access Manager deployed for? Intranet? Extranet? Internet? Are there any outstanding issues with the current environment? List these or provide PMR numbers if relevant. Are there any load balancers in place? How many data centers are deployed? Any other IBM products aside from Security Access Manager used? Do you need to be migrate them? What components of these other IBM products have been installed? What components of these other IBM products have not been used? Has any network specification information been documented, or you can provide it? What license do you hold? Is there End of Support agreement in place or under discussion? Table 4 Understand Existing Installation and Configuration Security Access Manager Specific Features Answer What components of Security Access Manager have been installed? What components of Security Access Manager have not been used? What Security Access Manager features are used? What Security Access Manager features are not used? 24 P age

25 Security Access Manager Specific Features Answer Have you reviewed the deprecated features in the appliance? Have you identify plans to manage any deprecated features Are you using Session Management Service? Are you using the Security Access Manager WebSEAL Cross- domain Authentication Service? Are you using a Security Access Manager External Authentication Interface authentication mechanism? Are you using any Security Access Manager integration points? Adapters? Tivoli Directory Integrator? What logging requirements are in place? What auditing requirements are in place? Table 5 Understand TAM specific features in place Project Specifics - Understanding and defining the roles and responsibilities during migration etc Answer What is the project timeframe? Who is the project manager? What resources are available for the migration process? What is the strategy for future support? Future maintenance? Is IBM Services engaged? Does any level of premium support exist? What is the skill level of the operations team? Table 6 - Understanding and defining the roles and responsibilities Support and Maintenance Answer What support agreement is in place? 25 P age

26 Support and Maintenance Answer Is any premium support in place? Table 7 Understand support and maintenance process Each customer environment is different. Use these tables as they apply to your environment. 6.2 Supported Migration Paths Before migration, you must understand the supported migration paths for an IBM Security Access Manager deployment. Figure 5 illustrates migration paths for all currently supported IBM Security Access Manager Offerings: IBM Security Access Manager for Web 6.x.x/7.0 Upgrade to ISAM Version 8.0 supported Directory Server Upgrade to ISAM Version 8.0 Appliance Completed upgraded to ISAM Version 8.0 Appliance Figure 5 Supported IBM Security Access Manager Migration paths As shown in Figure [5], the supported upgrade paths from Version 6.0.x, Version 6.1.x and Version 7.0 can be directly upgraded to Version 8.0. This pattern follows the upgrade process for standard software to appliance technology, as documented in section Migration from IBM Security Access Manager Software to Appliance When migrating an IBM Security Access Manager environment, consider the interdependencies between the IBM Security Access Manager components and any other software using client APIs. The order in which the migration occurs is critical to the overall success. This section provides details on how to migrate an IBM Security Access Manager environment to a Version 8.0 appliance. It is based on the migration paths identified in section Migration from 6.0.x, 6.1.x or 7.0 to Appliance 8.0 You can directly upgrade Versions 6.0.x, 6.1.x, or 7.0 to Version 8.0. Migration from IBM Security Access Manager Version 6.0.x to 7.0 requires the following steps: 1. Migrate the user registry directory supported by Version Page

27 2. Update certificates to ensure that it is signed for a supported protocol on the appliance. 3. Migrate the policy server to the Version 8.0 appliance. 4. Configure the IBM Security Access Manager authorization server (if applicable). 5. Migrate Access Manager WebSEAL servers. 6. Configure the Distributed Session Cache if you previously used the Session Management Service. The following sections discuss each of these steps in detail Migrating User Registry Before any IBM Security Access Manager base component upgrade, ensure your user registry directory is supported by the Version 8.0 appliance. If it is not supported, you must first upgrade the directory before upgrading IBM Security Access Manager. You can configure the appliance with a user registry for either local or remote user registry mode. Depending on the purpose and scale of the deployment, either configuration might be suitable. In an existing IBM Security Access Manager environment, you typically deploy the user registry on separate hardware than the rest of the supporting infrastructure. If you plan is to deploy the appliance and utilize the local user registry embedded on it, you cannot migrate data from a pre- existing user registry. For a remote user registry, you must upgrade the directory server to the prerequisite minimum level that is supported for appliance. If you use IBM Security Directory Server, you must upgrade to Version or later. If you use non- IBM user registries, see the product documentation and take appropriate steps to perform the upgrade, if necessary. To obtain the most updated software product compatibility report, see the Systems Requirements tech note at 01.ibm.com/support/docview.wss?uid=swg IBM Security Directory Server Migration considerations The IBM Security Directory Server upgrade process preserves existing schema definitions and directory server configuration. Version server and client can coexist with servers and clients for Versions 6.0, 6.1, 6.2, and 6.3. You can directly migrate IBM Security Directory Server, Version 6.3.1, to Versions 6.3, 6.2, and 6.1. Note: A direct upgrade of IBM Security Directory Server, Version 6.0, instances to Version is not supported. You can upgrade Version 6.0 instances to Versions 6.1, 6.2, or 6.3 and then to Version When upgrading from a previous version of the user registry, complete the following steps: Back up the schema, configuration files, and database of the instance so you can recover from any upgrade failures. Complete the new installation of IBM Security Directory Server at the supported version for the appliance. Migrate an existing instance from a previous version Upgrading the IBM Security Directory Server The high- level steps for upgrading IBM Security Directory Server are: 1. Prepare the database for migration by backing up and stopping the database. 27 Page

28 2. Back up the schema, configuration files, and database of an instance so you can recover from any upgrade failures. 3. Upgrade the operating system, if necessary. 4. Upgrade DB2, if necessary. See 01.ibm.com/support/docview.wss?uid=swg Check the migration path for the version of IBM Security Directory Server that is required for the appliance. 6. Install IBM Security Directory Server at the supported version for appliance. 7. Migrate schema and configuration files. 8. Migrate the original IBM Security Directory Server instance from a previous version to the new directory server instance. 9. Migrate database instances and the databases. For complete IBM Security Directory Server upgrade steps, see 01.ibm.com/support/knowledgecenter/SSVJJU/welcome. Make a note of the hostname and IP address for this new user registry. This information is used in later steps Migrating from a Microsoft Active Directory Since the IBM Security Access Manager Policy Server can no longer be configured directly against Active Directory (AD), it must be migrated to the appliance as a Federated Directory. The appliance must firstly be configured against the internal Open LDAP Server, or one of the other supported external LDAP Directories. AD Policy Server Migration is different from other migrations in the following ways: All ISAM user, group, policy and GSO meta- data must be extracted from AD, filtered, and inserted into the new Policy Server registry. After the base migration process, the AD server should be cleaned of ISAM meta- data. Before starting the migration, ensure the following tools are available on the old AD Policy Server machine: isam_migrate.pl Perl binaries IBM Security Directory Server client ldapsearch and ldapdelete Active Directory dsquery.exe (Windows Server Administration Tools Pack AD DS Tools). The migration consists of the following steps: 1. Run isam_migrate.pl and manually construct the ZIP file. 2. Configure the new appliance Runtime using the ZIP file 3. Apply the non- essential user and group meta- data to the Appliance LDAP (isam_migrate.pl generates a separate usergroup- ldif- file ). 4. Run isam_migrate.pl to remove AD ISAM configurations 5. Uninstall AD ISAM Policy Server packages 28 P age

29 7.1.2 Updating Security Access Manager Certifications ISAM 8 with default settings uses TLS 1.2 for encrypted communication channels. The TLS 1.2 protocol does not support certificates creates with a signature algorithm of md5rsa. Before upgrading ensure the certificates being used are complaint with TLS 1.2. The following communications channels should be checked: 1. Intra- component. For example Policy Server to WebSEAL. Older version of ISAM (5.1 and below) created the internal certificate with a signature algorithm of md5rsa. Based on time of upgrade and settings there exist the potential for the internal certs to still be using these older certificates even at versions 6. If the environment is migrated to ISAM 8 it will not function without disabling TLS 1.2. Use the instructions in the TechNote at 01.ibm.com/support/docview.wss?uid=swg to determine the signatures. If the certificates are still using md5rsa it is recommended to recreate them using 6.X utilities before performing the migration. Complete details are located at: 01.ibm.com/support/knowledgecenter/SSPREK_6.1.1/com.ibm.itame.doc_6.1.1/am611_admin281.htm%23chcert?lang =en 2. ISAM Components to LDAP. 3. Reverse Proxy to front- end user. 4. Reverse Proxy to backend junction servers. Please contact your certificate vendor if you have questions for channels Migrating the policy server software to the appliance You can migrate the existing policy server running as software to an IBM Security Access Manager appliance policy server. The policy server must be the first IBM Security Access Manager component in a deployment. Performing the policy server migration is similar to a two- systems approach, where the current software policy server is migrated to the appliance policy server Migration Considerations Before the policy server migration begins, review the following considerations: Back up the following data: All Tivoli Access Manager servers (software- based). See the pdbackup utility in the IBM Security Access Manager for Web Command Reference. User registry data. For Tivoli Directory Server, see previous section; otherwise, consult the documentation for supported registry server. The migration process does not support changing existing configuration, such as the configured registry type. For example, it is not possible to upgrade from an LDAP registry to an Active Directory registry. The policy proxy component is no longer supported, so you cannot migrate it. Policy Server HA is supported in IBM Security Access Manager, Version 8.0, in an active- passive configuration. 29 P age

30 Migrating the Software Policy Server to the IBM Security Access Manager appliance After you review the considerations and take the appropriate, you can migrate the policy. A set of Perl scripts are available on the appliance to help collect the files that are necessary for the migration. These include the IBM Security Access Manager configuration files, key files, and the authorization database. The script is called isam_migrate.pl. Consider the following procedure: 1. Install and configure a new appliance policy server. See the Quick Start Guide for the IBM Security Access Manager, which describes how to connect and configure the appliance. 2. Configure the management interface for the new appliance. Ensure you can access the appliance through the local management interface. 3. Activate the appliance with a valid license. 4. Deploy and save the license. 5. Return to the original IBM Security Access Manager policy server. 6. Install Perl and ensure that it is available. 7. Download the isam_migrate.pl from the new appliance. Perl scripts for migrating to an appliance are available at Manage System Settings > Secure Settings > File Downloads. 8. Under File Downloads, go to common > migrate for the list of migration scripts. 9. Double- click on isam_migrate.pl and save it to the directory of your choice. 10. Copy the isam_migrate.pl file to the original IBM Security Access Manager environment directory, such as C:\tmp or \tmp. 11. Run the isam_migrate.pl script and the location of the runtime environment and policy server configuration path. The command must run with the following options: 30 P age

31 perl isam_migrate.pl [-c config-path] [-d working-dir] [-o zip-file] {-v} where -c config-path is the path to the IBM Security Access Manager configuration files. -d working-dir is the working directory, which should not exist on the file system. -o zip-file is the configuration bundle zip file that you want to produce. It should not exist on the file system. -v displays status messages. 12. Import the exported zip file when configuring the IBM Security Access Manager runtime environment on the appliance. Do this step as part of the initial setup process, not as an addition to a previously configured policy server appliance. 13. Execute the script on a Windows system: a. Install a Perl interpreter, such as Strawberry Perl. b. Open the Perl command- line terminal. c. Browse to where you saved the migration script and execute the following command: perl isam_migrate.pl -c "C:/Program Files/Tivoli/Policy Director/etc/" -d "C:/tmp/isam" -o "C:/tmp/isam.zip" v Note: The / symbol is required for the - c config- path option. The following is an example of output generated when running the script. 31 P age

32 14. A compressed file might be created on the platform. If a compressed file is not automatically created, manually create a compressed file; the contents are relative to the location that contains the copied files. For example on a UNIX system, if you created the directory structure in /tmp/isam, the command is: cd /tmp/isam zip -r /tmp/isam.zip * On a Windows System, you can create a zip file with the contents relative to the destination directory with the following example command: cd C:\tmp\isam zip -r C:/tmp/isam.zip The compressed file bundle contains the following policy server configuration files: pd.conf, ivmgrd.conf, ldap.conf, and additional obfuscated config files A collection of key database and stash files used by the policy server - pd.kdb / pd.sth and ivmgrd.kdb / ivmgrd.sth A copy of the policy database - master_authzn 15. Verify the resulting output under the staging directory, such as C:/tmp/isam. 16. Manually change the host values in the pd.conf and ldap.conf files to IP addresses that are appropriate to the new environment. Edit both configuration files accordingly so it references to the correct LDAP server. The following entries must be modified: 32 P age

33 In pd.conf configuration file: [pdrte] user-reg-type = ldap user-reg-server = <Server host name> # Must reflect the host of the new LDAP user-reg-host = <Server host name> # Must reflect the host of the new LDAP user-reg-hostport = 389 # Must reflect the port of the new LDAP In ldap.conf configuration: [ldap] enabled = yes host = <Server host name> port = 389 ssl-port = 636 # Must reflect the host of the new LDAP # Must reflect the port of the new LDAP # Must reflect the port of the new LDAP 17. Update the new IBM Security Access Manager 8 Policy Server Host file with the host values to IP addresses that suit the new environment. Select Manage System Settings > Networks Settings > Hosts File. 18. Create a New entry and provide the appropriate IP address and Hostname. 33 P age

34 19. Save and deploy the changes to the system. 20. On the new policy server appliance, import the policy server compressed migration file created in previous steps by going to Secure Web Settings > Manage > Runtime Component. Note: This image can differ depending on if the Mobile license is activated. 21. Click Configure to display the Runtime Environment Configure window. 22. Under the Main tab, select Import for the Policy Server and click Next. 34 P age

35 23. Click Browse. 24. Locate the compressed file that contains the necessary migration files. 25. Click Open. The previously compressed IBM Security Access Manager configuration bundle filled is at File Name. 26. Click Finish. 35 P age

36 Once the configuration completes, you see the following screen: 27. Verify the host values in the pd.conf and ldap.conf files to IP addresses are suitable for your new environment. If not, you must change them. 28. Make any changes to the ldap.conf file using the following steps: a. From the Version 8.0 policy server, log in to the local management interface and select Secure Web Settings > Manage Runtime Component. b. Under Runtime Component, select Manage > Configuration Files > ldap.conf. 36 P age

37 c. In the Advanced Configuration File Editor ldap.conf window, make the appropriate changes under the [ldap] stanza. Include parameters that describe the LDAP server support for your new environment. d. Save and deploy these changes. 29. Repeat the previous step to change the host values (localhost) in the pd.conf file to IP addresses. Change the primary as follows: [pdrte] user-reg-type = ldap user-reg-server = <Server host name> # Must reflect the host of the new LDAP user-reg-host = <Server host name> user-reg-hostport = 389 The following screenshot provides an example of such configuration: 37 P age

38 Verify the new policy server Verify that the new policy server is operating correctly by inspecting the logs. 1. Under Monitor Analysis and Diagnosis, select Logs. 2. Click Application Log Files to view the Policy Server and User Registry log files link. 3. Relevant logs entries can be found under isam_runtime/policy_server and isam_runtime/user_registry 38 P age

39 Retiring original policy server After you complete the policy server upgrade, retire the original policy server after you successfully migrate the data and the IBM Security Directory Server client and server to the new policy server system. It is important to identify all IBM Security Access Manager components in the original environment and re- configure them to point to newly created policy server. This step is not time- critical, although you should complete it before upgrading the WebSEAL server. At this stage, everything should communicate with the Version 8.0 policy server. Keep the old policy server as a stand- by in case you require a roll- back during the next phase Authorization server If you configured an authorization server in a customer environment, validate if this component is actually needed. The objective of an authorization server is to provide access to the authorization service for third- party applications that use the IBM Security Access Manager authorization API in remote cache mode. Most customers do not need this component unless they have heavy Java authorization usage. There is no need to migrate the original authorization server. You can configure it on the appliance if it is required See Creating an authorization server instance at 01.ibm.com/support/knowledgecenter/api/content/SSPREK_ /com.ibm.amweb.doc_ /admin/task/tsk_auth_server _crt.html Migrating WebSEAL After you successfully migrate the policy server, migrate the WebSEAL instances. Upgrading the WebSEAL instances is similar to the policy server, except you must first create a blank WebSEAL instance before importing the saved configuration. 39 P age

40 Migration considerations Before starting the WebSEAL migration, review the following considerations. When migrating a WebSEAL server in a production environment, schedule downtime to upgrade the WebSEAL server. Re- evaluate the number of WebSEAL instances currently configured in the IBM Security Access Manager environment. Assess the need of each instance and consider consolidating them. Check the design rationale that requires large number of WebSEAL instances and then see if any previous product limitation that required a large number is addressed in IBM Security Access Manage, version 8 so you can reduce the number of instances. Re- analyze performance requirements to ensure the same levels of performance are achieved. To reduce down time, configure the existing WebSEALs severs to communicate with the new appliance policy server. Evaluate supported WebSEAL reverse proxy functionality in the appliance. See 01.ibm.com/support/knowledgecenter/SSPREK_ /com.ibm.amweb.doc_ /admin/concept/con_appl_ws_dif f_admin.html Custom Cross- domain Authentication Service (CDAS) or External Authentication Server (EAS) libraries are not supported. Before you migrate the system, ensure there is no dependency on custom CDAS or EAS libraries. For example, you must convert any custom CDAS processing to an External Authentication Interface (EAI). Local junctions are supported, but a fixed location is used as the document root. A local junction also cannot run any CGI scripts. It can serve only static page content. You must migrate any CGI scripts to a remote server. The appliance supports only a single local junction. You must also migrate the content for all other local junctions (if any) to a remote server Migrating WebSEAL to the appliance After you review the considerations and take any appropriate actions, you can migrate WebSEAL. The following options are available for the WebSEAL migration: Manually creating a directory structure, copying WebSEAL instance files, and bundling them into a compressed zip file. Use this method if enterprise security policies prohibit using a Perl script. Running the wga_migrate.pl Perl script. To employ the manual process, please see product documentation ( 01.ibm.com/support/knowledgecenter/SSPREK_ /com.ibm.isamw.doc_ /admin/concept/con_migration.html) for further details. The remainder of this section describes the migration process using the Perl script. Note: Both the manual approach and the Perl utility is based on a per- WebSEAL instance basis. The wga_migrate.pl Perl script is available on the appliance. It exports the complete configuration from the running WebSEAL server into a zip file. The zip file contains all WebSEAL configurations except for a couple of non- portable items, such as IP address, Port, etc. Note: Before migrating WebSEAL, you must configred the destination appliance Network Application Interfaces. 40 P age

41 Follow these steps: 1. Download the WebSEAL migration Perl Script from the appliance under Manage System Settings > Secure Settings > File Downloads. 2. Under File Downloads, go to common > migrate to see the list of available of migration scripts. 3. Double- click on wga_migrate.pl and save it to a directory of your preference. 4. Copy the wga_migrate.pl file to the original IBM Security Access Manager environment or source WebSEAL server to a directory, such as C:\tmp or \tmp. 5. On the source WebSEAL server, identify the WebSEAL instance to be migrated. 6. Locate the name of the configuration file for the WebSEAL instance that is to be migrated. Typically, it is located in C:\Program Files\Tivoli\PDWeb\etc or /var/pdweb/etc in a Windows or Linux system respectively. Run the wga_migrate.pl script and specify the name of the WebSEAL configuration file and the destination directory. Use the following options: perl wga_migrate.pl [-c config-file] [-d dst-dir] {-v} where -c config-file is the WebSeal configuration file. -d dst-dir is the destination directory. It must not exist on the file system. -v displays status messages. 7. Review the files in the destination directory to ensure that all the necessary files are there. 8. Create a compressed file with the contents relative to the location that contains the copied files. 9. Import the migration compressed file. 41 P age

42 The following example shows executing the migration from a Version WebSEAL instance that as Strawberry Perl installed on a Windows System to an appliance. a. Open the Perl command- line terminal. b. Browse to where you saved the WebSEAL migration script and execute the following command: perl wga_migrate.pl -c "C:/Program Files/Tivoli/PDWeb/etc/webseald-default.conf" -d "C:/tmp/migrate_out Note: The / symbol is required for the -c config-path option. The WebSEAL configuration files are staged to the directory defined by the -d option. The following is an example of output generated when running the script. c. Browse to the directory location where the WebSEAL configuration files were staged. In this example, the output is placed in C:/tmp/migrate_out: 42 P age

43 Note: The directory structure shown is different than migrations made on customer s environment as customers have their own set of configurations and customizations made to WebSEAL. 10. Examine the staged version of the WebSEAL configuration file to ensure that any configuration entries that are not applicable to the target system (e.g network settings) are removed. 11. Include the WebSEAL configuration file in the set of configuration files to be migrated. Also include the obfuscated configuration file, as defined by the [configuration-database] stanza and file configuration entry. Note: Do not change the name of the obfuscated database, webseald-<instance>.conf.obf. If the obfuscated database file name is different, rename it to the default and update the configuration entry accordingly. 12. Modify the copied WebSEAL configuration file and remove any configuration entries that are not applicable to the new WebSEAL instance. Examples of entries that you might not want to migrate include network settings. The following configuration entries are ignored when the configuration file is imported into the appliance: token-card configuration entry from the [authentication-levels] stanza server-name configuration entry from the [server] stanza network-interface configuration entry from the [server] stanza [interfaces] configuration stanza 13. From the staged output directory, create a compressed zip file with the content relative to the destination directory. For example on a UNIX system, if the directory structure was created in /tmp/migrate, the command is: cd /tmp/migrate zip -r /tmp/migrate.zip * For example on a Windows system, create a zip file with the contents being relative to the destination directory, the command is: cd C:/tmp/migrate_out zip -r C:/tmp/migrate.zip * 14. On the destination appliance, create a new blank WebSEAL instance that completes the WebSEAL instance migration. 43 Page

44 a. Log in to the destination appliance local management interface. b. Select Secure Web Settings > Reverse Proxy. c. Click New to create the new WebSEAL instance in the appliance. d. Specify the necessary entries for the instance and click Next. Note: This instance uses a new IP address for port bind. Note: The name of the instance on the appliance MUST be the same as the name of the original instance. 44 P age

45 e. Enter the sec_master user password and click Next. f. Specify the Network Transport details for the WebSEAL instance and click Next. 45 P age

46 g. Specify the User Registry details as required and click Finish. The new default WebSEAL instance is listed as a reverse proxy in the appliance. 15. Import the configuration zip file into this new default WebSEAL instance by selecting the default WebSEAL instance. 16. Select Manage > Configuration > Import Configuration. 17. In Import Configuration, click Browse. 46 P age

47 18. Locate the compressed file that contains the migration files. 19. Click Open. 20. Select Overwrite since the original key files are being imported. If you do not select it, the system displays the following response: 21. Click Import. 22. Click the link on the notice. 47 P age

48 23. Click Deploy. 24. Restart the WebSEAL instance by selecting Restart. 25. After the instance restarts, use a browser to access the URL to ensure that it is operational. 26. Examine the WebSEAL log file for any potential migration issues. a. Go to Secure Web Settings > Reverse Proxy > Select WebSEAL instance default > Manage > Logging. 48 P age

49 b. In the Manage Reverse Proxy Log files, inspect the log files. Note: If the session management server was previously employed, update it to employ Distributed Session Cache on the appliance. See Section 3 Migration on the Distributed Session Cache Guide 0Identity%20Manager/page/ISAM%20SMS%20to%20DSC%20Migration 27. If appropriate, change the load balancer to point to the new WebSEAL and remove the old WebSEAL from the list. Note: This step can be done individually for each WebSEAL or after all WebSEALs are recreated on appliances. After you migrate all instances to the new appliance, the appliance policy server has references to WebSEAL instances that point to the old environment. They might no longer be relevant to your new environment; if they are irrelevant, remove them. The appliance offers the Server Cleanup function so that an administrator can remove such instances or other authorization server instances that are no longer required. Note: This operation removes references the new policy server has to the old environment. It does not remove configurations in the old environment. Consider the following steps to utilize this function: 1. In the destination appliance local management interface console, select Secure Web Settings > Manage Runtime Component > Manage > Server Cleanup. 49 P age

50 2. Supply authentication details for sec_master. 3. Authorization Servers lists all the servers configured to this policy server. Select the ones you want to remove. Note: A red icon indicates that the server cannot be contacted. Stopping a server also means that it cannot be contacted. Make sure that you select only the instance that is no longer relevant in your current environment Retiring original WebSEALs After you migrate all original WebSEAL instances and performed the appropriate testing, retire the original WebSEALs that are no longer relevant. 50 P age

51 8 Summary While this document provides the details of a standard migration from a software deployment to an appliance deployment, keep in mind that certain environments might have customizations in place that can be affected by this upgrade. As a consequence, the significance of planning for the upgrade and backing up the existing environment cannot be overstated. Have at least one test or development environment. Make this test environment an accurate reflection of the production environment. Take into account, to a reasonable extent, the database size, server hardware, PC configuration (antivirus, and so on), and other variables. 51 P age

52 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 U.S.A. For license inquiries regarding double- byte character set (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd , Nihonbashi- Hakozakicho, Chuo- ku Tokyo , Japan 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 might 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. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation 2Z4A/ Burnet Road Austin, TX U.S.A. 52 P age

53 Such information may be available, subject to appropriate terms and conditions, including in some cases payment of a fee. The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development- level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. 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. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. All IBM prices shown are IBM's suggested retail prices, are current and are subject to change without notice. Dealer prices may vary. This information is for planning purposes only. The information herein is subject to change before the products described become available. 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. 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 IBM's application programming interfaces. Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows: IBM 2014, Portions of this code are derived from IBM Corp. Sample Programs. Copyright IBM Corp 2014, All rights reserved. If you are viewing this information in softcopy form, the photographs and color illustrations might not be displayed. 53 P age

54 Trademarks IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at Copyright and trademark information at ibm.com/legal/copytrade.shtml. Statement of Good Security Practices IT system security involves protecting systems and information through prevention, detection and response to improper access from in and outside your enterprise. Improper access can result in information being altered, destroyed, misappropriated or misused or can result in damage to or misuse of your systems, including for use in attacks on others. No IT system or product should be considered completely secure and no single product, service or security measure can be completely effective in preventing improper use or access. IBM systems, products and services are designed to be part of a comprehensive security approach, which will necessarily involve additional operational procedures, and may require other systems, products or services to be most effective. IBM DOES NOT WARRANT THAT ANY SYSTEMS, PRODUCTS OR SERVICES ARE IMMUNE FROM, OR WILL MAKE YOUR ENTERPRISE IMMUNE FROM, THE MALICIOUS OR ILLEGAL CONDUCT OF ANY PARTY. 54 P age

55 International Business Machines Corporation 2014, 2015 International Business Machines Corporation New Orchard Road Armonk, NY Produced in the United States of America All Rights Reserved References in this publication to IBM products and services do not imply that IBM intends to make them available in all countries in which IBM operates. 55 P age