User accounts

SafeLinx maintains a user database that contains account information for each user. These user account records can be added to the database in one of two ways, depending on how you manage authentication.

In environments where users authenticate against an external directory server or RADIUS server, or use certificate-only authentication for HTTP access services, SafeLinx generates user records automatically. When a user authenticates through one of these methods, SafeLinx retrieves information about the user from the authentication server or certificate. The information is then used to populate an entry in a shadow directory. Records are created automatically the first time that a user logs in to SafeLinx. The shadow directory is maintained as in a table that is called WLUSER within the SafeLinx configuration database (wgdata), and is available from the following container path: SafeLinx > System > Users.

User records in the shadow directory store attribute information that define the user and the user's interactions with SafeLinx. For example, user attributes report the date and time of the last successful login and of failed login attempts. User records also preserve information about the internal application servers or server pools that a user is assigned to. For a complete list of user attributes, type the following command from a SafeLinx Server command line:

lswg -T -s ibm-wlUser

To prevent the shadow directory from accumulating stale records, you can enable automatic cleanup of user records. For example, you can configure records to be removed if there is no user activity for a specified number of days.

In environments that do not rely on an external server or certificate for primary authentication, user records are not created automatically. You must use the SafeLinx Administrator to add a record for each user who connects to the server. To authenticate a connecting user, the SafeLinx Server examines the credentials that the user submits, and then searches the user database for a matching record. It then retrieves the encrypted password from the record, decrypts it, and compares it to the one that the user submitted. If the credentials match, the connection can be accepted, or you might require secondary authentication through a query to an external authentication server.

If you specify that the user ID requires a password, you assign a password policy that defines the password rules. For more information, see Wireless password policies.

Note: Do not store your users in a relational database with the same base distinguished name (DN) as access manager.

A user ID must be no greater than 32 characters and contain no spaces. It is not case-sensitive. For more information about adding user IDs in SafeLinx Administrator, see Adding users.