Persistent data storage requirements

The SafeLinx Server has specific requirements that are necessary to successfully store, manage, and use persistent data.

Your data consists of:
  • Your users of this product
  • Real-time session-related information that is maintained for each active user. Session data tracks all of the activities that take place during the establishment, maintenance, and release of any connection to the SafeLinx Server.
  • Accounting and billing information that is optionally collected by this product
  • Configuration information about your information technology (IT) resources
SafeLinx Server requires that configuration data about resources is stored by using one of these methods:
  • A version 3 Lightweight Directory Access Protocol (LDAP) directory service server (DSS)
    Note: Version 3 LDAP directory service server (DSS) Support is now limited to Tivoli® Directory Server only.
  • An ODBC-compliant relational database. For DB2® and Oracle installations, both the RDB client and server need to be installed. The RDB client must be installed on the same system as the SafeLinx Server. Messaging services require that you use an ODBC-compliant RDB to store session data
    Note: SafeLinx does not support the use of Oracle database with Microsoft™ Windows™ deployments. IBM® DB2 and Microsoft SQL Server are both tested and supported for use on Windows Server.

    The Oracle client is not supported. For deployments that use Oracle database, you must obtain a licensed copy of DataDirect Connect for ODBC for the operating system on which you plan to install the SafeLinx Server. The DataDirect ODBC Oracle Wire Protocol driver is also required.

  • The local file system. This option is valid for use with stand-alone installations only. Stand-alone installations might include proof-of-concept deployments or production environment that support fewer than 100 users.
    Note: This option is not available on 64-bit Windows since it is not available from the Database Configuration wizard.
After you begin to use one of the preceding methods to store configuration data, if you want to switch to a different method, you must first back up the existing configuration. Failure to back up the configuration results in the loss of configuration information. For more information about backing up and restoring the SafeLinx configuration, see the Backup & Imports tech notes listed on the Featured documents for HCL SafeLinx page on the HCL Product Support site.

The choice of where to store session and optional accounting and billing data is made during installation. On Windows, the choice of where to store configuration information occurs when you initially start the SafeLinx Administrator and configure the access manager.

Use the following worksheets to gather information for persistent data storage.

Table 1. General data storage worksheet
Description Gather your information here
Base DN - the suffix (base distinguished name) to indicate the highest entry in the directory information tree. This value in X.500 notation typically defines the organization and country (for example, o=hcl, c=us). This suffix serves as the parent or root of the database hierarchy for the SafeLinx Server. The default value is o=local.
Table 2. DSS worksheet
Description Gather your information here
Admin's distinguished name (DN) - used when you configure a DSS
Admin's password
Table 3. DB2 relational database worksheet
Description Gather your information here
Database name - The default value of the session database is wgdata. The default value of the accounting and billing database is wgacct.
Database administrator ID
Database administrator password
Database instance
Table 4. SQL Server relational database worksheet
Description Gather your information here
Database name - The default value of the session database is wgdata. The default value of the accounting and billing database is wgacct.
Server and instance name - The name of the instance and SQL Server to which the SafeLinx Server connects.
Login name and password - SQL Server requires that each database user is authenticated with a login name and a login password. Also, specify the SQL Server authentication mode.
Authentication mode - Choose from:
  • Windows - SQL Server validates the login name and password by using information in the Windows operating system. This method is considered more secure than using SQL Server authentication. When you choose Windows authentication, the services that are installed to begin when the operating system starts also use these login credentials.
  • SQL Server - The SafeLinx Server uses the user ID and password defined only to SQL Server and SQL Server completes the authentication itself.