Multiple Account Authentication on a Single Device

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 Conductor 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​

  • Read more at Configure Smart Card Logon on Windows Domains (idmanagement.gov)