How to identify expired persistent session with dxsearch or ldapsearch, then clean them up
search cancel

How to identify expired persistent session with dxsearch or ldapsearch, then clean them up

book

Article ID: 264535

calendar_today

Updated On:

Products

SITEMINDER CA Single Sign On Federation (SiteMinder) CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) CA Single Sign On Agents (SiteMinder)

Issue/Introduction

In a production setup, session store record size keeps increasing, while policy server does not appear to clean them up on time or not fast enough.

Environment

Release : ALL SiteMinder Releases.

This particular use case is reported on 12.8.06a.

Cause

Out of box, all realm should have max/idle timeout configured. When max/idle timeout is NOT configured in a non-persistent realm, and user is authenticated between non-persistent and persistent realm, the session sometimes will be created/exchanged with a future time stamp (about 10 years validity).

Since policy server only deletes a session that is marked as expired, any session record that its smExpirationTime with a future time stamp will never be removed from store. Hence number of records keeps growing.

For example:

dn: smSessionId=//4AXRnyfXJe/T1b8VnfWAENwqY\=,o=example,c=us
objectClass: smSession
objectClass: top
smSessionId: //4AXRnyfXJe/T1b8VnfWAENwqY=
smIdleExpirationTime: 20230407211701Z
smMaxIdleTime: 86400
creatorsName: uid=myadmin,o=example,c=us
smSessionStatus: 0
smExpirationTime: 20380407211701Z
smLastAccessTime: 20230406211701Z
smSessionBlob: //4AXRnyfXJe/T1b8VnfWAENwqY=
createTimestamp: 20230406211701.549Z

Resolution

First of all, all realms should have max/idle timeout configured. This will ensure smsession always have a valid reasonable Expiration Time.

SiteMinder admin should check how many records actually in the session store, please keep track of them daily.

From policy server, ~\siteminder\bin\ldapsearch  -h  computer-name -p 389   -D "UserID" -w password -b o=sessionstore  objectclass=smSession dxEntryCount
Or
From DSA server bin, run as user DSA, dxsearch -h LDAP-computer-name -p 389  -b "o=sessionstore"  objectclass=smSession dxEntryCount

smSessionId is the primary table where session master record is kept. Other entry or tables can be associated with existing smSessionId record, if a child record does not have links to smSessionId, chances are that they are already orphaned.  e.g.  refresh token is always tied to a smsessionid record. In fact, its dn PATH contains value of parent smsessionid.

For example:

dn: smSessionId=//4AXRnyfXJe/T1b8VnfWAENwqY\=,o=example,c=us
objectClass: smSession
objectClass: top
smSessionId: //4AXRnyfXJe/T1b8VnfWAENwqY=
smIdleExpirationTime: 20230407211701Z
smMaxIdleTime: 86400
creatorsName: uid=myadmin,o=example,c=us
smSessionStatus: 0
smExpirationTime: 20380407211701Z
smLastAccessTime: 20230406211701Z
smSessionBlob: //4AXRnyfXJe/T1b8VnfWAENwqY=
createTimestamp: 20230406211701.549Z

dn: cn=bIp9SqIXxxxxxxxxxxxxxxxxxxxxxxxxldKqreLIM\=,smSessionId=//4AXRnyfXJe/T1b8VnfWAENwqY\=,o=example,c=us
objectClass: smSessionVariable
objectClass: top
cn: bIp9SqIXxxxxxxxxxxxxxxxxxxxxxxxxxdKqreLIM=
smFullVariableName: refresh_token
smVariableName: refresh_token
creatorsName: uid=myadmin,o=example,c=us
createTimestamp: 20230406211701.551Z
smVariableValue: eyJjaWQiOiJNeUNhbm9uIiwidWlkIjoidXVpZD0zZDFhMTkyNjgzYTQyNmN
 9uLGRjPWNvbSIsInJ1cmkiOiJodHRwczovL........................................MvTU95R
 WR5TkNuVF......................................................OTdMMjEwPSIsImF1dGhM
 ZXZlbCI6IjUifQ==

Here are LDAP command that will let you search and find out old expired smsessions (older than Sep 1, 2022) to be deleted.

Login as dsa on CA directory server /opt/CA/Directory/dxserver/bin

// return count

./dxsearch -h host -p port  -b "o=example,c=us"  "(&(objectclass=smSession)(createTimestamp<=20220901143415.351Z))"  dxEntryCount

// return all results

./dxsearch -h host -p port  -b "o=example,c=us"  "(&(objectclass=smSession)(createTimestamp<=20220901143415.351Z))"  > to_be_deleted.ldif

//only return cn of the object

./dxsearch -h host -p port  -b "ou=smsession,o=example,c=us"  "(&(objectclass=smSession)(createTimestamp<=20220901143415.351Z))"  cn > to_delete.ldif         

You can then verify the to_be_deleted.ldif content and confirm that they are old record and safe to delete.

The key is making sure search within (objectclass=smSession), otherwise, one could delete things that are not part of smsession object, result in data corruption.

Apply the same logic, one could delete older refresh_token if wants to, which belongs to (objectclass=smSessionVariable).

To actually delete the record, use command line tool like dxdelete, ldapdelete, or any other 3rd party LDAP tool.