Existing r6.x Policy Servers can use an r6.x key store for key rollover, while r12.5 Policy Servers can use an r12.5 key store for key rollover. The following figure illustrates:
Important! If all key stores do not use the same Agent and Session keys, single sign–on fails.
Note: Although not illustrated, policy store and key store data can be replicated for failover. The database or directory server type determines how you replicate data. For more information about key management in a master/slave environment, see the Policy Server Administration Guide. For more information about replicating data, see your vendor–specific documentation.
You can configure an r12.5 environment independently of the existing environment. Install and configure the r12.5 components in the following order:
Important! If you are maintaining single sign–on with a common key store, all Policy Servers must use the same encryption key. If you do not know the value of the encryption key, you can reset the r6.x value in the policy store. Use the new value when installing r12.5 Policy Servers.
Note: For more information about resetting the policy store encryption key, see the Policy Server Administration Guide.
Note: For more information about installing a Policy Server, a policy store, an Administrative UI, and a Report Server, see the Policy Server Installation Guide. For more information about installing Web Agents, see the Web Agent Installation Guide.
If you are deploying a common key store, do the following or single sign–on fails:
Note: For more information about resetting the policy store encryption key, see the Policy Server Administration Guide.
Note: For more information about dynamically generating Agent keys, see the Policy Server Administration Guide.
Complete the following procedures to separate the key store from the policy store:
Note: If your environment uses static keys, this step is not required. However, be sure that a SiteMinder administrator does not generate a random agent key after you export the keys from the policy store.
Before the key store separation is complete, the r6.x environment is operating with two key stores:
Disabling dynamic agent key generation prevents a Policy Server from generating keys after you export them for the separate store. Stopping the Policy Server from generating keys prevents single sign–on issues that can occur when the keys are not synchronized in all stores.
Follow these steps:
The Policy Server is configured to use a static key. The Policy Server does not generate keys automatically.
You export the keys from the collocated policy/key store to make them available to the separate key store.
Follow these steps:
smobjectexport -ffile_name -x
Important! Before running a SiteMinder utility or executable on Windows Server 2008, open the command-line window with administrator permissions. Open the command-line window this way, even if your account has administrator privileges.
Note: For more information about these modes and arguments, see the r6.x Policy Server Installation Guide.
Example:
smobjexport -fagentkeys -x
The agent keys are exported from the collocated policy/key store.
You import the keys from the collocated policy/key store to make them available to the separate key store.
Follow these steps:
smobjimport -ffile_name -k
Important! Before running a SiteMinder utility or executable on Windows Server 2008, open the command-line window with administrator permissions. Open the command-line window this way, even if your account has administrator privileges.
Note: For more information about these modes and arguments, see the r6.x Policy Server Installation Guide.
Example:
smobjimport -fagentkeys -k
The agent keys are imported in to the separate key store.
Configuring all Policy Servers in the parallel environment to use a common r6.x key store maintains single sign–on across both environments.
Follow these steps:
If you disabled dynamic agent key generation, re–enable the functionality for the Policy Server that is nominated to generate agent keys. Complete this procedure only after all Policy Servers in the environment are configured to use the new key store.
Follow these steps:
The nominated Policy Server is enabled to generate keys dynamically.
You have completed the required tasks to separate the key store from the policy store.
If you are deploying multiple key stores, do the following or single sign–on fails:
Note: For more information about delegating administrator permissions, see the Policy Server Configuration Guide.
Note: For more information about configuring a static Agent key and session ticket, see the Policy Server Administration Guide.
If your environment contains one or more smkeydatabases, migrate their contents to the r12.5 certificate data store.
Follow these steps:
siteminder_home\config\properties
Specifies the Policy Server installation path.
smkeydatabase.properties
siteminder_home\config\properties
newsmkeydatabase.properties
Example:
The r6.x file references the following path:
DBLocation=C\:/Program Files/netegrity/siteminder/smkeydatabase
The r12.5 file references the following path:
DBLocation=C:/Program Files/CA/siteminder/smkeydatabase
Update the r6.x file to reference the following path:
DBLocation=C\:/Program Files/CA/siteminder/smkeydatabase
smkeydatabase
Example:
C:\Program Files\CA\SiteMinder\smkeydatabase
Note: The default location of this directory is siteminder_home.
smmigratecds
The migration is complete.
If you are managing legacy federation (Federation Security Services) objects in your r12.x environment, migrate the assertion issuer ID from the r12.x Producer to the r12.5 Producer. Migrating the ID prevents SAML 1.1 transactions from failing on the Service Provider.
Follow these steps:
siteminder_home\config\properties
Specifies the Policy Server installation path.
AMAssertionGenerator.properties
siteminder_home\config\properties
newAMAssertionGenerator.properties
The migration is complete.
If you plan on using the r12.5 deployment to protect r6.x resources, we recommend migrating your policy store data to the r12.5 policy store.
You can avoid the possibility of conflicts that are associated with duplicate objects by migrating policy store data before you begin managing the r12.5 policy store.
Follow these steps:
Note: For more information about the r6.x version of the smobjexport utility, see the r6.x Policy Server Installation Guide.
When moving SiteMinder policies from one environment to another, either as part of an upgrade or a policy migration, some objects that are environment–specific are included in the export file. Examples of these objects include:
Be sure that the SiteMinder user directory objects you create in both environments have the same names. If you use different names to point r6.x and r12.5 Policy Servers to the same user stores, single sign–on fails.
Copyright © 2012 CA Technologies.
All rights reserved.
|
|