- 25 Mar 2024
- 2 Minutes to read
- Print
- DarkLight
- PDF
Multiple Account Authentication on a Single Device
- Updated on 25 Mar 2024
- 2 Minutes to read
- Print
- DarkLight
- PDF
Authentication is typically one device to one user account; however, that is not always the case. A common scenario is when a user has multiple accounts, such as administrator and regular user, and they choose to authenticate with a single device rather than associate each account type to a unique authenticator.
This setup can be achieved using Certificate-based Authentication (CBA) and Axiad can help issue these certificates to a single authentication device.
Potential Added Risk
Linking multiple accounts to a single device is more convenient to the user and reduces the company’s cost, but it is worth noting that this scenario does pose an additional risk because if a malicious actor gets ahold of the device and is able to successfully authenticate (e.g. by guessing the PIN through social engineering), then they have access to any and all accounts tied to that user’s authentication device.
Axiad User Experience
The login flow for authenticating with a device that has multiple accounts is similar to authenticating with a device tied to a single account.
Windows Login
Windows will recognize that there are multiple accounts, so the user must select the account they want to use. Once selected, then they provide the PIN for their authentication device and they are logged into the machine.
Native Application, e.g. RDP or Run as Administrator
Users can click More choices and Windows will then present them with each of their accounts from which to select.
Browser Authentication
The browser prompt includes an additional step to select the user account before providing the PIN for authentication.
Axiad Setup
Account Provisioning
Axiad will create a credential workflow to define which certificates will be loaded on the device and how the certificates are built.
The content of the certificates identifies the account being used to authenticate. Most applications use one or two certificate extensions to identify which account the certificate represents:
The Subject Alternative Name (SAN) extension contains the User Principal Name (UPN)
The Object SID extension contains the unique SID representing the account in Active Directory
Axiad Cloud or UCMS must have access to the UPN and / or SID identifiers for the secondary certificate to provision multiple certificates. These details can be retrieved in multiple ways:
An attribute must be configured in the directory or IdP to hold the required information
For example, the secondary UPN can be added in the info field in AD, and the secondary SID can be added in the ExtentionAttribute1 field
The secondary UPN can be constructed on the fly as long as it has a standard structure to it
For example: firstname.lastname.admin@domain.com
Certificate and Account Mapping in Active Directory
An alternative way to authenticate different accounts with the same device is through Certificate and Account Mapping, which employs the same certificate to authenticate all the accounts. This can be done using one of two methods:
UPN Mapping
Update the UPN attribute of the secondary user account to match the Subject Alternative Name (SAN) of the certificate (i.e., user@domain.com)
This is applicable only if the secondary account(s) is in a separate domain that of the original user account
Certificate Serial Number Mapping
Update the altSecurityIdentities attribute of the secondary user account to match the Serial number of the certificate