Symantec Access Management

Expand all | Collapse all

SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

  • 1.  SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 19, 2016 12:14 PM

    Hello,

    We are in the process of upgrading our SiteMinder r12.0 SP3 CR10 policy server to version r12.52 SP1.  We chose to do this in a "parallel" environment to minimize impact and risks on our existing applications.  I started this parallel upgrade method in our DEV environment with a single policy server and encountered numerous issues but eventually resolved them all and learned quite a bit throughout the process.  I am now finally ready for our QA environment but the upgrade is not going so well.  Right now I am dealing with an issue with the r12.0 policy server sharing the agent key and session ticket with the r12.52 policy server to enable SSO between the two.

    Here are the specifics for the policy servers:

     

    Current Policy Server:

    *r12.0 SP3 CR10  RHEL 6

    *policystore = CA Directory r12.0 SP11

     

    New Policy Server:

    *r12.52 SP1 CR5  RHEL6

    *policystore = CA Directory r12.0 SP17

     

    This is the summary of my steps in the DEV environment:

    1) Install and configure the r12.52 policy server/components (parallel to the r12.0 environment)

    2) Export r12.0 policy data (smobjexport -oR12.0export.smdif -dsiteminder -wpassword -v)

    3) Export r12.0 agent & session ticket keys (smobjexport -oR12.0-keysexport.smdif -dsiteminder -wpassword -v -k -x)

    4) Import policy data into r12.52 (smobjimport -dsiteminder -wpassword -iR12.0export.smdif -v -a3)

    5) Import agent keys into r12.52 (smkeyimport -dsiteminder -wpassword -iR12.0-keysexport.smdif -v)

    6) restart the r12.52 policy server and the policystore (CA Directory Server)

     

    Testing SSO between r12.0 and r12.52 PS:

    1) Request and authenticate against: https://current-r12-0.testsite.com (obtain SMSESSION from r12.0 PS)

    2) Request the r12.52 protected site with existing r12.0 SMSESSION cookie in browser

    3) SSO failed - SMSESSION cookie unable to decrypt so redirected to r12.52 for authentication

     

    We want to avoid resetting the "Static Agent Key" for both the r12.0 and r12.52 policy servers because this would require restarting all of the web servers and causes interruptions.  The export/import of the agent key in our DEV environment successfully enabled SSO between the two policy servers and we want to employ the same process as we move on up to our production environment.

     

    With the given information, I hope that folks can provide some tips and suggestions to help me figure this out.

     

    Thanks in advance



  • 2.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 19, 2016 01:08 PM

    1. Have you tried clear text export of keys from both r12.0 and r12.52 Policy servers.

     

    Do all the key values match exactly.(including persistent key)

    smkeyexport  -d<admin> -w<password> -okeys.txt -c

     

    2. If keys does not match. Then try to point r12.52 PS to r12.0 key store and see if the clear text export of keys works. If clear text export of keys works SSO will work.

     

    3. Also ensure that neither of Persistent Key Or Agent Keys are null . It is best to try rolling the Agent Keys 4 times and also Session Ticket Key/Persistent Key from 12.0, perform clear text export of keys and then import the same in 12.52 key store.



  • 3.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 19, 2016 05:43 PM

    Hi Ujwol,

     

    I think the SiteMinder Agent keys concept is still not quite fully clear for me.  Reason I am more confused is because I did the "smkeyexport" of both of my existing/current r12.0 policy servers and they don't match!  Below are the plaintext export of the agent keys, the first two are for my r12.0 policy servers which currently have SSO between them but you'll see that their persistent key and agent keys do not match.  The last export is for my new r12.52 policy server that I am trying to get it to SSO with my two current r12.0 policy servers:

     

    r12.0 policy server (A):

    #! SiteMinder Version 12.0
    # Export Flags: Clear Text, Export Keys, Export Key store data.
    objectclass: Root
    Oid: 0a-00000000-0000-0000-0000-000000000000
    AgentTypes:
    Schemes:
    Agents:
    AgentGroups:
    UserDirectories:
    Domains:
    Admins:
    AuthAzMaps:
    CertMaps:
    SelfRegs:
    ODBCQueries:
    PasswordPolicies:
    KeyManagement: 1a-fa347804-9d33-11d3-8025-006008aaae5b
    AgentKeys: 1b-000bab18-0218-1fd9-8206-12970a1610b6, 1b-000bab0e-0218-1fd9-8206-12970a1610b6, 1b-000bab11-0218-1fd9-82
    06-12970a1610b6, 1b-000bab15-0218-1fd9-8206-12970a1610b6
    RootConfig:
    VariableTypes:
    PropertyCollections:
    TaggedStrings:
    TrustedHosts:
    IMSDirectories:
    IMSEnvironments:
    IMSOptionLists:
    SharedSecretPolicy:
    IMS6Directories:
    IMS6Environments:

    objectclass: KeyManagement
    Oid: 1a-fa347804-9d33-11d3-8025-006008aaae5b
    IsEnabled: false
    ChangeFrequency: 0
    ChangeValue: 0
    NewKeyTime: 0
    OldKeyTime: 0
    FireHour: 0
    PersistentKey: {RC2}NunWKma1lR3ePosSbF4OqYqLr7ExDFlxqhON1/8sz0jt2EG1wtwvp+cza0AUw6kw

    objectclass: AgentKey
    Oid: 1b-000bab18-0218-1fd9-8206-12970a1610b6
    KeyMarker: 4
    Key: {RC2}sDbZBbwE/jqL6sQdH/15geB7LjwBSOpKu2x6BKr0jp2F3akhn6ABUBpZFhOIvWyg

    objectclass: AgentKey
    Oid: 1b-000bab0e-0218-1fd9-8206-12970a1610b6
    KeyMarker: 1
    Key: {RC2}GU5vbQh0y5iQUfIkPF+EAactZvFffDiwocTKAKDyDnKqvmxO9qaSdYPj0x4G32Tj

    objectclass: AgentKey
    Oid: 1b-000bab11-0218-1fd9-8206-12970a1610b6
    KeyMarker: 2
    Key: {RC2}jzXxUYpXTiGcHU4UDN0GZWgi0tXm8oC1exDlEv99R0pVdvD4SFU6yFDypnf2vvOL

    objectclass: AgentKey
    Oid: 1b-000bab15-0218-1fd9-8206-12970a1610b6
    KeyMarker: 3
    Key: {RC2}fZo+jm65GX3uKBB/ZFuOHgptJqDhstuapWmb6/OuurTgTTv1d8czZHqgibCrnkrS

     

    r12.0 policy server (B):

    #! SiteMinder Version 12.0
    # Export Flags: Clear Text, Export Keys, Export Key store data.
    objectclass: Root
    Oid: 0a-00000000-0000-0000-0000-000000000000
    AgentTypes:
    Schemes:
    Agents:
    AgentGroups:
    UserDirectories:
    Domains:
    Admins:
    AuthAzMaps:
    CertMaps:
    SelfRegs:
    ODBCQueries:
    PasswordPolicies:
    KeyManagement: 1a-fa347804-9d33-11d3-8025-006008aaae5b
    AgentKeys: 1b-000bab18-0218-1fd9-8206-12970a1610b6, 1b-000bab0e-0218-1fd9-8206-12970a1610b6, 1b-000bab11-0218-1fd9-8206-12970a1610b6,
    1b-000bab15-0218-1fd9-8206-12970a1610b6
    RootConfig:
    VariableTypes:
    PropertyCollections:
    TaggedStrings:
    TrustedHosts:
    IMSDirectories:
    IMSEnvironments:
    IMSOptionLists:
    SharedSecretPolicy:
    IMS6Directories:
    IMS6Environments:

    objectclass: KeyManagement
    Oid: 1a-fa347804-9d33-11d3-8025-006008aaae5b
    IsEnabled: false
    ChangeFrequency: 0
    ChangeValue: 0
    NewKeyTime: 0
    OldKeyTime: 0
    FireHour: 0
    PersistentKey: {RC2}xr4JNB0PrvWB6/wZhwdEUYxwXnH+IKOjK/Nmvc6yJ/wih4FPzwmr/QRuIRsG3cCJ

    objectclass: AgentKey
    Oid: 1b-000bab18-0218-1fd9-8206-12970a1610b6
    KeyMarker: 4
    Key: {RC2}zHK9OyIBOiGLBkJuAFqB7fV3ZjJFW2PwVojv2mYfPxNmnPQ7n9XwZM7AofWXfkj8

    objectclass: AgentKey
    Oid: 1b-000bab0e-0218-1fd9-8206-12970a1610b6
    KeyMarker: 1
    Key: {RC2}IhnfxQUgZGPLEsGTK3upShr/K0ZJjnWUB7HaG3hfTRt3liAyjAk8xPqcX5GhZzTf

    objectclass: AgentKey
    Oid: 1b-000bab11-0218-1fd9-8206-12970a1610b6
    KeyMarker: 2
    Key: {RC2}/hXdNIioTYPNupApVWjjVLUIcudmalgDIsUwCs8lPZxrn1YzgvAmusCEcbNf1r1C

    objectclass: AgentKey
    Oid: 1b-000bab15-0218-1fd9-8206-12970a1610b6
    KeyMarker: 3
    Key: {RC2}TPvTsfrH1qRIRoTCtmgUoXEmJxoEiElLrt+fvmYpSjj5ERkHE5TvcxRzGB8zlsnc

     

    r12.52 policy server (A):

    #! SiteMinder Version 12.52
    # Export Flags: Clear Text, Export Keys, Export Key store data.
    objectclass: Root
    Oid: 0a-00000000-0000-0000-0000-000000000000
    AgentTypes:
    Schemes:
    Agents:
    AgentGroups:
    UserDirectories:
    Domains:
    Admins:
    AuthAzMaps:
    CertMaps:
    SelfRegs:
    ODBCQueries:
    PasswordPolicies:
    KeyManagement: 1a-fa347804-9d33-11d3-8025-006008aaae5b
    AgentKeys: 1b-000bab18-0218-1fd9-8206-12970a1610b6, 1b-000bab0e-0218-1fd9-8206-12970a1610b6, 1b-000bab11-0218-1fd9-8206-12970a1610b6, 1b-000bab15-0218-1fd9-8206-12970a1610b6, 1b-000d98bb-5478-16df-9476-
    87f40a16d0ad, 1b-000d98b3-5478-16df-9476-87f40a16d0ad, 1b-000d98b6-5478-16df-9476-87f40a16d0ad, 1b-000d98b9-5478-16df-9476-87f40a16d0ad
    RootConfig:
    VariableTypes:
    PropertyCollections:
    TaggedStrings:
    TrustedHosts:
    IMSDirectories:
    IMSEnvironments:
    IMSOptionLists:
    SharedSecretPolicy:
    IMS6Directories:
    IMS6Environments:

    objectclass: KeyManagement
    Oid: 1a-fa347804-9d33-11d3-8025-006008aaae5b
    IsEnabled: false
    ChangeFrequency: 0
    ChangeValue: 0
    NewKeyTime: 0
    OldKeyTime: 0
    FireHour: 0
    PersistentKey: THmi5LOXHiDlCgP6tPJGqC1kK9lbZK/v

    objectclass: AgentKey
    Oid: 1b-000bab18-0218-1fd9-8206-12970a1610b6
    KeyMarker: 4
    Key: aMQta7keVCkZG9tg9qOLZV7vswdDxwYn

    objectclass: AgentKey
    Oid: 1b-000bab0e-0218-1fd9-8206-12970a1610b6
    KeyMarker: 1
    Key: aMQta7keVCkZG9tg9qOLZV7vswdDxwYn

    objectclass: AgentKey
    Oid: 1b-000bab11-0218-1fd9-8206-12970a1610b6
    KeyMarker: 2
    Key: aMQta7keVCkZG9tg9qOLZV7vswdDxwYn

    objectclass: AgentKey
    Oid: 1b-000bab15-0218-1fd9-8206-12970a1610b6
    KeyMarker: 3
    Key: aMQta7keVCkZG9tg9qOLZV7vswdDxwYn

    objectclass: AgentKey
    Oid: 1b-000d98bb-5478-16df-9476-87f40a16d0ad
    KeyMarker: 4
    Key: n3sqeoTycD/4r7H91NdtFue1ryHKB0kJ

    objectclass: AgentKey
    Oid: 1b-000d98b3-5478-16df-9476-87f40a16d0ad
    KeyMarker: 1
    Key: n3sqeoTycD/4r7H91NdtFue1ryHKB0kJ

    objectclass: AgentKey
    Oid: 1b-000d98b6-5478-16df-9476-87f40a16d0ad
    KeyMarker: 2
    Key: n3sqeoTycD/4r7H91NdtFue1ryHKB0kJ

    objectclass: AgentKey
    Oid: 1b-000d98b9-5478-16df-9476-87f40a16d0ad
    KeyMarker: 3
    Key: n3sqeoTycD/4r7H91NdtFue1ryHKB0kJ



  • 4.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 19, 2016 06:51 PM

    Hi Duc,

     

    You seem to have two issue at the moment.

     

    1. Your r12.0 environment , they Key export are not coming in clear even when you use -c switch. This is a known issue.

    If you see the keys starting with {RC2} and {AES} marker, this means they are still encrypted.

    This is not really an issue, but it is just that it prevents us from doing the clear text comparison of keys with your r12.52 environment. If you want , we might be able to provide a quick dev fix, which will fix the clear text key export issue.

     

    2. Secondly, in your r12.52 setup , you have two set of Agent Keys (as Hongxu mentioned) . 1 set comprises of 4 Key marker starting with 1-4. This is not right. This happens if you have multiple policy servers generating the agent keys which in this case it seems like you have both r12.0 and r12.52 Policy servers configured to generate keys.

     

    So, my suggested next action :

     

    1. Configure only one PS to allow to generate keys2. From 12.52 PS, delete all the agent keys manually.(using ldap or odbc browser as applicable)

    3. Rollover Agent Keys 4 times from r12.0 and Session Ticket Keys 1 time, to ensure they are not null and actually have values.

    4. Perform key store export from r12.0 (doesn't matter even if it is encrypted as long as you are using the same policy server encryption keys in r12.0 and r12.52 setup)

    5. Import the keys in r12.52

    6. Restart r12.52 PS

     

    Hope this helps.

     

    Regards,

    Ujwol

     



  • 5.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 19, 2016 07:07 PM

    Ujwol / Hongxa,

     

    So it appears that when I do the "smkeyimport" on the r12.52 PS, it will "add" another set of 4 keys in addition to the existing 4 keys that are already there.  So should I start clean by locating all of the "objectclass: AgentKey" entries my the policystore and delete them then run the smkeyimport again?  But what kills me is that I don't understand how this still works in my DEV environment with r12.52 PS having 8 keys and still maintaining SSO with the r12.0 PS.



  • 6.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 19, 2016 07:31 PM

    Hi Duc,

     

    When you have two set of agent keys, the behavior will be random. If by chance two agents use the same set of keys the SSO will work. But if they use different set, for eg. web agent 1 uses set 1 and web agent 2 uses set 2, then SSO will fail.

     

    Yes, you should do the agent key clean up.

     

    Regards,

    Ujwol



  • 7.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Broadcom Employee
    Posted Jul 19, 2016 06:14 PM

    Hi,

     

    Based on the key output, in r12.52, you have two set of agent keys, which is not normal.

    In a SSO environment, there should be only one set of keys (4).

    If you have multiple policy servers, then only one should be turned on as key generator, the rest of servers only point to the same key store, or using same set of keys(4).

    That is the cause of SSO failure.

     

    To correct it,

    1. Determine the key generator server, disable key generation from other servers but turn on EnablekeyUpdate.

    2. Clean up redundant set of keys from key generator server, or generate a new set by rolling keys.

    3. All non-key generation servers points to same key store, or using same key values by import.

    4. Restart if needed, then test SSO.

     

    This is just high level guideline, if you have problems, it is better to open ticket and work through it with support.

    There could be many small issues people encounter along the way.

    Thanks,

     

    Hongxu Liu

     



  • 8.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 19, 2016 06:55 PM

    Hi Hongxu,

     

    Firstly, thank very much for your response.  And now second.. I am even more confused now

     

    I really want to understand how the SiteMinder agent key framework really works because looking at the way that my current r12.0 policy servers (server A and server B) and their agent keys output, this does not make any sense!  As you can see from the key output from the previous message, both server r12.0 A and r12.0 B, you'll see the keys are totally different and also their persistent keys don't match either so how is the SSO still working between these two policy servers?.  Also, the smps.log file on both of them shows that they're both generating agent keys.

     

    [5259/4124624576][Mon Jul 18 2016 19:00:45][SmPolicyServer.cpp:645][INFO] This policy server generates agent keys

    [5259/4124624576][Mon Jul 18 2016 19:00:45][SmPolicyServer.cpp:808][INFO] This policy server is allowed to roll over trusted host shared secrets

     

    Below are the keys output for my DEV environment, which only has a single policy server.  In this environment, I simply exported the agent keys via "smobjexport -o<filename> -d<admin> -w<password> -v -k -x from the r12.0 server and then import it into the new DEV r12.52 server via - - > smkeyimport -d<admin> -w<password> -I<inputfile> -v  but in this environment I have the r12.0 server generating agent keys while disabling the agent key generation on the r12.52 server.  Somehow this works.  You will also see that the DEV r12.52 server has the extra set of keys just like the current r12.52 server that I am having trouble with, but SSO appears to be working fine between the r12.0 and the r12.52 servers in our DEV environment.

     

    R12.0 DEV policy server keys:

    #! SiteMinder Version 12.0
    # Export Flags: Clear Text, Export Keys, Export Key store data.
    objectclass: Root
    Oid: 0a-00000000-0000-0000-0000-000000000000
    AgentTypes:
    Schemes:
    Agents:
    AgentGroups:
    UserDirectories:
    Domains:
    Admins:
    AuthAzMaps:
    CertMaps:
    SelfRegs:
    ODBCQueries:
    PasswordPolicies:
    KeyManagement: 1a-fa347804-9d33-11d3-8025-006008aaae5b
    AgentKeys: 1b-00009749-d7f9-1fc7-97e7-12960a161056, 1b-0000973f-d7f9-1fc7-97e7-12960a161056, 1b-00009742-d7f9-1fc7-97e7-12960a161056, 1b-00009746-d7f9-1fc7-97e7-1
    2960a161056
    RootConfig:
    VariableTypes:
    PropertyCollections:
    TaggedStrings:
    TrustedHosts:
    IMSDirectories:
    IMSEnvironments:
    IMSOptionLists:
    SharedSecretPolicy:
    IMS6Directories:
    IMS6Environments:

    objectclass: KeyManagement
    Oid: 1a-fa347804-9d33-11d3-8025-006008aaae5b
    IsEnabled: false
    ChangeFrequency: 0
    ChangeValue: 0
    NewKeyTime: 0
    OldKeyTime: 1456522227
    FireHour: 0
    PersistentKey: {RC2}kWvrjJ6Uq4yqZe3kgJBao5GqGr40bvawh+xrMOYmgKQQVhNSp4OA72J0K8NRzPri

    objectclass: AgentKey
    Oid: 1b-00009749-d7f9-1fc7-97e7-12960a161056
    KeyMarker: 4
    Key: {RC2}gq04LuzwOrEOHhdQaeoqp529khaVlq+zvxR/Jj/dRkCSP9WsDKeTut/kDCP4ZtlR

    objectclass: AgentKey
    Oid: 1b-0000973f-d7f9-1fc7-97e7-12960a161056
    KeyMarker: 1
    Key: {RC2}MkJUH9mZJoOsdTLkUH7J3lIp6UiwfnG3FZybIv3tnVri8qScera37YixNAvIUCPg

    objectclass: AgentKey
    Oid: 1b-00009742-d7f9-1fc7-97e7-12960a161056
    KeyMarker: 2
    Key: {RC2}CIuJVApEpf6NuYGE0TkrtNGBgOLqcTR7Rl22obxamEvLWkmzJEkvHAPsT7W7/xGZ

    objectclass: AgentKey
    Oid: 1b-00009746-d7f9-1fc7-97e7-12960a161056
    KeyMarker: 3
    Key: {RC2}9GIv1tP/i9wz/F3fs8mnKeQHd/MKC8ZhdRVq94qBqBtDbtiL326QTbRaHheGzMDG

     

     

     

    R12.52 DEV policy server keys:

    #! SiteMinder Version 12.52
    # Export Flags: Clear Text, Export Keys, Export Key store data.
    objectclass: Root
    Oid: 0a-00000000-0000-0000-0000-000000000000
    AgentTypes:
    Schemes:
    Agents:
    AgentGroups:
    UserDirectories:
    Domains:
    Admins:
    AuthAzMaps:
    CertMaps:
    SelfRegs:
    ODBCQueries:
    PasswordPolicies:
    KeyManagement: 1a-fa347804-9d33-11d3-8025-006008aaae5b
    AgentKeys: 1b-00009749-d7f9-1fc7-97e7-12960a161056, 1b-0000973f-d7f9-1fc7-97e7-12960a161056, 1b-00009742-d7f9-1fc7-97e7-12960a161056, 1b-00009746-d7f9-1fc7-97e7-12960a
    161056, 1b-0003610c-0a18-16b1-8a15-126e0a16d07d, 1b-00036107-0a18-16b1-8a15-126e0a16d07d, 1b-00036109-0a18-16b1-8a15-126e0a16d07d, 1b-0003610b-0a18-16b1-8a15-126e0a16d
    07d
    RootConfig:
    VariableTypes:
    PropertyCollections:
    TaggedStrings:
    TrustedHosts:
    IMSDirectories:
    IMSEnvironments:
    IMSOptionLists:
    SharedSecretPolicy:
    IMS6Directories:
    IMS6Environments:

    objectclass: KeyManagement
    Oid: 1a-fa347804-9d33-11d3-8025-006008aaae5b
    IsEnabled: false
    ChangeFrequency: 0
    ChangeValue: 0
    NewKeyTime: 0
    OldKeyTime: 1456522255
    FireHour: 0
    PersistentKey: joJ4+/2iYNxYK7q/CjkARIKZ0DQAAAAA

    objectclass: AgentKey
    Oid: 1b-00009749-d7f9-1fc7-97e7-12960a161056
    KeyMarker: 4
    Key: joJ4+/2iYNxYK7q/CjkARIKZ0DQAAAAA

    objectclass: AgentKey
    Oid: 1b-0000973f-d7f9-1fc7-97e7-12960a161056
    KeyMarker: 1
    Key: joJ4+/2iYNxYK7q/CjkARIKZ0DQAAAAA

    objectclass: AgentKey
    Oid: 1b-00009742-d7f9-1fc7-97e7-12960a161056
    KeyMarker: 2
    Key: joJ4+/2iYNxYK7q/CjkARIKZ0DQAAAAA

    objectclass: AgentKey
    Oid: 1b-00009746-d7f9-1fc7-97e7-12960a161056
    KeyMarker: 3
    Key: joJ4+/2iYNxYK7q/CjkARIKZ0DQAAAAA

    objectclass: AgentKey
    Oid: 1b-0003610c-0a18-16b1-8a15-126e0a16d07d
    KeyMarker: 4
    Key: joJ4+/2iYNxYK7q/CjkARIKZ0DQAAAAA

    objectclass: AgentKey
    Oid: 1b-00036107-0a18-16b1-8a15-126e0a16d07d
    KeyMarker: 1
    Key: joJ4+/2iYNxYK7q/CjkARIKZ0DQAAAAA

    objectclass: AgentKey
    Oid: 1b-00036109-0a18-16b1-8a15-126e0a16d07d
    KeyMarker: 2
    Key: joJ4+/2iYNxYK7q/CjkARIKZ0DQAAAAA

    objectclass: AgentKey
    Oid: 1b-0003610b-0a18-16b1-8a15-126e0a16d07d
    KeyMarker: 3
    Key: joJ4+/2iYNxYK7q/CjkARIKZ0DQAAAAA



  • 9.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 19, 2016 07:35 PM

    As per the design, the encrypted key store export is NEVER the same.

    So, even if the underlying keys are same, every time you export keys either from same or different PS , they will always be different if they are encrypted. So don't worry about the key out put being different in r12.0 , they are most likely the same internally.



  • 10.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 19, 2016 11:49 PM

    Hi Ujwol,

     

    So I went into the r12.52 policystore LDAP database (CA Directory) and I located all 8 agent keys and deleted them along with the persistent key as well.  Then I ran the "smkeyimport" and now I see only 4 keys along with the persistent key.  I then restarted the directory server first then the policy server and tested SSO and still failing.  Any more suggestions for me at this point?  I think one way for me to get the SSO between these two policy servers working is to manually reset the static agent + session ticket key on both the r12.0 and r12.52 server to the same value, but I want to avoid doing this because when I am ready for the production environment, this action will have impacts on the existing applications/web agents and may require restarting of the web servers causing downtime.  Below is the new output of the smkeyexport:

     

    R12.0 PS keys:

    #! SiteMinder Version 12.0
    # Export Flags: Clear Text, Export Keys, Export Key store data.
    objectclass: Root
    Oid: 0a-00000000-0000-0000-0000-000000000000
    AgentTypes:
    Schemes:
    Agents:
    AgentGroups:
    UserDirectories:
    Domains:
    Admins:
    AuthAzMaps:
    CertMaps:
    SelfRegs:
    ODBCQueries:
    PasswordPolicies:
    KeyManagement: 1a-fa347804-9d33-11d3-8025-006008aaae5b
    AgentKeys: 1b-000bab18-0218-1fd9-8206-12970a1610b6, 1b-000bab0e-0218-1fd9-8206-12970a1610b6, 1b-000bab11-0218-1fd9-8206-12970a1610b
    RootConfig:
    VariableTypes:
    PropertyCollections:
    TaggedStrings:
    TrustedHosts:
    IMSDirectories:
    IMSEnvironments:
    IMSOptionLists:
    SharedSecretPolicy:
    IMS6Directories:
    IMS6Environments:

    objectclass: KeyManagement
    Oid: 1a-fa347804-9d33-11d3-8025-006008aaae5b
    IsEnabled: false
    ChangeFrequency: 0
    ChangeValue: 0
    NewKeyTime: 0
    OldKeyTime: 0
    FireHour: 0
    PersistentKey: {RC2}NunWKma1lR3ePosSbF4OqYqLr7ExDFlxqhON1/8sz0jt2EG1wtwvp+cza0AUw6kw

    objectclass: AgentKey
    Oid: 1b-000bab18-0218-1fd9-8206-12970a1610b6
    KeyMarker: 4
    Key: {RC2}sDbZBbwE/jqL6sQdH/15geB7LjwBSOpKu2x6BKr0jp2F3akhn6ABUBpZFhOIvWyg

    objectclass: AgentKey
    Oid: 1b-000bab0e-0218-1fd9-8206-12970a1610b6
    KeyMarker: 1
    Key: {RC2}GU5vbQh0y5iQUfIkPF+EAactZvFffDiwocTKAKDyDnKqvmxO9qaSdYPj0x4G32Tj

    objectclass: AgentKey
    Oid: 1b-000bab11-0218-1fd9-8206-12970a1610b6
    KeyMarker: 2
    Key: {RC2}jzXxUYpXTiGcHU4UDN0GZWgi0tXm8oC1exDlEv99R0pVdvD4SFU6yFDypnf2vvOL

    objectclass: AgentKey
    Oid: 1b-000bab15-0218-1fd9-8206-12970a1610b6
    KeyMarker: 3
    Key: {RC2}fZo+jm65GX3uKBB/ZFuOHgptJqDhstuapWmb6/OuurTgTTv1d8czZHqgibCrnkrS

     

     

    R12.52 new keys:

    #! SiteMinder Version 12.52
    # Export Flags: Clear Text, Export Keys, Export Key store data.
    objectclass: Root
    Oid: 0a-00000000-0000-0000-0000-000000000000
    AgentTypes:
    Schemes:
    Agents:
    AgentGroups:
    UserDirectories:
    Domains:
    Admins:
    AuthAzMaps:
    CertMaps:
    SelfRegs:
    ODBCQueries:
    PasswordPolicies:
    KeyManagement: 1a-fa347804-9d33-11d3-8025-006008aaae5b
    AgentKeys: 1b-000bab18-0218-1fd9-8206-12970a1610b6, 1b-000bab0e-0218-1fd9-8206-12970a1610b6, 1b-000bab11-0218-1fd9-8206-12970a1610b6, 1b-000bab15-02
    18-1fd9-8206-12970a1610b6
    RootConfig:
    VariableTypes:
    PropertyCollections:
    TaggedStrings:
    TrustedHosts:
    IMSDirectories:
    IMSEnvironments:
    IMSOptionLists:
    SharedSecretPolicy:
    IMS6Directories:
    IMS6Environments:

    objectclass: KeyManagement
    Oid: 1a-fa347804-9d33-11d3-8025-006008aaae5b
    IsEnabled: false
    ChangeFrequency: 0
    ChangeValue: 0
    NewKeyTime: 0
    OldKeyTime: 0
    FireHour: 0
    PersistentKey: THmi5LOXHiDlCgP6tPJGqC1kK9lbZK/v

    objectclass: AgentKey
    Oid: 1b-000bab18-0218-1fd9-8206-12970a1610b6
    KeyMarker: 4
    Key: aMQta7keVCkZG9tg9qOLZV7vswdDxwYn

    objectclass: AgentKey
    Oid: 1b-000bab0e-0218-1fd9-8206-12970a1610b6
    KeyMarker: 1
    Key: aMQta7keVCkZG9tg9qOLZV7vswdDxwYn

    objectclass: AgentKey
    Oid: 1b-000bab11-0218-1fd9-8206-12970a1610b6
    KeyMarker: 2
    Key: aMQta7keVCkZG9tg9qOLZV7vswdDxwYn

    objectclass: AgentKey
    Oid: 1b-000bab15-0218-1fd9-8206-12970a1610b6
    KeyMarker: 3
    Key: aMQta7keVCkZG9tg9qOLZV7vswdDxwYn



  • 11.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 20, 2016 12:13 AM

    It looks to me you haven't' performed following step in your r12.0 setup before the export of keys :

     

    3. Rollover Agent Keys 4 times from r12.0 and Session Ticket Keys 1 time, to ensure they are not null and actually have values

    Can you please confirm ?

     

    Resetting agentkey/session ticket key whether static or dynamic does NOT need webserver restart.

    Policy server sends the updated keys to the agent on a regular basis determined by following ACO parameter.

     

    PSPollInterval

    Specifies how often (in seconds) the Web Agent contacts the Policy Server to retrieve information about policy changes or dynamically updated keys. Higher numbers (longer intervals) decrease network traffic. Lower numbers (shorter intervals) increase network traffic.

    Default: 30 (seconds)

     

    Moreover, as the purpose of agent keys and session ticket keys are as follows :

    Agent Keys - used by Agent to encrypt cookies

    Session Ticket Keys/Persistent Key - used by PS to encrypt session and identity specs

     

    So if the agent keys are stale at worst, SSO will fail and user will be re challenged.

     

    Can you also confirm what is the value for the following registry entry in your both 12.0 and 12.52 environment ?

    HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\ObjectStore

    DWORD key: AllowEmptyEncKey

     

     

     



  • 12.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 20, 2016 01:12 PM

    Hi Ujwol,

     

    I am very grateful for your help with this and wanting to make sure I fully understand the issue here and possible solution at hand so that we will be prepared when performing this in our production environment without surprises.  I have an active case open with CA Support on this issue, but they seemed to be quite slow with response and I find that you and other folks here are quite more knowledgeable and more helpful than CA Support. Let me reiterate for you on the setup of our existing r12.0 QA environment.  Our SiteMinder environments (DEV/QA/PROD) was initially setup by a CA consultant a short while back.  Our QA SiteMinder environment has two (2) policy servers and our PROD environment has three (3) policy servers.  Below are the current settings for the Agent Keys on these existing r12.0 policy servers for both environments, and of course SSO is working between the two QA policy servers and between the three PROD policy servers:

     

    *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

     

    For rolling the "agent key" I have the option of "Randomly Generate Key" rollover or I can "Specify Agent Key" then click on rollover now button.  For the Session Ticket Key, I also have those two options.

     

    So my question for you now is:

    1) Should I click on the "rollover now" button under the "Randomly Generate Agent Key" or should I specify a key value?

    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?

    3) Same thing with the Session Ticket Key, should I generate a random value with the rollover or specify specific value?

     

    Much thanks in advance!



  • 13.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 20, 2016 02:09 PM

    I went ahead and specified a static agent key and session ticket key value and rolled over.  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.  I did the same on the r12.52 policy server specifying the same agent key and session key but still no luck.



  • 14.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 20, 2016 02:43 PM

    I'm late to the party but would like to ask a question.  In your Dev environment, is the 12.0 and 12.52 policy servers sharing the same policy store?  I'm assuming they are not.  If they are not, 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?  Having non-matching encryption keys will keep SSO from ever working.  This just seems suspect to me since SSO is working in your other environments.



  • 15.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 20, 2016 03:27 PM

    Hi Samat,

     

    Thank you for your response.  I am not 100% absolutely certain that the policy server encryption keys between the two r12.0 servers in the QA environment matches with my new r12.52 QA policy servers, but I am about 95% sure that it is.

     

    I DID proceed to rollover the agent and session ticket keys in our existing r12.0 policy servers and it in deed cause some outages as I recall seeing in our DEV environment.  For many of the web agents the only impact is that if a user is currently login then that user will loose their session and will have to login again.  The big mess is with our Integrated Windows Authentication (IWA) web agent.

     

    After I initiated the agent/session ticket key rollover, it took about 15 minutes for both of our IWA web agents to start failing.  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.  I restarted the policy server few times and made no difference.  Meanwhile the other web agents that does not rely on the IWA as authentication scheme seem to be working fine, just the web agent for the IWA server that is affected.

     

    After a while things just started to work again by itself.  I would very much like to understand what is behind all of this because this is exactly what happened in my DEV environment a few months back when we were doing the DEV environment upgrade from r12.0 to 12.52.  It appears that only the IWA web agent that fails.  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?



  • 16.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 20, 2016 04:29 PM

    I feel like we are talking about multiple issues.  If the encryption keys don't match, you can roll keys forever and SSO won't ever work.  Have you tried taking IWA and everything else out of the loop and try using the smtesttool?  If you can't SSO between the 2 policy servers using that, nothing else will work.  That would be a good test to determine if there is a major underlying issue like mismatch of encryption key.



  • 17.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade
    Best Answer

    Posted Jul 20, 2016 07:44 PM

    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.

     



  • 18.  Re: SSO not working between SiteMinder r12.0 SP3 to r12.52 SP1 policy server in parallel upgrade

    Posted Jul 20, 2016 09:34 PM

    Ujwol / Sam / Hongxu,

     

    I want to extend my thanks to all of you for you expertise insights in helping me resolve this issue because it is now finally RESOLVED!

     

    It was indeed the multiple "sets" of agent keys in my r12.52 PS.  I just don't understand how I managed to get this to work in my DEV environment though with the exact same process/steps!  My r12.52 DEV PS still has 8 agent keys and it is still maintaining SSO with my r12.0 PS.

     

    So I did put a good amount of effort focusing on cleaning out the r12.52 keys by using LDAP Browser interface to pull up all of the "smAgentKeyOID4" objects and deleted them but I guess it wasn't clean enough for this to work.  What I finally ended up doing is whipping out EVERYTHING, the policy store and uninstalled all of the SiteMinder components and started FRESH!

     

    This time I performed the smkeyimport at the very beginning right after the initial import of the default SiteMinder objects then made sure to uncheck "Generate Agent Keys" before starting up the r12.52 PS that way the only set of keys in the r12.52 policystore is the ones imported from r12.0.

     

    Now that this SSO issue between policy servers is resolved, I still have one more outstanding issue with our r12.52 upgrade and this issue is with my r12.52 web agent + agent option pack in-place upgrade.  The SiteMinder Federation Services will stop working after I run the in-place upgrade of both the FSS web agent and agent option pack.  I get an error message saying that SiteMinder cannot find the SAML Service Provider ID that I am trying to invoke SAML SSO with.

     

    I initially created a separate case with CA Support on this, but I think I would have better luck with help from folks here at CA Community so I will create another thread for that issue.  Once again, I am very grateful for everyone's help, especially Ujwol!

     

    Thank you!