we are having eight siteminder policy servers that are connecting to same policystore and keystore. we don't have a seperate key store. So policystore and key store are together. when i take a smkeyexport on these policy servers i observed it's having two sets of agent keys.
So we are trying to clean up the key store based on this CA's KB article : How to Clean up a SiteMinder Key Store? - CA Knowledge . Currently we are having 1500 siteminder web agents that are connecting to these policy servers.So my questions are:
1) When we rollover the keys does siteminder agents needs a restart or they pick up changes automatically? (we are having siteminder web agents installed on IIS and IHS and Apache)
2) Do we need to roll over agent keys four times from adminui? (i mean there are four keys in one set)
3) Is it recommended to keep one policy server to generate agent keys and rest of policy servers don't generate agent keys? (I don't know how much this come into value when we are using static keys)
siteminder policy server: 12.52 SP1 CR06
siteminder web agent : 12.52 SP1 CR05
we are using static keys
policystore/keystore: oracle 12c
All replies are greatly appreciated.
If you see you have different values when you run smkeyexport using -c flag, then there is some problem as it does not align with the fact that you have been using Static keys from day-1.
If you have been using static key from the onset, then you need not follow the tech note of rolling multiple time. The Technote is for a case whereby you need to flush all your old keys, because of reasons stated (multiple PS generating Dynamic AgentKeys). When using Static Keys, you reset it only once and all 4 keys should be in sync.
When resetting keys, Agents pick the new keys on PSPoll and based on AgentCommand being present in PolicyServer Cache. If we restart we are rest assured that new keys are picked. If we don't restart, we should be able to still confirm by looking at the WebAgent.log as we'll see new key update / refresh entries.
I'd recommend keeping only one Policy Server designated to be as Key Generator irrespective of Dynamic OR static keys. One thing to consider it that this Policy Server should also be connected to WAMUI, to see the Keys link on WAMUI.
CA SSO : How policy server(s) will be synchronized?
Your target goal is to have one set of agent keys (with key marker 1-4 with all with the same value (when exported in clear text -c ).
Just like below :
objectclass: AgentKeyOid: 1b-e9bf02b0-4823-4259-a0cd-50af7e90f1b7KeyMarker: 3Key: iSvqiaMbslLW7n29IT4v4x4ttUM2yLcYobjectclass: AgentKeyOid: 1b-13173f02-270c-4841-b0a6-450917503980KeyMarker: 2Key: iSvqiaMbslLW7n29IT4v4x4ttUM2yLcYobjectclass: AgentKeyOid: 1b-f8ea756c-6698-4863-b641-a6eb17b5513cKeyMarker: 4Key: iSvqiaMbslLW7n29IT4v4x4ttUM2yLcYobjectclass: AgentKeyOid: 1b-5ef9041e-af7e-43f8-9a6a-61c042c41a46KeyMarker: 1Key: iSvqiaMbslLW7n29IT4v4x4ttUM2yLcY
As you can see here, the value for all the key is same "iSvqiaMbslLW7n29IT4v4x4ttUM2yLcY"
Ujwol => Agent doesn't need restart.
Ujwol => Once is enough if using static agent keys.
Ujwol => Yes, always keep only one PS to generate/manage keys.
Few more details on what these 4 different keys are :
Tech Tip : CA Single Sign-On:: Policy Server : Best practice on importing Agent Keys
we completed our production key store cleanup last saturday and it's successful. The reason for cleaning up our keystore is, we are having an integration in between CA API Gateway and CA SiteMinder policy server via Layer -7 agent.After the CA API Gateway upgraded from version 9.1 to 9.3 they are seeing the following errors more frequently.
After i open a support ticket with CA, Support Engineer identified additional keys in our keystore and suggested to clean up the keystore to see if that resolves the issue. But even after the keystore clean up our API Gateway team still seeing these kind of errors. Not sure why it's happening. can you please advise?
I am also including our API Gateway dashboard screenshot for reference. Red indicates failure attempts and Green indicates success.
But I am able to decode the SMSESSION by using webagent SDK.
Attribute name : DEVICENAMEAttribute value: ServerNameAttribute name : USERDNAttribute value: CN=XXXXX,OU=***,OU=***,DC=XXXX,DC=XXXX,DC=***Attribute name : SESSIONSPECAttribute value: Ly4LVWM1C6brHrbAAauzly1W3nkAf2khgsoFen6+dz9TfkD4he+6yfZDEurkdJBiJSGF61LodOAPwbXkCQpVUbNIwThx3QntMlHtLi6KBkJfizs0Xprg4Qbq+r+ZedSlHmEpPxrv6i60477Nc8D7GWH3bpYNRQFTu137KIngRfKH0YZH9va32DP/0AWtgQ3wuZxM0B7eIaL8AbNvJM7f4VbWjDnw/2AhHeJs9genJiPYd986sezgF/RsqdLlFOlfpSSLNVLALrNvBekMoboxaqhv2AYuhEbTyUycL1TU3dfRWZVKCF1wbDP3trqoqlJtEOyDhjijZBseZXBoQDlZUrCAOhQk2ohoS1CK6d5tgJGygtk+qCLQAaFDLrqCbZWoYXSU/x4VZLKQDwDr27L3aZPDBtNh73UNLsndupujYLlPkSM4d23kTzqL8YjTnk1ZQBgbqJ0+S0MdGcOuCLIE4bJOxJc0FEjP74MEtK+MtJvVw2w2b6AW0efLjKhZYXIKAttribute name : SESSIONIDAttribute value: 9P+B+6p3nPDoHYuFJZYQ3X5jdGk=Attribute name : USERNAMEAttribute value: CORPORATE\***Attribute name : CLIENTIPAttribute value: 10.86.191.30Attribute name : IDLESESSIONTIMEOUTAttribute value: 0Attribute name : MAXSESSIONTIMEOUTAttribute value: 622393886Attribute name : STARTSESSIONTIMEAttribute value: 1525089754Attribute name : LASTSESSIONTIMEAttribute value: 1525092508Attribute name : UNKNOWNAttribute value: SMUserID: CN=***,OU=XXXX,OU=XXXX,DC=XXXX,DC=XXXX,DC=***Session start time: 04/30/2018 07:02:34Last session time : 04/30/2018 07:48:28
Don't worry the XXXX's. Because it's a real user i masked those values. One Odd thing i noticed is the Max Session timeout value. It's very high.
We are also experiencing an issue like this after upgrading to API Gateway 9.3. It seems to be related to agent key rollover. If I re-register the siteminder configuration in the API gateway, it works again for a time. However, it appears that after a cert number of key rollovers the API Gateway loses its ability to perform authorizations against smsession cookies with the policy servers. It continues like this until I perform a re-registration.
I have a case open as well, and will update if I get any information.
We're running Siteminder (single sign-on) 12.7.
Thanks David. I also opened a Support ticket with CA regarding to this issue. Currently it's transferred to CA API Gateway team on CA Side. I will also update the discussion if i get any information.
Got an update from CA API gateway Support Engineer:
If "Idle Timeout" or "Maximum Timeout" at siteminder is not enabled (or even if they set to 0), we see Au or Az failures. If they are not enabled at siteminder, these values are set to 0. So when gateway is checking for the IdleTimeout, it always fails which is leading to Au/Az failures even though the session is just created/valid.
Also discovered this is a recent known issue DE343361 which is being addressed in CR
PRs request: 9.2 CR8 : Released march 2018
9.3 CR2 : Scheduled for release later this month
Work around for this issue: Configure the MAX/IDLE timeouts for the REALMS authentication
Currently CA released only two releases of CA API Gateway to customers. They are:
CA API Gateway 9.3
CA API Gateway 9.3 CR1
This defect is fixed in CA API Gateway 9.2 CR8 (Released march 2018) and CA API Gateway 9.3 CR2 (Scheduled for release later this month) . we are waiting for gateway 9.3 CR2 release so that we can update our systems to get rid of this issue.
That MaxSessionTimeOut is not right.
What value have you configured on the realm ?
Seems like if the IDLE TIMEOUT and Maximum Timeout is not specified in the realm configuration SiteMinder is taking idlesessiontimeout as 0 and maximumsessiontimeout as a high random value.
Upon decoding so many cookies with web agent SDK which are failing on API gateway side. I would say 85-90% of cookies are having idlesessiontimeout as zero and maximumsessiontimeout as a high random value. Not sure what's new introduced in CA API gateway 9.3 version. we don't have this issue with earlier versions of API gateway.