About User Accounts

User accounts are provided in the test system to authenticate users, to determine the actions that are available to the user, and to provide an individual section in the Test Libraries for each user. Creating User Accounts creates associated User Libraries. Every user has a unique user name and password, and an assigned account type that defines the user's system permissions. The Real-Time Logs tracks user actions by user name, allowing you to track actions taken by users when troubleshooting system or test problems.

The use of accounts and passwords prevents unauthorized personnel from accessing the system and its data, and protects the system from unauthorized configuration changes. Passwords should be changed periodically to protect the system's security. By default, passwords will not expire. To set a duration for the password, click the Password Never Expires checkbox when adding or modifying a User account to clear the check mark, and enter the number of days for which the password will be valid in the Password Expires... field. A System Administrator can force users to change their passwords by setting a password expiration duration in the account definition. If your password expires, you will receive this error message : “User’s password has expired, please see System Administrator”.

In order for the user to login to the system, the User Enabled checkbox must be checked. It is checked by default. If you Disable the user (uncheck), [ ] User Enabled, this will prevent the user from logging in, the user will receive a generic authentication type error.

When TAS Setting (Edit Settings) - case_sensitive_usernames is set to “OFF”, the TAS will operate in case-insensitive mode for usernames WRT to authentication and user admin:

Creating a user from Landslide User Admin, the true case of the username will be established. And adding a second username with the same characters mixied case will fail. You will not able to create two users ‘Abcd’ and ‘abcd’. And since we do not allow modification of usernames, to fix wrong case username you should delete the bad one and add the corrected one.
For normal/local authentication: When a user attempts to login username `Abcd`, the TAS will first convert the entered username to lowercase ‘abcd’ and compare that against all system usernames set to lowercase. If the system has a user with the username `abcd` and the password matches, the user will be logged in, and the username will be set to the exact case in the system. Logging in as “aBcD” and finding “Abcd” in the system will result in “Abcd” for the username.
3rd party external authentication work as it does today. When a user with username `Abcd` logs in, it will match with a username “abcD” and if authentication succeeds:
1. If the TAS has a matching user, the username displayed will match the case in the TAS.
2. If the TAS does not have a matching user a user
  1. If Automatic Creation Of User Accounts is enabled, a user will be created with username ‘Abcd’, matching what they used in the login.
  2. Else Authentication will fail
When usernames are part of other objects or features (TS Assignments, User Groups, etc…), they will be expected to be matched case-sensitively, especially from the APIs. The case insensitive treatment should only be expected for logins and user admin.

When the TAS setting ‘case_sensitive_usernames’ option is set to ON, TAS will operate in case-sensitive mode for usernames WRT to authentication and user admin:

When a user with username `Abcd` logs in, if the system only has a user with the username `abcd`, TAS will authenticate using the username `Abcd` and fail.
When a user with username `Abcd` logs in via OIDC/Oauth2/TACACS+/LDAP, TAS will directly forward user entered authentication information to OIDC/Oauth2/TACACS+/LDAP to perform authentication or authorization. If user is authenticated and authorized, but the TAS only, if the system only has a user with the username `abcd`, the TAS will login user as `Abcd`.
If a situation arises where you have multiple users with conflicting usernames, you will see these types of errors: "There are multiple users with the same case-insensitive username. Click OK to view the help" . To keep using case sensitive usernames, just turn on support for it: #1. Turn on case_sensitive_usernames in TAS Settings ((Edit Settings)) (stop TAS, set setting, start TAS). To no longer use it: #1. Turn on case_sensitive_usernames (stop TAS, set setting, start TAS) #2. Delete the duplicate usernames #3. Turn off case_sensitive_usernames (stop TAS, remove the setting, start TAS).

The number of simultaneous users is governed by the system's licensed capacity.

When LDAP is enabled in Server Settings, all users except 'sms' will be authenticated by the LDAP server and not the internal password. LDAP requires that users be added to Landslide, their user names should match the user names in the LDAP server, minus their domain, if any.

IMPORTANT INFORMATION:

IMPORTANT:

The TAS supports 96 simultaneous logins (i.e. connections). The combination of (Tcl API + GUI Clients <= 48) + (REST (Web) Clients <=48) must never result in more than 96 client connections to the TAS in the same instant.

Account Types

There are four types of user accounts available, each with its own level of system permissions. See Account Permissions.

User Type

Permissions

Test Operators

Configure and execute tests, and manage their individual libraries and its contents. In addition, they also have access to Global Library and Custom Libraries.

NOTE: Test Operators cannot Save files to Global library. Only Test Administrators and above accounts may save to Global library.

Also, the Test Operators can write to their own library and sub folders and Custom Libraries with Writable by all and sub folders.

Test Administrators

Define SUTs, and have full control over all of the test libraries (Except Basic), in addition to the permissions of a Test Operator.

System Administrator

Perform system configuration tasks and assign lower level user accounts, in addition to the permissions of a Test Administrator.

Super User

Perform system operation tasks and assign System Administrators, in addition to the permissions of the System Administrator.

NOTE: The test system is delivered with a pre-configured Super User account. Only one Super User account is permitted in the test system: the "sms" user account. The password for this account can be changed; however, the user name and privilege level cannot be modified. The default password should be changed during the system installation.

With the User Account Administration window, System Administrators can:

User Account Administration is also supported by :

Supported by RESTFul API - Using the RESTFul API contains reference information about the Landslide RESTFul API system. Refer to Swagger UI on Landslide Home Page, it contains the latest most accurate information for anything it covers.

Everyone can:

Look up an account
Modify their own contact information and password

System Accounts

Two accounts are provided for SSH access to system platforms: the cfguser and tester accounts. These accounts are not used to access the test system through the Login window.

The cfguser account is used to manage and configure the test system's servers and to access the TAS Manager. The password for this account can be changed using the TAS Manager Console or TAS Manager Web UI, and should be changed during installation.

NOTE: Each platform maintains individual system accounts. Separate cfguser accounts exist on the TAS and on each test server. When the cfguser password is changed with the TAS Manager, only the TAS cfguser account is affected.

The tester account provides non-administrator access to the TAS for running benign commands on the TAS. Example include checking the TAS CPU, memory, or to execute network test commands like curl, ping, traceroute. The customer can change the password to disable access and Advanced Security will disable the login.

Learn more about using API Commands