Layer7 Access Management

Tech Tip - CA Single Sign-On:Policy Server:Persistent Key/Session Ticket Key Introduced

By Ujwol posted 09-02-2016 03:36 AM

  

Question:

  • What is Persistent Key / Session Ticket Key ? What is it used for ?
  • Where and how is Session Ticket Key stored ?
  • What is the impact of resetting Persistent Key/ Session Ticket Key?

Environment:

Policy Server : Any 

Answer:

 

What is Persistent Key / Session Ticket Key ? What is it used for ?

Persistent/Session Ticket Key is used for following purpose by Policy Server :

  1. To encrypt Session Ticket (Spec). The session ticket is what the Policy Server uses to determine how long a user’s authentication remains valid. This session ticket is encrypted using the session ticket key and cached in the Agent User Cache.The Session Ticket can only be decrypted by Policy Server.

SESSION Ticket (Spec)contains following list of information :

  • SessionVersion
  • SessionStartTime
  • SessionLastTime
  • SessionMaxTimeout
  • SessionIdleTimeout
  • SessionLevel
  • SessionId
  • SessionIp
  • SessionDn
  • SessionDirOid
  • SessionDirName
  • SessionUnivId
  • SessionType
  • SessionAnonymous
  • SessionImpersonatorName
  • SessionLoginName
  • SessionPersistent
  • SessionDrift
  • SessionImpersonatorDirName
  • SessionAuthContext

    2.   To encrypt password service data (blob) in the user directory. The password blob contains following list of information:

    • LoginFailures (count)
    • LastLoginTime
    • PreviousLoginTime
    • PasswordHistory
    • LastPasswordChange (Date & Time)

Where and how is Session Ticket Key stored ?

Session Ticket key is stored in the Key Store.

In case of LDAP key store, it is stored under following DN :

smKeyManagementOID4=<id>,ou=PolicySrv4,ou=Siteminder,ou=Netegrity,<ROOT DN>


Example :

smKeyManagementOID4=1a-fa347804-9d33-11d3-8025-006008aaae5b,ou=PolicySvr4,ou=SiteMinder,ou=Netegrity,o=siteminder,c=in

 

In case of ODBC Key store, it is stored in KeyMangement4 table :

 

What is the impact of resetting Persistent Key/ Session Ticket Key?

Resetting persistent Key has following impacts :

  • Existing logged in user sessions will not be valid anymore. User will have to re-login to establish a new session.
  • Existing password blob will be no more be valid, which means all the information related to password change, login tracking etc. is lost.

Additional Information:

https://docops.ca.com/ca-single-sign-on-12-52-sp1/en/administrating/configuring-and-managing-encryption-keys

9 comments
3 views

Comments

07-26-2018 05:52 PM

Hi Ujwol,

 

You mentioned above that the password blob will be lost when the persistent key is reset. Can you advise on the impact to users?

 

Will all users logging into applications via SiteMinder need to immediately reset their passwords?

 

Will SiteMinder overwrite the current password blob with the new key and start collecting fresh password data?

 

Please advise on user or system implications.

 

Thanks,

Jaime

09-22-2017 06:58 AM

Hi Ujwol,

 

Thanks for the clarification.

 

Regards,

Dhilip

09-22-2017 04:27 AM

Ah, that has a different purpose.

It is just to enable/disable manual agnet key rollover.


It has nothing to do with persistent key.


https://communities.ca.com/community/ca-security/ca-single-sign-on/blog/2017/08/09/tech-tip-ca-single-sign-on-web-agent-how-to-enable-manual-key-rollover-option-for-dynamic-agent-keys

09-22-2017 02:39 AM

Hi Ujwol,

 

Thanks for your detailed explanation for all my questions.

 

1) I could see a parameter named "IsEnabled" in KeyMangement object. What is the significance of this attribute? In fact, this attribute is the reason for my questions in previous comment.

 

2) In case, if we did not add AllowEmptyEncKey in registry but we have set the value of IsEnabled to 0, what will be the behavior/drawback?

 

Regards,

Dhilip

09-21-2017 07:47 PM

Hi Dhilip ,

 

Glad you found it useful.

Please find answer to your questions below :

 

1) Could you please elaborate the below point? "To encrypt password service data (blob) in the user directory"

Ujwol => When you configure basic password policies , you must also specify a password data (blob) attribute in the user store definition :

 

 

This attribute stores various sensitive data such as :

  1. Current Login Failure Count
  2. Last Login Timestamp
  3. Previous Login Timestamp
  4. Disabled Timestamp
  5. Password History
  6. Last Password Change Timestamp (from the most recent entry in the Password History)

 For this reason, this data is encrypted using the session ticket key.

You can read more about this here :

Tech Tip - CA Single Sign-On:Policy Server: Read Password Blob Utility 

 

2) How to enable/disable the Persistent key (without modifying it directly in Directory/DB)?

Ujwol => You can rollover Persistent Key/Session Ticket Key from Admin UI.

3) Why there is a provision to disable this key? On which scenarios, it should be disabled? 

Ujwol => There is no option to disable persistent key from Admin UI.

However, you can configure policy server to continue work even when it can't decrypt the current persistent key from key store.

This can be done via registry 

HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\ObjectStore

DWORD key:

AllowEmptyEncKey

I have explained in detail the scenerio where this may be applicable here :

Tech Tip : CA Single Sign-On : Data Protection, Key Management,Configuration & Common Issues 

 

Refer to : "2. "No Session" error in Administrative UI  and "Failed to decrypt persistent key error" in SMPS log."

Having said that , it is a bad security practice to enable this key. You should disable this as soon as you fix your persistent key.

 

4) If this key is disabled, will the Session Ticket be embedded in siteminder cookie without any encryption? What are all the drawbacks of having this key disabled?

 

Ujwol => If  AllowEmptyEncKey=1 and if the current persistent key can't be decrypted, then the session ticket will be encrypted with the null keys which is vulnerable as may be able steal it and decrypt it without having the matching persistent key in your setup.

 

Let me know if any further questions.

 

Regards,

Ujwol

09-21-2017 08:17 AM

Hi Ujwol,

 

Thanks for this useful post. Have few questions.


1) Could you please elaborate the below point?
To encrypt password service data (blob) in the user directory

2) How to enable/disable the Persistent key (without modifying it directly in Directory/DB)?

3) Why there is a provision to disable this key? On which scenarios, it should be disabled? 

4) If this key is disabled, will the Session Ticket be embedded in siteminder cookie without any encryption? What are all the drawbacks of having this key disabled?

 

Thanks.

 

Regards,

Dhilip

09-14-2016 03:48 AM

Good questions

Please find my answers below :

 

1.  what are the cases that policy server needed to decrypt the session ticket key and validate ?

Ujwol : Once the user is authenticated, it maintains the usersession in its local cache. However, if it receives a session cookie , for which it couldn't validate the session information (may be it is not present in the agent cache) or the session validation period is expired (in case of persistent session) , it needs to send the session validation request to Policy server. This is the case where policy serve needs to decrypt the session ticket to validate the user session.

 

2.  do policy server need to call keystore every-time it need to decrypt or it will be cached on policy servers as well ?

Ujwol : No, the Persistent key is cached so Policy server doesn't' need to contact key store every time.

 

3.  what is the dis advantage of loosing the password blob data when there is reset ?

Ujwol : I have covered this above - the disadvantage is that if the password blob is reset all the information related to password change, login tracking,password history etc. is lost.

 

Regards,

Ujwol 

09-13-2016 06:11 PM

Hi Ujwol , Nice information . Thank you /-

 

Couple of questions if you can help

 

1.  what are the cases that policy server needed to decrypt the session ticket key and validate ?

2.  do policy server need to call keystore every-time it need to decrypt or it will be cached on policy servers as well ?

3.  what is the dis advantage of loosing the password blob data when there is reset ?

09-02-2016 03:42 AM