Logon permutation tables

In the following reference tables, Back-end authentication Required means that the back-end authentication setting is either set to Always or If Needed.

Where back-end authentication is enabled, logon attempts that receive a failure from the back-end server may achieve a logon action, e.g. change PIN request, even though the logon was unsuccessful.

Back-end authentication is required for self-assignment and password autolearn.

Response-only: Cleartext separate password format

With this logon permutation, the following two tables only apply if SOAP uses Cleartext Separate password format. In both tables, back-end authentication is still required for successful self-assignment.

Table: Logon permutations – Response-only cleartext separate applies in this case when:

• EITHER the Stored Password Proxy feature is enabled.
• OR back-end authentication is not enabled.

The following table applies in this case when:

• The Stored Password Proxy feature is not enabled.
• AND back-end authentication is enabled.

Response-only: CHAP/MS-CHAP/MS-CHAP2

Table: Logon permutations – Response-only CHAP/MSCHAP/MSCHAP2 applies if RADIUS is using CHAP, MS-CHAP, or MS-CHAP v2, and the following is true:

• EITHER the Stored Password Proxy feature is enabled.
• OR back-end authentication is not enabled.

2-step challenge/response: Cleartext separate password

The following table applies when SOAP uses Cleartext Separate password format

The column Stored Password Proxy Off AND Back-End Auth. Required contains Yes if:

• The Stored Password Proxy feature is not enabled.
• AND back-end authentication is enabled.

In most cases, this does not affect 2-step challenge/response, just when a keyword only is used.

A self-assignment process that uses 2-step challenge/response is always done using the static password. The request method is not applicable until after the authenticator is assigned to the user account.

2-step Virtual Mobile Authenticator logon

The 2-step Virtual Mobile Authenticator logon is possible when using a SOAP client, the RADIUS Access-Challenge mechanism or an IIS Module in form-based authentication mode. The static password is required in either the first or the second step, but not both.

However, many RADIUS environments, IIS Module basic authentication, and Digipass Authentication for Windows Logon do not support the 2-step logon process. If the 2-step logon process is not possible, two separate 1-step logons are required. The second logon must include the password as well as the OTP, but it is not necessary to provide the password in the first logon, if only a keyword is used.

Using the Cleartext Combined password format, all inputs in the table below are entered into the Password field. In addition, with the Cleartext Separate password format, the keyword and/or password are always entered into the Static Password field, while the OTP is entered into the OTP field.

Digipass Authentication for Windows Logon does not support 2-step Virtual Mobile Authenticator logon and requires two 1-step logons to be performed consecutively instead.

The Keyword-Only request method is only available with Digipass Authentication for Windows Logon.

The Keyword-Only request method must be used if Windows Password Randomization is enabled in the policy when using Digipass Authentication for Windows Logon.

Virtual Mobile Authenticator OTP request is not possible if RADIUS CHAP or MSCHAP is used.

Push notification logon permutations

Table: Logon permutations – Push notification lists the possible logon permutations for push notification–based logon procedures.

Digipass Authentication for Windows Logon (DAWL) does not provide a dedicated field to enter the keyword, since it handles keywords implicitly. You do not need to provide the keyword when authenticating with DAWL, but only the password (if configured accordingly)