User Management
The Admin UI, Control API, REST API, and CLI each require a username and password to authenticate each connection. This login authenticates the user and, by way of Permissions Groups, defines the authorization the user has to read, write and otherwise manage configuration and system operation.
In order to configure users and groups, click System > Users.
User Authentication
The Virtual Traffic Manager verifies a user’s credentials (username and password) against two authentication sources:
- Local Users: Credentials are stored locally in the Virtual Traffic Manager configuration.
The Virtual Traffic Manager includes a factory-default local user "admin" that has full administrative permissions (in other words, is a member of the "admin" Permissions Group). In basic administration environments, users log in with this account to perform configuration tasks.
You cannot rename user accounts, but you can remove them. If you want to remove the "admin" user, you must first ensure that another user account with equivalent admin permissions exists so that you can log in and manage your cluster.
- Remotely authenticated users: Credentials are authenticated against externally-located systems based on RADIUS, LDAP or TACACS+ services.
Authenticators define how the Virtual Traffic Manager verifies usernames and passwords against the database and how it determines the Permissions Group that the user is a member of. To configure authenticators, use the “Authenticators” section in System > Users.
When a user attempts to log in, the Virtual Traffic Manager first compares the credentials to the list of Local Users and determines the Permissions Group that the user is a member of. If a match is not found, the Virtual Traffic Manager then tries each Authenticator in turn until the user is authenticated and a Permissions Group is determined.
Local Users
To add a new local user, provide a username and password in the “Create New User” box, and select a group from the drop-down box. This specifies which Permission Group this user belongs to.
To modify the password, Permission Group or UI Preferences for an existing user, click the username on the “Local Users” page.
UI Preferences for Local Users
Local Users have access to several preference settings that control aspects of the Admin UI:
Setting | Description |
|---|---|
use_applet | Enables or disables the status applet that is displayed in every UI page. You can disable this applet to reduce bandwidth, or to reduce HTTP requests when using a tool such as LiveHTTPHeaders or FireBug to monitor HTTP traffic to the Virtual Traffic Manager IP address. |
appletwidth | Changes the width of the applet, allowing it to display more (or fewer) bars in the chart that graphs traffic per virtual server. |
trafficscript_editor | Enables or disables the advanced TrafficScript editor, replacing it with a simple textbox when disabled. |
To delete a user, click Delete User.
Password Policy
The Password Policy page allows you to configure the password policies applied when local users are created or when they change their passwords. Restrictions on the length of passwords, what character types they must contain, how often they can be changed and how often they must be renewed can be configured here.
You can specify the following security settings:
- No restrictions: All passwords are allowed, no restrictions are applied.
- Default restrictions: Standard password security is applied to new passwords, specifically:
- Passwords must be at least 8 characters in length.
- Passwords must contain at least two alphabetic characters.
- Passwords must contain at least one uppercase character.
- Passwords must contain at least one numeric character.
- Passwords must contain at least one special, non-alphanumeric character.
- Passwords must not contain repeated consecutive characters, such as 'aaaaa'.
- Custom restrictions: The minimum length of passwords and the types of characters they can contain can be specified manually.
In addition, the Virtual Traffic Manager will maintain a history of passwords used by each user. The setting password_reuse_after allows you to specify after how many changes a user can re-use a previous password. This helps to ensure that your users do not simply reset to the same password each time a change is made or required. A value of 0 means a user can re-use any passwords they have previously used.
The setting password_changes_per_day specifies how many times a user is allowed to change their password in a 24-hour period. If it is set to 0 then there is no limit to the number of times a password can be changed in one day.
Multi-Factor Authentication (MFA)
The Multi-Factor Authentication (MFA) page allows users to configure two-factor authentication for their accounts, providing an additional layer of security during sign-in.
When MFA is enabled, users must enter both their account password and a time-based one-time password (TOTP) generated by an authenticator application, such as Microsoft Authenticator, to successfully log in.
Home screen displays security recommendation for the enabling MFA.
Enable MFA
To enable MFA:
- Navigate to System> Users >Multi-Factor Authentication. On the Multi-Factor Authentication page, click Enable MFA.
- A QR code is displayed.
- Open your authenticator application (for example, Microsoft Authenticator) and scan the QR code. Or you can Cancel if not needed.
- After the account is added, the authenticator application begins generating a 6-digit verification code that refreshes every 30 seconds.
- During subsequent logins, enter the verification code from the authenticator application after entering your password.
If MFA is enabled, you must enter the authentication code with credentials and complete the verification process to log in.
You can disable MFA for the administrator account from the CLI console:
- Connect to the appliance CLI.
- Navigate to the configuration directory: cd /opt/zeus/zxtm/conf
- change the following entry in the users file user!admin!mfa_enabled Yes to user!admin!mfa_enabled No
/opt/zeus/zxtm/conf# cat users
user!admin!group admin
user!admin!mfa_enabled Yes
user!admin!mfa_secret xxxxxxx
user!admin!mfa_setup_time 1783665584
user!admin!password @@@&&&$$$$$.
user!admin!password!timestamp 1783064930
user!admin!status 1
zxtm:/opt/zeus/zxtm/conf#Disable MFA
To disable MFA:
- On the Multi-Factor Authentication page, click Disable MFA.
- MFA is removed from the account.
- Subsequent logins require only the account password.
Security Recommendation
Ivanti strongly recommends enabling MFA for all user accounts. MFA helps protect against unauthorized access by requiring a second authentication factor in addition to the account password.
Authenticators
If a user cannot be found in the list of Local Users, the Administration Server will test the credentials against any Authenticators that have been fully configured (and are not disabled). An Authenticator queries an external database, and returns the name of the Permissions Group for users who have valid credentials. Generally the name of the Permissions Group is stored in a field in the remote authentication database, and users who do not have a valid Permissions Group are not allowed access to the Administration Server.
The Administration Server supports LDAP, RADIUS and TACACS+ authentication databases.
Creating an Authenticator
To add a new authenticator, click System > Users > Authenticators. Provide a name and select the appropriate authenticator type, then click Create Authenticator. This creates an unconfigured authenticator; you must provide the appropriate configuration settings for the type you have chosen. After the authenticator is configured and you have tested it, enable the authenticator by setting auth!enabled to “Yes”.
The Virtual Traffic Manager does not use an Authenticator until it has been enabled in this way. If several Authenticators are enabled, the Virtual Traffic Manager tries each authenticator (in lexicographic order) until one successfully retrieves a Permissions Group.
LDAP Authenticators
LDAP authenticators have the following configurable settings:
Setting | Description |
|---|---|
ldap!server | The IP address or hostname of the LDAP server. |
ldap!port | The port used to connect to the LDAP server. |
ldap!ssl | Whether the connection to the LDAP server is protected by SSL, and If so, whether that protection incorporates the STARTTLS or LDAPS method. If you enable SSL for the connection, you must also configure a Certificate Authority for the LDAP server's certificate in the Administration Certificate Authorities and Certificate Revocation Lists Catalog. For more information, see Managing Administration Certificate Authorities. |
ldap!timeout | The timeout period (in seconds) for a connection to the LDAP server. |
ldap!basedn | The base DN (Distinguished Name) for directory searches. |
ldap!filter | A filter that uniquely identifies a user located under the base DN. The string "%u" will be substituted with the username. Examples: "sAMAccountName=%u" (Active Directory) or "uid=%u" (Unix LDAP). |
ldap!dnmethod | The bind DN for a user can be constructed from a known string (“Construct”) or can be searched for in the directory (“Search” - necessary if you have users under different directory paths). |
ldap!binddn | The template to construct the binddn from the username. The string "%u" is replaced by the username. Examples: "%[email protected]" or "cn=%u, dn=mycompany, dn=local". This setting is applicable only if ldap!dnmethod is “Construct”. |
ldap!searchdn / ldap!searchpass | The bind DN and password to use when searching the directory for a user's bind DN. Leave this setting blank if it is possible to perform the bind DN search using an anonymous bind. These settings are applicable only if ldap!dnmethod is “Search”. |
ldap!groupfilter | If the user record returned by ldap!filter above does not contain the required group information, use this setting to specify an alternative group search filter. This is typically required if you have UNIX/POSIX-style user records. If multiple records are returned, the list of group names are extracted from all records. The string %u is replaced by the username. Example: (&(memberUid=%u)(objectClass=posixGroup)) |
ldap!groupattr | The LDAP attribute that gives a user's group. If multiple values are returned by the LDAP server the first valid one is used. |
ldap!groupfield | The sub-field of the group attribute (ldap!groupattr) that specifies a user's group. For example, if ldap!groupattr is set to "memberOf", which returns a value such as "CN=mygroup, OU=groups, OU=users, DC=mycompany, DC=local", set ldap!groupfield to "CN" (the first matching field is used). |
ldap!fallbackgroup | If ldap!groupattr is not defined above, or is not set for the user, the group named here is used. If not specified, users with no attribute matching ldap!groupattr are denied access. |
RADIUS Authenticators
RADIUS authenticators have the following configurable settings:
Setting | Description |
|---|---|
radius!server | The IP address or hostname of the RADIUS server. |
radius!port | The port used to connect to the RADIUS server. |
radius!timeout | The timeout period (in seconds) for a connection to the RADIUS server. |
radius!secret | The secret key shared with the RADIUS server. |
radius!groupvendor | The RADIUS identifier for the vendor of the RADIUS attribute that specifies an account's group. Leave blank if using a standard attribute * such as Filter-Id. |
radius!groupattr | The RADIUS identifier for the attribute that specifies an account's group. May be left blank if radius!fallbackgroup is specified. |
radius!fallbackgroup | If no group is found using the vendor and group identifiers, or the group found is not valid, the group specified here is used. |
radius!nas-ip-address | This value is sent to the RADIUS server, if left blank the address of the interfaced used to connect to the server is used. |
radius!nas-identifier | This value is sent to the RADIUS server. |
TACACS+ Authenticators
TACACS+ authenticators have the following configurable settings:
Setting | Description |
|---|---|
tacacsplus!server | The IP or hostname of the TACACS+ server. |
tacacsplus!port | The port to connect to the TACACS+ server on. |
tacacsplus!timeout | The timeout period (in seconds) for a connection to the TACACS+ server. |
tacacsplus!secret | The secret key shared with the TACACS+ server. |
tacacsplus!authtype | The authentication type to use. This can be PAP or ACSII. |
tacacsplus!groupsvc | The TACACS+ "service" that provides each user's group field. |
tacacsplus!groupfield | The TACACS+ "service" field that provides each user's group. |
tacacsplus!fallbackgroup | If tacacsplus!groupsvc is not defined, or no group value is provided for the user by the TACACS+ server, the group specified here is used. If this is not specified, users with no TACACS+ defined group is denied access. |
Testing an Authenticator
To test an authenticator, use the “Test Configuration” section on the System > Users > Authenticators > Edit page. Specify the username and password you want to test; the Authenticator will run and, if successful, return the name of the Permissions Group that the user is a member of. The Authenticator will also provide detailed debugging information to help you fine-tune or correct your configuration if necessary.
Worked Example: Authenticating Against Active Directory
You can authenticate users against an Active Directory database using the LDAP Authenticator. Use the following settings for your authenticator:
Setting | Value |
|---|---|
ldap!server | dir.company.com |
ldap!port | 389 |
ldap!ssl | STARTTLS |
ldap!basedn | OU=Company Users, DC=company, DC=local |
ldap!filter | sAMAccountName=%u |
ldap!dnmethod | Construct |
ldap!binddn | |
ldap!groupattr | memberOf |
ldap!groupfield | CN |
Test this Authenticator with a username and password. The following typical output is produced:
Authenticating as [email protected]
Authenticated
Executing LDAP search, parameters:
filter: sAMAccountName=username
basedn: OU=Company Users,DC=company,DC=local
dir.company.com(fd6e:9138:1b6c:6401::a3e:9850:389): Connected
Bound as user [email protected]
Found group record, DN: CN=User Name,OU=Company Users,DC=company,DC=local
Found groups: Demo
No ldap!fallbackgroup defined
Groups returned by authenticator: Demo
SUCCEEDED, group: DemoPermission Groups
Permission Groups are used to assign access to different parts of the Virtual Traffic Manager Admin Server to different users. All local and remote users are members of groups, and these groups define the access users have to the different aspects of the Virtual Traffic Manager. By default, Ivanti provides a number of pre-defined groups that you can modify or delete according to your local needs. You can also add any number of new customized groups.
To add a new group, specify a name in the "Group name" box and click Update. After the change has been committed, click the new group name.
Each group has a basic "Description" and a "Login Timeout" setting. The description can be used to provide a brief explanation of the purpose of this group, and the login timeout is the period after which inactive Admin Server sessions are terminated. All users that belong to this group inherit this timeout value.
Editing the Permissions of Users in the Group
The Virtual Traffic Manager displays a complete list of pages available within the Admin UI, together with the permission settings for each one. All actions are permitted within the “admin” group. A newly created group starts with all permissions set to “None”.
Each page can have one of the following permissions set for the group in question:
- None: Group members cannot use this feature.
- Read Only: Group members can view, but not modify items associated with this page.
- Full: Members can view and modify items associated with this page.
Using the Catalog > SSL Certificates page as an example, if you set the permissions to "None", members of this group cannot view the “SSL Certificates” catalog page. Use "Read Only" permissions to allow members to view the page but not make changes. Use "Full" permissions to ensure no restrictions apply.
On some pages (such as catalog summary pages) there are no configurable settings. Blocking access to a page does not restrict access to those hierarchically below it, nor the settings on them.
ATTENTION Groups with access to the System > Users pages can edit their own account details. Ivanti recommends taking care when setting which users have these privileges.
Advice Concerning External Program Permissions
Action programs and monitor programs run with the same UNIX user permissions as the Virtual Traffic Manager itself, thus caution is recommended when allowing permission to the pages that control these items.
The specific permissions affected are:
- Extra Files > Action Programs
- Extra Files > Monitor Programs
- Monitors > Edit
- Alerting > Actions > Edit
Login Timeout
The login timeout is measured in minutes, and is the period of inactivity allowed before the Virtual Traffic Manager ends your session with the Admin UI. Your session is also closed automatically if you close your browser window, or if you log out manually by clicking Logout.
The login timeout is a property of a Permissions Group. Click System > Users > Permissions Groups and click the name of the Permission Group you want to modify. Set the new timeout value in "Inactivity Timeout" and click Update.
Suspended Users
This page allows you to re-enable one or more users that have been suspended. Users might have been suspended due to exceeding the maximum allowed login attempts, or for some other administrative reason.
Check the box next to each user you want to re-enable, and click Enable Selected Users.
Note that individual users can also be re-enabled from the System > Users > Local Users > Edit page, by setting Status to "Active".