Ibm tivoli access manager for enterprise single sign on v8.0 migration guide for encentuate 3.4 and 3.5 redp4615

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.

1
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 1

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.

2 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 manufacturer’s 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 3

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


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.


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.


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


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.


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.


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


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


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


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 user’s 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.


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.


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


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 user’s 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


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 user’s 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 AccessAgent’s
automatic sign-on functionality will not be disabled automatically.
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.
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.


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.

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_MACHINESoftwareEncentuateDeploymentOptions

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.


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


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.


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 FilesMicrosoft SQL ServerMSSQLData

IMS Server configuration backup
The IMS configuration files are located in the IMS installation folder under:
$IMS INSTALL DIR$imsconfig

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.
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_MACHINESoftwareEncentuateDeploymentOptions

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.
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.
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.


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.

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


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® Redbooks® Tivoli®
IBM® Redpaper™
IMS™ Redbooks (logo) ®

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.


Ibm tivoli access manager for enterprise single sign on v8.0 migration guide for encentuate 3.4 and 3.5 redp4615

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Ibm tivoli access manager for enterprise single sign on v8.0 migration guide for encentuate 3.4 and 3.5 redp4615

Ähnlich wie Ibm tivoli access manager for enterprise single sign on v8.0 migration guide for encentuate 3.4 and 3.5 redp4615 (20)

Mehr von Banking at Ho Chi Minh city

Mehr von Banking at Ho Chi Minh city (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Ibm tivoli access manager for enterprise single sign on v8.0 migration guide for encentuate 3.4 and 3.5 redp4615