Looking up and checking the user account

OneSpan Authentication Server Appliance performs a number of checks before proceeding to local authentication:

User ID and domain resolution

In OneSpan Authentication Server Appliance, user accounts are identified using a user ID and a domain.

If entry fields for the user ID and domain are separate, name resolution ends and authentication continues. Otherwise simple name resolution continues with step 2.
If logon uses a similar format to UPN: user@domain, simple name resolution continues to step 3. Otherwise, default domain processing proceeds in step 5.
The OneSpan Authentication Server Appliance searches for a domain record with the name given after the @ sign. If the domain record is found, name resolution continues to step 4. Otherwise, default domain processing proceeds in step 5.
The user ID and domain parts are separated out, name resolution ends and authentication continues.
If a default domain has been configured for the policy, name resolution continues in step 6. Otherwise, domain processing continues in step 7.
The user ID is used as entered, with the default domain from the policy. Domain resolution ends and authentication continues.
The master domain is used, domain resolution ends and authentication continues. For more information about the master domain, see Master domain concepts and practical uses.

Figure: User ID and domain resolution

Additional considerations for user ID and domain resolution

Users who have the domain name in their user ID can experience authentication issues because OneSpan Authentication Server Appliance uses the corresponding part of the user ID as the domain name. To prevent this issue, users with the domain name in their user ID need to also provide the domain when logging on.

User jane.master in the master domain needs to use one of the following formats for a successful logon:
master\jane.master
jane.master@master
If user jane.master does not explicitly provide the domain in addition to the user ID, the logon attempt will fail.

Windows group check

OneSpan Authentication Server Appliance can use specific Windows groups for authentication when all users are Windows accounts. This Windows group check feature is optional and might be useful in the following scenarios:

The authenticators are deployed in stages. The users are not required to log on using an authenticator until they are put into a Windows group. Users can be placed into the group in manageable stages.
Two-factor authentication is only needed to access sensitive data and that access is granted to a specific group of users, e.g. administrators. This group of users will require authenticators and will be authenticated by OneSpan Authentication Server Appliance. Other users are authenticated by another authentication method.
Most users will have authenticators and are allowed to log on to the system, but some users should not be authenticated under any circumstances.
Authentication is needed for live Audit Viewer connections to OneSpan Authentication Server Appliance. Windows group checks can be used to limit which users are allowed to connect, for example, to the Domain Admins group.

Nested groups

OneSpan Authentication Server Appliance supports nested groups for Windows group checks in the context of Active Directory. For more information about nested groups, refer to the Microsoft documentation.

Enabling nested groups can cause performance issues in OneSpan Authentication Server in the following cases:
There are too many groups in one domain.
Active Directory is not optimally configured. For more information, refer to the Microsoft documentation.

Group check modes

If Windows group check is active, users who are members of one of the defined groups are validated via the full authentication process. You can set the group check mode in the OneSpan Authentication Server Appliance policy to control the result for users who are not members of one of the defined groups.

At least one Windows group must be defined in the Windows group list in the relevant policy. Group membership is verified within the user's own domain only. This means that these groups must exist in each domain where users need to be included in a specific group.

If Windows group check is enabled, logon requests will fail if the group check fails. This occurs for users who are unknown to Windows.

The following group check modes are available:

Pass back mode

The policy property refers to this mode as Pass requests for users not in listed groups back to host system. In this mode, OneSpan Authentication Server Appliance will not handle authentication for users who are not members of any of the listed/defined groups. Instead, these users are handled by the host system, e.g. IIS.

This means that such users neither need an individual user account nor do they need to use an authenticator to log on. As soon as the group check determines that the user is not to be handled, OneSpan Authentication Server Appliance stops authentication and returns a respective result (not handled).

This mode is suitable for staged deployment of authenticators and for cases, where only certain users need strong authentication (using authenticators).

Reject mode

The policy property refers to this mode as Reject requests for users not in listed groups. In this mode, OneSpan Authentication Server Appliance rejects authentication immediately for users who are not member of any of the defined/listed groups.

This mode is suitable to restrict users who are permitted to log on.

Back-end mode

The policy property refers to this mode as Use only Back-End Authentication for users not in listed groups. This mode can be used if back-end authentication is set up (see Back-end authentication).

In this mode, OneSpan Authentication Server Appliance will only use back-end authentication for users who are not members of any of the defined/listed group.

OneSpan Authentication Server Appliance will use back-end authentication for the out-of-group users, even if the policy setting for back-end authentication is set to None. With such a policy configuration, the in-group users would be authenticated only by local authentication, while the out-of-group users would be authenticated only by back-end authentication. However, it is necessary to define the Back-End Protocol Policy setting.

If RADIUS back-end authentication is used, authenticating users who are not members of the defined/listed groups is delegated to the RADIUS server. OneSpan Authentication Server Appliance will not look up the user account and will skip further local authentication.

This mode is suitable for staged deployment of authenticators and for cases, where only certain users need strong authentication (using authenticators).

Look up a user account

OneSpan Authentication Server Appliance verifies that a user account for the user who attempts to authenticate exists in the data store. The user ID and domain resolution performed earlier determines the search criteria to look up the user account.

If a user account is found, the account status is verified (see Verify user account status).

If no user account is found, then the policy settings will determine whether OneSpan Authentication Server Appliance continues processing the authentication request or rejects it:

If Local Authentication Policy is set to DIGIPASS/Password during Grace Period, DIGIPASS or Password, or Digipass Only, local authentication is required. In this case, a user account must exist. It is only possible to proceed if Dynamic User Registration (DUR) is enabled (see Dynamic User Registration (DUR) ).
If Local Authentication Policy is set to None, local authentication is not required. In this case, the authentication process can proceed without a user account.

For more information about the local authentication settings, see Local authentication.

Dynamic User Registration (DUR)

Dynamic User Registration (DUR) allows to create a new user account automatically when the user credentials are validated using back-end authentication. The correct static password is sufficient to create a new user account. DUR saves the administrative work of manually creating or importing a user account.

DUR is typically used together with the following features:

auto-assignment. OneSpan Authentication Server Appliance selects a random authenticator and assigns it to the new user account as it is created..
If maker–checker authorization is enabled, assigning an authenticator requires the approval of a checker administrator. In that case, auto-assignment is not available.
self-assignment. This allows new users to assign an authenticator to their accounts as part of their logon process.

For more information about authenticator assignment features, see Assigning authenticators to users.

To control the creation of new accounts, DUR can be used with the following features:

Windows name resolution. This prevents that more than one user account is created for the same Windows user account, when they use different user ID formats to authenticate.
Windows group check. This allows a staged creation of user accounts and assignment of authenticators.

A typical DUR process using auto-assignment and Windows group check is illustrated in Figure: Dynamic User Registration (Process).

Figure: Dynamic User Registration (Process)

If the data store is case-sensitive and OneSpan Authentication Server Appliance has not been configured to convert user IDs and domains to upper or lower case, it is possible for multiple user accounts to be created for a single user (if Dynamic User Registration is also enabled and configured).
Example: OneSpan Authentication Server Appliance is not configured to convert user IDs and domains to upper case. If a user logs in with jsmith one time and with JSmith another time, then two user accounts can be created, i.e. jsmith and JSmith.

LDAP synchronization can be used as an alternative to Dynamic User Registration (see LDAP user synchronization). However, there is a difference between these two methods:
Dynamic User Registration is a one-off synchronization. Deletion or modifications to a user account are not updated in the back-end authentication system.
LDAP synchronization supports ongoing synchronization of deletions or modifications to a user account in the back-end authentication system.

Verify user account status

OneSpan Authentication Server Appliance verifies the status of the user account found for the user attempting to log on:

If the user account is disabled, the authentication request is rejected.
If the user account has expired because a specified expiration date has passed, the authentication request is rejected.
If the user account has been suspended due to inactivity, the authentication request is rejected.
OneSpan Authentication Server Appliance can be configured to force a user account to be suspended if it is not used for a specified amount of time. The number of days that a user account can remain unused before being suspended can be configured in the policy used to log in. This value will be checked and the number of days since the last logon will be calculated. If the user account has been unused for too long, logon will be denied.
If the user account is locked, OneSpan Authentication Server Appliance verifies whether a user auto-unlock attempt is possible (see User account auto-unlock).
If any unlock retries are left and the calculated lock duration since the last authentication request has elapsed, OneSpan Authentication Server Appliance assumes a possible user auto-unlock attempt and allows the authentication request.