Installation and Upgrade Guides › SiteMinder Upgrade Guide › Upgrading from r12.x › How to Configure a Parallel Environment › Upgrade an r12.x Report Server › Multiple Key Store Deployment

Multiple Key Store Deployment

Existing r12.x Policy Servers can use an r12.x key store for key rollover, while r12.0 SP3 Policy Servers can use an r12.0 SP3 key store for key rollover. The following figure illustrates:

• r12.x Policy Servers connecting to an r12.x policy store.
• r12.0 SP3 Policy Servers connecting to an r12.0 SP3 policy store.
• r12.x Policy Servers connecting to an r12.x key store to retrieve new keys.
• r12.0 SP3 Policy Servers connecting to an r12.0 SP3 key store to retrieve new keys.
• A SiteMinder administrator using the Administrative UI to configure static Agent and Session keys for each key store.

  Important! If all key stores do not use the same Agent and Session keys, single sign–on fails.

• r12.x Web Agents polling their respective r12.x Policy Servers to retrieve new keys.
• r12.0 SP3 Web Agents polling their respective r12.0 SP3 Policy Servers to retrieve new keys.

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.

Create the r12.0 SP3 Environment

You can configure an r12.0 SP3 environment independently of the existing environment. Install and configure the r12.0 SP3 components in the following order:

1. One or more Policy Servers.

   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 r12.x value in the policy store. Use the new value when installing r12.0 SP3 Policy Servers.

   Note: For more information about resetting the policy store encryption key, see the Policy Server Administration Guide.

2. A policy store.
3. An Administrative UI.
4. One or more Web Agents.
5. A Report Server

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.

Common Key Store Single Sign–on Requirements

If you are deploying a common key store, do the following or single sign–on fails:

• Be sure that the r12.x policy and key store are configured separately:
  • If the r12.x environment is configured with a separate key store, leave the key store version at r12.x. r12.0 SP3 Policy Servers can communicate with an r12.x key store, but r12.x Policy Servers cannot communicate with an r12.0 SP3 key store.
  • If the r12.x environment is configured with a collocated policy/key store, separate the r12.x keys in to a separate r12.x key store.
• Leave the key store version at r12.x. r12.0 SP3 Policy Servers can communicate with an r12.x key store, but r12.x Policy Servers cannot communicate with an r12.0 SP3 key store.
• Configure all Policy Servers to use the common r12.x key store.
• Be sure that all Policy Servers use the same encryption key. If you do not know the value of the encryption key, you can reset the r12.x value in the policy store. Use the new value when installing an r12.0 SP3 Policy Server.

  Note: For more information about resetting the policy store encryption key, see the Policy Server Administration Guide.

• Nominate a single Policy Server to generate dynamic Agent keys. Disable Agent key generation for the remaining Policy Servers.

  Note: For more information about dynamically generating Agent keys, see the Policy Server Administration Guide.

More information:

Reset the r12.x Policy Store Encryption Key

How to Separate a Key Store from a Policy Store

Complete the following procedures to separate the key store from the policy store:

1. Install or locate a set–up Policy Server. A set–up Policy Server is a Policy Server that is not configured with the collocated policy/key store.
   • If a Policy Server is configured with the collocated store, you cannot use it to configure the new key store instance. The required SiteMinder utilities available on the Policy Server host system are configured to manage the collocated store.
   • The set–up Policy Server makes available a separate set of the required utilities. The separate set lets you configure the key store without interfering with the collocated store.
2. Use the set–up Policy Server host system to create a separate r12.x key store instance. Consider the following items:
   • The key store only requires the default policy store schema. For more information about configuring a separate key store, see the r12.0 SP3 Policy Server Installation Guide.
   • The key store does not require that you:
     • Set the SiteMinder superuser password.
     • Import the default policy store objects.
3. Disable dynamic agent key generation in the r12.x environment.

   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.

4. Export the agent keys from the r12.x policy/key store.
5. Import the agent keys in to the r12.x key store.
6. Configure all Policy Servers to use the separate key store.
7. If you disabled dynamic agent key generation, re–enable it.

Disable Dynamic Agent Key Generation

Before the key store separation is complete, the r12.x environment is operating with two key stores:

• Some Policy Servers use the agents keys in the collocated policy/key store.
• Some Policy Servers use the agent keys in the separate key store.

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:

1. Log in to the r12.x Administrative UI.
2. Click Administration, Policy Server.
3. Click Key Management, Agent Key Management.
4. Select the Use Static Agent Key option.
5. Click Submit.

   The Policy Server is configured to use a static key. The Policy Server does not generate keys automatically.

Export the Agent Keys

You export the keys from the collocated policy/key store to make them available to the separate key store.

Follow these steps:

1. Log in to a r12.x Policy Server host system. Be sure that this Policy Server is configured with the collocated policy/key store.
2. Run the following command to export only the keys from the policy store:

   smkeyexport -dadministrator -wpassword -ofile_name
   

   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 the utility, see the r12.x Policy Server Administration Guide.

   Example:

   smkeyexport -dsuperuser -wpassword -oagentkeys
   

   The agent keys are exported from the collocated policy/key store.

3. Copy the file that contains the agent keys to the set–up Policy Server host system.

Import the Agent Keys

You import the keys from the collocated policy/key store to make them available to the separate key store.

Follow these steps:

1. Log in to the r12.x set–up Policy Server host system.
2. Run the following command to import the agent keys in to the separate key store:

   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 r12.x Policy Server Administration Guide.

   Example:

   smobjimport -fagentkeys -k
   

   The agent keys are imported in to the separate key store.

Configure all Policy Servers to use the Key Store

Configuring all Policy Servers in the parallel environment to use a common r12.x key store maintains single sign–on across both environments.

Follow these steps:

1. Identify the Policy Server that is nominated to generate agent keys dynamically. Configure this Policy Server with the key store last.
2. Complete the following steps for all other Policy Servers in the environment:
   1. Log in to the Policy Server host system.
   2. Open the Policy Server Management Console.
   3. Click the Data tab.
   4. Select Key Store from the Database list and clear the Use Policy Store database option.
   5. Select the key store type from the Storage list.
   6. Complete one of the following steps:
      • (LDAP) Enter the required connection information in the LDAP Key Store section.
      • (ODBC) Enter the data source information in the Data Source Information section.
   7. Test the Connection.
   8. Click OK.
   9. Restart the Policy Server to configure the Policy Server to use the key store.
3. Configure the Policy Server that is nominated to generate agent keys to use the key store.

Re–enable Dynamic Agent Key Generation

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:

1. Log in to the r12.x Administrative UI.
2. Click Administration, Policy Server.
3. Click Key Management, Agent Key Management.
4. Select the Use Dynamic Agent Key option.
5. Click Submit.

   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.

Multiple Key Store Single Sign–on Requirements

If you are deploying multiple key stores, do the following or single sign–on fails:

• Disable dynamic Agent key generation for all Policy Servers.
• Be sure that a SiteMinder administrator has the necessary Administrative UI permissions to specify the same static Agent key and the same session ticket in the r12.x and r12.0 SP3 key stores.

  Note: For more information about delegating administrator permissions, see the Policy Server Configuration Guide.

• Be sure that the same static Agent key and the same session ticket are configured in the r12.x and r12.0 SP3 key stores.

  Note: For more information about configuring a static Agent key and session ticket, see the Policy Server Administration Guide.

Migrate the r12.x Policies

If you plan on using the r12.0 SP3 deployment to protect r12.x resources, we recommend migrating your policy store data to the r12.0 SP3 policy store.

Although not required, if you migrate the policy store data before you begin managing the r12.0 SP3 policy store, you can avoid the possibility of conflicts associated with duplicate objects.

To migrate policies

1. Use the r12.x version of the XPSExport utility to export the r12.x policy store data. For more information about the r12.x version of XPSExport, see the r12.x Policy Server Administration Guide.
2. Use the r12.0 SP3 version of the XPSImport utility to import the policy data into the r12.0 SP3 policy store. For more information about the r12.0 SP3 version of XPSImport, see the Policy Server Administration 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:

• Trusted hosts
• HCO Policy Server settings
• Authentication scheme URLs
• Password services redirects
• Redirect responses

Depending on the mode you select when using XPSExport, these objects may be added to the new environment or can overwrite existing settings. Be sure that you do not adversely affect environment settings when importing the objects.

Note: For more information about the XPSExport modes of export, see the Policy Server Administration Guide.

User Directory Single Sign on Requirements

Be sure that the SiteMinder user directory objects you create in both environments have the same names. If you use different names to point r12.x and r12.0 SP3 Policy Servers to the same user stores, single sign–on fails.