There are 2-ways to utilize the Evo Secure Login:
- Via a web browser login to evosecurity.com, or an integrated SAML web application.
- Via Windows (Desktop or Server) login through the Evo Credential Provider (ECP).
In the past, these were treated as two separate logins. The usernames and passwords were unique unless the user purposefully made the passwords the same.
In the Evo system, there are mappings between the Windows username for a certain directory and the email account. The email address can be thought of as a kind of primary key. Based on a username and directory, the Evo system can determine the associated email address for an account. Based on an email address, the Evo system can find pairs of usernames and directories.
With the Evo Secure Login LDAPs Agent, there will still be two sets of credentials—but only one password. On the Evo application, the username will still be the email address, however, the password will now be the Active Directory (AD) password. For Windows login, the username and password will remain as they always have been.
If you are looking for instructions on how to install the Evo Credential Provider with your windows machine, head here! - Integrating Evo with Windows Desktops
When a user logs into Evo via the web page, the user enters their email address and password. Based upon this combination, the system sends a push notification to the Evo Secure Login mobile app and if accepted, logs in the user.
When a user logs into their computer via the Evo Credential Provider, the credential provider prompts the user to enter their username and password.
The username and password combination are for the Windows/AD account.
If the account is recognized, the credential provider progresses to a new screen where it prompts the user to enter an MFA code.
**If the user does not see the next screen, it is because:
- Evo Credential Provider could have been configured incorrectly.
- The user does not have an Active Domain account registered on Evo.
- Possible network problems.
If the user approves the push notification, or if they successfully enter the MFA code in the ECP, and the Windows credentials are correct, then Windows will logon the user.
If the user is prompted for an OTP, but the push notification was not received. It could be a result of:
- The user has not set up the Evo Secure Login mobile app for their AD account on their phone.
- The AD account is mapped in the Evo system to a different email account than what the user expects.
Error scenarios for Windows Login
When the user tries to log into Windows using the ECP, there are several ways that the system can fail to logon.
- The user enters an incorrect password for the system. In that case, the user will be displayed a message ofThe username or password is incorrect.
- The user manually enters the MFA code, the MFA code may be incorrect. In that case, the ECP will display a message of Wrong One-Time Password!
- The user enters an account name that the Evo system cannot find, then the ECP will display a message like Unable to connect to server. There may be more than one reason this message could be displayed: User has not been synced to Evo with the entered username/email address.
4. If the user’s network is down or the Evo website is somehow down, the user can receive the above-mentioned message. If it is a networking problem. The user has a previous successful login on the machine, then there should be some stored offline MFA codes. In that case, the user will see a display message of Failed to connect. Use stored OTP.
5. If the user would like to back out of any sign-in flows, make sure the text boxes are empty and hit ENTER/RETURN. This will cancel the sign-in flow and back the user out.
Registry settings for Evo Secure Login
The base registry setting is HKEY_LOCAL_MACHINE\SOFTWARE\EvoSecurity\EvoLogin-CP
The following values in this key are as follows:
Can be 10,90, or 100 which indicates “Elevated Login”, “Secure Login”, or both “Secure and Elevated Login”
This is the user directory on Evo
The Windows username of an account for which Evo MFA will be bypassed. Typically, an administrator account in case anything goes wrong like network down, etc.
Evo Elevated Login
Evo Elevated Login is part of the Evo Credential Provider. When installed, it is installed as Evo Secure Login, Evo Elevated Login, or Evo Secure+Elevated Login. This is all controlled in the registry depending on how credential_mode is set.
What Elevated Login does is allow the Evo Directory administrator to assign Windows administrator accounts to Evo logins. With these types of logins, a user can administrate a Windows machine, but they are unaware of the actual credentials to the Windows machine.
Evo LAPS Login
Evo also supports LAPS login. LAPS is an acronym for Local Administrator Password Solution. It is a Microsoft Technology which works in concert with Active Directory (AD). It is a free downloadable feature to enhance Active Directory.
Consider one typical usage scenario. A technician at XYZ MSP needs to install some software on a specific machine for their client Acme. The technician will have to login to the machine at Acme via RDP and will use the machine Administrator account. LAPS is installed on the AD network and local machine at Acme. The technician will use one of two methods to do this:
- Login to the machine as local Administrator with the LAPS password and perform admin tasks
- Login to the machine with a domain (or local) account, elevate using UAC with the LAPS account credentials to perform local machine admin tasks
Protecting LAPS Login With MFA
The Evo Credential Provider enables LAPS login with MFA in the following way:
If the local machine is enabled for LAPS, the LAPS checkbox appears on the credential provider. An example screenshot for UAC with LAPS is here:
If the local machine is capable of LAPS, then the checkbox for LAPS is displayed and enabled.
The credential provider determines if LAPS is capable by examining the registry. The end user or end administrator need not be concerned about these settings. These registry settings are populated when a domain admin either creates group policy for LAPS or install it manually on a workstation or laptop. The conditions necessary for LAPS to be enabled are:
- The registry key HKEY_LOCAL_MACHINE\software\Policies\Microsoft Services\admpwd must exist
- If the registry key exists, then it is possible for there to be a AdmPwdEnabled value under that key. If the value does not exist or if it is non-zero, then the condition is met. For most cases, the value will be absent.
- If the AdminAccountName value is present under that key, then the system checks to see if that user exists on the system. If the user exists, then the condition is met. Otherwise, if the value is not present (most likely scenario), then the system verifies that it can locate the local administrator account to meet the condition.
MFA Grace Period
There will now be a grace period when unlocking a computer. This setting is in the installer as parameter MFATIMEOUT and it appears on an installer configuration screen.
The valid ranges for the timeout are 0-1440 minutes. Zero indicates that MFA is always required when unlocking. If a number greater than 1440 is used, then 1440 will be used. FYI, 1440 is the number of minutes in a day.
How does it work?
The MFA Grace Period only works for locking the computer, not on a log out. Logging out will still require the user to MFA. However, if the user only locks the screen and a Grace Period is set, the user can bypass MFA. For a more detailed explanation of how the MFA Grace Period works, please visit this article - MFA Grace Period
The new installation screen looks like this, with the new included MFA Grace Period setting and Access Token/Secret Key fields. For more information on what has changed with Access Tokens, please view this article - https://support.evosecurity.com/hc/en-us/articles/10117446354971 :
This also includes the updated Evo Settings Editor for dynamic editing of the provider.