Description:

How can I clean out the SiteMinder Key Store to ensure that there is only one set of 4 keys in use by all Agents?

Solution:

Cleaning out a SiteMinder Key Store requires that you; ensure that only one Policy Server in the environment is configured to generate Agent Keys, Roll the Agent keys to determine the correct set of keys to keep in the environment, delete the extra keys from the Key Store.
Care should be taken if performing these steps on a running Policy Server; deletion of the active keys will cause the Policy Server to stop and re-start.

Ensure only one Policy Server generates Agent Keys
In a Siteminder environment, only one Policy Server should be configured to generate Agent keys. If multiple Policy Servers are configured to generate Agent Keys and the keys are "Dynamic", then it is possible to end up with multiple sets of keys with each set containing different values.
There is no guarantee in which set of keys an Agent will utilize if more than one set is delivered from the Key Store on Agent start up. Multiple sets of Agent Keys in the key store can lead to decryption errors.

The steps are as follows:

1.) From the "Keys" Tab on the SMConsole of each Policy Server in the environment, ensure that only one Policy Server has the "Enable Agent Key Generation" check-box checked. 

After this, on the Policy Servers that are not going to Generate Keys, one must enable key updates in the SiteMinder Registry. On Unix and Linux systems this is a flat file. On windows it is in the SiteMinder Hive. The Hive location for Unix and Linux follows the Windows 32 bit format.

The Windows 32 bit location is: "HKEY_LOCAL_MACHINE\software\netegrity\SiteMinder\CurrentVersion\ObjectStore"

The Windows 64 bit location is: "HKEY_LOCAL_MACHINE\software\wow6432node\netegrity\SiteMinder\CurrentVersion\ObjectStore"

The Key Name is: "EnableKeyUpdate"

This key is Binary, 0 and 1 are the acceptable values. It's description is: "When a single Policy Server generates encryption keys in an environment with multiple Policy Servers that connect to disparate policy stores, but share a central key store, an additional registry setting is required. This registry setting configures each Policy Server to poll the common key store and retrieve new encryption keys at a regular interval."

Determine Keys to keep in the Environment

Synchronizing the keys to help determine which keys should be kept in the environment requires an smkeyexport of the Key Store to be taken for review, the Agent Keys need to be "Rolled" twice, and then a second smkeyexport of the Key Store is required for comparison.

2.) Take a Key Store Export. This is done at the command prompt with a command that will look like: smkeyexport-d<siteminderadminname> -w<siteminderadminpassword> -o<outputfilename>startingkeys.txt

3.) Roll the keys. It will be in a screen that looks like one of the two following pictures. On the left is the 6.x style screen. On the right is the 12.x style screen. This step is to isolate which keys are in use.

Note: If you are using static keys, you must fill out a value even if it is the same value.

4.) Roll the keys a second time. This step is to synchronize all Agents to one set of keys.

Note: If you are using static keys, you must fill out a value even if it is the same value.

5.) Take a Key Store Export. This is done at the command prompt with a command that will look like: smkeyexport -dsiteminderadmin -wsiteminderadminpassword -o<outputfilename>Newkeys.txt

6.) Compare the two outputs. You should see one set of 4 keys that is different between the two files. The difference will be the {RC2} value of the Key.

If this is not the case then please call in citing this knowledge base article and the error at this step for further assistance.

Deleting Extra Keys from the Environment

This is done in order to allow all agents in the environment to communicate with each other properly once more. At this point you can be sure that the agents are synchronized in keys, however there should be a short disturbance that will cause some people to login again. This can be done in one of two methods: deleting all keys or deleting select keys. If your Policy Servers are running you may only use the later method. If you can turn them off we suggest you do so and use the delete all keys method as it is less complex

Deleting All Keys:

7A.) If using a RDBMS, you may use your SQL or RDBMS commands to drop the data from the table.

7B.) If using LDAP, you may use the ldapmodify command or your GUI interface to sequentially select and delete all keys.

Deleting Specific Keys:

7C.) For RDBMS use the SQL commands to delete the keys that did not change between the two files.

Example command:

DELETE FROM smagentkey4 WHERE agentkeyoid '1b-4a79595f-9a40-1000-a34a-830cefdf0cb3'

Note: The example commands are for example only and will need to be modified for your environment.

7D.) For LDAP use the LDAPModify command to delete the keys that did not change between the two files.

Example command:

Note: the values are for illustration purposes only and will need to be modified for your environment.

* Save these two lines into a file (for instance, save as temp.txt file):
      dn: smAgentKeyOID4=1b-4a79595f-9a40-1000-a34a-830cefdf0cb3, ou=PolicySvr4,ou=SiteMinder,ou=Netegrity,o=ghost
      changetype: delete

* run the command:
      ldapmodify -D "cn=directory manager" -w dirmanagerpassword -h localhost -f "<path>\temp.txt"