Ok, seems like a lot of things happened overnight Between I am based on Australia , hence the delay in the reply.
Let me clarify few things here...
Sam said -"are you absolutely sure that when the 12.52 policy server was installed, the encryption key that was entered during installation is the same one that was entered back when the 12.0 server was installed"
Ujwol - I am sure they are the same. Had it NOT been the same , you will not be able to import the "encrypted" key export from r12.0 environment to r12.52.
You would have got error something like this during the import :"Unable to decrypt persistent key with policy store / key store key"
Duc said -"*From the Admin UI, all of the r12.0 policy servers are currently set to "Use Static Keys"
*From the SiteMinder Console, all of the r12.0 policy servers has the "Enable Agent Key Generation" checked"
Ujwol => This is NOT right. This is okayish only because you are using static Keys and do not have dynamic agent key rollover policy enabled . Had you been using dynamic agent keys, having multiple policy server to allow generating the agent keys would have created a lot of mess. I would strongly recommend to have only ONE policy server to have the "Enable Agent Key Generation" checked.
Duc said-"1) Should I click on the "rollover now" button under the "Randomly Generate Agent Key" or should I specify a key value?"
Ujwol => Either is fine. When you use "Randomly Generate Key" , it will use a a randomly generated value as a "seed" to generate Agent Keys. When you specify a Key value , it will use that specific string as the seed. If you choose to specify a key value , make sure you specify a non null/empty value, that is the key point here.
Duc said -"2) Should I click on "rollover now" four times back to back or wait for about a minute for all of the agents to update on each rollover occurrence?"
Ujwol => No need to wait, it can be done back to back. As I said earlier, there are 4 agent keys in one set and they are -
- KEY_UPDATE_PERSISTENT
- KEY_UPDATE_LAST
- KEY_UPDATE_CURRENT
- KEY_UPDATE_NEXT
The idea of 4 times rollover is to have a new value for each of these keys.
Duc said -"3) Same thing with the Session Ticket Key, should I generate a random value with the rollover or specify specific value?"
Ujwol => Either is fine.
Duc said-"This action did terminate any active SiteMinder sessions so any users that are currently login to a app that is protected by the policy server then their current session is lost"
Ujwol => This is expected as I explained before. The reason for this is , as the existing SMSESSION cookie are encrypted with the *old* agent keys, the Agent when they receive the new set of agent keys, they won't be able to decrypt the existing cookie.
Duc said -"When restarting the IIS web server the agent.log files indicate that it failed to talk to the policy servers. I tried everything from bouncing the web servers to even rebooting the IWA Windows server but the web agent still not load/communicated with the policy servers."
Ujwol =>This is ODD. Is this agent connected to the same policy server from where you rolled over the Agent Keys or different ? What is the value of PSPollInterval for this agent ? No matter what, rolling over of Agent Keys and Session Ticket Keys should NOT cause the communication failure with the Policy servers as this doesn't play any role with that.
If you have multiple policy server and common key store, you will also need to have following registry :
HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\ObjectStore\EnableKeyUpdate = 1
Do you have this set ?
Manage the Session Ticket Key - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation
When the Agent Keys are rolled over, you should expect following logs in your agent.log shortly after indicating that it received the new set of agent keys. Was there a much delay in getting this ?
[11665494/2057][Fri Feb 28 2014 22:19:37][CSmAdminManager.cpp:815][INFO] ADMIN: Received key update attribute 'KEY_UPDATE_PERSISTENT'.
[11665494/2057][Fri Feb 28 2014 22:19:37][CSmAdminManager.cpp:833][INFO] ADMIN: Successfully processed key update attribute 'PERSISTENT'.
[11665494/2057][Fri Feb 28 2014 22:19:37][CSmAdminManager.cpp:766][INFO] ADMIN: Received key update attribute 'KEY_UPDATE_LAST'.
[11665494/2057][Fri Feb 28 2014 22:19:37][CSmAdminManager.cpp:782][INFO] ADMIN: Successfully processed key update attribute 'LAST'.
[11665494/2057][Fri Feb 28 2014 22:19:37][CSmAdminManager.cpp:790][INFO] ADMIN: Received key update attribute 'KEY_UPDATE_CURRENT'.
[11665494/2057][Fri Feb 28 2014 22:19:37][CSmAdminManager.cpp:807][INFO] ADMIN: Successfully processed key update attribute 'CURRENT'.
[11665494/2057][Fri Feb 28 2014 22:19:37][CSmAdminManager.cpp:740][INFO] ADMIN: Received key update attribute 'KEY_UPDATE_NEXT'.
[11665494/2057][Fri Feb 28 2014 22:19:37][CSmAdminManager.cpp:757][INFO] ADMIN: Successfully processed key update attribute 'NEXT'.
Duc said -"Actually it appears that this effect is related to IIS web agents because two of our other applications that runs on IIS web servers also had the same problem after the agent key rollover so perhaps this key rollover effect only cause problems for the SiteMinder IIS web agents?"
Ujwol -> No, all the web agents are the same, there is no special logic for IIS agents.
Anyway, I believe now the SSO is working between r12.0 and r12.52 setup right ? Yeah, I think the key point was , most likely your r12.0 policy server were using null valued Agent Keys. I have seen this problem with one of my customer before, that was the reason for suggesting you to rollover the agent keys and session ticket keys to ensure none of them are null valued.