Hide navigation sidebar
Hide table of contents sidebar
Back to top
Toggle table of contents sidebar

# Settings

Note

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

#### SAML 2.0 Configuration

The Cluster Manager can be integrated with a SAML 2.0 directory. The system administrator can specify connection parameters and account mapping. Once activated, users will be given access based on the user accounts defined in the SAML directory. 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 SAML configuration. System administrators will need to log in using the special login page by accessing the `/login/admin` 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.

Once SAML 2.0 has been configured, the `SYSADMIN` can login using the page mentioned above with the local system password set in the Cluster Manager, or using the regular SAML Login flow if the `username` matches the user provided by the IdP.

If a user is enabled in SAML but disabled in cluster manager, a redirection to the error page will be performed and, a log in the system will indicate the cause.

After configuring SAML 2.0 as the Authentication Provider, the username attribute mapping will be employed to associate existing users. Any user not found in the system will be treated as a new user. If it is necessary for existing users to match the format of new usernames, system administrators can rename the users to the desired format in the user table.

When selecting the ID Format from the Identity Provider, make sure to select one of the following:

- Persistent: `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent`

- Email: `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`

##### Connection

Identity Provider SSO URL | This is the URL where the Identity Provider provides the endpoint to send authentication requests. Azure: When using Microsoft Azure AD, please use the SAML-P sign-on endpoint `https://login.microsoftonline.com/[TenantIDGUID]/saml2` JumpCloud: Use the IDP URL defined within the SSO settings `https://sso.jumpcloud.com/saml2/[custom identifier]` Google: Use the SSO URL provided in the Google Identity Provider details `https://accounts.google.com/o/saml2/idp?idpid=[idpId]` Okta: Use the provided SSO URL when the Integration has been created
Identity Provider ID | The Identity Provider ID identifies the authentication server in the SAML 2.0 protocol. The Cluster Manager will make sure that authentication response are issued by a provider matching this ID, otherwise the authentication request will be rejected. Azure: when using Microsoft Azure AD, please use the tenant identity URI `https://sts.windows.net/[TenantIDGUID]/` JumpCloud: use the IdP Entity ID defined within the SSO settings `https://gurobi.contoso.com` Google: use the Entity ID provided in the Google Identity Provider details `https://accounts.google.com/o/saml2/?idpid=[idpId]` Okta: use the provided IdP ID generated when the Integration has been created
Request Binding | Preferred method to perform the authentication request from the Cluster Manager to the Identity Provider. Azure, JumpCloud, Google and Okta does support any of the following values. HTTP-Redirect: the SAML request is encoded and sent as URL query parameters in an HTTP GET request. This is the default binding method. HTTP-POST: the SAML request is sent as a form within the body of an HTTP POST request.
Service Provider ID | The Service Provider ID identifies the Cluster Manager in the SAML protocol. It is passed as the `Issuer` when sending the authentication request to the Identity Provider. The Identity Provider also includes this ID as the Audience in the authentication response. The cluster Manager will make sure that the `audience` matches the specified value, otherwise the authentication request will be rejected. The Cluster Manager generates a default value based on the URL where it is deployed, for example: `https://gurobi.contoso.com`. Azure: when using Microsoft Azure AD, please use the `Application ID URI`. JumpCloud: the property can be assigned in the `SP Entity ID`. Google: the property can be assigned in the `Entity ID`. Okta: the property can be assigned in the `Audience URI (SP Entity ID)`.
Cluster Manager base URL | This field indicates the base URL to receive the authentication responses. It must specify the base URL that can be accessed from the browser when the identity provider has authenticated a user using a POST command. The Cluster Manager generates a default value based on the URL where it is deployed, for example `https://gurobi.contoso.com:61080`. The complete endpoint URL consists of this base URL and the `/api/v1/saml2/callback` path. When configuring the Identity Provider, please use the complete URL. When configuring the Identity provider: Azure: add a Web platform with the redirect URI as the complete endpoint URI. JumpCloud: the property can be assigned in the `ACS URLs`. Google: the property can be assigned in the `ACS URL`. Okta: the property can be assigned in `Single sign-on URL`.

##### Mapping

A claim is a piece of information about a user or entity. Claims are used to represent various attributes, such as name, email address, first name, last name and username. The mapping configuration is used to match the claims coming from the Identity Provider into Cluster Manager. `Email` and `Username` are mandatory mappings, and usually they can be the same claim.

Email | SAML claim for the Email Azure: When using Microsoft Azure AD, please use the identity claim for the name attribute `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name` JumpCloud, Google and Okta: the email claim is called `email`.
Username | SAML claim for the username, it should be unique. In many instances, the email assertion serves as an attribute to uniquely identify users.
First name | SAML claim for the first name Azure: When using Microsoft Azure AD, please use the identity claim for the given name `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname` JumpCloud, Google and Okta: the claim is called `firstName`.
Last name | SAML assertion for the last name Azure: When using Microsoft Azure AD, please use the identity assertions for the surname `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname` JumpCloud, Google and Okta: the assertion is called `lastName`.

##### Certificates

When the Identity Provider replies to the authenticated request, claims are returned as digitally signed XML assertions. In order to ensure response integrity, you can include the digital certificates provided by the IdP used to verify the assertions. The certificates must adhere to the X.509 standard.

In order to add a new certificate click on this button and copy and paste the certificate provided by your identity provider. When more than one certificate is required, new field for certificates can be added clicking on the same button.

If a certificate field was added by mistake, it can be removed by clicking on the trash bin icon.

The Identity Provider has established expiration dates for the Certificates, making it crucial to regularly verify these expirations and keep the Certificates list in the settings up-to-date.

##### Upload IdP metadata

The Identity Provider (IdP) typically provides a metadata `XML` file that contains essential information about the IdP’s configuration and capabilities. This XML can be used to automatically configure the following properties, if they are provided: `Identity Provider SSO URL`, `Identity Provider ID`, `Request Binding` and `Certificates`.

To upload a metadata file, click on this button. A new dialog will be displayed, allowing you to upload a valid `XML` file.

After selecting a metadata file, click on `UPLOAD`. If the metadata file is valid, the information will be loaded into the corresponding fields. Otherwise, a specific error message will be displayed.

##### Download Metadata

Some Identity providers, such as JumpCloud, support the upload of a Service Provider XML Metadata file. The Cluster Manager provides the capability to generate this file by clicking on this button. The following information is generated based on the SAML Protocol:

- `EntityDescriptor - entityID (Service Provider ID)`

- `Consumer service - location (Cluster Manager base URL + /api/vi/saml2/callback)`

- `Consumer service - binding (urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST)`

- `AttributeConsumingService - RequestedAttributes (firstName, lastName and email)`

##### View Metadata configuration

If the Identity Provider does not support uploading a metadata file, the properties mentioned above can be reviewed and copied manually by clicking on this button.

##### Case sensitivity

Configure case sensitivity for SAML configuration.

Disable username case sensitivity | Defines if usernames are case-sensitive. By default, case sensitivity is enabled so that users with different uppercase and lowercase letters are handled as different users. For example, `JohnDoe` and `johndoe` are different users by default. If case sensitivity is disabled, usernames will match even if some letters are uppercase or lowercase. For example, `JohnDoe` and `johndoe` will be the same user.
Validate case sensitivity | When disabling the case-sensitivity configuration, you need to make sure that existing usernames do not generate conflicts. For example, if you had `JohnDoe` and `johndoe` as different users, then disabling case-sensitivity will lead to conflicts with these users. This action allows you to run a validation check that will report if duplicates are detected. In this case, rename or merge the users accordingly before changing the configuration. If there is no conflicts, the cluster manager will proceed with the migration of users to be case-insensitive when saving the settings, and this operation cannot be undone.

##### Logout

Configure logout for SAML configuration.

Logout page URL | Defines the URL of the page to redirect to when the user logs out. If not defined, the user is redirected to `/logout`.

##### Command line login for SAML with `grbcluster`

If the cluster manager is configured for SAML Authentication, it’s essential to follow the authorization flow for secure access.

When you initiate the login process, the cluster manager will generate a unique URL along with a Device ID Code. By default, this action will automatically open a web browser for your convenience. However, if you wish to disable this automatic browser launch, you can use the `--no-browser` flag.

The login operation itself must be conducted within the web browser. It’s important to clarify that this web browser doesn’t have to be on the same machine where the login was initiated. You can access it from any device that has connectivity to the cluster manager. This flexibility ensures that you can perform the authorization operation from a location that is most convenient for you.

#### 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.
Filter template | 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))`
Unique Username Attribute | Used for mapping the unique username identifier. If no unique username attribute is specified, it will default to using `uid`. Alternatively, you can specify other values such as `sAMAccountName` for use with Microsoft Active Directory. It’s important that the attribute name matches the one used in the filter template. Ex: `sAMAccountName`
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.

##### Case sensitivity

Configure case sensitivity for LDAP configuration.

Disable username case sensitivity | Defines if usernames are case-sensitive. By default, case sensitivity is enabled so that users with different uppercase and lowercase letters are handled as different users. For example, `JohnDoe` and `johndoe` are different users by default. If case sensitivity is disabled, usernames will match even if some letters are uppercase or lowercase. For example, `JohnDoe` and `johndoe` will be the same user.
Validate case sensitivity | When disabling the case-sensitivity configuration, you need to make sure that existing usernames do not generate conflicts. For example, if you had `JohnDoe` and `johndoe` as different users, then disabling case-sensitivity will lead to conflicts with these users. This action allows you to run a validation check that will report if duplicates are detected. In this case, rename or merge the users accordingly before changing the configuration. If there is no conflicts, the cluster manager will proceed with the migration of users to be case-insensitive when saving the settings, and this operation cannot be undone.

##### Logout

Configure logout for SAML configuration.

Logout page URL | Defines the URL of the page to redirect to when the user logs out. If not defined, the user is redirected to `/logout`.

#### Local Configuration

The authentication configuration for local authentication managed by the Cluster Manager.

##### Case sensitivity

Configure case sensitivity for LDAP configuration.

Disable username case sensitivity | Defines if usernames are case-sensitive. By default, case sensitivity is enabled so that users with different uppercase and lowercase letters are handled as different users. For example, `JohnDoe` and `johndoe` are different users by default. If case sensitivity is disabled, usernames will match even if some letters are uppercase or lowercase. For example, `JohnDoe` and `johndoe` will be the same user.
Validate case sensitivity | When disabling the case-sensitivity configuration, you need to make sure that existing usernames do not generate conflicts. For example, if you had `JohnDoe` and `johndoe` as different users, then disabling case-sensitivity will lead to conflicts with these users. This action allows you to run a validation check that will report if duplicates are detected. In this case, rename or merge the users accordingly before changing the configuration. If there is no conflicts, the cluster manager will proceed with the migration of users to be case-insensitive when saving the settings, and this operation cannot be undone.

##### Logout

Configure logout for SAML configuration.

Logout page URL | Defines the URL of the page to redirect to when the user logs out. If not defined, the user is redirected to `/logout`.

## 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) Authenticating 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. History cleanup batch size When jobs have reached their expiration period, they will be deleted by blocks. This parameter configure the block size for the deletion process. This needs to be tuned according to the usage pattern. If the block size is too small, the process may not be able to keep up with the deletion. If the block size is too large, it may overload 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.

Help and Feedback

Press `/` or click to search this documentation | Gurobi website | Gurobi community forum
Go to other Gurobi documentation | Gurobi download | Contact support