Symantec Access Management

 View Only
Expand all | Collapse all

CA SSO : How policy server(s) will be synchronized?

Jump to Best Answer
  • 1.  CA SSO : How policy server(s) will be synchronized?

    Posted Jan 09, 2018 05:13 AM

    Hi,

     

    Assume that I have 5 policy servers sharing the common policy store. If one policy server modifies the policy store,

     

    1. How other policy servers will be communicated (to flush the cache) and how to control the time taken for this sync?
    2. I am aware that web agent will be notified to flush the cache while polling (PSPollInterval), but which policy server does web agent poll? Will it poll same policy sever (every time) or different policy servers (depending on HCO configurations)?

     

    Thanks.

     

    Regards,

    Dhilip



  • 2.  Re: CA SSO : How policy server(s) will be synchronized?



  • 3.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Jan 10, 2018 08:53 AM

    Hi Hubert,

     

    Thanks for sharing many useful links.

     

    Regarding 1,

    1. where journal entries will be stored/saved?
    2. How to control the path of the journal file?

     

    Regarding 2,

    I could see/understand the following lines in/from shared articles.

     

    In Kim's blob => LLAWP.exe would contact HCO listed Policy Server every 30 seconds.

     

    In Ujwol's blob => In load balancing mode, the request will  be served by the different policy servers (best server algorithm will be used for selection of server) 

     

    Kim has used only one PS in HCO (in shared article) resulting in using same channel. I would like to know how the behavior will be for 5 PS (in Load balancing mode).

    1. Will web agent poll different policy servers?
    2. What are the list of objects (Realm, Agent keys etc..) that will be considered during this check/validation? 
    3. How this validation will be performed? How policy server will be aware of current details in agent caches? Could you please explain in detail?

     

    Thanks.

     

    Regards,

    Dhilip



  • 4.  Re: CA SSO : How policy server(s) will be synchronized?
    Best Answer

    Posted Jan 10, 2018 11:12 AM

    Regarding-1 : 

    1. Refer Description below.
    2. No it cannot be controlled by us other than the Policy Store Root which is controlled by what we specify when initializing a Policy Store.

     

    The word "Journal" is an arbitrary word used to represent the ServerCommand Object which is stored in Policy Store. Any changes that we do on WAM UI or XPSExplorer to an Object, generates a ServerCommand. It is the ServerCommand entry in PolicyStore which tells the Policy Server that there are updates to be made to the Policy Server Cache. The ServerCommand also tell the Policy Server which Object needs to be refreshed. Here is an example of how we can see ServerCommands in Policy Store. We can use LDAP Browser OR LDAP Expression. In this example I modified a Rule and added OPTION. See the ServerCommand that gets generated.

     

     

    NOTE : 

    • smServerCommandOID : Even ServerCommand is a Object in Policy Store. Hence has a unique OID of their own. They start with 13-xxxxxxxxxxxxxxxxxxxxxx.
    • smTimeStamp4 : A Siteminder generated value (This is not a visible Clock Timestamp, but believe it is epoch time). The Siteminder time stamp in seconds (if ServerCmdMsec=0x1 this include milliseconds) and I believe this is what the PS sorts by. With ServerCmdMsec=0x2 we should not see any 2 commands with the same value.
    • smCommandData : The Object which needs to be updated / deleted / refreshed.
      • Here in this Example
      • 0b-****************** is the Rule. All Rules start with 0b-
      • 03-****************** is the Domain. All Domain's start with 03-
    • smCommand : Instructs Policy Server what Action to be taken
      • Example 
      • smCommand: 6   ----- Update Cached OID.
      • smCommand: 5   ----- Flush Realm.
      • smCommand: 7   ----- Delete Cached OID.

     

     

    Regarding-2 : 

     

    1. Will web agent poll different policy servers?
      1. Answer : Yes.
      2. Answer : During Startup the Policy Servers defined in SmHost.conf is used for bootstrap. This is sequential i.e. Try 1st, then 2nd, then 3rd...
      3. Answer : Once LLAWP is up and running (thus HCO was downloaded successfully), It would connect based on Clustered HCO or Standard HCO (Refer to Ujwol's blog).
    2. What are the list of objects (Realm, Agent keys etc..) that will be considered during this check/validation?
      1. Answer : The Resource Cache and Session Cache is updated by virtue of Normal Priority Requests (i.e. IsProtected / IsAuthenticated / IsAuthorized).
      2. Answer : The ACO Updates, HCO Update (DynamicHCO), Flush Cache, Agent Key updates are handled by the DoManagement Calls. Refer details below.
    3. How this validation will be performed? How policy server will be aware of current details in agent caches? Could you please explain in detail?
      1. Answer : The Policy Server never keeps track of Agent Cache. The Agent Cache is local to WebAgent.
      2. Answer : Some ServerCommand's convey information that has to be carried over to the various agents. In order to achieve that, when persisting the ServerCommand object, an Agent Command is generated, buffered and scheduled to be saved within 15sec (configurable by JournalRefresh in sec). Every 10sec (configured by ServerCmdDelay), the Management Thread on Policy Server goes through the list of Agent Commands scheduled to be saved, and if their scheduled time was reached, saves them. The purpose of Agent Commands is that information will be delivered to the agent instances, regardless of which Policy Server they are connected to. Policy Server maintains a cache of AgentCommands read from the Policy Store. Policy Server will search the Policy Store every 15sec (configurable by JournalRefresh, in sec) searching for new Agent Commands. Every Agent Command object has a timestamp. The timestamp’s granularity is seconds. Agents use the DoManagement API call to poll the Policy Server for the list of new agent commands. The Agent keeps an indicator of which commands where processed and which ones are new, by keeping the timestamp of the last agent command it received (called Management Timestamp). When starting up, the Agent will send a timestamp of 0, indicating to the Policy Server that it has just started up. Policy Server replies by sending the list of current agent keys along with the time of the latest agent command it has in its cache. The agent then poll the Policy Server every 30 sec (Configured by the ACO parameter PollInterval, in sec) using the DoManagement call. PS will respond to the DoManagement call (in particular the GetAgentCmd request) by sending the list of Agent Command objects newer than the agent’s ManagementTime.
      3. Answer : As an example I updated the ACO parameter TraceLogFileSize. I first was able to see ServerCommand Object in Policy Store for my ACO modification. After 30 to 40 seconds, a corresponding AgentCommand Object was generated in the Policy Store. Refer below screenshot.

     

     

     

     

    Lastly, if the Policy Server Tracing is configured correctly, we can see the Cache Updates.

     

    It would be very helpful to enable PS trace logging for ServerGeneral, i.e. (from smtracedefault.txt) and monitor the trace logs for Policy Server.
    components: Server/Policy_Object, Server/Policy_Server_General
    data: PreciseTime, SrcFile, Function, Message, ReturnValue, HexadecimalData, Data, ObjectOID, ErrorValue, ErrorString, ObjectClass, Tid

     

    [03:48:24.150][SmObjProvider.cpp:991][CSmObjProvider::Save][Saving 'ServerCommand' object.][][][][13-000dee3f-a254-1cdf-9e95-b16e8a2ac054][][][ServerCommand][3023559568]
    [03:48:24.171][SmObjProvider.cpp:991][CSmObjProvider::Save][Saving 'AgentCommand' object.][][][][14-00024cd1-a258-1cdf-9e95-b16e8a2ac054][][][AgentCommand][3023559568]
    [03:48:30.240][SmObjProvider.cpp:900][CSmObjProvider::Fetch][Fetching 'Domain' object with oid][][][][03-0005d073-4a10-1cde-b115-b16e8a2ac054][][][Domain][3023559568]
    [03:48:30.246][SmObjProvider.cpp:900][CSmObjProvider::Fetch][Fetching 'Policy' object with oid][][][][04-000a4dd4-4d3b-1cde-b115-b16e8a2ac054][][][Policy][3023559568]
    [03:48:49.567][SmObjStore.cpp:471][ManagementThread][Processing 13 server commands][][][][][][][][3023559568]
    [03:48:49.567][SmObjProvider.cpp:900][CSmObjProvider::Fetch][Fetching 'ServerCommand' object with oid][][][][13-000b7e0a-a24d-1cdf-9e95-b16e8a2ac054][][][ServerCommand][3023559568]
    [03:48:49.568][SmObjProvider.cpp:900][CSmObjProvider::Fetch][Fetching 'ServerCommand' object with oid][][][][13-000c5df5-a254-1cdf-9e95-b16e8a2ac054][][][ServerCommand][3023559568]
    [03:48:49.569][SmObjProvider.cpp:900][CSmObjProvider::Fetch][Fetching 'ServerCommand' object with oid][][][][13-000bee96-a24e-1cdf-9e95-b16e8a2ac054][][][ServerCommand][3023559568]
    [03:54:27.742][SmObjProvider.cpp:900][CSmObjProvider::Fetch][Fetching 'ServerCommand' object with oid][][][][13-000cc9c2-a3ab-1cdf-9e95-b16e8a2ac054][][][ServerCommand][3002923920]
    [03:54:27.743][SmObjStore.cpp:672][ManagementThread][Processing server command: DeleteOid][][][][0b-0004cffe-8039-1cdf-be8e-b16e8a2ac054/03-0005d073-4a10-1cde-b115-b16e8a2ac054][][][][3002923920]
    [03:54:27.755][SmObjStore.cpp:672][ManagementThread][Processing server command: DeleteOid][][][][05-00051917-8450-1cdf-be8e-b16e8a2ac054/03-0005d073-4a10-1cde-b115-b16e8a2ac054][][][][3002923920]
    [03:54:27.764][SmObjStore.cpp:672][ManagementThread][Processing server command: DeleteOid][][][][0b-000d3b5b-8051-1cdf-be8e-b16e8a2ac054/03-0005d073-4a10-1cde-b115-b16e8a2ac054][][][][3002923920]
    [03:54:27.772][SmObjStore.cpp:672][ManagementThread][Processing server command: DeleteOid][][][][05-000518c8-8451-1cdf-be8e-b16e8a2ac054/03-0005d073-4a10-1cde-b115-b16e8a2ac054][][][][3002923920]

     

     

    Regards

    Hubert



  • 5.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Jan 11, 2018 12:32 PM

    Hi Hubert,

     

    Thanks for your detailed response. A big Thumps Up!!! These details give much clear picture.

     

    Unfortunately, I got stuck with multiple issues today. So, I was not able to try implementing the details you have provided. Appreciate your help!

     

    I am going on vacation. I will be able to check again on 4th week of January. You have cleared my queries. But, is it possible to keep this thread open until I am back (so that I can check once from my side and I don't need to start a new thread for small follow up questions, if any)?

     

    I will definitely confirm/reply on this thread (once I am back) even if I don't have any further question.

     

    Thanks.

     

    Regards,

    Dhilip



  • 6.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Jan 22, 2018 07:57 AM

    Hi Hubert,

     

    Thanks for keeping this thread open.

     

    1) I could see the following lines in your response.
    <<
    The Resource Cache and Session Cache is updated by virtue of Normal Priority Requests (i.e. IsProtected / IsAuthenticated / IsAuthorized).
    >>

    1. Could you please elaborate this point?

     

    2) I have noticed that value of attribute named 'smCommandData4' in Agent Command is encrypted.

    As per my knowledge, it is not a sensitive information so Policy Store key should not be used for encryption. As agent should be able to decrypt this value(I hope encrypted value will be passed to agent), it should have been encrypted using Agent Key.

    1. Please confirm if my understanding is correct.
    2. May I know the significance of this encryption?


  • 7.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Jan 22, 2018 10:35 AM

    Dhilip Dhi1ip

     

    What is Normal Priority Request ? Refer https://support.ca.com/us/knowledge-base-articles.TEC491240.html

    WebAgent has two Cache's of its own i.e. Resource Cache and Session Cache. These two Caches are updated based on Policy Server responses to IsProtected / IsAuthenticated / IsAuthorized.

    • Resource Cache is updated by virtue of IsProtected Calls.
      • You may see these lines in WebAgent Trace log "Resource is protected from Cache". WebAgent does not make a call to Policy Server.
    • Session Cache is updated by virtue of IsAuthenticated and IsAuthorized Calls.
      • You may see these lines in WebAgent Trace logs "User is Authenticated from Cache". WebAgent does not make a call to Policy Server.

    If there are further queries on WebAgent Caches open a new thread. But I'll leave some notes for you to read.

    https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/web-agent-configuration/performance/web-agent-caches

    https://support.ca.com/us/knowledge-base-articles.TEC1172843.html

     

     

    smCommandData4 in AgentCommand being encrypted, my thoughts....

    {Corrected} Refer below thread...

     

     

    Regards

    Hubert



  • 8.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Jan 23, 2018 08:09 AM

    Hi Hubert,

     

    Thanks for your response and sharing useful links.

     

    As per my knowledge, Flush Cache of DoManagement call will flush the cache from WebAgent Caches (Resource Cache and Session Cache). But, you have mentioned "The Resource Cache and Session Cache is updated by virtue of Normal Priority Requests (i.e. IsProtected / IsAuthenticated / IsAuthorized)", that's why I thought of knowing your perspective. Sorry, I am not aware that DoManagement call is also a part of Normal Priority Requests.

      

    Regarding smCommandData4 ,

     

    1. Will smCommandData4 parameter of AgentCommand store the updated value? Because I thought it will store only the OID of the modified object so that it can be removed from the WebAgent cache (and webagent will contact the policy server instead of using from it's cache when it needs to access same object next time). But from your response, I guess my understanding is wrong.
    2. I tired updating few objects, I could see only the OID in smCommandData4 of ServerCommand. Will it store only OID or will this also store values? If it will store values, could you please provide any scenario (where value will be stored) so that I will try to replicate the same?
    3. Could you please share the complete list of values for parameter named 'smCommand' and the meaning/description for each value so that it will be easy to understand various/all possible scenarios?

     

    Thanks.

     

    Regards,

    Dhilip



  • 9.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Jan 23, 2018 11:04 AM

    Dhilip Dhi1ip

     

    Q1] You are correct. I misjudged that (my head was viciously stuck in my own example of ACO modification). AgentCommand is generated for objects, wherein WebAgent Caches needs to be updated. So a AgentCommand is generated for a Rule update as well (after 10 -20 seconds of generation of ServerCommand). Hence Yes, it should be only the OID. I'll try to find what is encrypted value in AgentCommand (Ujwol Ujwol - would you have ready insight into this space "why smCommandData4 in AgentCommand is encrypted?").

    Here smCommand is '5', which equates to 'FlushRealm' because I updated my rule. Thus by definition smCommandData4 should only contain OID. This is true for ServerCommand and in ServerCommand you'll see the smCommandData4 in clear text. I can't think of a reason why it is encrypted in AgentCommand (Especially when Agent to PS communication is encrypted using proprietary mechanism).

     

     

    Q2] Mostly OID. But Answer to Q3 will get you what you need.

     

     

    Q3] Here's the list with Comments for "smCommand".

    None = 0
    FlushAll = 1                                                       // no data
    FlushUsers = 2                                                // no data
    FlushRealms = 3                                             // no data
    FlushUser = 4                                                  // data contains user DN
    FlushRealm = 5                                               // data contains realm oid
    UpdateCachedOid = 6                                 // data contains oid
    DeleteCachedOid = 7                                  // data contains oid
    ChangeDynamicKeys = 8                            // no data
    ChangePersistentKey = 9                           // data may contain optional key value
    ChangeAllKeysToPersistentKey = 10     // data may contain optional key value
    ChangeSessionKey = 11                              //data may contain optional key value
    UpdateConfig = 12                                        // data contains <configtype>/<configname>
    RolloverSharedSecrets = 13                      // no data
    DisableCacheUpdates = 14                        // no data
    EnableCacheUpdates = 15                         // no data



  • 10.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Jan 24, 2018 12:37 AM

    If agent key is beign rolled, the smCommandData4 field in agent command would contain the actual agent keys.

    As the agent keys are sensitive, it is encrypted.

    For agent command of other type like flushall, flushuser etc, there isn't any senstive data but the API to set commdata is generic for all command type so everything gets encyrpted irrespective of the type of agentcommand.

     

     



  • 11.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Jan 24, 2018 01:04 AM

    Hi Ujwol,

     

    Thanks for your response.

     

    1. Could you please let me know if you are talking about rollover of static agent key as rollover of dynamic keys has no data?

          <<
          ChangeDynamicKeys = 8                            // no data

          >>

    2. If yes, could you please let me know the corresponding smCommand value for the same as I can't find it in the list shared earlier? 

    3. I would like to know if there is any specific reason beyond passing the value for static agent keys but not passing the same for dynamic agent keys.

    (or)

    4. Will the same process be used to update static key (1 new Agent command) as well as dynamic key (3 new Agent command)? If yes, then, how web agent will know how to map these agent command to last, current and future keys? will parameter name also be shared in smCommandData4?

     

    Regards,

    Dhilip



  • 12.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Jan 24, 2018 03:02 AM

    Dhilip Dhi1ip

     

    I have not played with static keys and dynamic keys in relation to ServerCommands, i will check this as I get some space. We can very easily test it in a sandbox env, with no changes happening to policy store. 

     

    But I am guessing that the updates to the key value itself (irrespective of static or dynamic) would be within these smCommands.

     

    ChangePersistentKey = 9                           // data may contain optional key value
    ChangeAllKeysToPersistentKey = 10     // data may contain optional key value
    ChangeSessionKey = 11                              //data may contain optional key value

     

    For static key, 'ChangeAllKeysToPersistentKey' makes logical sense.

     

    Static keys are entered in WAMUI, hence they have to be first persisted in the Policy / Key Store. Thus it makes sense that PersistentKey flags play a role for Static.

     

    For Dynamic keys, one policy server in a Cluster generates it and saves it into Policy / Key Store. 

     

    Remember most of the time smCommands / smCommandData is only a pointer to a object. There is unique objects in the Policy / Key Store which contains all the keys.

     

    But as I said I will test it tomorrow in a lab env and suggest as per what I see.



  • 13.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Jan 26, 2018 04:35 PM

    Dhilip Dhi1ip

     

    FOR SESSION KEY ROLLOVER USING STATIC KEY

     

    Two Server Commands were generated. No AgentCommand generated. Thus this indicates only update Policy Server Cache. Hmmm not sure why no AgentCommand for Session Key Ujwol thoughts ?

    ServerCommand-one displayed my key in clear, hence I masked it.

    ChangeSessionKey = 11 //data may contain optional key value

    ServerCommand-two

    UpdateCachedOid = 6  // data contains oid

     

     

     

    FOR AGENT KEY ROLLOVER USING STATIC KEY

    Before rollover.

    smKeyMarker4 // Contains value 1 / 2 / 3 / 4. Refer this link for details.

    smKey4            // encrypted Static Agent key, all 4 AgentKeyOIDs will have the same value.

     

    After rollover.

    One ServerCommand and One AgentCommand is generated. Thus it indicates to update Policy Server Cache and also update Agent Cache.

    AgentCommand has the encrypted Data.

    UpdateCachedOid = 6  // data contains oid

     

     

    FOR AGENT KEY ROLLOVER (MANUALLY) USING DYNAMIC KEYS

    One ServerCommand and One AgentCommand. 

    Thus it indicates to update Policy Server Cache and also update Agent Cache.

    AgentCommand has the encrypted Data.

    NOTE : In my use case only smKeyMarker4 value 3 is updated. All other smKeyMarker4's i.e. 1/2/4 contain the old Static Key. But as the Keys roll over, sequentially AgentKey OIDs 1/2/3 will be updated.

    UpdateCachedOid = 6  // data contains oid



  • 14.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Jan 26, 2018 04:43 PM

    Hubert Dennis Session Ticket Key/Persistent key is used only by Policy server, its never used by agent so AgentCommand is not needed while rolling Persistent Key


    https://communities.ca.com/community/ca-security/ca-single-sign-on/blog/2016/09/02/tech-tip-ca-single-sign-onpolicy-serverpersistent-keysession-ticket-key-introduced



  • 15.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Jan 29, 2018 06:30 AM

    Hi Hubert,

     

    Thanks for your detailed analysis and for providing screenshots.

     

    Regarding rollover of Session ticket key,

     

    From your previous mail, I understood that ChangeSessionKey(ServerCommand:11) will be generated for changing Session Ticket Key (or) Persistent Key.

     

    1) May I know in which case, following smCommand4 will be triggered as initially I thought this will be used for above scenario.

    ChangePersistentKey = 9                           // data may contain optional key value 

    I hope ServerCommand:11 will be generated irrespective of rollover mode(Static or Dynamic).

     

    Regarding rollover of Agent keys,

     

    2) In your screenshots for both cases(static and dynamic), I noticed that ServerCommand was generated after AgentCommand. May I know if it is because of any setting( like JournalRefresh and ServerCmdDelay) which you have modified (because whenever I try to modify any object, ServerCommand was generated first and then AgentCommand was generated)? If yes, how to achieve this as I thought ServerCommand will be generated instantly (on modification)? If no, what is the reason for this?

    << 

    Previous comment:

    Some ServerCommand's convey information that has to be carried over to the various agents. In order to achieve that, when persisting the ServerCommand object, an Agent Command is generated, buffered and scheduled to be saved within 15sec (configurable by JournalRefresh in sec). Every 10sec (configured by ServerCmdDelay), the Management Thread on Policy Server goes through the list of Agent Commands scheduled to be saved, and if their scheduled time was reached, saves them.

    >> 

     

    3) I could see that generated Server Command(UpdateCachedOid = 6) is having reference to 1a-*** (i.e., smKeyManagementOID)? May I know the reason for the same? Why smKeyManagementOID in PS cache needs to be updated as it has no reference to agent keys?

    Note : I presume smKeyManagementOID is used for storing only the details related to Persistent Key(Session Ticket key) as even in Root objectclass, KeyManagement(having smKeyManagementOID) and AgentKeys(having smAgentKeyOID) are stored as separate parameters.

     

    4) I hope Agent keys will not be cached in policy server(like Persistent key), so server command will not be generated for updating agent key(though one ServerCommand is generated for updating smKeyManagementOID). Please confirm. If no, on which case policy server needs agent keys(apart from sharing it to the web agents)?

     

    5) I could see AgentCommand is generated with smCommand4(UpdateCachedOid = 6  // data contains oid). Are we sure that smCommandData4 contains the encrypted value of agent key? Is there a chance that after receiving this AgentCommand(to update cache), agent has contacted policy server for the updated/latest set of keys? Have we verified(from the logs) that agent didn’t contacted policy server for the update?

     

    6) Have we tired rolling over of dynamic key for second time? I would like to know if following smCommand4 is generated on second/following roll overs.

    ChangeDynamicKeys = 8                            // no data

     

    7) Have we tried switching from dynamic key to static key (to know the generated smCommand4) because I would like to know how agents are being informed as it has to change all 4 agent keys at a time?

     

    Sorry Hubert, we are using custom agents(as well) in our setup, I am not sure about how keys will be used by custom agents(maybe I will raise a new thread for the same ), that's why I have refrained myself from playing around regarding roll over of keys.

     

    Thanks,

    Dhilip



  • 16.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Jan 31, 2018 06:40 PM

    Dhilip Dhi1ip

     

    [For - 1] 

    ServerCommand:11 will be generated irrespective of rollover mode (Static or Dynamic) for Session Key : Yes that is what I see in my lab.

    ChangePersistentKey = 9  : I was unable to produce the action which results in "9". May need to check code to see what triggers "9". 

     

     

    [For - 2]

    ServerCommand is always generated first, followed by AgentCommand. That is the expected design.

     

     

    [For - 3]

    The way it has been behaving in my lab is, irrespective of whether I change AgentKeys or SessionKeys, the reference is always to the single OID i.e. "smKeyManagementOID". Therefore it is my belief that irrespective of AgentKey (applicable to Static & Dynamic) or SessionKey rollover (applicable to Static & Dynamic); the reference will always be to the single OID i.e. "smKeyManagementOID". Further based on what was rolled Agent or Session Key, the respective commands would be generated i.e. ServerCommand (first) and AgentCommand (second) for AgentKey rollover && only ServerCommand for SessionKey. If an AgentCommand has "smKeyManagementOID" then that is a good enough pointer to the Policy Server, that in response to a WebAgent's DoManagement Call, send all 4 AgentKeys (not just a single one). You can see this in WebAgent logs as below.

    [sm-AgentFramework-00320] ADMIN: Received key update attribute 'KEY_UPDATE_LAST'.
    [sm-AgentFramework-00310] ADMIN: Successfully processed key update attribute 'LAST'.
    [sm-AgentFramework-00320] ADMIN: Received key update attribute 'KEY_UPDATE_CURRENT'.
    [sm-AgentFramework-00310] ADMIN: Successfully processed key update attribute 'CURRENT'.
    [sm-AgentFramework-00320] ADMIN: Received key update attribute 'KEY_UPDATE_NEXT'.
    [sm-AgentFramework-00310] ADMIN: Successfully processed key update attribute 'NEXT'.
    [sm-AgentFramework-00320] ADMIN: Received key update attribute 'KEY_UPDATE_PERSISTENT'.
    [sm-AgentFramework-00310] ADMIN: Successfully processed key update attribute 'PERSISTENT'.

     

     

    [For - 4]

    The purpose of Policy Server Caching Agent Commands is that information will be delivered to the agent instances, regardless of which Policy Server they are connected to. Policy Server maintains a cache of AgentCommands read from the Policy Store. The keys will be cached in the Policy Server cache. Agents Keys will be sent to Agents. Session Keys will only be used by Policy Server. There is a reason why ServerCommand is generated before AgentCommand, that way the Policy Server Cache is updated by virtue of ServerCommand being first. Now when the time for AgentCommand arrives to be processed, the updated object is present in the Policy Server Cache. The Agent has no access to Policy Store, nor does every doManagement call from Agent result in a read to Policy Store. Everything is done only via Policy Server Cache.

     

     

    [For - 5]

    Yes. smCommandData4 contains the encrypted value of agent key. Ujwol already confirmed this in his comment above.

    Policy Server does not push the AgentKeys proactively to all WebAgents. The WebAgent polls the Policy Server for updates. That is when the Policy Server sends all AgentCommands. The agent poll the Policy Server every 30 sec (Configured by the ACO parameter PollInterval, in sec) using the DoManagement call. PS will respond to the DoManagement call (in particular the GetAgentCmd request) by sending the list of Agent Command objects newer than the agent’s ManagementTime.

     

     

    [For - 6]

    When I tried manual Dynamic roll over for AgentKeys, I did not see that value. It always ended up as "6". I have a feeling it would be associated with Automatic Key Rollover. May need to check in code to confirm.

     

     

     

    [For - 7]

    The Policy Server never sends one AgentKeyMarker. It sends all 4. AgentKeyMarker4 contains the Static Key at all times. AgentKeyMarker 3 / 2 / 1 keep rotating. When using DynamicKeys,  AgentKeyMarker 3 / 2 / 1 have different values. When we switch the radio button from Dynamic to Static (note : I am not yet specifying a static value), the value from AgentKeyMarker4 gets duplicated in AgentKeyMarker3.  Now if I go back to UI and specify a static value and hit rollover now. All AgentKeyMarker values are updated to same value. Now to your question, How agents are being informed as it has to change all 4 agent keys at a time? Because Policy Server always sends all 4 AgentKeys as a response to WebAgent's doManagement call, if there exists an AgentCommand with "smKeyManagementOID". This allows WebAgent to decrypt (previously encrypted SMSESSION Cookie using an older key) using fallback / previous key, when current key is updated.

     

     

    Regards

    Hubert



  • 17.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Feb 02, 2018 01:27 AM

    Hi Hubert,

     

    Thanks for your detailed response and for sharing many helpful information!

     

    1. Regarding point 2,  ServerCommand is always generated first, followed by AgentCommand. That is the expected design. => In your earlier screenshots, I could see that Agent commands are generated before Server Commands. May I know the reason for this behavior?

    Static rollover:
    Timestamp of Server Command : 1517001932
    Timestamp of Agent Command : 1517001930

    Dynamic rollover:
    Timestamp of Server Command : 1517003751
    Timestamp of Agent Command : 1517003748

     

    2. I could see the following lines in your previous response.

    <<
    In point 3 => If an AgentCommand has "smKeyManagementOID" then that is a good enough pointer to the Policy Server, that in response to a WebAgent's DoManagement Call, send all 4 AgentKeys (not just a single one)
    In point 5 => smCommandData4 contains the encrypted value of agent key.
    In point 7 => The Policy Server never sends one AgentKeyMarker. It sends all 4. Policy Server always sends all 4 AgentKeys as a response to WebAgent's doManagement call, if there exists an AgentCommand with "smKeyManagementOID".

    >>


    What does the smCommandData4 of AgentCommand contains? Will it have both smKeyManagementOID and encrypted value of agent keys? If it will have all 4 keys, how are we differentiating this? Will it have parameter name as well (or) are we using any delimiter? In case, if we decrypt the value of smCommandData4, how will it look like?

     

    3. Please confirm if Policy Store key will be used for the encryption of smCommandData4 of AgentCommand.

     

    4. Commands which needs to be confirmed from code.
    ChangeDynamicKeys = 8 // no data
    ChangePersistentKey = 9 // data may contain optional key value
    ChangeAllKeysToPersistentKey = 10 // data may contain optional key value

     

    Thanks,

     

    Regards,

    Dhilip



  • 18.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Feb 02, 2018 02:59 PM

    Dhilip Dhi1ip

     

    Question....

    1. Regarding point 2,  ServerCommand is always generated first, followed by AgentCommand. That is the expected design. => In your earlier screenshots, I could see that Agent commands are generated before Server Commands. May I know the reason for this behavior?

    Static rollover:
    Timestamp of Server Command : 1517001932
    Timestamp of Agent Command : 1517001930

    Dynamic rollover:
    Timestamp of Server Command : 1517003751
    Timestamp of Agent Command : 1517003748

     

     

    Thank You for pointing that out. I think I know what happened and was able reproduce. However I'm unable to explain in my first screenshot, there is only One ServerCommand and One AgentCommand, the time value for AgentCommand should be the same of the ServerCommand.

    Static rollover:
    Timestamp of Server Command : 1517001932
    Timestamp of Agent Command : 1517001930

    In the second screenshot for dynamic rollover there are multiple ServerCommand, I highlighted the wrong one.

    Dynamic rollover:
    Timestamp of Server Command : 1517003751
    Timestamp of Agent Command : 1517003748

     

    Here is what I was doing and the result.

     

    If I hit only the "RollOver Now" button, then one ServerCommand is generated first and persisted first into PStore.

    After 10 -15 seconds, AgentCommand is generated and persisted into the PStore. Both have the same timestamp.

    I also see that all AgentKeys are updated, at this point.

     

    Now going back to WAMUI. There is a conspicuous "Submit" button blaring back to you in blue. If I clicked on "submit"; another ServerCommand is generated. I figured out that this "Submit" was an overdo, and not needed. I was hitting "Submit" after hitting the rollover button. Which explains the 2 seconds difference and my ldap tool was sorting based on most updated class / group of entry. Thus the incorrect representation.

     

     

     

     

     



  • 19.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Feb 02, 2018 03:07 PM

    Dhilip Dhi1ip

     

    Question....

    3. Please confirm if Policy Store key will be used for the encryption of smCommandData4 of AgentCommand.

     

     

     

    PolicyStore encryption key will be used to encrypt any sensitive information in all Objects in PolicyStore. If smCommandData4 within AgentCommand Object contain AgentKey, it is marked Sensitive.



  • 20.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Feb 02, 2018 04:45 PM

    Dhilip Dhi1ip

     

    Question....

    2. I could see the following lines in your previous response.

    <<
    In point 3 => If an AgentCommand has "smKeyManagementOID" then that is a good enough pointer to the Policy Server, that in response to a WebAgent's DoManagement Call, send all 4 AgentKeys (not just a single one)
    In point 5 => smCommandData4 contains the encrypted value of agent key.
    In point 7 => The Policy Server never sends one AgentKeyMarker. It sends all 4. Policy Server always sends all 4 AgentKeys as a response to WebAgent's doManagement call, if there exists an AgentCommand with "smKeyManagementOID".

    >>


    What does the smCommandData4 of AgentCommand contains? Will it have both smKeyManagementOID and encrypted value of agent keys? If it will have all 4 keys, how are we differentiating this? Will it have parameter name as well (or) are we using any delimiter? In case, if we decrypt the value of smCommandData4, how will it look like?

     

     

     

    smCommandData4 in AgentCommand will not contain smKeyManagementOID. smCommandData4 in AgentCommand will only contain AgentKeys.

     

    How are we differentiating this, by using smKeyMarker4 in AgentKey Objects. Each smKeyMarker4 Object stands for a Key e.g. AgentKeyOID with smKeyMarker4 containing value 4 = PersistantKey (i.e. Static Key).

    Last = 1
    Current = 2
    Next = 3
    Persistent = 4

    You can see the corresponding info in webagent log.

    [sm-AgentFramework-00320] ADMIN: Received key update attribute 'KEY_UPDATE_LAST'.
    [sm-AgentFramework-00310] ADMIN: Successfully processed key update attribute 'LAST'.
    [sm-AgentFramework-00320] ADMIN: Received key update attribute 'KEY_UPDATE_CURRENT'.
    [sm-AgentFramework-00310] ADMIN: Successfully processed key update attribute 'CURRENT'.
    [sm-AgentFramework-00320] ADMIN: Received key update attribute 'KEY_UPDATE_NEXT'.
    [sm-AgentFramework-00310] ADMIN: Successfully processed key update attribute 'NEXT'.
    [sm-AgentFramework-00320] ADMIN: Received key update attribute 'KEY_UPDATE_PERSISTENT'.
    [sm-AgentFramework-00310] ADMIN: Successfully processed key update attribute 'PERSISTENT'.

    Added Info.

    https://support.ca.com/us/knowledge-base-articles.TEC1392087.html 

    https://support.ca.com/us/knowledge-base-articles.TEC528065.html

     

    Will it have parameter name as well OR are we using any delimiter ? If we decrypt the value of smCommandData4, how will it look like ?

    I spend some time today looking at this. Here is what I found. Bottemline, the value of smCommand4 in ServerCommand and AgentCommand could mean same for some scenarios, but it would mean different for other scenarios.


    AgentCommand
    None                            = 0
    FlushAll                        = 1
    FlushUsers                      = 2
    FlushRealms                     = 3
    FlushUser                       = 4 // data contains user DN
    FlushRealm                      = 5 // data contains realm oid
    ChangeAgentKey                  = 6 // data contains key value, encoded and string encrypted
    ChangeAffiliateKey              = 7 // data contains affiliate agent's name
    UpdateConfig                    = 8 // data contains <configtype>/<configname>


    ServerCommand
    None                            = 0
    FlushAll                        = 1  // no data
    FlushUsers                      = 2  // no data
    FlushRealms                     = 3  // no data
    FlushUser                       = 4  // data contains user DN
    FlushRealm                      = 5  // data contains realm oid
    UpdateCachedOid                 = 6  // data contains oid
    DeleteCachedOid                 = 7  // data contains oid
    ChangeDynamicKeys               = 8  // no data
    ChangePersistentKey             = 9  // data may contain optional key value
    ChangeAllKeysToPersistentKey    = 10 // data may contain optional key value
    ChangeSessionKey                = 11 //data may contain optional key value
    UpdateConfig                    = 12 // data contains <configtype>/<configname>
    RolloverSharedSecrets           = 13 // no data
    DisableCacheUpdates             = 14 // no data
    EnableCacheUpdates              = 15 // no data



  • 21.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Feb 08, 2018 02:03 AM

    Hi Hubert,

     

    Thanks for your response.

     

    Regarding point 1,
    I could see the following line in your response
    <<
    In the second screenshot for dynamic rollover there are multiple ServerCommand, I highlighted the wrong one.
    >>

    Could you please let me know how many ServerCommand will be generated on clicking the Rollover button once?
    Earlier response:
    <<
    FOR AGENT KEY ROLLOVER (MANUALLY) USING DYNAMIC KEYS

    One ServerCommand and One AgentCommand.
    >>
    Note : I am not sure if you have tried rolling over multiple times.


    Regarding point 2, I am rephrasing my question. I understand that smKeyMarker4 in AgentKey Object will be used to differentiate the keys. As you have confirmed, smCommandData4 in AgentCommand will contain AgentKeys (presuming it will have all 4 agent keys). My doubt is, how are we differentiating the 4 keys which are in a single attribute i.e., smCommandData4 of AgentKey? Will it have parameter name as well (or) are we using any delimiter? In case, if we decrypt the value of smCommandData4, how will it look like?


    Regarding point 4, [Updated the question], please let me know on which scenarios following commands will be used(by checking the code).
    Server command:
    ChangeDynamicKeys               = 8  // no data
    ChangePersistentKey             = 9  // data may contain optional key value
    ChangeAllKeysToPersistentKey    = 10 // data may contain optional key value
    ChangeSessionKey                = 11 //data may contain optional key value
    Agent Command:
    ChangeAffiliateKey              = 7 // data contains affiliate agent's name

     

    Regards,

    Dhilip



  • 22.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Feb 08, 2018 10:34 AM

    Dhilip Dhi1ip

     

    The initial intent of this thread is going out of scope. I have opened new discussions for specific question (You have been tagged and I have referenced it back to this thread; on all new discussions forked).

     

    Question

    Regarding point 1,
    I could see the following line in your response
    <<
    In the second screenshot for dynamic rollover there are multiple ServerCommand, I highlighted the wrong one.
    >>

    Could you please let me know how many ServerCommand will be generated on clicking the Rollover button once? 
    Earlier response:
    <<
    FOR AGENT KEY ROLLOVER (MANUALLY) USING DYNAMIC KEYS

    One ServerCommand and One AgentCommand. 
    >>
    Note : I am not sure if you have tried rolling over multiple times.

     

    Clicking Rollover button once, will generate One ServerCommand and One AgentCommand.

     

     

     

    Question

    Regarding point 2, I am rephrasing my question. I understand that smKeyMarker4 in AgentKey Object will be used to differentiate the keys. As you have confirmed, smCommandData4 in AgentCommand will contain AgentKeys (presuming it will have all 4 agent keys). My doubt is, how are we differentiating the 4 keys which are in a single attribute i.e., smCommandData4 of AgentKey? Will it have parameter name as well (or) are we using any delimiter? In case, if we decrypt the value of smCommandData4, how will it look like?

     

    I'll let someone closer to Engineering answer this for you OR someone who has access to that level of code. As such I have opened a new thread, as scope was creeping away from the original intended question. 

    Decrypted value of smCommandData4 in AgentCommand (AgentKey) 

     

     

    Question
    Regarding point 4, [Updated the question], please let me know on which scenarios following commands will be used(by checking the code).
    Server command:
    ChangeDynamicKeys               = 8  // no data
    ChangePersistentKey             = 9  // data may contain optional key value
    ChangeAllKeysToPersistentKey    = 10 // data may contain optional key value
    ChangeSessionKey                = 11 //data may contain optional key value
    Agent Command:
    ChangeAffiliateKey              = 7 // data contains affiliate agent's name

     

    I'll let someone closer to Engineering answer this for you OR someone who has access to that level of code. As such I have opened a new thread, as scope was creeping away from the original intended question. 

    Scenario's where following AgentCommands / ServerCommands be used 

     

     

    Regards

    Hubert



  • 23.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Feb 09, 2018 12:46 AM

    Hi Hubert,

     

    Thanks for spending your time on analysis/on providing detailed response for all my queries. Really appreciate your help!! I completely agree with your previous response.

     

    Have a great day!

     

    Regards,

    Dhilip



  • 24.  Re: CA SSO : How policy server(s) will be synchronized?

    Posted Feb 09, 2018 07:43 AM
    A huge kudos to Hubert Dennis for being patient and taking time to answer each of the customer questions so thoroughly here.