Enrolling and using Token2 programmable TOTP tokens with UserLock MFA

UserLock is a user login security system for on-premises Windows Active Directory designed by ISDecisions. It works alongside Active Directory to protect access to Windows systems. With specific and customizable user login rules and real-time monitoring, UserLock reduces the risk of external attacks and internal security breaches while helping to address regulatory compliance. UserLock is one of the few solutions existing on the market that allows implementing multi-factor authentication for logging on to Windows computers with Active Directory domain membership or standalone terminal servers. 

Previous versions of UserLock are allowing using Token2 programmable tokens as the second factor (TOTP protocol).  Starting from version 11, UserLock natively supports  Token2 T2F2 Security keys (second-generation only: ALU, AZ, NFC and Bio) by utilizing the HOTP functionality of these keys.

In this article, we will show the procedures required to enrol and use Token2 programmable TOTP tokens to log in to your Windows workstation protected with UserLock.

1. Enable MFA for a user

this step is done by the administrator of the system

In the UserLock management console, navigate to "Protected Accounts" and click on "Protect a new account" button. 

Then follow the wizard's instruction to protect a single account or a group. The steps below show enabling UserLock protection for "mfauser" local account on a standalone server as an example.

Then, double-click on the newly created protected account record to open its properties window.

Scroll down to Multi-factor authentication section and configure settings for this user. On the screenshot below, we configured the user with the most strict settings: MFA is enabled for both workstation and server logins, and the second factor will be asked on every logon.

Click Apply/OK to finish this step. Now, the next time this user logs in, a wizard asking to configure the second factor will appear and the login will only be possible after this process is completed successfully.

2. Configuring the second factor for the user

this step is done by the user

After the user account's UserLock protection is enabled and MFA is activated, on the next logon attempt, UserLock will prompt the user to enrol one of the second factors. We will show the process of configuring a Token2 programmable token as the second factor.

Choose Authenticator App  from the first window - make sure your Token2 programmable token and the NFC Burner app (or the USB Config tool)  is ready.

Then, launch your NFC Burner/USB Config app and scan the QR code shown by UserLock. The seed encoded in the QR code should be shown in the seed field of the app, then hit the "Burn" button on the app.  The animation below shows how this looks like on Token2 NFC Burner app for iPhone.

The process looks similar with Android and Windows applications.

Once the burning process is completed, turn the token off, then turn it on again. Enter the 6 digit code displayed on the token's screen into the verification field of UserLock MFA enrollment wizard (№3)

After clicking "Verify and continue", if the code entered is correct, you will see the screen below, which confirms the provisioning was completed successfully.

Upon successful enrollment, UserLock will prompt to enrol an additional factor for MFA (this can be a  USB Security key, you cannot add a second TOTP programmable token or an app)

3. Logging in using a Token2 Hardware token

Once enrollment is complete, the MFA prompt will ask to enter the OTP. 

On this screen, type in the 6-digit code displayed on your hardware token to complete the login process.

Frequently asked questions

1. Can I use this method for Remote Desktop logins?

Yes, you can both enrol and login via Remote Desktop using Token2 programmable tokens.  

2. What is the difference between using Token2 TOTP programmable tokens and Token2 Security keys with UserLock MFA?
The main difference from the user experience point of view is that with the Token2 Security keys, users do not need to manually type in the one-time password (6 digits) as with TOTP (apps or tokens). Instead, to provide the second factor to complete the login process, the user will only have to plug in the device to a USB port and press the button. The only exception to this is when using our USB programmable tokens - they can also send the code over USB by leveraging the HID/Keyboard emulation feature. 

Another aspect is the provisioning and login process differences, briefly shown in the comparative table below:

	TOTP Tokens	Security keys
Provisioning requirements	An additional device is needed (for NFC models only, USB-programmable tokens do not need any additional devices)	No additional device needed
Provisioning security level	Medium Secret key transferred to end-user	High Provisioning done by UserLock directly on the device
Provisioning over RDP	Possible	Not possible
Logon over RDP	Possible	Possible

3. Can I enroll more than one Token2 programmable token?

Yes, there is no limit on the number of tokens. However, be aware that this has to be done at the same time - during the initial MFA enrollment process. In other words, only during the step when the QR code is shown on the screen. Please note that you can also have the same QR code provisioned both on a hardware token and a mobile app - this can be used as a backup method if needed.

4. Can I use the Token2 programmable token for other services?

Theoretically, yes, but the other service you plan to use the token with should support importing factory-set seeds. An example of such service is Azure MFA OATH hardware tokens feature (requires Azure AD (Microsoft Entra ID) Premium P1 or P2). This article describes how this can be achieved. 

5. Which tokens are compatible with UserLock MFA?

Any of our programmable tokens can be used.  The principle behind is the same for all, the differences are with dimensions, form-factors and provisioning methods.

6. My users are getting the message 'this code is invalid' when entering the MFA code. What should they do?

If users encounter the 'this code is invalid' error, first check the server's system time. If it's correct, consider adjusting the hardware token's clock if it supports unrestricted time sync. If that doesn't work or you use tokens with restricted time sync, this can be fixed by changing the server settings. To do this, go to Advanced Settings (e.g., via server console with 'F7') and increase 'MaxTotpCodeCount' to resolve the issue.

 

This setting defines the maximum number of out of sync TOTP codes (between UserLock server time and smartphone or hardware token time; past and future) accepted. The authorized values for this setting are between 0 and 10 (by default 2). As this setting concerns past and future desynchronization and the TOTP codes are renewed every 30 seconds, the effective number of desynchronized TOTP codes accepted is therefore (2 * (the value of this setting) + 1): the TOTP code of the current time, the TOTP Code for the current time minus AND plus 30 seconds, the TOTP code for the current time minus AND plus 60 seconds, etc. Rest assured that having this value set as high as 10 does not decrease security, as the codes are for one-time usage and cannot be reused. For instance, Microsoft Azure defaults to a value of 15 (15x30 seconds)