Domains and organizational units are included in the ODBC database to mirror the data structure used by Active Directory.
Organizational units are designed to hold user accounts and authenticator records. They allow to group users according to department, job function, or other criteria. They also allow authenticators to be allocated for auto-assignment to single or multiple groups of users. Both, domains and organizational units can be used to limit administrators to a group of users and/or authenticators.
Figure: Domains and organizational units
Domains
Domains are essentially separate sub-databases of user account and authenticator data. All user accounts and authenticators must belong to a domain. The domain is used as a naming scope for the user ID—it is allowed to have two different user accounts with the same user ID as long as they are in different domains.
For more information about creating domains and organizational structures, see Creating an organizational structure.
Master domains
During installation, a default domain is created, i.e. the master domain. By default, all new user accounts and authenticators are created in or imported to the master domain, and may then be moved to other domains and organizational units.
When you create a user account, you need to select a domain, since the domain is part of the account identification (primary key). A user account can be moved to a different domain.
Authenticators can also be moved to a different domain after import. However, an authenticator is uniquely identified by its serial number, which cannot be duplicated in different domains.
An authenticator assigned to a user account must belong to the same domain as the user account. Therefore, you need to ensure that the correct numbers of authenticators are allocated to the different domains.
Administrators belonging to the master domain may be assigned administration privileges for all domains in the database, or just their own domain. By default, administrators belonging to any other domain will have the assigned administration privileges for that domain only.
If you do not need to use the concept of domains in your system, then you can leave all user accounts and authenticators in the master domain.
You can designate a different domain as the master domain with the Maintenance Wizard during the initial setup. You can change it later using the Storage > Advanced Settings tab in the Configuration Utility.
Modifying the master domain
You might need to modify the domain used as the master domain in the following cases:
You want new user account and authenticator records to be created in a different domain by default.
You want to change the name of the master domain.
The letter case used in the master domain name will not be compatible with OneSpan Authentication Server configuration settings.
For more information about changing the master domain, see Creating an organizational structure.
Domain identification during logon attempts
As the domain is part of the naming scope for a user account, the domain must be identified when a user attempts to log on (see Figure: Domain identification logic).
When Windows or Active Directory back-end authentication is used, the domain of a user account must match the DNSDomainName of the corresponding Windows (Active Directory) user account. In this situation, Windows user name resolution or Active Directory user name resolution is typically used, allowing the same user to log on using different Windows user name formats (DOMAIN\userid, userid@domain.com, userid@alternative.domainsuffix.com, userid). You can enable this feature in the back-end server settings in the OneSpan Authentication Server Administration Web Interface.
To avoid that multiple user entries for the same Windows user account are created when using Dynamic User Registration (DUR), Windows name resolution must be enabled. A new user entry would be created when first logging on using the Windows down-level logon name (DOMAIN\userid, where DOMAIN is the NetBIOS domain name), and later logging on using the Active Directory user principal name (userid@domain.com), or vice versa.
Without user name resolution, a simple rule is applied to identify the domain of a user who is logging on:
If the user@domain format is used for the user ID, OneSpan Authentication Server looks for a domain record with the name given after the '@'. If the domain is found, the @domain part is stripped from the user ID before the process continues.
If no domain is found, the user ID will be left as user@domain, and no domain will be identified.
If a domain cannot be identified via name resolution, the applicable policy will be checked. If a default domain is specified in the policy, it will be used for the logon. If no default domain is specified in the policy, the master domain will be used. The master domain is a configuration setting.
When the domain has been identified, it is verified against the accepted domain field in the policy. If the identified domain and the accepted domain do not match, the authentication is rejected.
For more information about Windows user name resolution, see Windows user name resolution. For more information about Active Directory user name resolution, see Active Directory user name resolution.
Organizational units
Within a domain, organizational units can be used to group user accounts and authenticators. They are primarily used in OneSpan Authentication Server to allocate unassigned authenticators to groups of users such as offices or departments and to provide delegated administration by user group.
Organizational units can be created as a hierarchy, in a similar way to Active Directory/LDAP. The creation of circular chains is not permitted in the hierarchy.
User accounts and authenticators do not have to belong to an organizational unit. If you do not need to use the organizational unit feature, you can ignore it.
Organizational units are not used as a naming scope in the same way as domains. You can move user accounts and authenticators between organizational units whenever required. However, an authenticator that is assigned to a user must belong to the same organizational unit, as well as the same domain. Upon assignment, or upon moving the user account, the authenticator is moved automatically. Moving an assigned authenticator is not permitted: instead, you must move the user account, which may have other authenticators assigned also. For more information about moving user accounts, see Moving/renaming a user account.
Organizational units have no effect on the authentication process, with the exception of auto-assignment and self-assignment – in either case, the authenticator to be assigned must be in the same organizational unit as the user account. However, if you enable the Search up Organizational Unit Hierarchy policy setting, the authenticator may be located higher up the organizational unit structure, provided it is still in the same domain.