General configuration and behavior

Any initial server-side values given below are overwritten by possibly different AdminClient default values when the first login via the AdminClient takes place! So also see Authentication settings in the AdminClient user manual [UM AdminClient], where the default values are given that become effective in any standard installation.

The corresponding options in the AdminClient can have a slightly different name, e.g.: In the server-side configuration, the parameter “loginDelay.attemptTimeout” represents the same option as “Clearance Time” in the AdminClient.

Property

Description

loginDelay.attemptsBeforeDelay
(initial server-side value: 5)

number of unsuccessful login attempts (i.e. invalid password submissions), which activates the delay mechanism

With value 0 no delay is active.

loginDelay.attemptTimeout
(initial server-side value: 3600)

number of seconds after which a login delay is revoked (and the counter of unsuccessful login attempts is reset)

With value 0 no delay is active.

loginDelay.delaySeconds
(initial server-side value: 30)

number of seconds that a delay lasts

If option “dynamicLength” is true, this is multiplied by the number of unsuccessful login attempts.

loginDelay.dynamicLength
(default: true)

boolean value (true/false), that defines if the delay length is calculated dynamically as the number of unsuccessful attempts multiplied by “loginDelay.delaySeconds”

loginDelay.maxDynamicLength
(default: -1, i.e. unlimited)

the maximal length of the (dynamically calculated) login delay in seconds

Table 79: Default ImageMaster configuration properties

An ImageMaster login is characterized by the following behavior:

  • If external authentication fails, internal authentication can still enable the login.

  • If the overall login process fails due to wrong credentials, the login delay mechanism is triggered.

  • If the overall login process fails and an external authenticator is in use, the error message of the external authenticator is displayed.

  • A credential mismatch can originate from an external authenticator (if in use) as well as from the internal ImageMaster authentication mechanism.

  • An end user cannot determine the source of a credential mismatch from the error message if an external authenticator is in use, but the ImageMaster log files provide details (for administrators) to determine the exact cause of a failure.

  • An end user can choose the applicable authentication method and assign an applicable authorization mode.

Starting from version 9.9.1 ImageMaster supports a set of configurable authenticators based on an authentication module and an identity store:

  • If no authentication module is configured, only the internal database is used to check the credentials.

  • If an authentication module is active, it decides about how the credentials are checked.

  • If no identity store is configured, the system tries to fall back on the authentication module.

  • If both are configured, username and password are checked with the authentication module, but finally the user data is retrieved from the identity store.

See the AdminClient user manual [UM AdminClient] for related topics such as:

  • section “Authentication settings” (with subsection “Authentication configuration parameters”)

  • two-factor verification with a mobile device

  • authentication configuration of connected storage systems

  • authentication configuration of integrated components and of optional modules and services