Skip to main content

OpenLab Security Test

The OpenLab Security Test confirms that the system can be reached only by authorized users and that access controls behave the way a regulated environment requires. It exercises authentication, password policy, role-based access, and activity logging in OpenLab Shared Services (OLSS), using temporary test users so it can prove the controls work without disturbing real accounts. The test requires enforced authentication to be available at all: it can run only on a system where login is required. Separately, it belongs to the recommended test set on Server, Workstation, and Workstation Plus systems, but not on Client or AIC machines.

What the test verifies​

The test creates an admin test user and a non-admin test user, then drives a sequence of checks with them. It is verifying three related promises that the system makes.

  • Authentication works. Valid credentials are accepted and invalid credentials are rejected, so the system genuinely requires a correct identity to log in.
  • Roles are enforced. The admin user can do what an administrator should, and the non-admin user is held to a limited set of privileges, confirming that role-based access control actually restricts access.
  • Activity is recorded. Security-relevant actions, such as creating users and granting privileges, appear in the OLSS activity log, so the system keeps the audit record a compliant lab relies on.

On systems that use internal authentication, the test also checks password policy and account lockout: it confirms a minimum password length is enforced and that repeated failed logins lock an account.

The activity log is central to the test, and on OLSS turning the activity log on is a one-way decision. The test fails if the activity log is not on, because without it the system cannot produce the audit record the test is there to verify. This enforcement applies on every storage backend. On OpenLab ECM systems the test additionally inspects the ECM audit trail, but it only records whether that audit trail is on; an ECM system can still pass that part even when its ECM audit trail is off, as long as the OLSS activity log is on.

Why it needs a license and a privileged user​

The Security Test requires the QlaSecurity license. The license is acquired the first time the test runs and stays held rather than returning to the pool, so each machine that runs the test consumes one. A single QlaSecurity license covers both this test and the Storage System Test. On Workstation Plus the license is included; on other products it is purchased and installed separately. If no license is available, the test fails at the license-check step.

The person running the test must hold the System Administrator role with the Manage Security and View Activity Log privileges. The test provisions users and reads the activity log, so it cannot run with a limited account, and it reports as not available when the running user lacks the required permissions.

Configuration with domain authentication​

When the system uses domain authentication, the test must be told which two domain users to act as before it becomes available, and a Configure button appears for that purpose. With internal authentication the test generates its own users and no configuration is needed. The configuration is entered once and applies across the machines in a client/server environment, where it propagates to the other machines within three minutes. For the steps, see Run verification tests.

How the test users are cleaned up depends on this configuration. Internal-authentication users are always removed when the test finishes or is aborted. Domain users are kept by default and removed only if you choose to.

note

If the Security Test and the Storage System Test share the same test users and one test removes them while the other is still running, the second test loses its account and fails with the message "Account is not authorized in this system. Contact system administrator." This can happen even when the two tests are started from different machines at the same time. Giving each test its own test users avoids the clash.

One account cannot be removed this way. If you set a currently logged-in user as a test user and choose to remove test users at the end, the test fails, because the system does not allow the removal of a user who is logged in. Avoid using your own account, or any active account, as a test user when removal is selected.

Where it fits​

The Security Test report records the authentication configuration, the test users and their roles, and the outcome of each individual check. It is stored with the other reports in the OpenLab storage backend, included in the overall Summary report, and available from the home page and the execution history.

See also​