- Incorrect IP addess used for Adaptive Authentication
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.
- AD bad password count incorrectly incremented
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.
- Re-installation breaks login functionality
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.
- Login failure for users with a space in sAMAccountName
The issue has been resolved for users who were unable to log in if a space exists in their sAMAccountName property.
- Users in a bypass group unable to use Self-Service Password Reset function
The Self-Service Password Reset link now appears for users who are in a bypass group.
- Installation requires an absolute path to the configuration file
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).
- Potential offline lockout for new users
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.
- Double prompting for RDP logins
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.
- Self-service Password Reset function is non-proxy aware
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.
- Self-service Password Reset may not function correctly for certain Operating Systems
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.
- Offline endpoint when proxy is unavailable
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-installing Login for Windows does not apply configuration file updates
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.
- SMS and Voice numbers are not correctly masked
Users prompted for Multi-Factor Authentication can view the full telephone number for a registered Multi-Factor Authentication method.
- Incorrect username shown on lock screen
Users in a bypass group are shown the wrong username on a Windows 7 workstation lock screen.