Configure Symantec Directory as a Session Store

You can configure Symantec Directory as a session store by completing the following procedures:
You can configure Symantec Directory as a session store by completing the following procedures:
The procedures assume that Symantec Directory is installed and operating.
In this topic use the following convention:
  • DXHOME= C:\Program Files\CA\Directory\dxserver (Windows)
  • DXHOME=/opt/CA/Directory/dxserver (UNIX)
Locate the Session Store Schema File
In the session store, the Policy Server uses its own LDAP directory objects. Symantec Directory has to know about the structure of those extra classes. The session store schema file, netegrity.dxc, lets Symantec Directory know the names and structure of those extra classes.
file is installed with the Policy Server. Verify that you have the correct schema file.
Follow these steps:
  1. Navigate to the directory
    \eTrust, where
    specifies the Policy Server installation path
  2. Verify that you have the schema file
    . This file creates the DSA session store schema, which lets the DSA store and retrieve user session information. If you do not have this file, contact your
    Administrator and request it.
Create a Directory System Agent (DSA) for the Session Store
Create a DSA and dedicate its use only to the session store. A dedicated DSA helps to maximize session store performance.
Follow these steps:
  1. Log in to the Symantec Directory host system.
  2. Create a data DSA by running the following command:
    dsa_name port prefix
    • dsa_name
      specifies the name of the session store DSA.
    • port
      specifies the port on which the session store must listen for requests.
    • prefix
      specifies the namespace prefix. Use LDAP syntax to specify the prefix.
    dxnewdsa smsessionstore 1234 o=forwardinc,c=us
    Forwardinc is a fictitious company name. The name is used strictly for instructional purposes only and is not meant to reference an existing company.
The DSA is created.
Create the Session Store Schema
The DSA requires the schema to store and retrieve the user session information.
Follow these steps:
  1. Log in to the Symantec Directory host system.
  2. Stop the DSA using the following command:
    dxserver stop
    is the name that you assign to the DSA.
  3. Copy the
    file from
  4. Navigate to
    \config\schema and paste
    into the directory.
  5. Create a schema file by following these steps:
    1. Copy the default DSA schema file (default.dxg). The default.dxg file is in the schema directory.
    2. Remove the read-only attribute from the copy.
    3. Rename the copy to create a new file. For example, rename the copy to smsession.dxg.
  6. Add the following lines to the bottom of the new schema file:
    #CA Schema
    source "netegrity.dxc";
  7. Save the file.
  8. Reapply the read-only attribute to the new schema file.
Set the Session Store Limits on the DSA
In the session store schema, set the session store default limits. The limits define DSA operations, such as how long an application stays connected to the DSA or how search queries are controlled.
Follow these steps:
  1. Navigate to
  2. Create a session store limits file by complete these steps:
    1. Copy the default limits file (default.dxc).
    2. Remove the read-only attribute.
    3. Rename the file, such as smsession.dxc
  3. In the size limits section of the
    file, set the
    setting to match the following example. This value represents a high limit. The session store is not expected to return more than 1,000 objects per search query.
    set max-op-size = 1000;
  4. Configure the
    multi-write queue
    setting. The multiwrite queue setting specifies the maximum number of transactions that are held in memory for a DSA that is unavailable. Use this setting to support a server that is offline for a given period. The default value is 20,000. Set the queue to handle from 300,000 through 500,000 transactions. The optimal value allows a normal reboot of one of the directory server hosts without causing the multiwrite queue to fill. For example:
    set multi-write-queue = 300000;
  5. Set the
    multi-write-outstanding-ops limits
    setting. This setting determines the number of updates that a DSA can send at one time, from its multiwrite queue to a recovering DSA. The default is 10. Based on the number of potential updates in the multiwrite queue, a DSA sending the default 10 updates at a time prolongs the automatic recovery of a DSA.  The recommenced value is 1000. For example:
    set multi-write-outstanding-ops = 1000;
  6. Save the file.
  7. Reapply the read-only attribute.
Modify the Session Store Initialization File
The initialization file (
.dxi) contains settings for configuring the following functions:
  • Indexes
    Optimization of the Symantec Directory indexes is critical for the overall performance of Symantec Directory. If you do not properly configure the indexes, the directory might experience slower response times for add and remove operations. Specify the attributes that require indexing in the
    set cache-index
  • Storing session objects in memory
  • Transaction logging
    By default, each Symantec Directory Data DSA is configured to use a transaction log. The session store does not need the transaction log and it can negatively affect the performance of the directory. So, disable logging.
Follow these steps:
  1. Navigate to
    \config\servers and open the session store initialization file
    specifies the name of the session store DSA.
  2. In the #schema section, edit the schema reference from default.dxg to the new file.
    Change default.dxg to smsession.dxg.
  3. In the #service limits section, edit the service limits reference from default.dxc to the new file.
    Change default.dxc to smsession.dxc.
  4. In the #grid configuration section, edit the
    set cache-index
    entry to match the following text:
    set cache-index = smSessionId, smExpirationTime, smIdleExpirationTime, smSearchData, smVariableName, smFullVariableName;
    Verify that the
    set cache-index
    entry is above the
    set lookup-cache
    entry, for example:
    set cache-index = smSessionId, smExpirationTime, smIdleExpirationTime, smSearchData, smVariableName, smFullVariableName;
    set lookup-cache = true;
  5. (Optional) To store more session objects in memory, compress the smVariableValue attribute using the following command:
    set compress
    is one of the following values: base64, hex, deflate, deflate1, deflate2. The deflate type is fastest, deflate1 balances speed with compression, and deflate2 tries for maximum compression.
    Use only base64 when all the values of the specified attributes are base64 encoded. Specify the hex type only when all values of the specified attributes are hex encoded. If the values of an attribute are encoded using any type other than base64 or hex, then use one of the deflate types.
  6. Ensure that the
    setting is set to false, the default setting. This session store does not need this recovery method. The correct entry is shown in the following example:
    set multi-write-disp-recovery = false;
    Routing DSAs do not need this setting.
    You can set up multiple DSA peers and use multiwrite replication, but
    do not
    use this feature with DISP recovery. For instructions on setting up replication, see the Symantec Directory documentation.
  7. (Optional) Disable transaction logging to improve performance. It is enabled by default. To disable logging, add the following setting to each initialization file:
    set disable-transaction-log = true;
    Place the logging entry
    the entry set multi-write-disp-recovery = false. For example:
    set multi-write-disp-recovery = false;
    set disable-transaction-log = true;
    Disabling the transaction logging is not required for the routing DSAs. Consider the effects disabling transaction logging has on data recovery. For more information, see the Symantec Directory documentation.
  8. (Optional) If session store DSAs are replicated, add the dsp-idle-time setting to the DSA
    file (
    /config/knowledge/). Setting the idle time is useful so that the idle time is not too low. If set too low, the link between a multiwrite DSA and its recovering peer DSA can time out before the DSA is recovered.
    dsp-idle-time = 30
  9. Restart the DSA using the following command:
    dxserver start
The session store schema is configured.
Session Store Backups Not Required
It is not necessary to to back up the session store as the data within it is always changing. Restored data would therefore be out-of-date and inaccurate.
Asynchronous Replication
You can configure DSA replication so that the same directory information is stored on several servers. Replication is deployed to improve the availability of directory servers so applications can continue working. Replication can also improve performance by enabling load balancing between DSAs.
The Symantec Directory session store processes update requests (modify/add/remove) at a high volume. To optimize the replication configuration across all the DSA session stores including the local stores, set replication to asynchronous. Updates that are sent asynchronously free up threads so that they can continue processing requests without waiting for validation. Therefore, replication performance is efficient.
Follow these steps:
  1. Navigate to
    /config/knowledge/ of the DSA.
  2. Set the option
    as a dsa-flag in the knowledge configuration of all DSAs. For example:
    [ dsa-flags = multi-write-async, no-service-while-recovering ]
Enable the Policy Server to Manage the Session Store
For the Policy Server to manage the session store, complete the following tasks:
  • Add a session store administrative user to the DSA
  • Establish a root DN for the session store.
  • Point the Policy Server to the session store.
Add a Session Store Administrative User and Root DN for the DSA
For the Policy Server to manage the session store, it requires the following information:
  • The complete distinguished name (DN) and password of a user in the DSA. The Policy Server uses these credentials to manage the session store.
  • A root DN to which session information can be written.
Follow these steps:
  1. Access the DSA using anonymous authentication with
    of the following methods: These procedures use the JXplorer tool.
  2. Create a user that the Policy Store can use to manage the session store.
    • Be sure to create the user with only the following OBJECT CLASS:
    • Note the credentials. The credentials are required to point the Policy Server to the session store DSA.
  3. Disconnect from JXplorer.
  4. Start JXplorer.
  5. Log in to the DSA using the complete DN of the administrative user you created to verify that you can access the DSA.
  6. Manually create an organizational unit that serves as the root DN of the session store.
  7. Disconnect from JXplorer.
We recommend that you disable the anonymous authentication to prevent unauthorized access to the session store.
Point the Policy Server to the Session Store
Point the Policy Server to the session store DSA so the Policy Server can manage the session store.
Follow these steps:
  1. Open the Policy Server Management Console.
    On Windows Server, if User Account Control (UAC) is enabled open the shortcut with Administrator permissions. Use Administrator permissions even if you are logged in to the system as an Administrator. For more information, see the release notes for your
  2. Click the Data tab.
  3. Select Session Store from the Database list.
  4. Select Symantec Directory from the Storage list.
  5. Select the Session Store Enabled option.
  6. Under LDAP Session Store section:
    1. Enter the IP address and port of the session store DSA.
    2. Enter the root DN of the session store DSA.
    3. Enter the complete DN of an administrative user in the DSA.
    4. Enter the password of the administrative user.
  7. Click Test LDAP Connection to verify the connection.
  8. Click OK.
  9. Restart Policy Server.
The Policy Server is configured to manage the session store.
Session Store Performance Optimization
If your environment requires high performance, consider the following recommendations:
  • Symantec Directory supports namespace partitioning which allows for the data for a single OU to be divided up among multiple DSAs.  This can have a significant impact on performance by allowing more DSAs to handle the LDAP request load. Data Partitioning allows you to take advantage of all available hardware, including extra CPUs on a single host or CPUs across multiple hosts. The more replicas you have, the more parallel writes to the directory can occur.
    If your environment has CPUs or cores on the existing host or on other hosts that not being leveraged, consider configuring partitioning the Symantec Directory namespace.
  • Do not index all session store attributes. Configuring a high number of indexes on session data degrades deletion performance. Only index session store attributes that are used in your deployment. To determine which indexes are used in a deployment, see the Symantec Directory documentation.
  • Use partitions but have each partition on a separate host.
  • Allow enough physical memory to contain all Symantec Directory server data files for each host. The host can be a physical system or a guest instance. You can view the size of the data files in the data directory of the Symantec Directory server installation.
  • Verify the following entries in the initialization file
    .dxi) for your DSA. This file resides in the directory
    /config/servers. If these entries are not in the file, add them.
    • Disable Symantec Directory transaction logging by adding the following command to the server file:
      # disable transaction logging for performance
      set disable-transaction-log = true;
      set disable-transaction-log-flush = true;
      If there is a service interruption, disabling transaction logging without enabling replication requires users to log in again.
    • Use a default single queue by adding the dxgrid-queue command. The setting for this command defaults to "true." For example:
      # use single queue in front of DSA instead of
      # one queue per thread
      set dxgrid-queue = true;
  • Add the following registry keys that affect the performance of an LDAP session store in the
    registry location, and customize their values as required:
    • SessionUpdateGracePeriod
      Specifies, in seconds, the grace period for updating the session store record. Enter a hexadecimal number. If multiple requests to validate a session are sent to the Policy Server within the time that is defined by SessionUpdateGracePeriod, those requests only require a single round trip to the session store. If there are no changes to the session store record, it is only updated if the last touched time difference from the current time equals or exceeds the value that is placed in this variable. SessionUpdateGracePeriod affects idle timeout (effective idle timeout = idle timeout + SessionUpdateGracePeriod). If this registry key is not added, the default grace period is 0x1.
    • MaxConcurrentDeletes
      Determines how many pending delete requests are sent to the directory server at any given time. Expired sessions in LDAP are deleted at regular intervals. Reduce this value if you have an excessive deletion load on your session store. Enter a hexadecimal number. If this registry key is not added, the default count is 0x19.
    • MaintenanceQueryRowLimit
      Specifies how many expired session records are deleted simultaneously. Reduce this value if you have high delete/insert contention against your session store. Enter a hexadecimal number. If this registry key is not added, the default count is 0x64.
      : 0x64
    • EnableFlushUserCmdOnLogout
      Specifies whether users are flushed from the session store cache on logout. Enter 1 to enable the parameter or 0 to disable the parameter. If this registry key is not added, the users are not flushed.
Connection Pools
A connection pool is a cache of database connection handles that is maintained so that the connections can be reused when future requests to the database are required. The Policy Server uses a connection pool (of 10 LDAP connection handles by default) to enhance session store performance.
However, if too many concurrent threads require a session store connection handle, the connection pool can be overwhelmed and the thread queue can build up. To diagnose this issue, search the Policy Server profiler log for requests with a delay before LDAP handles are locked. Such a delay indicates that you must increase the number of session store connections
For example, the following excerpt from the profiler log shows a two-second wait before the worker thread ID 3003599728 was able to get an LDAP connection handle:
.671][26918][3003599728][Leave function CSm_Auth_Message::SetAuthContext][Sm_Auth_Message.cpp:4280][CSm_Auth_Message::SetAuthContext]
.671][26918][3003599728][Lock LDAP handle. slot=0 ld=0xb3071fe0][LdapStore.cpp:375][Lock_LdapHandle]
(The delay is indicated by the 2-second difference between the message timestamps, which are shown in bold.)
To increase the size of the session store connection pool, modify the value MaxConnections registry setting, which can be found at the following registry location:
: Connection pool size in hex. For example, 0xf (15)
: 0xa (10)
: Configure a value close to half the max worker thread value so you have at least one connection handle for every 2 worker threads. This recommendation varies based on the hardware that is used and other environmental factors. For optimal performance, we recommend testing these settings in a test environment and modify as required to adjust to your environment.
Deleting Excess Expired Sessions in High Volume Environments
Policy Servers that are configured to use Symantec Directory as a session store are responsible for creating sessions and then cleaning up the expired sessions. The Policy Servers create sessions when users authenticate, then periodically, the Policy Server searches for sessions that have expired and removes them.
In high volume environments, the Symantec Directory session store can fill with excess expired sessions. If you encounter this issue, open an issue with Broadcom Support, who can provide you with the SMDeleteSession utility, which continuously checks for and removes expired sessions.