How to identify expired persistent session with dxsearch or ldapsearch, then clean them up
Article ID: 264535
Updated On:
Products
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.
Feedback
