ibm tivoli access manager for enterprise single sign-on v8.0 migration guide for encentuate 3.4 and...

7/31/2019 IBM Tivoli Access Manager for Enterprise Single Sign-On v8.0 Migration Guide for Encentuate 3.4 and 3.5 Redp4615

1/24

Copyright IBM Corp. 2009. All rights reserved. ibm.com/redbooks 1

Redpaper

IBM Tivoli Access Manager for Enterprise

Single Sign-On v8.0Migration Guide for Encentuate 3.4 and 3.5

IBM Tivoli Access Manager for Enterprise Single Sign-On enables organizations toautomate access to corporate information, strengthen security, and enforce compliance at the

endpoints. With Tivoli Access Manager for Enterprise Single Sign-On, organizations canefficiently manage business risk, achieve regulatory compliance, decrease IT costs, and

increase user efficiency. Tivoli Access Manager for Enterprise Single Sign-On delivers thefollowing 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 featureset 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 automatedand 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 forEnterprise Single Sign-On.

1 Encentuate was the company that or iginally developed this application. They were acquired by IBM Tivoli Software

and the application was renamed to Tivoli Access Manager for Enterprise Single Sign-On.

Axel Buecker

Archit Lohokare
http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/


2/24

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

Planning the migration

This document should be consulted as part of the first stage of migration planning. It isimportant to note that with Tivoli Access Manager for Enterprise Single Sign-On, there maybe 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 severalcomponents. An overview of the basic architecture is shown in Figure 1.

Figure 1 Deployment architecture

IMS servers

TheIntegrated Management System (IMS) server provides administrative, reporting, helpdesk, and password reset functionality, as well as being the repository for user data.

AccessAdmin and AccessAssistant are the tools used to provide management andreporting 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-Oncurrently 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.


3/24

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

The following components are not part of the Tivoli Access Manager for Enterprise SingleSign-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 forEnterprise Single Sign-On to validate users during the registration process for SSOservices. 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 themobility 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 Managerfor Enterprise Single Sign-On. Client communication over unsecured HTTP is only usedduring 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 Managerfor 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 theIMS server to v3.5, and subsequently to v8.0. The AccessAgents, however, can be directlyupgraded 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 havecompleted 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 singledomain, whereas v3.5 supports multiple domains.

To enable this design, a new configurationActiveDirectory (AD) Deployment Type wasintroduced. For IMS Server versions prior to 3.5.0, support for Active Directory (AD) as the


4/24


enterprise directory can be configured to use AD deployment type 1 or 2. In an ADdeployment 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. Ifuser 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 ADdeployment type 2 configurations.

IMS Server upgrade steps

As a first step you need to check whether the enterprise directory is configured to use theActive 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 athttp://:8080

Figure 2 The IMS v3.4 configuration utility


5/24


2. Go to Basic SettingsEnterprise Directories (Figure 3). Select the enterprisedirectory 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 isActive Directory (ADSI) Connectoror theActive Directory(LDAP) Connector. If it is the latter, click the Delete Connector button and then proceedto 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.


6/24


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 changedto type 2 and the users have been migrated as well.


7/24


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


8/24


7. In the next panel scroll down to Application connector configuration. In the Basicconfiguration keys section select DNS for the domain type to be shown in AccessAgent, asshown 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.


9/24


9. Stop the IMS Server by clicking StartAll ProgramsEncentuate IMS ServerStop IMSService (Figure 9).

Figure 9 Stopping the IMS Service

10.Start the IMS Server by clicking StartAll ProgramsEncentuate 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 inFigure 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.2or later.


10/24


Once that is done, you can switch back to using the NetBIOS domain by performing thefollowing steps:

1. Launch the IMS Server Configuration utility.

2. Go to Basic settingsEnterprise 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 StartAll ProgramsEncentuate IMS Server

Stop IMSService.

7. Start the IMS Server by clicking StartAll ProgramsEncentuate IMS ServerStart 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 theAccessAdmin application. To access the applicable user policy template click the specific

link in the User Policy Templates section in AccessAdmin; in our case that isDefault.Once Password is selected in the Authentication Policies section, as shown inFigure 11, scroll all the way down and click Update.

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


11/24


2. Search for a user to whom the policy has to be reapplied. If you search for a particularuser, 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 ofusers. 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


12/24


3. Scroll down to the bottom of the user profile page, select the appropriate user policytemplate, 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


13/24


5. In the users found list that is displayed in Figure 15, select the users you want to applythe 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 whenAD 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 ADdeployment 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 versionsprior 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 inAD deployment type 2.

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 followingmeasures should be taken before upgrading the IMS server:

1. Before upgrading to deployment type 2, replace [dbowner] and [Authentication serviceID linked to enterprise directory] accordingly and run the SQL script in Example 1against the IMS Server database.

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 withapplications 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 differentlogon name. Other than confusing the user, the multiple account data can go out of sync

when the user changes his AD or Encentuate password.


14/24


Example 1 SQL upgrade script

UPDATE [dbowner].IMSTemplatedSyncRepoSET isDeleted = 1, updateTimeStamp = GETDATE()WHERE (attrName = 'account_data') AND (entityTypeID = 'scp_user') AND (keyValueLIKE '%>' + '[Authentication service ID linked to enterprise directory]' +'' +

(SELECT attrValueFROM [dbowner].IMSIdentityUniqueAttribute BWHERE entityID = B.imsID AND attrName = 'Enterprise Login') + '


15/24


2. Use the XML editor in AccessStudio to add the attribute wnd_should_be_enabled="0" to allwnd_xpath_combo_box_indirect_auth_info nodes in the sso_site_gina_winlogonAccessProfile 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


16/24


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 isbest to enforce no changing of AD and Encentuate passwords until all AccessAgent clientshave been upgraded. After all AccessAgent clients have been upgraded, replace [dbowner]and [Authentication service ID linked to enterprise directory] accordingly and runthe SQL script shown in Example 2 against the IMS Server database.

Example 2 SQL update script

UPDATE [dbowner].IMSTemplatedSyncRepoSET isDeleted = 1, updateTimeStamp = GETDATE()WHERE (attrName = 'account_data') AND (entityTypeID = 'scp_user') AND (keyValueLIKE '%>' + '[Authentication service ID linked to enterprise directory]' + '' +(SELECT attrValueFROM [dbowner].IMSIdentityUniqueAttribute BWHERE entityID = B.imsID AND attrName = 'Enterprise Login') + '


17/24


this functionality, additional services are needed to implement the virtual channel functionalityon-site.

The reduced Citrix functionality and corresponding workarounds are summarized in thefollowing 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 settingpid_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 SingleSign-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 settingpid_en_network_provider_enabled to 1 so that the Windows credentials will be used tolog on to AccessAgent.

There will be no immediate synchronization between a local AccessAgent on a users PCand 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 AccessAgentsautomatic sign-on functionality will not be disabled automatically.


Remote AccessAgent will not be informed when the user logs out of the localAccessAgent 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 thelocal 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 whetherthe 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 sameright-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 localAccessAgent exists, and thus will always display the full menu. The user will, however, beable 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 ifthe network connection is poor. In that case, the thin client may automatically reconnectback 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 knowwhether this is a thin client scenario, it will not automatically perform logoff.



18/24


Cannot disable launching of remote AccessAgent even when local AccessAgent is notpresent.

Currently, the launching of remote AccessAgent while a published application is launchedthrough Terminal Server can be disabled if local AccessAgent is not present by settingpid_ts_start_aa_no_local_aa_enabled to 0. Without ICA channel support, remoteAccessAgent does not know whether local AccessAgent exists, and thus, will always be

launched.


Machine policy templatesIn IMS Server version 3.5 the concept of machine policies was non-existent on the server. Asillustrated 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. Thepackage consisted of a folder called Reg, which would contain a registry file calledDeploymentOptions.reg, which would be responsible for configuring the machine with thecorrect registry settings.


19/24


In IMS version 3.6 and later, a new scope of policies applicable to machines in an enterprisehas 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 toclients 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 thenautomatically 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 assignmentA 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 asecond factor authenticator like RFID, biometrics, and so on. Since there are differentrequirements 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 thisassignment 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 criterionMachine policy template criteria can be mixed and matched using the any or andoperators.

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 bepossible 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 choosethe 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-, andtheir shared workstations to begin withshared-. In deployments such as these, assignmentsbased on hostnames would be recommended. A caveat to note here is that if the hostname ofthe 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 policytemplates is also a function that needs to be implemented at the subnet level. This would bethe typical situation where you would need to assign templates based on IP addresses. A


20/24


caveat to note here is that if the IP address of the machine changes (resulting in a newtemplate 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 inorganizational units in the Active Directory. This mechanism makes use of this infrastructureto implement the assignments. Note that if the machine's group is changed (resulting in a newtemplate 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 newtemplate 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 computerscentrally, an organization can use the Machine Group Tag to assign policies. This tag

essentially is a registry setting calledMachineTagthat the AccessAgent uses to resolve whatpolicy 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. Theorganization 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 tothe section Applying policy templates to machines under Policy template management in

the Administrator Guide. You can access this information through the Tivoli Access Managerfor 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 acurrent 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 thecomponents, 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 setupThe IMS server is a typical application server with a database tier. As with other suchsystems, 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 thatthe data and configurations are not lost in the event of an unexpected malfunction.
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/concepts/Policies_Templates_Applying_Machines.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/concepts/Policies_Templates_Applying_Machines.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/concepts/Policies_Templates_Applying_Machines.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/concepts/Policies_Templates_Applying_Machines.html


21/24


For MS SQL server, it is recommended that you store the MDF (data) and LDF (transactionlog) 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 ServerDue to the introduction of the machine policy template (MPT) the upgrade from v3.5 to v8.0involves, 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 anewer 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 classifyit 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 wouldsupport.

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. Youhave 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 Serverrefer 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 forEnterprise 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 infrastructuremight be needed.
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/tasks/IMS_Installation_Upgrading_existing_IMSServer_installation.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/tasks/IMS_Installation_Upgrading_existing_IMSServer_installation.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/common/policies_definitions.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/common/policies_definitions.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/references/Policies_Templates_Management.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/references/Policies_Templates_Management.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/references/Policies_Templates_Management.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/common/policies_definitions.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/references/Policies_Templates_Management.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/common/policies_definitions.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/tasks/IMS_Installation_Upgrading_existing_IMSServer_installation.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/tasks/IMS_Installation_Upgrading_existing_IMSServer_installation.html


22/24


Upgrading the AccessAgentsAfter the server has been upgraded and the machine policy templates with their assignments

created, the AccessAgents can be incrementally upgraded according to the deploymentupgrade 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 thesection 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 upgradeand 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, PCconfiguration (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 theInternational 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 classesworldwide 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 23years 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 theadoption of IBM Tivoli Solutions in customer engagements worldwide and also partners withIBM 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 degreefrom 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 ChandlerInternational Technical Support Organization, Poughkeepsie Center

Linda Chang, Chiang Kai Er, James Keenan, Chee Meng LowIBM
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/references/AA_Installation_intro.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/references/AA_Installation_intro.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itamesso.doc/references/AA_Installation_intro.html


23/24

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

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. Consultyour local IBM representative for information on the products and services currently available in your area. Anyreference 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 notinfringe any IBM intellectual property right may be used instead. However, it is the user's responsibility toevaluate 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. Thefurnishing of this document does not give you any license to these patents. You can send license inquiries, inwriting, 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 suchprovisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATIONPROVIDES 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 ofexpress 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 madeto the information herein; these changes will be incorporated in new editions of the publication. IBM may makeimprovements and/or changes in the product(s) and/or the program(s) described in this publication at any timewithout notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in anymanner serve as an endorsement of those Web sites. The materials at those Web sites are not part of thematerials 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 incurringany obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their publishedannouncements or other publicly available sources. IBM has not tested those products and cannot confirm theaccuracy of performance, compatibility or any other claims related to non-IBM products. Questions on thecapabilities 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 themas 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 businessenterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which illustrate programmingtechniques 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 applicationprograms conforming to the application programming interface for the operating platform for which the sampleprograms 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.


24/24

Redpaper

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:

[email protected] Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. HYTD Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400 U.S.A.

Trademarks

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business MachinesCorporation in the United States, other countries, or both. These and other IBM trademarked terms aremarked on their first occurrence in this information with the appropriate symbol ( or ), indicating USregistered or common law trademarks owned by IBM at the time this information was published. Suchtrademarks 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/orits 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.
http://www.redbooks.ibm.com/http://www.ibm.com/redbooks/http://www.redbooks.ibm.com/contacts.htmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.redbooks.ibm.com/contacts.htmlhttp://www.ibm.com/redbooks/http://www.ibm.com/redbooks/http://www.redbooks.ibm.com/

ibm tivoli access manager for enterprise single sign-on v8.0 migration guide for encentuate 3.4 and...

Documents