Introduction

Login for Windows, available in SecureAuth IdP version 9.2 and later only, adds SecureAuth’s multi-factor authentication to the Windows desktop and remote server login experience.

See the Release notes to learn about new features, enhancements, resolved issues, known issues, and hotfixes.

This product supports the following authentication methods:

• Timed Passcode
• Voice Call
• Passcode sent via SMS / Text Message
• Passcode sent via Email
• One-time Passcode via Push Notification
• Login Notification via Push Notification
• YubiKey HOTP Device Passcode
• YubiKey OATH-TOTP Device Passcode
• Passcode from Help Desk
• Security Questions (knowledge-based questions and knowledge-based answers)

NOTE: Methods delivered via Push Notification require the use of the SecureAuth Authenticate App.

In addition to the supported multi-factor authentication methods, Login for Windows supports the following setups and features:

• Offline mode login
• Multi-factor authentication for desktops and and remote servers
• Multi-factor authentication for single users only and and multi-users
• Users in bypass group can skip multi-factor authentication
• Bypass group lookup on a domain other than user's domain
• Password expiration notification
• Password Reset link to SecureAuth IdP realm or 3rd party service
• Multiple login capability
• Endpoint identified during login multi-factor authentication request
• Use Third-party Credential Providers
• YubiKey HOTP support for 2-Factor Authentication
• YubiKey OATH-TOTP support for first-time authentication
• TOTP 2-Factor Authentication
• Cached user credentials, which let users sign in with fewer clicks
• Installation API validation, to ensure successful login to Login for Windows
• Adaptive Authentication
• Validated with FIPS 140-2 compliant cryptographic libraries

DISCLAIMERS:

• Login for Windows does not support non-domain joined devices. Issues pertaining to account synchronization are the responsibility of the customer and not SecureAuth.

If a computer is not domain-joined AND all local users are blocked by Adaptive Authentication OR are not Active Directory members on SecureAuth IdP, end users receive the following message: Access is denied for all users on this computer.

• Login for Windows supports the samAccountName login name format if using Microsoft Active Directory (AD); in this use case, userPrincipalName (UPN) is not supported.

UPN is supported at login if running Login for Windows with a non-AD profile store containing OATHSeed/OATHToken/PNToken. In this use case, samAccountName is not supported, so the multi-factor authentication lookup will fail and the user will be unable to use other multi-factor authentication methods.

• Login for Windows users might be unable to complete the self-service password reset process because of default Internet Explorer settings in the operating systems on Windows Server versions 2008 R2 and 2012 R2.

• The Login for Windows Self-Service Password Reset feature does not function in environments that use a proxy to access SecureAuth IdP. Contact SecureAuth Support and inquire about workarounds. Note this feature differs from the inline password reset feature that is used when a user’s password expires. The inline password reset feature functions properly in proxy environments.

---

Prerequisites

Administrator

Login for Windows requires SecureAuth IdP version 9.2 or later.

Setup requirements

1. Ensure SecureAuth IdP v9.2 or later is running and is using a SHA2 or later certificate bound to Microsoft Internet Information Services (IIS). For example, in the IIS Management Console's Default Web Site section, check the Site Bindings section to ensure the https/443 type and port settings have a valid and trusted SHA2 certificate selected, as shown in the following image:

2. Create a realm or access an existing realm where more than one multi-factor authentication is required.

NOTE: Do not configure this realm for Single Sign-on.

3. Configure these SecureAuth IdP Web Admin tabs: Overview, Data, Workflow, Multi-Factor Methods, Post Authentication, and Logs.

4. Ensure target end-user machines are running any of the following supported OS versions:

NOTE: To use the proxy bypass feature with Windows, a proxy server and proxy bypass list must be configured. See Login for Windows Installer Configuration for information about configuring the proxy server and proxy bypass list.

Verify TLS 1.1 and TLS 1.2 enablement via GPO on Windows Server OS

Verify TLS 1.1 and TLS 1.2 are enabled via the Group Policy Object (GPO) to ensure a streamlined and secure login experience for users logging on a Remote Desktop.

The external article How to Enable TLS 1.1 and TLS 1.2 in Internet Explorer via Group Policy provides instructions on how to enable TLS 1.1 and TLS 1.2.

NOTE: TLS 1.1 and TLS 1.2 are not enabled by default on Windows Server 2008 R2.

End-user

First-time usage requirements

Login for Windows requires end users to use one OATH-based method (i.e., TOTP, YubiKey), if at least one method is available to end users. If at least one OATH-based method is not available to end users, they can use any other available method.

To meet this requirement, end users must use one of the following accounts provisioned with a SecureAuth IdP realm that enables their device to generate timed passcodes for multi-factor authentication: 

• SecureAuth Authenticate App on a phone or tablet or

• YubiKey HOTP or TOTP security key. Refer to the YubiKey HOTP Device Provisioning and Multi-Factor Authentication Guide or the YubiKey OATH-TOTP Device Provisioning and Multi-Factor Authentication Guide to ensure all requirements are met. To ensure that supported YubiKey devices are used, see the "YubiKey" section of the SecureAuth Compatibility Guide.

Thereafter, end users can use Login for Windows to log in when working online and offline.

NOTE: If end users are currently using the SecureAuth Credential Provider, they do not need to uninstall it before installing Login for Windows.

---

SecureAuth IdP Web Admin configuration

Data tab 

1. Create a new realm and configure a data store on the Data tab.

2. In the Membership Connections Settings section, under Group Permissions, select True from the Advanced AD User Check dropdown.

3. Select Bind from the Validate User Type dropdown.

4. In the Profile Fields section, enter adminDescription in an unused Aux ID field—Aux ID 3 in this example—and make the field Writable.

5. If using a single OATH seed for end-user multi-factor authentication (see sample Post Authentication page image), then map Fields to OATH Seed and OATH Tokens Properties, as shown in the Profile Fields image below.

SecureAuth recommends setting OATH Tokens. If OATH Tokens is not set, users might receive a failure message when attempting to authenticate by using TOTP after their device wakes from sleep mode while online. The failure occurs because a second factor method is sent at different times between the device being connected to the internet and disconnected from the internet, which causes the timed passcodes to be out of sync.

6. Click Save.

Optional: Adaptive Authentication tab

Use Adaptive Authentication to control the user login experience and to mitigate security risks.

The order of priority to handle user authentication login requests using Adaptive Authentication is as follows:

A. Threat Service

B. IP allow list / deny list

C. Geo-location

D. Geo-velocity

E. User / Group

NOTE: See Group Bypass configuration notes in the Login for Windows Installer configuration section for information about using Adaptive Authentication with the group bypass feature.

Multi-Factor Methods tab

7. In the Multi-Factor Configuration section, configure the multi-factor authentication methods you want enabled.

8. Click Save.

Optional: Security Questions setup

Set up Security Questions so users can authenticate by answering knowledge-based questions (KBQ). Security Questions gives users the option to log into devices without requiring a phone or token.

Follow steps in the Knowledge-based Authentication (KBA / KBQ) as 2-Factor Authentication Method Configuration Guide to set up knowledge-based questions for end users.

System Info tab

9. Open the web.config file, located at  D:\SecureAuth\SecureAuth1 on the appliance.

10. Add the following line under <appSettings>:

    <add key="OTPFieldMapping" value="AuxID#" />

NOTE: In this example, AuxID3 is used because this Property was selected and configured on the Data tab in step 4.

11. Save the changes before exiting from the file.

API tab

12. In the API Key section, click Generate Credentials.

The API ID and API Key are required and used in the config.json file for all scenarios of using this product.

13. In the API Permissions section, select Enable Authentication API.

NOTE: It is not recommended to enable Identity Management options since the password reset function uses an IdP realm or third party password reset URL—not the Identity Management API.

14. Click Save once the configuration is complete.

15. Select Enable Login for Endpoints API, and then click Configure Login for Endpoints Installer.

Login for Windows Installer Configuration 

16. On the Login for Endpoints Installer Configuration page, select Windows as the Endpoint Operating System.

17. Select the Endpoint Type to specify that either a single user or multiple users can log on the device.

NOTE: For the single user selection, once the user has successfully logged on the endpoint online, thereafter the user can log on the endpoint offline without an Internet connection.

18. Enter the IdP Hostname.

19. Under Multi-Factor Authentication Settings, specify whether the user must use multi-factor authentication to access the device from a desktop and / or remote desktop session.

20. If any user group is allowed to bypass multi-factor authentication, enable the bypass option and list the user group(s).

Group Bypass configuration notes:

• If using Adaptive Authentication AND the group bypass feature, Adaptive Authentication takes precedence for handling the user's login request and group bypass is checked next.
• In a multi-forest AD environment, the user account must be included on each domain to bypass multi-factor authentication on any domain.
• Login for Windows supports the group bypass feature when users are online and offline. An internal group cache performs validations when Active Directory is unreachable.
• The group specified must be a top-level group; nested groups are not supported.

If using a proxy bypass, you must configure the proxy server and proxy bypass list, which is a list of hosts to use to bypass the proxy.Proxy Server and Proxy Bypass List configuration notes:

The following order is used:

A. "proxy_server" and "proxy_bypass" configuration from config.json file. These settings are derived from entries made in the Web Admin Login for Endpoints Installer Configuration section.

B. Windows proxy configuration. See the Netsh.exe and ProxyCfg.exe Proxy Configuration Tools article on the Microsoft website.

21. If enabling Password Reset, specify either the SecureAuth IdP realm or the web page URL the user can access for resetting a password.

22. If Alternate Credential Providers are permitted, specify if non-SecureAuth credential providers and other credential providers, such as card scanners, can be used.

Alternate Credential Provider notes: 

• By enabling alternate credential providers, users will be able log in without using the Login for Windows credential provider, and potentially bypass multi-factor authentication.
• Enabling alternate credential providers is only recommended in test environments, to let testers bypass Login for Windows so they can readily access their machines.
• If the default Windows Credential Provider is enabled, users will see their normal login prompt and will have to manually select a different login option in order to use Login for Windows.

23. Click Download Installer Config to download the JSON file (config.json). The JSON file must first be configured before it can be used with the MSI file, as described in the Installation section of this guide.

NOTE: Before installation, config.json must be edited if the end-user is not always required to use multi-factor authentication for logging on a local console and / or remote console. See the Set end-user access level section for access level settings and configuration.

---

Pre-installation steps 

Optional: Set end-user access level 

Login for Windows requires the end-user to use multi-factor authentication by default to access the local console or remote console in an RDP session.

Before installing Login for Windows on the end-user's (target) machine, the config.json file must be edited if you want to change the end-user's login access level setting.

Change the user's access level

1. Find the config.json file you downloaded in step 23 of the Web Admin Configuration section of this document, and copy that file to the Temp folder on the target machine.

2. Start a text editor such as Notepad++ and edit the access_level in the file, changing the value to a pertinent value:

• 0 = Multi-Factor Authentication always required
• 1 = Multi-Factor Authentication required for local access only
• 2 = Multi-Factor Authentication required for remote access only

• 3 = Multi-Factor Authentication never required. This setting is used for Self-service Password Reset (SSPR) only.

  SSPR is completed in SecureAuth IdP. After the password reset, the local machine still must contact Active Directory to verify the password change. After verification, the new password is available on the local machine.

3. Save the configuration.

Verify "allow_self_signed" setting

Setting "allow_self_signed" to True is commonly used in test or lab environments in which the server has a self-signed certificate. This setting is not supported in a production environment because it introduces critical security risks, namely the potential "Man in the middle" attack which grants users access to a system without validating their credentials, and lets unauthorized users steal OATH seeds.

Find the config.json file you downloaded in step 23 of the Web Admin Configuration section of this document, and verify the setting for "allow_self_signed". You may need to change this setting based on how users will log on your environment.

Note that after installing an endpoint with "allow_self_signed" set to True, this setting remains effective until Login for Endpoints is uninstalled and then re-installed using a configuration file with "allow_self_signed" set to False. 

Verify "version" setting

If you have set up an IdP realm to use HOTP or TOTP, set "version" to "v2" in the config.json file. This keeps end users from receiving an error message that they must "change password at next login" or that their expired password fails without allowing them to change the expired password. You must also complete the settings in the Data tab. 

Find the config.json file you downloaded in step 23 of the Web Admin Configuration section of this document and edit it.

In the config.json file, find the "version" key and set it to "v2", as follows:

"version": "v2",

Optional: Enable failover to one or more backup SecureAuth IdP instances

You can set Login for Windows to failover to one or more alternate IdP instances automatically if the main IdP instance fails. You can specify up to five backup instances and set the order that they are used.

Find the config.json file you downloaded in step 23 of the Web Admin Configuration section of this document and edit it.

1. Specify the IdP instance to failover to by replacing the "api_id", "api_secret", and "host" keys with a new "apis" array.

2. In the config.json file, replace the "api_id" and "api_secret" keys and set the host to specify a single or multiple backup IdP instances.

To specify a single backup IdP instance, edit the file as follows:

    "apis":[ 

       { "id":"", "secret":"", "host":"https://localhost/secureauth#" }

    ],

Where secureauth# is your single backup IdP instance.

To specify multiple backup IdP instances, edit the file as follows: 

    "apis":[ 

       { "id": "", "secret":"", "host":"https://localhost/secureauth2" },

       { "id": "", "secret":"", "host":"https://localhost/secureauth3" }

    ], 

The backup IdP instance is chosen in the order listed in the array. An IdP instance must be online or it is ignored and the next instance is used. In the above example, "secureauth2" will be chosen first, then "secureauth3". 

Optional: Enable MFA for User Account Control (UAC) setting

You can enable or disable the UAC option based on how you want users to log on your environment.

• If you enable the UAC setting, users who log on as administrator (with "Run as administrator"), on the same machine used to log into a regular user account, will be required to authenticate again. 
• If you disable the UAC setting, users who log on as administrator (with "Run as administrator"), on the same machine used to log into a regular user account, will not be required to authenticate again.
• "Run as administrator" with MFA is not supported on Windows 7 (x86 and x64) and Windows Server 2008 R2.

See How User Account Control works on the Microsoft website to learn more about UAC.

Find the config.json file you downloaded in step 23 of the Web Admin Configuration section of this document and edit it.

In the config.json file, add the "enabled_on_uac" key and set it to "true" or "false", as follows:

"enabled_on_uac": true 

"enabled_on_uac": false 

---

Installation steps

Download and run the Login for Windows MSI package

1. Download the Login for Windows .zip file to the target machine (laptop, desktop, server, etc.).

2. Unzip the file.

3. Within the Login for Windows folder, find the .msi file for your machine, either SecureAuthLogin-1.x.x-x64.msi or SecureAuthLogin-1.x.x-x86.msi. Place the file in the Temp folder.

Install Login for Windows

IMPORTANT: On a Windows server, SecureAuth Login for Windows should only be installed or uninstalled from a console session and not an RDP session.

1. Find the config.json file which you downloaded in step 23 of the Web Admin Configuration section of this document, and copy that file to the Temp folder on the target machine.

NOTE: You may have already performed this step if you changed the user's access level in the Set End-user Access Level section above.

2. On the target machine, run the following command line with administrator permissions, using the file name of your .msi file and correct path of that file on your machine, as in this example:

    msiexec /i "C:\Temp\SecureAuthLogin-1.0.4-x64.msi" /L*V "C:\Temp\install.log" /qn CONFIG="C:\Temp\config.json"

3. Log off the target machine.

After this installation, SecureAuth Login for Windows appears on the next login session.

NOTES:

• If using Login for Windows in a PCI environment, see Login for Windows SSL configuration requirements if Login for Windows is not installing on a machine. 
• If reinstalling Login for Windows immediately after unstalling the software, the "Failed to write configuration" message will appear if the installer is not finished performing cleanup tasks, such as removing the C:\ProgramData\SecureAuth directory.

SecureAuth IdP transaction log information

The Login for Windows software issues a User-Agent HTTP Request Header when the Application Programming Interface interacts with SecureAuth IdP. The following items are included in the User-Agent string:

• Login for Windows software version
• OS version
• Computer name (hostname)
• Time Zone
• IP address
• MAC address

For example:

   SecureAuthLogin for Windows 10.5.2 (Windows 10 Pro x64 6.2.9200; LT-JSMITH; (UTC-05:00) Eastern Standard Time; 111.22.333.44; 0f:10;35:7a:81:4e)

Uninstallation

On the target machine, run the following command line with administrator permissions, using the file name of your .msi file and correct path of that file on your machine: 

   msiexec /x "<msi>" /L*V "uninstall.log" /qn

Alternatively, you can manually uninstall using the Windows "Programs and Features" menu. Use the following table to map the installation version number to the public product version:

---

End-user login experience on Windows 10

First-time login experience

1. Enter your username on the Windows login screen.

2. The first time end users log in, Login for Windows shows only OATH-based methods (for example, TOTP, HOTP YubiKey), if at least one method is available to end users. If at least one OATH-based method is not available to end users, they can use any other available method. This could be a method that uses the SecureAuth Authenticate App on your mobile device or another device provisioned with the SecureAuth IdP realm to supply timed passcodes, such as an HOTP YubiKey.

After selecting a timed authentication option and entering your password, TOTP and HOTP passcode options will be available for you to use when logging on this machine offline.

If you do not have an authentication method that provides a timed passcode, then select any other option available to you.

3. Show or hide the passcode so that, as you type, you see characters instead of dots. 

1. 1. Focus on the passcode field and enter characters to see the following "eye" icon displayed.
      
   2. Click the icon and hold it until the dots in the field turn to characters.
   3. To hide the passcode, click and hold the icon until the characters turn to dots.

Subsequent login experience

When logging on the same machine in subsequent sessions, the Login for Windows page includes a selection of all multi-factor authentication methods for which you enrolled.

To show characters as you type a passcode instead of seeing dots, refer to step 3. 

Admin login experience

Login for Windows requires you to enter a multi-factor authentication method when you log in to a privileged account as an administrator (with "Run as administrator") on the same machine used to log into a regular user account. See the options by right-clicking over an executable or holding the Shift key over a short cut. 

Select one of the options and then enter the admin password.

To show characters as you type a passcode instead of seeing dots, click and hold the "eye" icon to the right of the characters. 

---

Release notes 

New features and enhancements

Version: 1.0.4
Release Date: April 23, 2019
Last Updated: May 28, 2019
Compatibility: SecureAuth IdP versions 9.2 or later

Resolved issues 

Known issues

Hotfixes 

---

Related documentation

YubiKey HOTP Device Provisioning and Multi-Factor Authentication Guide

YubiKey OATH-TOTP Device Provisioning and Multi-Factor Authentication Guide

Login for Windows configuration guide v1.0.3

Login for Mac configuration guide v1.0.3

SecureAuth Credential Provider Configuration Guide, v2.8.5

Login for Endpoints Configuration Guide v1.0.2

Login for Windows SSL configuration requirements