Access to Cluster Manager settings is restricted to SYSADMIN users.
Security
Password Policy
The Cluster Manager supports password policies to ensure that passwords for local accounts match configurable security standards. With a password policy, the system administrator can specify the minimum length of a password and can require that a password contain a mix of upper and lower case characters, digits, or symbols. Any changes to a policy will apply only when new passwords are created; previously created password will remain valid.
Password Requirements
Password requirements allow the system administrator to define a set of rules that enforce password strength. Weak passwords may result in unauthorized access and/or exploitation of the application's resources.
Password Length Password length must be between the given minimum and maximum values.Strong password should contain at least 8 characters. | |
aA | Character Case Indicates whether passwords must contain a mix of upper and lower case characters (e.g., a-z, A-Z).Strong password should contain both. |
01 | Digits Optionally requires passwords to contain at least one number (e.g., 0-9).Strong password should contain at least one digit. |
!@ | Symbols Optionally requires passwords to contain at least one symbol (e.g.,!@#$%^&*()_+|~-=\`{}[]:”;í<>?,./) . Strong password should contain at least one symbol. |
Account Lockout
When activated, this option enables the system administrator to define a maximum number of failed login attempts before the account is locked. When a user account has been locked, a message will appear on the login page, and the user will be asked to contact a system administrator. The system administrator can then change the user's password to unlock their account.
Authentication
LDAP Configuration
The Cluster Manager can be integrated with a Lightweight Directory Access Protocol (LDAP) repository. The system administrator can specify connection parameters (including the use of LDAPS for encrypted communication), account filtering, and account mapping. Once activated, users will be given access based on the user accounts defined in the LDAP server. Accounts with a system administrator role can log in using their local passwords, which enables them to administer the cluster even if there is a problem with the LDAP configuration. System administrators will need to log in using the special login page by following the "System Administrator Log in" link at the top of the main login page. System accounts (i.e., accounts with no interactive login) can always gain access using API keys. The Cluster Manager continually synchronizes user accounts with the LDAP server in the background. If a given user account is no longer mapped to the LDAP filter in place, it will be disabled. In particular, if an account was created before the integration with the LDAP server and if it is not mapped to the defined LDAP filter in place, it will be disabled. The same policy will apply during migration from local accounts to LDAP. Two important exceptions are system administrator accounts and system accounts, which will not be disabled for this reason.
Connection
LDAP Server host | Specifies the Host name or IP address of your organization's LDAP server. |
LDAP Server port | The LDAP server port. The default port is 636 if LDAPS is selected, or 389 otherwise. |
Bind DN and password | The admin Bind DN and password, which allow the LDAP connection to gain access to the directory. Ex: CN=Administrator,CN=Users,DC=mycompany,DC=com |
Encryption - LDAPS | LDAPS is the "LDAP over SSL" protocol, which communicates over a secure port such as 636. It establishes a secure connection before any communication is performed with the LDAP server. Check the Use LDAPS checkbox to enable encryption. When using encryption, a public or private SSL certificate must be provided in the TLS Certificate field:![]() This is used to set up the LDAPS directory. The Disable Certificate Validation box determines whether LDAPS will validate certificate signatures. When activated, no validation will be performed, which is insecure. |
Test connection | ![]() The TEST CONNECTION button is used for testing your parameters to the LDAP server. If you cannot connect to the LDAP server, user mapping and filtering will fail as well. |
Filters and Mapping
Base DN | The base DN subtree that is used when searching for user entries on the LDAP server. |
Filters | Filter for finding entries in the LDAP base DN (groups) subtree that match the group name. The '%s ' string must be included to indicate where the provided user entry should be found.Ex: (&(uid=%s)(memberOf=cn=Technical Users \(Dev/Support/IT\),ou=Users,dc=company,dc=com)) |
Firstname and Lastname | LDAP attributes for user first name and last name. Firstname ex: 'givenName' Lastname ex: 'sn' |
Email Attribute | LDAP attribute for user email. Ex: ['mail','email','userPrincipalName'] |
Test Mapping | To make sure that user IDs, real names, email addresses, and groups have been mapped correctly, click on the TEST MAPPING button.![]() |
Test Login | As a final test, to ensure users can log in, the TEST LOGIN button prompts for a username and password and ensures that this user can be successfully authenticated with the LDAP server.![]() |
Synchronization
Configure synchronization between the LDAP server database and the Cluster Manager database. The synchronization with the LDAP server is a background process that runs at the given frequency. At each iteration, it will synchronize a given number of users, i.e. batch size, that have not been synchronized for at least the given minimum duration (Minimum age). These parameters help tune the synchronization to avoid overloading the LDAP server with too many requests.Minimum Age | ![]() Accounts already synchronized within this time limit will not be synchronized. |
Frequency | ![]() Frequency of the background synchronization. |
Batch | ![]() The field above defines the synchronization batch size. |
System
System - Authentication
Interactive session duration (minutes) When users are authenticated with an interactive login, a session token is created (JWT) to grant access for a specific duration. When the token expires, the user must reauthenticate. | |
Authentication cache max age (secs) Authenticaing users or applications through an interactive login or API key requires access to the database. A cache is used to make this process more efficient. Cached entries expire once they reach the specified maximum age. Some actions such as disabling a user or an API key will only take affect once this maximum age has been reached and all cached copies have been discarded. |
Data Management
Incomplete object expiration (hours) Due to networking or client issues, some objects (e.g., model files) may not be completely uploaded. A background process deletes these incomplete entries after the specified expiration time has elapsed. | |
History expiration (days) Jobs and batches are deleted in the background when they expire. Note that if the number of jobs and batches to delete is very large, these deletions will be performed in blocks to avoid overloading the database. | |
Metrics expiration (days) Metrics are deleted in the background when they expire after the selected number of days, it is recommended this setting to be equals to History expiration (days) | |
Metrics refresh interval (seconds) Metrics are stored with the Max value pulled within the refresh interval, change this setting to poll faster the metrics and have more precision on the stored metrics. |