Login for Windows v20.09.01 configuration guide
Updated January 12, 2021
Security Notice
A critical security vulnerability affects SecureAuth Login for Windows version 1.0. SecureAuth recommends all users upgrade to version 1.0.1 (or later) immediately.
Login for Windows, available in SecureAuth IdP v9.2+ and the SecureAuth® Identity Platform v19.07+, adds SecureAuth’s multi-factor authentication to the Windows desktop and remote server login experience.
Release highlights
An enhancement was added so that push-to-accept works with Login for Windows version 20.09.01 in the SecureAuth Identity Platform version 20.06+ cloud model.
Read on to learn more about the new features in Login for Windows version 20.09.
Integrate a pre-login questionnaire
You can integrate a questionnaire that your organization has created and then configure Login for Windows so that end users are redirected to the questionnaire before logging in. For example, organizations might create a COVID-19 health questionnaire and then integrate it so end users must fill it out before logging into Login for Windows. End users' answers can help to perform additional risk analysis.
This feature is supported in Identity Platform version 19.07 or later.
Customers create a questionnaire, which can be any web application that can run on a supported web browser.
Set up the redirect to the questionnaire in Login for Windows.
Install without connection to the Identity Platform
Configure Login for Windows so it can be installed on a machine without a connection to the Identity Platform. This is useful if a third-party company configures machines for end users and the third-party company does not have connectivity to the Identity Platform.
Set number of days to log in with password-only
You can configure Login for Windows so that end users can log into their machine with password-only for the specified number of days. This allows end users to access their device to set up their two-factor authentication methods, such as push-to-accept and answers to Security Questions, before they must authenticate to access their device.
Connect to VPN clients before logging into Login for Windows
If end users need to connect to VPN clients before logging into Login for Windows, you can configure this setting.
Dashboard metrics for Login for Windows
Dashboard metrics are available for Login for Endpoints transactions. These metrics include login information for VPNs and endpoint desktop access to Windows and Mac. View metrics by selecting Home on the left side of the Identity Platform page.
Transactional logging requires SecureAuth Identity Platform v20.06 or later, using the /authenticated endpoint.
For more information, see the Authentication API guide.
See the Release notes to learn about enhancements and known issues.
Disclaimers
The Identity Platform does not currently support duplicate usernames in multiple data stores. Login for Windows will not authenticate end users if their usernames are duplicated across multiple data stores.
Customers who want to use the pre-login questionnaire must create the questionnaire themselves. SecureAuth does not host this document; rather, SecureAuth enables customers to integrate their own questionnaire with the Identity Platform version 19.07+ and Login for Windows version 20.09+.
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 (AD) 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; 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.
With the exception of the Microsoft-provided credential providers, SecureAuth does not support other third-party credential providers installed on the same computer as the Login for Windows credential provider.
SecureAuth did not certify Windows 7 and Windows Server 2008 with Login for Windows v20.03+ because Microsoft deprecated both operating systems as end-of-life. Be aware of the following:
Login for Windows v20.03+ works on Windows 7, but SecureAuth does not certify that all features are supported.
Only Login for Windows security fixes will be released in the near future.
SecureAuth recommends upgrading to an officially supported version of Windows.
Prerequisites
Administrator
Login for Windows requires SecureAuth IdP version 9.2 or later or SecureAuth® Identity Platform version 19.07 or later.
To use biometric fingerprint and face (iOS only) recognition, Login for Windows requires SecureAuth Identity Platform v19.07 or later, using the 2019 theme (see Setting the default theme for new realms).
To use Symbol-to-Accept through SecureAuth Authenticate mobile app, Login for Windows requires SecureAuth Identity Platform v19.07 or later.
To use the Passwordless workflow, Login for Windows requires the following:
SecureAuth Identity Platform 9.2 or later running on Windows 10 version 1607 or later
Available to sites running the Prevent package
To use a primary credential provider different from the SecureAuth credential provider, Login for Windows requires the following:
SecureAuth Identity Platform 9.2 or later
Windows sites running the SecureAuth Protect or Prevent package
If you will customize the Login for Windows experience by setting or changing configuration options, see the Login for Windows configuration options section to download a PDF with all available options.
If you use a load balancer:
When you use Push-to-Accept, Symbol-to-Accept, or Link-to-Accept MFA methods with Login for Windows, you must enable session persistence ("sticky sessions") on the load balancer to maintain state with the Identity Platform. Login for Windows supports cookie-based persistence only.
Setup requirements
Ensure SecureAuth Identity Platform v9.2 or later is running and is using a SHA2 or later third-party publicly trusted 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 in the SSL certificate field. The following example shows the SSL connection being terminated on the SecureAuth server.
Alternatively, you can also terminate the SSL connection on the load balancer, and then your publicly-trusted certificate will reside on the load balancer.
Note
Do not remove the SecureAuth certificates from the certificates console or the SecureAuth appliance will no longer function.
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.
Configure these SecureAuth Identity Platform Classic Experience Web Admin tabs: Overview, Data, Workflow, Multi-Factor Methods, Post Authentication, and Logs.
Ensure target end user machines are running any of the following supported OS versions:
Supported OS versions
Windows OS versions:
Windows 8.1 (32/64-bit)
Windows 10 (64-bit)
Windows Server OS versions:
Windows Server 2012 (64-bit)
Windows Server 2012 R2 (64-bit)
Windows Server 2016 (64-bit)
Windows Server 2019 (64-bit)
See SecureAuth compatibility guide for OS and SecureAuth IdP version support information.
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.
End user
First-time usage requirements
End users can log in without second-factor authentication for the number of days set by the administrator. This allows end users to log in with a password only so they can set up their two-factor authentication methods before they must authenticate to access their device. After end users set up 2FA, the following is the authentication workflow.
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, but offline login will not be available.
To meet this requirement, end users must use one of the following accounts provisioned with a SecureAuth Identity Platform 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.
Additionally, consider the following requirements for end users:
If using Passwordless as a first factor, end users must ensure the following:
Run Windows 10 build 1607 or later
Connect a fingerprint reader to the computer
If using face recognition, available for iOS mobile phones only, end users must complete the following:
Enable their iOS mobile phone Face Recognition setting
Download and set up the SecureAuth Authenticate app
Sites upgrading from SecureAuth v9.2 to the Identity Platform v19.07: End users who already use the Authenticate app and want to add the ability to accept biometric push notifications to use face (iOS) or fingerprint recognition must first reconnect the account for their mobile device.
If using fingerprint recognition, end users must complete the following:
Enable their iOS or Android mobile phone Fingerprint setting
Download and set up the SecureAuth Authenticate app
End users who already use the Authenticate app and want to add the ability to accept biometric push notifications to use face (iOS) or fingerprint recognition must first reconnect the account for their mobile device.
Note
If end users are using the SecureAuth Credential Provider and the admin upgrades to a later version of Login for Windows, end users do not need to uninstall the SecureAuth Credential Provider before installing Login for Windows.
Classic Experience Web Admin configuration
Use the following sections to set up Login for Endpoints (Login for Windows or Login for Mac) with SecureAuth Identity Platform Classic Experience version 9.2 or 9.3.
If your team will set up and use Login for Endpoints with the cloud or hybrid model of SecureAuth Identity Platform version 19.07 or later, see SecureAuth Identity Platform configuration.
Data tab
Do not use the same realm for SecureAuth RADIUS server and Login for Endpoints because the OTPFieldMapping app key in web.config is used differently in the two products.
Create a new realm and configure a data store on the Data tab.
In the Membership Connections Settings section, under Group Permissions, select True from the Advanced AD User Check dropdown.
Select Bind from the Validate User Type dropdown.
In the Profile Fields section, enter adminDescription in an unused Aux ID field—Aux ID 3 in this example—and make the field Writable.
You must specify an auxiliary ID (AUX ID) to communicate with the Identity Platform to validate one-time passcodes (OTPs) from email, phone calls, SMS, Helpdesk, and Notification Passcode.
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.
Note
Sample image from Post Authentication page showing Single OATH Seed setting...
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
Save the changes.
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:
Threat Service
IP allow list / deny list
Geo-location (redirect option not available)
Geo-velocity (redirect option not available)
User / Group (redirect option not available)
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
In the Multi-Factor Configuration section, configure the multi-factor authentication methods you want enabled.
Save the changes.
 |
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.
Contact SecureAuth Support for the Knowledge-based Authentication (KBA / KBQ) as 2-Factor Authentication Method Configuration Guide to set up knowledge-based questions for end users.
Optional: Integrate the pre-login questionnaire
After you create a questionnaire, you can integrate it with the Identity Platform and Login for Windows. End users will then see the questionnaire and provide answers prior to logging into Login for Windows
Integrate the pre-login questionnaire by using the Adaptive Authentication tab in a SecureAuth Identity Platform Classic Experience realm. In the following steps, the images show a fictitious company called Acme that has set up a COVID-19 form to check employee health.
Add or clone a realm in the SecureAuth Identity Platform Classic Experience.
In the Overview tab, change the realm description in the Details section and the page header in the Look and Feel section, then save your changes.
In the Adaptive Authentication tab, in the User Risk section, do the following:
Set the user risk to Enabled by moving the slider to green.
Add a risk provider by clicking the Add User Risk Score Provider button.
Add the risk score settings, then save your changes.
Disable other risk providers in the User Risk Score Providers table by moving the sliders to gray.
Edit the new risk provider by selecting the Edit (pencil) icon to the right of the name.
Specify weighting for each minimum, medium, high, and maximum event. The system uses the configured weighting to compute the end user’s risk score.
Adjust the risk score levels by moving the sliders or setting the threshold score for each range, as the red arrows show in the following image, then save your changes.
Set the user risk levels.
High Risk: Represents the highest level of risk. Set Refuse authentication request to keep end users with high risk levels from logging in. For example, if your questionnaire asks health-related questions and the end user's answers show that they are ill, the risk level will be high and the end user will not be allowed to log in.
Medium Risk: For a medium risk level, set Redirect to realm or URL, so end users with medium risk levels are redirected to the realm or URL with the questionnaire you have set up. End users will need to fill out the questionnaire, and based on their answers, can or cannot log in.
Low Risk: For a low risk level, set Resume authentication workflow so end users can bypass the questionnaire and log in.
Score Unavailable: If a risk score is not available, for example, the risk provider is unavailable to provide a score, set the appropriate action for end users.
To read detailed descriptions of each user risk score action, see Risk check actions. To read detailed descriptions about configuring user risk scores, see SecureAuth User Risk score provider configuration.
Save your changes.
You also must add two attributes in the config.json file, later in the pre-installation steps. See Optional: Enable redirect to questionnaire before logging into Login for Windows.
System Info tab
Open the web.config file, located at D:\SecureAuth\SecureAuth1 on the appliance, and decrypt the web.config file.
Add the following line under <appSettings>:
<add key="OTPFieldMapping" value="AuxID#" />In this example, AuxID3 is used because this Property was selected and configured on the Data tab in step 4. (Recall that you must specify an auxiliary ID (AUX ID) to communicate with the Identity Platform to validate one-time passcodes (OTPs) from email, phone calls, SMS, Helpdesk, and Notification Passcode.)
Save the changes before exiting from the file.
API tab
In the API Key section, click Generate Credentials.
The Application ID and Application Key are required and used in the config.json file for all scenarios of using this product.
In the API Permissions section, select Enable Authentication API.
NOTE: It is not recommended to enable Identity Management options because the password reset function does not use the Identity Management API. The password reset function uses an IdP realm or third party password reset URL.
Click Save after the configuration is complete.
Select Enable Login for Endpoints API, and then click Configure Login for Endpoints Installer.
SecureAuth Identity Platform configuration
Use the following sections to set up Login for Endpoints with the cloud and hybrid model of SecureAuth Identity Platform version 19.07 or later.
If your team will set up and use Login for Endpoints with SecureAuth Identity Platform Classic Experience version 9.2 or 9.3, see Classic Experience Web Admin configuration.
You will configure the Identity Platform and the Classic Experience to use Login for Endpoints. If your team wants to use biometric identification (face (iOS only) or fingerprint recognition), you must complete the following set up. Only the Identity Platform v19.07 or later supports biometric identification; additionally, you must use the 2019 theme (see Setting the default theme for new realms). You will set up the authentication API in the Classic Experience; this is necessary until feature parity is achieved with the Identity Platform.
Prerequisites
The following steps must be completed before you can set up MFA methods; some steps are specific to cloud and they are called out accordingly. Most active sites will have performed the first two steps already and can begin at "Set up a policy."
Cloud: Download and install the SecureAuth Connector on your data store server to begin the Identity Platform deployment.
See Data Stores for a discussion and prerequisites. See Install the SecureAuth Connector for prerequisites and steps.
In Map Data Store Properties, enter adminDescription in an unused ID field—Aux ID 3 for endpoints—and set the data format to plain text. Later in these steps, you will map this field to the OTP Validation Property, which is used for end user authentication.
Set up a policy
Policies in the Identity Platform allow you to define rules to authenticate and block your users to certain applications. See How policies are used in the Identity Platform to learn about policies.
If you have an existing policy or default policy that will meet your security needs, you can use that policy; otherwise, you can set up a new policy specifically for endpoints.
Set up a policy for Login for Endpoint.
On the left side of the Identity Platform page, click Policies. Click Add New Policy and give the policy a name. Add a minimum of two authentication rules.
Select the MFA methods that you want to enable for the new Login for Endpoints policy that you created in the previous step. The MFA methods will be available to your end users as their end user login workflow experience.
Open the policy you created in the previous step and select the Multi-Factor Methods tab. Define the login workflow and multi-factor methods settings for the policy and save the choices. The following image shows the available MFA methods available in Login for Endpoints.
Optional: Set up rules to prompt or skip MFA when end users authenticate by comparing rules like their country, group access, and more.
On the policy page, select the Authentication Rules tab. See Adaptive authentication rules settings in a policy to learn more about setting rules.
If you make changes, be sure to save the changes.
Optional: Set up rules to evaluate behaviors that will cause an end user to be blocked from authenticating in. such as IP range, group access, and more.
On the policy page, select the Blocking Rules tab. See Blocking rules settings in a policy to learn more about rules.
If you make changes, be sure to save the changes.
Save the policy.
Add an application
Use the Application Manager tool to select an application template from over 500 applications in the library, then use the common components to customize each new application integration. See Application Manager overview to learn more.
Add a Security Assertion Markup Language (SAML) application. Later, you will edit the SAML application in the Classic Experience to work with Login for Endpoints.
On the left side of the Identity Platform page, click Application Manager and then click Add an Application. On the list of applications, select SAML Application.
On the Application Details screen, set up the application to be used by endpoints products.
Provide a name for the application.
Provide a description for the application.
Select the name of the policy you created previously.
Select the data store for this application.
Select the user groups that can access to this application. Hint: Admins typically select Allow every group in your selected data stores to access this application. Additionally, you can add specific user groups only; for example, to let a test group use it for a short time period before adding more or all groups.
Click Continue.
On the Connections Settings screen, under IdP Signing Certificate, click Select Certificate. Select an IdP signing certificate. (You do not need to set up anything else on the page. You are setting up a realm to add endpoints options in the Classic Experience.)
The IdP-initiated signing certificate integrates the SAML application with IdP so that the login process starts at the Identity Platform.
After end users successfully authenticate, they are asserted back to the Login for Endpoints application.
Add the application.
On the Connections Settings screen, at the bottom, click Add Application. You will receive a success message when the application is added.
Check the Information for Service Providers screen to ensure the information is correct, and then click Continue to Summary.
Check the summary information. If you need to edit, click the pencil icon to the right of the field to be edited. Be sure to click Update Settings in each screen that you change.
API
Set up the authentication API in the Classic Experience.
Open the Classic Experience.
On the Identity Platform page, click the Admin pull-down menu and select Go to Classic Experience.
Search for the endpoints application you created previously.
Select the application you created previously.
Generate API credentials.
In the Admin Overview page, click the API tab on the top menu bar.
The Application ID and Application Key are required and used in the config.json file for all scenarios using Login for Endpoints. The Identity Platform contains an endpoints API; the config.json file calls the Identity Platform endpoints API.
On the top section, API Key, click Generate Credentials.
Set up the authentication API for Login for Endpoints. In the API Permissions section, complete the following:
Select Enable Authentication API.
Add Aux ID 3 to the OTP Validation Property to map it to the setting you completed in Map Data Store Properties.
You must specify an auxiliary ID (AUX ID) to communicate with the Identity Platform to validate one-time passcodes (OTPs) from email, phone calls, SMS, Helpdesk, and Notification Passcode.
Select Enable Login for Endpoints API, and then click Configure Login for Endpoints Installer.
Click Save, located on the left side of the page, at the bottom.
Login for Windows installer configuration
On the Login for Endpoints Installer Configuration page, select Windows as the Endpoint Operating System.
Select the Endpoint Type to specify that either a single user or multiple users can log on the device.
Single user: The last user logged into the endpoint login screen is remembered and does not need to log in again.
Multiple users: Each user must enter their username to log in.
For the single user selection, after the user has successfully logged on the endpoint online, thereafter the user can log on the endpoint when offline without an Internet connection.
Enter the IdP Hostname.
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.
If any user group is allowed to bypass multi-factor authentication, enable the bypass option and list the user groups.
Select Users are a member of the following groups. Add the user groups in the fill-in field.
Alternatively, you can add groups manually by adding the group_bypass key to the config.json file, described in Optional: Add groups that can bypass MFA.
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 Active Directory (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 AD is unreachable.
* Users who need to log in without being prompted for additional MFA must belong to a local or domain group that is set up in the bypass option. Add local users only to the local group.
* 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. A "proxy_server" can be configured on the Windows OS, but if present as a root parameter in the config.json file, takes precedence over the OS setting. The format to configure the proxy is:
"http://[user[:password]@]host[:port]\"Parameters surrounded by [ ] are optional. Both "user" and "password" are not supported on HTTP clients on Login for Windows version 19.06 and earlier, or on 19.09.xx or later that choose to use the legacy HTTP client by setting"legacy_http_communication”: truein the config.json file.B. The "proxy_bypass" is a semicolon-separated list of server names or IP addresses to be excluded from proxy usage, for example: ".acme.sec;.lore.sec;.acme-ppi.com;10...;192.168.."
Each item in the list must be one of the following:
* Fully-qualified domain name (FQDN)
* Full IP address
* Partial IP address with the following forms: Class A example = 10.* or Class B example = .16. or Class C example = .168.*
* Sub-domain name of a parent domain, where the parent is
" .parent.domain.name"The following is an example of a domain that uses direct communication with mail.google.com, but does not communicate withgoogle.comitself:*.google.com.C. Windows proxy configuration. See the Netsh.exe and ProxyCfg.exe Proxy Configuration Tools article on the Microsoft website.
If enabling Password Reset, specify either the SecureAuth IdP realm or the web page URL the user can access for resetting a password.
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 to 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 to use Login for Windows.
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.
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 remote console. See the Set end user access levelsection for access level settings and configuration.
Pre-installation steps
Use the following settings to customize the Login for Windows experience.
Verify "allow_self_signed" setting
Setting "allow_self_signed" to true should be used only in test or lab environments where the server has a self-signed certificate.
When set to
false, only valid certificates are accepted.When set to
true, all certificate validations will be turned off. The HTTP client then will accept valid certificates, self-signed certificates, expired certificates, certificates with invalid root. certificates without matching common names, etc. to establish communication.
Do not set this key to true in a production environment. In production, the key 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. If the key is set to true in production, the following warning message is displayed: Warning! 'allow_self_signed' is enabled.
Find the config.json file you downloaded in step 8 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 Windows 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 Identity Platform 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 8 of the Web Admin Configuration section of this document and edit it. Find the "version" key and set it to v2, as follows:
"version": "v2",
Login for Windows configuration options
Download the following PDF document, which contains a table of all configuration options for Login for Windows. Be sure to check the configuration version listed under "conf_version," to ensure that the optional settings you want to use are supported. Login for Windows supports three configuration versions; the conf_version value (either 1, 2, or 3) defines the config.json file.
The options supported are listed in the following table. Save the PDF to a folder of your choice by right-clicking over the image and selecting Save link as.
Login for Endpoints configuration optionsClick link to download the file.
Optional: Set end user access level
Compatible with: conf_version 1 and later
Login for Windows requires the end user to use multi-factor authentication by default to access the local console or remote console in a Remote Desktop protocol (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
Find the config.json file you downloaded in step 8 of the Web Admin Configuration section of this document, and copy that file to the Temp folder on the target machine.
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 only for Self-service Password Reset (SSPR) where SecureAuth is the primary credential provider. A value of 3 or 4 is required if you use the install_without_idp option without grace_period, which is compatible with conf_version 5 and later only.
SSPR is completed in SecureAuth Identity Platform. 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.
4 = Use a primary credential provider different from the SecureAuth credential provider. This setting is also used for SSPR, where end users can update their password by clicking the Password Reset icon:
Login for Windows is the password reset credential provider.
A value of 4 or 3 is required if you use the install_without_idp option without grace_period, which is compatible with conf_version 5 and later only.
Save the configuration.
Optional: Enable failover to one or more backup SecureAuth Identity Platform instances
Compatible with: conf_version 2 and later
You can set Login for Windows to failover to one or more alternate IdP instances automatically if the main Identity Platform 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 8 of the Web Admin Configuration section of this document and edit it.
Specify the Identity Platform instance to failover to by replacing the "api_id", "api_secret", and "host" keys with a new "apis" array.
In the config.json file, replace the "api_id" and "api_secret" keys and set the host to specify a single or multiple backup Identity Platform instances.
To specify a single backup Identity Platform instance, edit the file as follows:
"apis":[ { "id":"", "secret":"", "host":"https://localhost/secureauth#" } ],Where secureauth# is your single backup Identity Platform instance.
To specify multiple backup Identity Platform instances, edit the file as follows:
"apis":[ { "id": "", "secret":"", "host":"https://localhost/secureauth2" }, { "id": "", "secret":"", "host":"https://localhost/secureauth3" } ],The backup Identity Platform instance is chosen in the order listed in the array. An Identity Platform 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: Add groups that can bypass MFA
Compatible with: conf_version 1 and later
Users who need to log in as local admins without being prompted for additional MFA must belong to a local or domain group that is set up in the config.json file, in the "group_bypass" key. Add local users only to the local group. Users in this group must including a warning stating the group names are case sensitive and need to match AD exactly.
Find the config.json file you downloaded in step 8 of the Web Admin Configuration section of this document and edit it. Add the "group_bypass" key and set it as follows:
"group_bypass" can include the following:
group name: For groups of the domain on which the machine is joined; for example, "BypassGroup"Note that group names must match Active Directory exactly.
domain\\groupname: For groups that are part of a specific domain; for example,"customerDomain\\BypassGroup".\\groupname: For local machine groups; for example,".\\Administrators"
 |
You can also set up bypass groups in the SecureAuth Identity Platform API page, in the Multi-Factor Authentication Settings section, described in step 5.
Optional: Enable MFA for User Account Control (UAC) setting
Compatible with: conf_version 2 and later
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.
See How User Account Control works on the Microsoft website to learn more about UAC.
Find the config.json file you downloaded in step 8 of the Web Admin Configuration section of this document and edit it. Add the "enabled_on_uac" key and set it to true or false, as follows:
"enabled_on_uac": true
"enabled_on_uac": false
 |
Optional: Disable Adaptive login
Compatible with: conf_version 2 and later
The adaptive_enabled key is set to true by default so that administrators can install and modify Login for Windows. Disable this key to false to ensure that an admin or other user is never restricted. This key acts similar to Adaptive Authentication settings in SecureAuth Identity Platform, where you can restrict admins and users from logging in in several ways, for example, by username, group, IP, etc.
If the option is not set or removed, the default behavior is the same as if it were set to
true.
Find the config.json file you downloaded in step 8 of the Web Admin Configuration section of this document and edit it. Add the "adaptive_enabled" key and set it to false or reset it to true, as follows:
"adaptive_enabled": false
"adaptive_enabled": true
 |
Optional: Disable OATH seed cache
Compatible with: conf_version 2 and later
SecureAuth uses OATH seeds to validate OTPs when end users log in. Most use cases require SecureAuth to store OATH seeds; if seeds are not stored, end users will not be able to log in while offline. In a scenario where, for example, a server is always online, you might not want to cache the OATH seed, to prevent the seed from leaking or being stolen.
Use the store_seeds key in the config.json file to disable the OATH seed cache, and Login for Windows will not store OATH seeds. The first-time login experience is disabled in this scenario because it is used to store OATH seeds, which are not required for this option.
The option is
trueby default.If the option is removed, the default behavior is the same as if it were set to
true.
Find the config.json file you downloaded in step 8 of the Web Admin Configuration section of this document and edit it. Add the "store_seeds" key and leave it true or set it to false, as follows:
"store_seeds": true
"store_seeds": false
 |
Optional: Enable custom message for end users locked out
Compatible with: conf_version 2 and later
Enable this option so that end users receive customized assistance when they are locked out of their accounts or their password or passcode is incorrect or expires. Administrators can set a custom assistance string in the config.json file to guide end users so they have next steps after an issue occurs during login.
The option must be added manually.
If the option is not added, an error message will be displayed.
Find the config.json file you downloaded in step 8 of the Web Admin Configuration section of this document and edit it. Add the "custom_error_message" key and enter your custom assistance message. The following message is an example:
"custom_error_message": "For assistance, please contact Acme helpdesk at 949-555-1212, help@acmeco.com, or https://helpdesk.acmeco.com."
 |
Optional: Set time period between authentication and next MFA log in
Compatible with: conf_version 2 and later
Set this option to establish the time period between end user authentication and the next MFA log in. Administrators can set a custom duration by adding "bypass_interval" in the config.json file.
The option must be added manually.
The time period is set in seconds. Entering 0 (zero) as the time period disables the option.
If the option is not added, end users must authenticate in after each screen lock.
When the option is set, end users must authenticate in after a screen lock that exceeds the defined time period. For example, if the time period is set for 3600 seconds (one hour) and an end user locks the screen and goes to lunch for an hour and 15 minutes, that end user must authenticate in after returning from lunch.
After end users initially log in or unlock their screen with appropriate MFA, the session time period is reset to the defined "bypass_interval."
Find the config.json file you downloaded in step 8 of the Web Admin Configuration section of this document and edit it. Add the "bypass_interval" key and enter your custom time period. The following time period is an example:
"bypass_interval": 3600
 |
Optional: Hide button to retry connection when Login for Windows offline
Compatible with: conf_version 3 and later
Set this option to hide the button to retry the connection on the login screen when Login for Windows is offline. Administrators can add the "hide_retry_option" key in the config.json file.
Find the config.json file you downloaded in step 8 of the Web Admin Configuration section of this document and edit it. Add the "hide_retry_option" key and hide the retry button, as in the following example:
"hide_retry_option": false
 |
Optional: Set passwordless authentication
Compatible with: conf_version 3 and later
Set the "passwordless_enabled" key in the config.json file to enable or disable passwordless authentication as a first factor. End users can use a fingerprint reader to authenticate by using any enrolled fingerprint. (This setting does not enable the second factor biometric identification available to end users through the SecureAuth Authenticate app. See Use fingerprint recognition on mobile for instructions.)
The option must be added manually.
The option is false by default.
If the option is removed, the default behavior is the same as if it were set to
false.Passwordless as a first factor is available for Windows 10 users only; if the key is set to
truefor a different OS, the setting will have no effect.
Find the config.json file you downloaded in step 8 of the Web Admin Configuration section of this document and edit it. Add the "store_seeds" key and leave it true or set it to false, as follows:
"passwordless_enabled": true
"passwordless_enabled": false
 |
Optional: Configure number of password-only login days
Compatible with: conf_version 5 and later
Set this option to establish the number of days that end users can log into a machine with password only. Administrators can set a custom number of days in "grace_period" in the config.json file. After end users set up their second-factor methods, they can dismiss the password-only login screen.
The option must be added manually for each machine.
The grace_period value can be any rational number; there is no maximum. Entering 0 (zero) disables the option.
If the option is not added, end users must always authenticate with 2FA.
If end users accidentally indicate that they are ready to authenticate with 2FA when they are not, they can move back into the workflow to log in with password only.
If end users choose to proceed with 2FA, an invalid 2FA login attempt (e.g., mistyped password) will return them to a password-only login.
After end users set up 2FA, they must indicate on the UI that they no longer need to log in with a password only, which cancels password-only for the machine; otherwise, they are presented with the password-only login screen until they dismiss it permanently or reach the maximum number of days for that machine, set by the admin.
Login is determined in the following order:
Adaptive authentication: If set in SecureAuth Identity Platform to block an end user, the end user cannot log in regardless of how many grace_period days are set.
Local settings: Checks, such as access_level and bypass_interval, are considered.
grace_period: If set, the number of days are considered next.
group_bypass and any second factor: These login settings are considered last.
If end users are able to log in with password-only because grace_period is set, they automatically receive a 3 minute time period to enter their password. After 3 minutes, Login for Windows checks if any settings have changed. If the previous settings are the same, end users can log in with password-only. If any of the previous settings have changed, end users are redirected to the 2FA login screen.
Find the config.json file you downloaded in step 8 of the Web Admin Configuration section of this document and edit it. Add the "grace_period" key and enter the number of password-only login days. The following number of days is an example:
"grace_period": 5
 |
Read about how this setting impacts end users in First login with password only.
Optional: Install without connection to Identity Platform
Compatible with: conf_version 5 and later
Set this option to install Login for Windows on a machine without a connection to the Identity Platform. This option is useful if a third-party company configures machines for your end users; if the third-party company does not have connectivity to the Identity Platform, this option enables them to complete the configuration. To use this option, set "install_without_idp" to true. Additionally, the administrator must set one of the following so that end users will still be able to log in if their machine is not connected to the Identity Platform:
Number of days that end users can log in with password-only in grace_period in the config.json file OR
End user access_level to 3 or 4 in the config.json file
Without either grace_period or access_level defined, the installation will fail with the following message in the install.log file:
InstallConfiguration: [1] - JSON Validation: A valid 'grace_period' or 'access_level' attribute must be configured to use the attribute install_without_idp
After end users' machines connect to the Identity Platform, they can ignore the password-only login messages if the access_level is set to 3 or 4; or they can set up their second-factor methods, and then dismiss the password-only login screen if the grace_period was set to at least 1 day.
If end users are able to log in with password-only because grace_period is set, they automatically receive a 3 minute time period to enter their password. After 3 minutes, Login for Windows checks if any settings have changed. If the previous settings are the same, end users can log in with password-only. If any of the previous settings have changed, end users are redirected to the 2FA login screen
Administrators must manually add the option.
Option is set per machine, not per user.
If the option is removed, the default behavior is the same as if it were set to false.
If the option is not added, machines must always be connected to the Identity Platform to install Login for Windows.
Find the config.json file you downloaded in step 8 of the Web Admin Configuration section of this document and edit it. Add the "install_without_idp" key and pair it with either the "grace_period" key or "access_level: 3" setting. The following example shows one kind of pair:
"install_without_idp": true
 |
Read about how this setting impacts end users in Login without connection to Identity Platform.
Optional: Enable pre-logon access provider to connect to VPN clients before Login for Windows login
Compatible with: conf_version 5 and later
You can enable a pre-logon access provider so that end users can connect to VPN clients before logging into Login for Windows.
You must set this option manually.
If the option is removed, the default behavior is the same as if it were set to
false.If the option is not added, end users cannot connect to VPN clients before logging into Login for Windows.
Find the config.json file you downloaded in step 8 of the Web Admin Configuration section of this document and edit it. Add the "auto_add_plaps" key and set it to true or false, as follows:
"auto_add_plaps": true
"auto_add_plaps": false
 |
Read about how this setting impacts end users in Login with VPN client.
Optional: Set redirect to questionnaire before login
Compatible with: conf_version 5 and later
Set the "follow_idp_redirect" and the "adaptive_enabled" options to true to redirect end users to a questionnaire that they must answer before logging into Login for Windows.
Enabling a redirect to a questionnaire is available in the Identity Platform version 19.07 or later.
You must integrate an Identity Platform Classic Experience realm; see Integrate pre-login questionnaire.
You must set these options manually.
The questionnaire you create can be any web application that can be run on a supported web browser.
If end users submit answers to the questionnaire and have their login request denied because they entered incorrect information, they can log in again after the expiration time set by the admin has passed. This scenario can be potentially frustrating for end users; consider adding a confirmation message that is displayed when end users submit their answers, for a final chance to check their entries on the questionnaire.
End users who are offline can bypass the questionnaire by default.
If the "follow_idp_redirect" option is removed, the default behavior is the same as if it were set to
false.If the options are not both set to true, end users will not see a questionnaire before logging into Login for Windows.
To view information about end users who have their login request denied because of risk score, check the Identity Platform debug logs and the Analyze API logs.
The following workflow describes how this feature is realized for admins and end users if "follow_idp_redirect" and "adaptive_enabled" are true:
Admins can integrate their corporate questionnaire by adding a risk provider and providing a web page with the questions. When end users submit answers, the web page submits the answers to the risk provider, and the risk provider handles business requirements, such as logging the answers for compliance purposes.
End users complete authentication that validates their identity, and then see a message that states "Additional information required. Click here to proceed."
After end users click the link, they are redirected to a pop-up form in a separate browser. They fill out the questionnaire, submit it, then close the browser, which resets the login process.
The risk provider returns a risk score, which determines if the end user is allowed to continue.
If the risk score is above the threshold, the end user login request is denied.
If the risk score is below the threshold, the end user can proceed to complete authentication as usual, such as by entering a password and fingerprint.
Find the config.json file you downloaded in step 8 of the Web Admin Configuration section of this document and edit it. Add the "follow_idp_redirect" and "adaptive_enabled" keys and set them to true, as follows:
"follow_idp_redirect": true, "adaptive_enabled": true
 |
Installation and upgrade steps
The following sections describe how to upgrade and install Login for Windows.
Upgrade Login for Windows
Login for Windows supports upgrading from version 1.0.4 to 20.09.xx without uninstalling before installing the latest version.
Upgrading from version 1.0.3 to 20.09.xx is supported but the cache is cleared. After the upgrade, the first available second factor will be selected by default instead of the previous second factor the user entered.
Upgrading from 1.0.2 or earlier, first uninstall Login for Windows before installing 20.09.xx. Upgrading from earlier than 1.0.2 to 20.09.xx is not supported.
If end users are using the SecureAuth Credential Provider and the admin upgrades to a later version of Login for Windows, end users do not need to uninstall the SecureAuth Credential Provider before installing Login for Windows.
Download and run the Login for Windows MSI package
Download the Login for Windows .zip file to the target machine (laptop, desktop, server, etc.).
Unzip the file.
Within the Login for Windows folder, find the .msi file for your machine, either SecureAuthLogin-20.09.00-x64.msi or SecureAuthLogin-20.09.00-x86.msi. Place the file in the Temp folder.
Install Login for Windows
Important
On a Windows server, SecureAuth Login for Windows should be installed or uninstalled only from a console session and not an RDP session.
Find the config.json file which you downloaded in step 8 of the Web Admin Configuration section of this document, and copy that file to the Temp folder on the target machine.
You might have already performed this step if you changed the user's access level in the Set End user Access Level section above.
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-20.09.00-x64.msi" /L*V "C:\Temp\install.log" /qn CONFIG="C:\Temp\config.json"
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 uninstalling 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 Identity Platform transaction log information
The Login for Windows software issues a User-Agent HTTP Request Header when the Application Programming Interface interacts with SecureAuth Identity Platform. 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:
SecureAuth Login for Windows 20.09.00 (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)
Login for Windows error logs
Error logs are displayed in the following locations.
Information related to installation is written in the
install.logfile:%temp%\install.log
Information related to logging in is written in the
login.logfile:C:\ProgramData\SecureAuth\login.log
The login.log log file displays system information, such as the type and version of the operating system, the version of Login for Windows your organization is running, and more as shown in the following image:
 |
After you view the login.log file, then connect later through RDP, you might see what look like inconsistencies because the log file will have new start lines and threads. This is expected behavior because connecting through RDP causes new instances of the credential provider to be created, which causes the new start lines and threads.
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.
Log files are not uninstalled; use them to assist with troubleshooting any issues with the uninstallation. After you have worked through any issues, you can delete the log files.
End user login experience on Windows 10
Important
If using a proxy that becomes unavailable, Login for Windows behaves as if it is offline. This issue might impact laptop users who connect their laptops to networks in which the proxy is unavailable.
The Self-service Password Reset might not function correctly for certain operating systems. On Windows Server version 2012 R2, users are unable to complete the self-service password reset process due to default Internet Explorer settings in the operating systems.
First login with password only
End users can log in without second-factor authentication for the number of days set by the administrator in the config.json file, in the grace_period value. This allows end users to log in with a password only (without using second-factor authentication), and typically occurs after the Login for Windows installation. End users can then access their device to set up their two-factor authentication methods, such as push-to-accept and answers to Security Questions, before they must authenticate to access their device.
Use case: Password-only login is useful for one or more new employees who have been issued a laptop on their first day of employment. For example, if Login for Windows is already installed on the laptops and the admin has not set a grace_period value, new employees might not be able to log into their computer if they cannot connect to the SecureAuth Identity Platform realm to register their mobile phone or self-service page to enter a phone number.
Workflow: End users are prompted to log in with their username and password only. The login screen indicates the number of days end users can continue to log in with a password only on the machine, as shown in the following image.
End users who want to log in with a password only enter their password in the field next to number 1. After end users set up their second-factor methods, they are ready to authenticate so they click the message next to number 2, which dismisses the password-only screen and opens the 2FA login screen. Thereafter, the 2FA login screen opens for end users.
 |
Login without connection to Identity Platform
End users can log in when their machine does not have a connection to the Identity Platform if the install_without_idp option is set to true and the grace_period option is set to at least 1 or the access_level option is set to 3 or 4. This allows end users to log in with a password only (without using second-factor authentication).
Use case: Password-only login is useful if a third-party company configures machines for end users and the third-party company does not have connectivity to the Identity Platform. For example, if Login for Windows is installed on machines by a third-party without a connection to the Identity Platform, and the admin has not set install_without_idp and grace_period or access_level values, when new employees get their machine, they will not be able to log in.
Workflow: End users are prompted to log in with their username and password only. The login screen indicates the number of days end users can continue to log in with a password only on the machine, as shown in the following image.
End users whose machines are not connected to the Identity Platform should contact the admin first so they can copy the message next to number 1 and send it to their admin. End users can then log in with a password only in the field next to number 2. After the machine connects to the Identity Platform, the 2FA login screen opens for end users so they can set up their second-factor methods and log in.
 |
Login with VPN client
If you have VPN clients and you enabled a pre-logon access provider by setting the auto_add_plaps value to true in the config.json file, end users can connect to your VPN server before logging into Login for Windows. The frequency that end users must log into the VPN client depends on settings completed by the administrator. When end users log into their machine, they will first select the VPN login icon, called Network sign-in, which is shown in the following image surrounded by a red box:
 |
End users can then authenticate with Login for Windows.
First-time login experience
If the administrator has set up a mandatory questionnaire for your organization to fill out prior to logging into Login for Windows, you will log in with a username and then you will be redirected to the questionnaire. After you fill out the questionnaire and submit it, close the browser to display the second-factor authentication screen.
Note that if different end users log into the same machine by using Other User, the Windows Credential Provider causes the end user that has answered the questionnaire to complete an extra step before logging in. The following describes the workflow for this scenario:
David logs off the workstation.
Maria sits at the same workstation, clicks Other User, and enters her username. Maria sees the "Additional information required" message, clicks the link, and fills out the questionnaire. She submits the form and closes the browser.
Maria sees the login screen for David. She must click Other User again, enter her username again, then she will see the 2FA screen where she can enter her password and MFA option to log in.
Enter your username on the Windows login screen.
To authenticate by using a different primary credential provider, proceed to instructions for logging in when using a different primary credential provider and alternate_providers.
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 Identity Platform realm to supply timed passcodes, such as an HOTP YubiKey.
If the end users need to login when their machine is offline, they must choose an OATH-based method during the first login. After end users select a timed authentication option and enter their password, TOTP and HOTP passcode options will be available for them to use when logging on the machine offline.
End users with more than one mobile phone or YubiKey provisioned can select which device or token to use when online. When logging on the machine offline, any OATH-based method that was used online will be available for use.
If you do not have an authentication method that provides a timed passcode, then select any other option available to you.
End users who already use the Authenticate app and want to add the ability to accept biometric push notifications to use face (iOS) or fingerprint recognition must first reconnect the account for their mobile device.
You can provision either "Approve login" or "Symbol-to-Accept." The following image shows the login screen with the "Approve login notification on mobile" option; if "Symbol-to-Accept" is set, end users will see the "Passcode from Symbol-to-Accept" option in place of the "Approve login notification on mobile" option on the login dropdown. (On the SecureAuth Authenticate mobile app, the icons will be different, but both icons will have a tool tip that reads "Approve login".)
If you are authenticating through a different primary credential provider (that is, not the SecureAuth credential provider), you will see the login screen offered by that credential provider. The different primary credential provider supports offline mode, for end users who need to login when their machine is offline.
The following image shows an example of a login screen, but yours will look different.
Sign in.
The image shows two sign-in options, a Microsoft credential provider (the key icon) and a Microsoft Smart Card credential provider (the card icon). To sign in, you could click the icon with your preferred method. If your site offers one kind of sign-in option, then only that option will be displayed for you to sign in with.
Additionally, if you can sign in as "Other user", a multi-user credential login provided by that credential provider will be displayed. After specifying who you are, click the Sign-in options link to choose which multi-user credential you want to use to sign in.
You have completed your authentication login process. You can disregard the remaining end user steps in this section and in "Subsequent login experience." Your login experience will remain the same as the one provided by your primary credential provider.
Notice the placement of the Password Reset icon on the lower left. To update your password, click the icon. Login for Windows is the password reset credential provider, and requires online network access.
Show or hide the passcode so that, as you type, you see characters instead of dots.
Focus on the passcode field and enter characters to see the following "eye" icon displayed.
Click the icon and hold it until the dots in the field turn to characters.
To hide the passcode, click and hold the icon until the characters turn to dots.
Fields | Instructions | |
|---|---|---|
| Timed passcode from app This method and "Passcode from token" are displayed at first login, if available. If not available, all available methods are displayed.
| |
| Passcode from voice call
| |
| Passcode from SMS / text
| |
| Passcode from email
| |
| Passcode from notification
| |
| Approve login notification on mobile
| |
| Contact help desk for passcode
| |
| Passcode from token This method and "Timed passcode from app" are displayed at first login, if available. If not available, all available methods are displayed.
| |
| Passcode from YubiKey This method and "Timed passcode from app" are displayed at first login, if available. If not available, all available methods are displayed.
| |
| Use passwordless as first factor This method and "Timed passcode from app" are displayed at first login, if available. If not available, all available methods are displayed. End users must have a fingerprint reader installed on their computer and must enroll at least one fingerprint to use passwordless as a first factor. For this option:
End users with external fingerprint readers should not disconnect the reader from their computer before logging out; doing so will cause an error to be displayed: Fingerprint data not found. The error is an "unknown identity" signal that the reader sends to the driver; however, the fingerprint data will be found when the reader is connected to the same computer. | |
| Use fingerprint recognition on mobile End users must use the Authenticate mobile app to use fingerprint recognition. For this option:
| |
| Use face recognition on mobile End users must use the Authenticate mobile app to use face recognition. This option is available to users on iOS mobile phones. For this option:
|
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.
Note
The login screen defaults to the authentication method used in the last login session.
To show characters as you type a passcode instead of seeing dots, refer to step 2.
You can provision either "Approve login" or "Symbol-to-Accept. The following image shows the login screen with the "Approve login" icon; if "Symbol-to-Accept" is set, end users will see the "Symbol-to-Accept" icon in place of the "Approve login" icon on the login screen. (On the SecureAuth Authenticate mobile app, the icons will be different, but both icons will have a tool tip that reads "Approve login".)
 |
Sign-in option icons | Fields | Instructions | |||
|---|---|---|---|---|---|
|
| Answers to Security questions
| |||
| Single user credential:
Multiple user credential:
| Timed passcode from app
| |||
|
| Contact help desk for passcode
| |||
|
| Approve login notification on mobile
| |||
|
| Passcode from notification
| |||
|
| Passcode from email
| |||
|
| Passcode from voice call
| |||
|
| Passcode from SMS / text
| |||
|
| Passcode from Symbol-to-Accept End users must use the Authenticate mobile app to receive symbols.
| |||
| Single user credential:
Multiple user credential:
| Passcode from token
| |||
|
| Passcode from YubiKey
| |||
| Single user credential:
Multiple user credential:
| Use fingerprint recognition on mobile End users must use the Authenticate mobile app to use fingerprint recognition.
| |||
| Single user credential:
Multiple user credential:
| Use face recognition on mobile End users must use the Authenticate mobile app to use fingerprint recognition. This option is available to users on iOS mobile phones.
|
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.
 |
Select one of the options and then enter the admin password.
 |
Note
Users with access to privileged accounts are not prompted for additional MFA when logging into their normal user accounts; however, it is possible to configure UAC policies to prompt administrators for password or MFA when they log into their normal user accounts. See UAC - Require a Password for Administrator.
To show characters as you type a passcode instead of seeing dots, click and hold the "eye" icon to the right of the characters.
Troubleshooting
Use the topics in this section to help you problem-solve.
Admin needs to view logs in Event Viewer
End users receive a message that Login for Windows encountered an error and are guided to try a different login method. Admins are guided to check the Event Viewer. The following steps describe how to open the Event Viewer to read the event logs.
In the Windows Search bar, type
eventvwr.msc.Open the Application folder. In Windows Logs > Application, select Filter Current Log, as shown in the following image.
In the Filter screen, in the Event sources field, type
LoginForWindows.
View the event information to troubleshoot the issue, as shown in the following example.
To export information, for example, to send to SecureAuth Support, click Save Filtered Log File As.
Release notes
The following sections describe the release enhancements, including resolved and known issues, for Login for Windows version 20.09.
Enhancements
Version: 20.09.xx
Release Date: 20.09.00: September 15, 2020; 20.09.01: January 12, 2021
Compatibility: Note the following compatibility requirements:
SecureAuth IdP v9.2.x or later and the SecureAuth Identity Platform v19.07 or later
Biometric fingerprint and face (iOS only) recognition require SecureAuth Identity Platform v19.07 or later, using the 2019 theme.
Transactional logging requires SecureAuth Identity Platform v20.06 or later, using the
/authenticated endpoint.The "grace_period" option replaces the "login_attempts" option.
CP-949 | After rebooting a machine where passwordless is set up and functioning correctly, passwordless login works correctly at next login. |
CP-507 | Characters in user IDs sent to Login for Windows are handled appropriately. |
CP-956 | Passwordless login is available in scenarios where end users' first login was bypassed so they logged in the first time with password-only. |
CP-959 | End users in a bypass group who must change their password at next login now see the password reset screen when they next log in. |
CP-962 | On the Login for Windows login screen, the face and fingerprint icons now display the correct tool tips when you hover the cursor over the icons. |
CP-966 | If Login for Windows is installed and references a realm that does not have the Authentication API enabled, the installation fails. This is the appropriate behavior. |
CP-970 | Product logging is enabled by default for DEBUG; when troubleshooting product issues, Support might require that you view this log located at C:\ProgramData\SecureAuth |
CP-971 | Log files are not uninstalled to assist with troubleshooting any issues with the uninstallation. |
CP-985 | During login, the username is bypassed for end users in a bypass group, even after canceling a login because of an expired password. |
CP-991 | Message improvements to help the user experience. |
CP-993 | The credential prompt will be displayed quickly in the following scenario: Install Login for Windows, open a remote desktop connection, and then connect to another machine that has a remote desktop connection enabled and Login for Windows installed. |
CP-1082 | Push-to-accept works with Login for Windows version 20.09.01 in the SecureAuth Identity Platform version 20.06+ cloud deployment. If you use a load balancer, there is no cloud deployment restriction. |