Redpaper

Axel Buecker Archit Lohokare

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0

Migration Guide for Encentuate 3.4 and 3.5
IBM Tivoli Access Manager for Enterprise Single Sign-On enables organizations to automate access to corporate information, strengthen security, and enforce compliance at the endpoints. With Tivoli Access Manager for Enterprise Single Sign-On, organizations can efficiently manage business risk, achieve regulatory compliance, decrease IT costs, and increase user efficiency. Tivoli Access Manager for Enterprise Single Sign-On delivers the following capabilities: Strong authentication for all user groups Enterprise single sign-on with workflow automation Comprehensive session management ability User-centric access tracking for audit and compliance reporting Secure remote access for easy access anywhere, anytime Integration with user provisioning technologies Building of a strong digital identity Tivoli Access Manager for Enterprise Single Sign-On allows a transparent solution to be deployed with no change to the underlying infrastructure. Its foundation is built on the feature set in every version in an effort to better adapt itself to the changing IT needs in an organization. While the upgrades from one version to the next are designed to be automated and should require little to no execution of specialized upgrade scripts, there is a possibility that significant changes in product architecture might necessitate such manual actions. In this IBM Redpaper document we discuss the actions required to migrate an existing pre-v3.6 Encentuate1 deployment to a v8.0 or later deployment of Tivoli Access Manager for Enterprise Single Sign-On.

Encentuate was the company that originally developed this application. They were acquired by IBM Tivoli Software and the application was renamed to Tivoli Access Manager for Enterprise Single Sign-On.

Copyright IBM Corp. 2009. All rights reserved.

ibm.com/redbooks

Planning the migration

This document should be consulted as part of the first stage of migration planning. It is important to note that with Tivoli Access Manager for Enterprise Single Sign-On, there may be multiple phases due to organizational, infrastructure, or business demands, and therefore, it may be helpful to revisit these guidelines several times throughout the deployment.

Overview of the deployment architecture

A typical Tivoli Access Manager for Enterprise Single Sign-On deployment involves several components. An overview of the basic architecture is shown in Figure 1.

Figure 1 Deployment architecture

IMS servers The Integrated Management System (IMS) server provides administrative, reporting, help desk, and password reset functionality, as well as being the repository for user data. AccessAdmin and AccessAssistant are the tools used to provide management and reporting capability. The infrastructure to communicate and manage the AccessAgents (Clients) is also managed through the IMS Server. IMS database The IMS server requires a database to store configuration data, policy data, user data, application profiles, and audit logs. Tivoli Access Manager for Enterprise Single Sign-On currently supports Oracle, Microsoft SQL, and IBM DB2 database servers. AccessAgent The client component is installed on all systems that require single sign-on (SSO) functionality. AccessAgent can be installed on individual Windows clients, as well as Microsoft Terminal Services and Citrix MetaFrame/Xen systems. AccessStudio AccessStudio is a software tool designed for Tivoli Access Manager for Enterprise Single Sign-On administrators to profile applications.

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0: Migration Guide for Encentuate 3.4 and 3.5

The following components are not part of the Tivoli Access Manager for Enterprise Single Sign-On product, but they represent infrastructure components that may or may not be present in the environment. Identity directory Typically an Active Directory or LDAP environment is used by Tivoli Access Manager for Enterprise Single Sign-On to validate users during the registration process for SSO services. Additionally, in the case of using Active Directory, Tivoli Access Manager for Enterprise Single Sign-On can also provide self-service password reset services. Load balancing/high availability for IMS and database services While Tivoli Access Manager for Enterprise Single Sign-On is a client/server architecture, the solution is not dependent on having network connectivity between the AccessAgent and the IMS Server to ensure a functional SSO experience for the users. In fact, given the mobility of laptops and the typical movement of users between office and home, it is typical that the AccessAgent is not in contact with the IMS server. IMS servers can be clustered for load balancing and high availability. A separate session-aware load balancer must be used to channel traffic into an IMS Server cluster. Database servers can be clustered for load balancing and high availability using the individual manufacturers technology. Figure 1 on page 2 also depicts the communication protocols used by Tivoli Access Manager for Enterprise Single Sign-On. Client communication over unsecured HTTP is only used during installation; SSL encrypted communication is used for all production traffic. To find out more about the Tivoli Access Manager for Enterprise Single Sign-On components read the IBM Redbooks publication Deployment Guide Series: IBM Tivoli Access Manager for Enterprise Single Sign-On 8.0, SG24-7350.

Overview of the upgrade

An upgrade from v3.4 to v8.0 is a two step server upgrade, requiring you to first upgrade the IMS server to v3.5, and subsequently to v8.0. The AccessAgents, however, can be directly upgraded to v8.0. Since IMS servers are designed to be backward compatible with AccessAgents, it is possible for us to perform a gradual upgrade of the AccessAgents from v3.4 to v8.0, once we have completed the server upgrade from v3.4 to v.3.5 and subsequently to v8.0.

Upgrade from v3.4 to v3.5

It is important to understand the major architectural and configuration differences between the two versions before performing the upgrade from v3.4 to v3.5.

Differences between v3.4 and v3.5

One of the primary differences in the architectures between Encentuate v3.4 and v3.5 is the support for multiple domains. Encentuate v3.4 had been designed to work only with a single domain, whereas v3.5 supports multiple domains. To enable this design, a new configuration ActiveDirectory (AD) Deployment Type was introduced. For IMS Server versions prior to 3.5.0, support for Active Directory (AD) as the

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0 Migration Guide for Encentuate 3.4 and 3.5

enterprise directory can be configured to use AD deployment type 1 or 2. In an AD deployment type 1 configuration, all user names must be unique, across domains and even forests. This mode is used for backward compatibility with previous AccessAgent versions. If user names can be duplicated across different domains, the IMS Server should be configured to use AD deployment type 2. IMS Server versions from 3.5.0 onwards support only AD deployment type 2 configurations.

IMS Server upgrade steps

As a first step you need to check whether the enterprise directory is configured to use the Active Directory (LDAP) connector. If so, the enterprise directory must be changed to use the Active Directory (ADSI) connector. 1. Launch the IMS Configuration Utility (Figure 2). By default, this is located at http://<ims_server_url>:8080

Figure 2 The IMS v3.4 configuration utility

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0: Migration Guide for Encentuate 3.4 and 3.5

2. Go to Basic Settings Enterprise Directories (Figure 3). Select the enterprise directory you have configured for Active Directory (ENCActiveDirectory) and click Update directory.

Figure 3 The Enterprise Directories drop down menu

3. In the next panel scroll down to the Application Connector Configuration section and check whether the connector is Active Directory (ADSI) Connector or the Active Directory (LDAP) Connector. If it is the latter, click the Delete Connector button and then proceed to configure an Active Directory (ADSI) Connector instead. The red frame in Figure 4 on page 6 shows that the Active Directory (ADSI) Connector is configured.

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0 Migration Guide for Encentuate 3.4 and 3.5

Figure 4 Viewing the existing Application Connector configuration

4. You can now begin the migration to v3.5. Run the IMS installer v3.5 and proceed to the Select Installation Type dialog. Select Upgrade and click Next.

Figure 5 Choosing the Upgrade option in the v3.5 IMS installer

When proceeding with the update installer make sure to select the correct previous installation folder and the new installation folder and finish the upgrade process. Once the upgrade is complete, the AD deployment type has been automatically changed to type 2 and the users have been migrated as well. 6
IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0: Migration Guide for Encentuate 3.4 and 3.5

5. The IMS Server Configuration utility will be automatically launched as shown in Figure 6.

Figure 6 The v3.5 IMS Server Configuration utility

6. Go to Basic settings Enterprise directories, select the enterprise directory you have configured for Active Directory, and click Update directory as shown in Figure 7.

Figure 7 The v3.5 Enterprise Directories list

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0 Migration Guide for Encentuate 3.4 and 3.5

7. In the next panel scroll down to Application connector configuration. In the Basic configuration keys section select DNS for the domain type to be shown in AccessAgent, as shown in Figure 8. Scroll all the way to the end of the dialog and click Save and Test.

Figure 8 Changing the domain type display in the AccessAgent

8. Close the IMS Server Configuration utility.

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0: Migration Guide for Encentuate 3.4 and 3.5

9. Stop the IMS Server by clicking Start All Programs Encentuate IMS Server Stop IMSService (Figure 9).

Figure 9 Stopping the IMS Service

10.Start the IMS Server by clicking Start All Programs Encentuate IMS Server Start IMSService. 11.Note that the DNS domain (for example, tci.encentuate.com) instead of the NetBIOS domain (for example, tci) will now be shown in the AccessAgent logon prompt, as shown in Figure 10.

Figure 10 The AccessAgent login prompt with the DNS domain name

If you would like to switch back to using a NetBIOS domain, the IMS Server must be upgraded to version 3.5.1 or later, and AccessAgent on all machines must be upgraded to version 3.5.2 or later.
IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0 Migration Guide for Encentuate 3.4 and 3.5

Once that is done, you can switch back to using the NetBIOS domain by performing the following steps: 1. Launch the IMS Server Configuration utility. 2. Go to Basic settings Enterprise directories. 3. Select the enterprise directory you have configured for Active Directory and click Update directory. 4. In the next panel scroll down to the Application connector configuration. In the Basic configuration keys section select NetBIOS for the domain type to be shown in AccessAgent. Scroll all the way to the end of the dialog and click Save and Test. 5. Close the IMS Server Configuration utility. 6. Stop the IMS Server by clicking Start All Programs Encentuate IMS Server Stop IMSService. 7. Start the IMS Server by clicking Start All Programs Encentuate IMS Server Start IMSService.

Using AccessAgent version 3.4 with the new IMS

Once the new IMS Server is installed, you should be able to log into your existing AccessAgent version 3.4. If you encounter problems logging in, update the specific users' authentication policies to allow password-only login. This can be done by re-applying the user policy template to the users by performing the following steps. 1. Ensure that the user policy template allows password login to the Wallet. Start the AccessAdmin application. To access the applicable user policy template click the specific link in the User Policy Templates section in AccessAdmin; in our case that is Default. Once Password is selected in the Authentication Policies section, as shown in Figure 11, scroll all the way down and click Update.

Figure 11 Updating the User Policy Template with the correct authentication policy

10

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0: Migration Guide for Encentuate 3.4 and 3.5

2. Search for a user to whom the policy has to be reapplied. If you search for a particular user, as shown in Figure 12, and that user has been found, you will immediately be presented with the user profile page. If you search with a wildcard you may see a list of users. Once you select a particular user you will be presented with the user profile page.

Figure 12 Searching for a user who is not able to successfully login

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0 Migration Guide for Encentuate 3.4 and 3.5

11

3. Scroll down to the bottom of the user profile page, select the appropriate user policy template, in our case Default, and click Update (Figure 13).

Figure 13 Updating a user with a new (or existing updated) user policy template

4. To achieve the same results for a larger number of users, rather than an individual user, search for the users in AccessAdmin, as shown in Figure 14.

Figure 14 Searching for multiple users

12

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0: Migration Guide for Encentuate 3.4 and 3.5

5. In the users found list that is displayed in Figure 15, select the users you want to apply the policy template to. Select the policy template in the drop-down menu, and click Apply to selected results.

Figure 15 Updating a list of users with a new (or existing updated) user policy template

Using AccessAgent versions prior to 3.3.2.6

AccessAgent versions prior to 3.3.2.6 do not properly support AD deployment type 2 when AD password synchronization is used. In AD deployment type 1, a user can log on to AccessAgent only with the AD attribute SAMAccountName as the user name. In AD deployment type 2, a user can log on to AccessAgent with a different logon name, for example, UPN as the user name. The latter is not fully supported in AccessAgent versions prior to 3.3.2.6. Hence, users, except those who use RFID as a second factor authenticator, should continue to log on to AccessAgent only with SAMAccountName as the user name in AD deployment type 2. Note: When a user logs on to AccessAgent, the username and password provided is used to save account data in the users Wallet. This account data is used for SSO with applications that authenticate with AD. In AccessAgent versions prior to 3.3.2.6, account data with different user names is saved if a user logs on to AccessAgent with a different logon name. Other than confusing the user, the multiple account data can go out of sync when the user changes his AD or Encentuate password. If RFID is being used as a second factor authenticator and all the applications that authenticate with AD accept [domain]\[SAMAccountName] as the user name, the following measures should be taken before upgrading the IMS server: 1. Before upgrading to deployment type 2, replace [dbowner] and [Authentication service ID linked to enterprise directory] accordingly and run the SQL script in Example 1 against the IMS Server database.

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0 Migration Guide for Encentuate 3.4 and 3.5

13

Example 1 SQL upgrade script

UPDATE [dbowner].IMSTemplatedSyncRepo SET isDeleted = 1, updateTimeStamp = GETDATE() WHERE (attrName = 'account_data') AND (entityTypeID = 'scp_user') AND (keyValue LIKE '%>' + '[Authentication service ID linked to enterprise directory]' + '<%>' + (SELECT attrValue FROM [dbowner].IMSIdentityUniqueAttribute B WHERE entityID = B.imsID AND attrName = 'Enterprise Login') + '<%') You might need to run the SQL script more than once if multiple authentication services are linked to the enterprise directory. Figure 16 shows an example when using SQL Server as the IMS database.

Figure 16 SQL Server Enterprise Manager SQL Query Analyzer

Note: This SQL script deletes account data used to synchronize with Encentuate passwords for all users by setting the isDeleted flag to 1 and updating the updateTimeStamp.

14

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0: Migration Guide for Encentuate 3.4 and 3.5

2. Use the XML editor in AccessStudio to add the attribute wnd_should_be_enabled="0" to all wnd_xpath_combo_box_indirect_auth_info nodes in the sso_site_gina_winlogon AccessProfile as shown in Figure 17. Upload the AccessProfile to IMS Server.

Figure 17 Modifying XML related to the Windows Logon AccessProfile

After upgrading the IMS server, all users who are using RFID as a second factor should only log on to AccessAgent using [domain]\[SAM Account Name] as the user name, as shown in Figure 18.

Figure 18 Logging in to AccessAgent with the new user name format

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0 Migration Guide for Encentuate 3.4 and 3.5

15

Note: When users tap their RFID card before entering their password, they are effectively logging in to AccessAgent with [domain]\[SAMAccountName] as the user name. This will cause account data with the same user name to be saved in the Wallet. If RFID is being used as a second factor authenticator, but at least one application that authenticates with AD does not accept [domain]\[SAMAccountName] as the user name, it is best to enforce no changing of AD and Encentuate passwords until all AccessAgent clients have been upgraded. After all AccessAgent clients have been upgraded, replace [dbowner] and [Authentication service ID linked to enterprise directory] accordingly and run the SQL script shown in Example 2 against the IMS Server database.
Example 2 SQL update script

UPDATE [dbowner].IMSTemplatedSyncRepo SET isDeleted = 1, updateTimeStamp = GETDATE() WHERE (attrName = 'account_data') AND (entityTypeID = 'scp_user') AND (keyValue LIKE '%>' + '[Authentication service ID linked to enterprise directory]' + '<%>' + (SELECT attrValue FROM [dbowner].IMSIdentityUniqueAttribute B WHERE entityID = B.imsID AND attrName = 'Enterprise Login') + '<%') You might need to run the SQL script more than once if multiple authentication services are linked to the enterprise directory. Note: This SQL script deletes duplicate account data used to synchronize with the Encentuate password for all users by setting the isDeleted flag to 1 and updating the updateTimeStamp.

Upgrade from v3.5 to v8.0

Before performing an upgrade from v3.5 to v8.0, it is important to understand the differences between the two. The next section provides an explanation of these differences.

Differences between v3.5 and v3.6/v8.0

Tivoli Access Manager for Enterprise Single Sign-On v8.0 was the first version release after Encentuate was acquired by IBM. Major architectural changes were introduced in v3.6 that have since then been incorporated in all subsequent Tivoli Access Manager for Enterprise Single Sign-On versions. Due to the relative similarity in the architectures, the steps to upgrade from v3.4 to v8.0 are practically identical to the steps needed to upgrade from v3.4 to v3.6. This section discusses the loss of Citrix-related functionality as well as the Machine Policy Templates (MPTs) that were introduced in v3.6.

Citrix functionality
In v8.0, there has been a significant change in the Citrix functionality of the AccessAgents. Prior to v8.0, the local AccessAgent installed on the users local PC could communicate with the AccessAgent installed on the Citrix Server. In v8.0, this communication, which is facilitated through the Citrix Virtual Channel, is no longer available by default. If you do require

16

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0: Migration Guide for Encentuate 3.4 and 3.5

this functionality, additional services are needed to implement the virtual channel functionality on-site. The reduced Citrix functionality and corresponding workarounds are summarized in the following paragraphs to help you determine how critical this functionality is for you: A second manual logon to AccessAgent on the Citrix Server is required if the Tivoli Access Manager for Enterprise Single Sign-On Network Provider is not enabled. Workaround 1: If AD password synchronization is disabled, caching of Encentuate logon credentials on the Citrix Server should be enabled by setting pid_ts_logon_cache_enabled to 1. However, a user still has to manually log on to AccessAgent for the first time, and subsequently every time he changes the Tivoli Access Manager for Enterprise Single Sign-On password. Workaround 2: If AD password synchronization is enabled, the Tivoli Access Manager for Enterprise Single Sign-On Network Provider should be enabled by setting pid_en_network_provider_enabled to 1 so that the Windows credentials will be used to log on to AccessAgent. There will be no immediate synchronization between a local AccessAgent on a users PC and a remote AccessAgent on the Citrix Server. There is no workaround for this situation. If you disable automatic sign-on on the local AccessAgent, the remote AccessAgents automatic sign-on functionality will not be disabled automatically. There is no workaround for this situation. Remote AccessAgent will not be informed when the user logs out of the local AccessAgent or locks the computer. This would mean that in Shared Desktop User switch scenarios, the remote AccessAgent will not log off from the user's Citrix session even if the local AccessAgent logs off from the user's session. Workaround: The AccessProfile for Citrix ICA client (wfica32.exe) must be able to close the Citrix client (or graceful logoff) to make sure the remote session also ends. For situations where users lock the computer, AccessAgent lock scripts can be used. AccessAgent on the Citrix Server icon cannot show a different menu based on whether the user is logged into the server via a Citrix session or directly. If a user is logged in to both local and remote AccessAgent, two AccessAgent icons are displayed in the system tray. Currently, the remote AccessAgent will not have the same right-click menu options as the local AccessAgent if pid_ts_aa_menu_option is set to 1. Without ICA channel support, remote AccessAgent does not know whether local AccessAgent exists, and thus will always display the full menu. The user will, however, be able to distinguish between the two AccessAgent icons because the mouse-over text of the remote AccessAgent icon indicates TAM E-SSO AccessAgent on xxx server. There is no workaround for this situation. User is not logged off from Remote AccessAgent when a thin client session is reconnected. If RFID is used for two-factor authentication on thin clients, the Citrix session is a generic machine-specific session to each thin client. This session may be disconnected at times if the network connection is poor. In that case, the thin client may automatically reconnect back to the previous session when the network is available again. The previously open desktop may then show up on the screen. Since the remote AccessAgent does not know whether this is a thin client scenario, it will not automatically perform logoff. There is no workaround for this situation.
IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0 Migration Guide for Encentuate 3.4 and 3.5

17

Cannot disable launching of remote AccessAgent even when local AccessAgent is not present. Currently, the launching of remote AccessAgent while a published application is launched through Terminal Server can be disabled if local AccessAgent is not present by setting pid_ts_start_aa_no_local_aa_enabled to 0. Without ICA channel support, remote AccessAgent does not know whether local AccessAgent exists, and thus, will always be launched. There is no workaround for this situation.

Machine policy templates

In IMS Server version 3.5 the concept of machine policies was non-existent on the server. As illustrated in Figure 19, all the machine policies were stored in the Windows registry of the client machine as registry settings under the hive: HKEY_LOCAL_MACHINE\Software\Encentuate\DeploymentOptions

Figure 19 Registry location of the Machine Policy Templates in pre-v3.6 versions

These registry settings controlled the behavior of the machine, examples of which are: Desktop inactivity timeout Second factor used to strengthen access to the machine Type of workstation (Shared or Personal) Type of desktop for Shared machines (Private or Shared) These registry settings were distributed along with the AccessAgent installation package. The package consisted of a folder called Reg, which would contain a registry file called DeploymentOptions.reg, which would be responsible for configuring the machine with the correct registry settings.

18

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0: Migration Guide for Encentuate 3.4 and 3.5

In IMS version 3.6 and later, a new scope of policies applicable to machines in an enterprise has been introduced on the IMS Server. These machine policies can be configured via AccessAdmin. As with policies in other scopes, changes in these policies are propagated to clients the next time AccessAgent synchronizes with the IMS Server (for example, usually every 30 minutes). IMS applies machine policies to machines after they join the IMS Server, they are then automatically synchronized with AccessAgent. There can be several machine policy templates defined in IMS. One of these templates is set as default. Through AccessAdmin, machine policies can be modified by an administrator. However, a help desk officer can only view machine policies.

Machine policy templates assignment

A machine policy template refers to a set of policies that govern the behavior of the machine. In any enterprise, there are bound to be machines that serve as personal workstations, shared workstations, and so on, access to which might have to be strengthened using a second factor authenticator like RFID, biometrics, and so on. Since there are different requirements from different machines, the IMS permits you to create several machine policy templates. Since there are multiple templates, there has to be a definite way of assigning a specific template to a machine. The IMS AccessAdmin provides you with the ability to specify this assignment based on several attributes of the machine, such as: AccessAgent version IP Address Hostname Active Directory Group Machine Group Tag

Drivers for choosing a specific template assignment criterion

Machine policy template criteria can be mixed and matched using the any or and operators. The typical drivers for choosing specific criteria are explained in the following paragraphs.

Assignment based on AccessAgent versions

Machine policies are specified on the IMS, but interpreted and enforced by the AccessAgent. A deployment might have several versions of AccessAgents. Consequently, it might be possible for a newer version of the IMS to specify a policy that cannot be interpreted and enforced by an older version of the AccessAgent. In cases such as these, we would choose the policy template with the new policy to be assigned only if the AccessAgent version matches a specific one.

Assignment based on hostnames

Some organizations use hostnames to enforce and identify the function of a machine. For instance, an organization may specify all their Citrix Servers to begin with the string ctx-, and their shared workstations to begin with shared-. In deployments such as these, assignments based on hostnames would be recommended. A caveat to note here is that if the hostname of the PC is changed (resulting in a new template assignment), the template assigned to it would have to be changed manually.

Assignment based on IP addresses

While this has not been widely seen, some organizations have a functional requirement of managing machines based on their IP subnets. In such cases, managing the machine policy templates is also a function that needs to be implemented at the subnet level. This would be the typical situation where you would need to assign templates based on IP addresses. A
IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0 Migration Guide for Encentuate 3.4 and 3.5

19

caveat to note here is that if the IP address of the machine changes (resulting in a new template assignment), the template assigned to it would have to be changed manually.

Assignment based on Active Directory groups

This would be the recommended best practice for machine policy template assignment. The basic driver for this type is centralized Active Directory enforced templates. Most organizations typically have machines organized into groups already, or have them stored in organizational units in the Active Directory. This mechanism makes use of this infrastructure to implement the assignments. Note that if the machine's group is changed (resulting in a new template assignment), the machine policy template assigned to it does not change automatically. Either the machine must be deleted from the IMS via AccessAdmin, or the new template must be explicitly assigned to it. On synchronization, the template will come into effect on the local AccessAgent.

Assignment based on Machine Group Tag

In deployments without Active Directory and without the infrastructure to manage computers centrally, an organization can use the Machine Group Tag to assign policies. This tag essentially is a registry setting called MachineTag that the AccessAgent uses to resolve what policy template to download from the IMS Server. As with the other assignments, templates assigned to a machine will not be updated dynamically if this registry setting is changed. The organization would need to delete the machine from the IMS Server and re-synchronize. For detailed information on how to specify the machine policy template assignments, refer to the section Applying policy templates to machines under Policy template management in the Administrator Guide. You can access this information through the Tivoli Access Manager for Enterprise Single Sign-On, Version 8.0.1 Information Center at the following Web location: http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/ concepts/Policies_Templates_Applying_Machines.html

Upgrade steps from Version 3.5 to 3.6/8.0

The IMS Servers are always designed to be backward compatible. This typically means that a current IMS Server has the ability to work with the current version of AccessAgent, and also with older versions of the AccessAgents. Consequently, this architecture necessitates a specific sequence of upgrades for the components, with the IMS Server being the first to be upgraded. The steps involved in upgrading the deployment are the following: Back up the existing setup. Upgrade the IMS Server to v8.0. Upgrade the AccessAgents in the deployment to v8.0 (incrementally).

Back up the existing setup

The IMS server is a typical application server with a database tier. As with other such systems, a backup essentially involves two activities: Backup of the database Backup of the application server's configuration

Database backup
A complete backup of the database is recommended before proceeding. This ensures that the data and configurations are not lost in the event of an unexpected malfunction.

20

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0: Migration Guide for Encentuate 3.4 and 3.5

For MS SQL server, it is recommended that you store the MDF (data) and LDF (transaction log) files to the backup folder, in addition to taking a standard SQL backup. The SQL files by default are stored in: C:\Program Files\Microsoft SQL Server\MSSQL\Data

IMS Server configuration backup

The IMS configuration files are located in the IMS installation folder under: $IMS INSTALL DIR$\ims\config This entire folder has to be backed up. This includes several files critical to the installation.

Upgrading the IMS Server

Due to the introduction of the machine policy template (MPT) the upgrade from v3.5 to v8.0 involves, in addition to the typical installer-based upgrade, the creation and assignment of the MPTs. The following sections provide the pertinent details.

Executing the IMS installer to upgrade

The first step is to use the IMS Server v8.0 installer to upgrade the server. Typically, this involves going through the usual steps required to upgrade the IMS from an older version to a newer version. For details on these steps, refer to the Tivoli Access Manager for Enterprise Single Sign-On Information Center Administrator Guide. http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/ tasks/IMS_Installation_Upgrading_existing_IMSServer_installation.html

Creation of machine policy templates

Before version 3.6, the machine policies were stored in the Windows registry at this location: HKEY_LOCAL_MACHINE\Software\Encentuate\DeploymentOptions The values defined in this registry hive would define the behavior of the machine and classify it as a personal workstation, shared workstation (shared or private desktop), Citrix workstation, and so on, along with the policies related to the second factors the PC would support. Since these machine policy templates are now defined on the server, you need to translate these registry settings (policies) to their equivalents on the IMS Server AccessAdmin. You have to create a machine policy template for each type of workstation used in the deployment. For guidance on translating the registry settings to their policy equivalents on the IMS Server refer to Definitions of Policies in the Tivoli Access Manager for Enterprise Single Sign-On Information Center Administrator Guide. http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/ common/policies_definitions.html Once the registry settings have been translated, the machine policy templates must be created. For details on the creation of these templates, refer to the Tivoli Access Manager for Enterprise Single Sign-On Information Center Administrator Guide. The section Policy Template Management explains how to create a new machine policy template. http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/ references/Policies_Templates_Management.html

Assignment of machine policy templates

Along with the creation of these templates, you also need to specify the assignment criteria. Depending upon the assignment criteria chosen, changes in the existing IT infrastructure might be needed.
IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0 Migration Guide for Encentuate 3.4 and 3.5

21

Upgrading the AccessAgents

After the server has been upgraded and the machine policy templates with their assignments created, the AccessAgents can be incrementally upgraded according to the deployment upgrade plan. The details of upgrading (installation) of the new AccessAgents can be found in the Tivoli Access Manager for Enterprise Single Sign-On Information Center Administrator Guide in the section AccessAgent Installation. This section provides details on manual as well as push installations that can leverage your existing software distribution infrastructure. http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/ references/AA_Installation_intro.html

Summary
While this document presents the details of a standard v3.4 to v8.0 upgrade, it is important to keep in mind that certain environments may or may not 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. A typical recommendation would be to have at least one test or development environment. This test environment should be an accurate reflection of the production environment and should take into account, to a reasonable extent, the database size, server hardware, PC configuration (antivirus, and so on) and other variables.

The team who wrote this paper

This paper was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center. Axel Buecker is a Certified Consulting Software IT Specialist at the International Technical Support Organization, Austin Center. He writes extensively and teaches IBM classes worldwide on areas of Software Security Architecture and Network Computing Technologies. He holds a degree in Computer Science from the University of Bremen, Germany. He has 23 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. Archit Lohokare is a Managing Consultant with the IBM Tivoli SoftWare Advanced Technology (SWAT) organization. At IBM, he provides technical sales expertise to drive the adoption of IBM Tivoli Solutions in customer engagements worldwide and also partners with IBM sales, IBM business partners, and consulting teams on complex and strategic business opportunities in the identity and access management space. Archit holds a B.Eng degree from Nanyang Technological University, Singapore. Prior to joining IBM, he worked for Encentuate, Inc., which was acquired by IBM in March 2008. Thanks to the following people for their contributions to this project: Alison Chandler International Technical Support Organization, Poughkeepsie Center Linda Chang, Chiang Kai Er, James Keenan, Chee Meng Low IBM 22
IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0: Migration Guide for Encentuate 3.4 and 3.5

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.

Copyright International Business Machines Corporation 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.

23

This document REDP-4615-00 was created or updated on December 17, 2009. Send us your comments in one of the following ways: Use the online Contact us review Redbooks form found at: ibm.com/redbooks Send your comments in an email to: redbooks@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400 U.S.A.

Redpaper

Trademarks
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:
DB2 IBM IMS Redbooks Redpaper Redbooks (logo) Tivoli

The following terms are trademarks of other companies: Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation and/or its affiliates. Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.

24

IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0: Migration Guide for Encentuate 3.4 and 3.5