The initial server-side values listed below are overwritten by the AdminClient's default values during the first login. For details on the default values that take effect in a standard installation, see Authentication settings in the AdminClient user manual [UM AdminClient].
The corresponding options in the AdminClient may have slightly different names, for example: In the server-side configuration, the parameter “loginDelay.attemptTimeout” represents the same option as “Clearance Time” in the AdminClient.
|
Property |
Description |
|---|---|
|
loginDelay.attemptsBeforeDelay |
The number of unsuccessful login attempts (i.e., invalid password submissions) that activates the delay mechanism. If the value is 0, the delay is disabled. |
|
loginDelay.attemptTimeout |
The number of seconds after which a login delay is revoked and the counter for unsuccessful login attempts is reset. If the value is 0, the delay is disabled. |
|
loginDelay.delaySeconds |
The duration of the delay in seconds. If the “dynamicLength” option is set to true, this value is multiplied by the number of unsuccessful login attempts. |
|
loginDelay.dynamicLength |
A boolean value (true/false) that specifies whether the delay duration is calculated dynamically by multiplying the number of unsuccessful attempts by “loginDelay.delaySeconds”. |
|
loginDelay.maxDynamicLength |
The maximum duration of the dynamically calculated login delay, in seconds. |
|
Table 55: Default ImageMaster configuration properties |
|
An ImageMaster login is characterized by the following behavior:
-
If external authentication fails, the user can still log in using internal authentication.
-
If the login process fails due to incorrect credentials, the login delay mechanism is triggered.
-
If the login process fails and an external authenticator is used, the error message from the external authenticator is displayed.
-
A credential mismatch can originate from an external authenticator (if one is used) or the internal ImageMaster authentication mechanism.
-
If an external authenticator is used, end users cannot determine the source of a credential mismatch from the error message. However, the ImageMaster log files provide administrators with the details needed to find the exact cause of the failure.
-
An end user can choose the authentication method and assign an 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:
-
The section “Authentication settings” (with the 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