New features and enhancements
|CP-447||An empty screen without login functionality no longer appears after installation.|
|CP-288||Login for Window performance degradation when loading the login screen in the offline mode on Windows 10.|
|CP-386||SMS / Voice telephone numbers are not completely masked for registered Multi-Factor Authentication methods.|
|CP-414||User details are missing when choosing a registered user on the "Other user" login screen|
|CP-416||Manual uninstallation from the "Programs and Features" menu on Windows 10 results in an error.|
|CP-443||User is given a private IP address when Adaptive Authentication is used in an RDP session.|
|CP-447||Non-local user whose account is not found in Active Directory receives an empty login screen.|
|CP-457||User is blocked by Adaptive Authentication on Windows Server 2012 R2 and receives an error message if no alternate providers are configured.|
|CP-470||The last user displays even with the multiple_user flag set.|
|CP-472||Adaptive Authentication login error after Login for Windows installation on Windows 7.|
When logging on locally, SecureAuth IdP now correctly uses the endpoint's public-facing IP address instead of a local adaptor IP address.
In this issue, a private IP address was being used which prevented IP-related Adaptive Authentication features from functioning properly. Remote / RDP logins were not impacted by this issue.
When attempting to log on using a bad password, the bad password count now increments appropriately – i.e. one time for each login attempt.
In this issue, the Active Directory bad password count would increment multiple times for a single login attempt, causing the user to be locked out immediately or sooner than anticipated. In certain scenarios, the bad password count incremented once for each OATH seed-based Multi-Factor Authentication method – e.g. for each app-based OTP or hardware token.
Login for Windows can now be re-installed on the same machine.
In this issue, the Login for Windows software could become corrupted if re-installed on a machine which already had the software installed. This issue prevented users from logging in and required the user to boot up the machine in safe mode to repair the software.
Beta support is now available for proxies in Login for Windows – see Login for Windows Installer Configuration to configure Login for Windows 1.0.1 for use with a proxy. Note the known issues when using a proxy in the 1.0.1 release.
This issue affected environments in which direct access to the SecureAuth IdP appliance is blocked and users must use a proxy.
The issue has been resolved for users who were unable to log in if a space exists in their sAMAccountName property.
The Self-Service Password Reset link now appears for users who are in a bypass group.
The installer does not accept a relative path to the configuration file, which prevents deploying the installer from a directory that cannot be defined in advance (such as when using a Group Policy).
To use the offline mode, a user must first use an OATH-based authentication method – such as a one-time code (OTP) generated by the SecureAuth Authenticate App – at least one time while online in order to cache the OATH seed used for authenticating the user. SecureAuth recommends instructing users how to enable the offline mode before they attempt to go online.
A future release of Login for Windows will address the potential new user lockout issue by providing guidance to users during the login process.
Users utilizing NLA (Network Level Authentication) when logging on a system with RDP enabled may still be prompted for a username and password once the session is established.
The Self-service Password Reset feature – which opens a browser to a Self-Service Password Reset page – does not function in environments using a proxy to access SecureAuth IdP.
In these scenarios, 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 – this feature functions properly in proxy environments.
On Windows Server versions 2008 R2 and 2012 R2, users are unable to complete the self-service password reset process due to default Internet Explorer settings in the operating systems.
Use of any proxy configured for Login for Windows becomes mandatory. If the proxy is unavailable, Login for Windows behaves as if it is offline.
This issue may impact laptop users who connect their laptops to networks in which the proxy is unavailable.
Re-running the installer with a new or updated configuration file does not result in configuration changes made to the current installation. Administrators must uninstall and then re-install Login for Windows to apply the new settings.
Users prompted for Multi-Factor Authentication can view the full telephone number for a registered Multi-Factor Authentication method.
Users in a bypass group are shown the wrong username on a Windows 7 workstation lock screen.