Two-Step Login for System Access
For Administrators: How to add Two-Step Login for logging in to servers and workstations
This article applies to: Two-Step Login
Console Login vs Remote Access
The Two-Step Login service is primarily intended for enhanced security of critical services and data repositories. Duo also lets you add two-factor authentication for logging in to Unix, Windows and Mac OS systems.
• Unix two-factor authentication can be required for remote access via SSH.
• Windows two-factor authentication can be used both with console login and with remote access via RDP. There is an option to apply the requirement only to RDP access and not to console login.
• Mac OS two-factor authentication is supported only console logins, though it can also be required when using SSH for remote access to the underlying Unix shell.
Requiring two-factor authentication for remote system access is a valid security measure, but the value of similarly protecting local console login is less clear. This may not be relevant for most workstations in the Cornell environment, and presents some challenges.
For any of these login applications, you should carefully review both the instructions on the Duo site and any FAQ material. They have some significant limitations, e.g., the ability to bypass two-factor authentication under Windows by booting into Safe Mode. Two-Step Login for console access should be viewed as effective only on tightly managed workstations.
Console Login and Policy 5.10
You may be considering adding Two-Step Login to console login to satisfy the requirements for protecting confidential found in Policy 5.10, Information Security. In particular, you may see this as a means to enforce two-factor authentication before mounting a share, or some other repository, that contains confidential data. A simpler solution would be to allow access to the server in question only over a private/departmental VPN that requires secondary authentication, even for access from on-campus networks.
Fail Open and Console Login
Console login is an application where you can elect to set failmode to open/safe instead of closed/secure. This enables logins with just username and password when a system is not connected to the Internet. If the system is lost, its contents should still be protected by whole-disk encryption, as mandated in Policy 5.10, Information Security.
Administrator / Tech Support Accounts
A serious obstacle to requiring Two-Step Login for console login on Windows and Mac OS systems is that this would prevent logging in with a local account that is not based on a NetID. Such accounts are very commonly used to provide administrator access for IT support personnel. If failmode is configured to safe/open, then such non-NetID accounts can be used for login when the system has been taken off the network.
Another solution is to request that the New user policy for the Duo integration you are using for console login be set to “Allow” rather than “Deny.” With the “Allow” setting only people who have existing Two-Step Login accounts need to complete the second step of logging. Access using other accounts, like a tech support account, will just require a username and password.
This approach is viable because most members of the campus community, including all employees, are now required to have a Two-Step Login account and so logging in with any NetID-based account on the system should trigger two-factor authentication.
The Duo application for Unix login via SSH allows one to create a local group that defines who does and doesn’t need to use two-factor authentication. This can be used to permit accounts not based on NetIDs to log in with just username and password.
Duo Client Software and Shared Application Keys
For each system where you want to add two-factor authentication to the login process, you will need to install and configure client software provided by Duo. Ideally, each system should have its Duo application, with unique integration and secret keys. Especially for an area that is broadly deploying Two-Step Login for access to workstations, this would be a large logistical burden.
Duo has confirmed that there is no significant security risk to using the same login integration, with the same keys, across multiple systems. At least for workstation login, one Duo Application can be used to support an entire work group or department. These users and systems should, however, share a similar security profile and a similar level of risk. For diverse environments, separate Duo Applications can be created.