MFA improves network security by reducing vulnerabilities associated with Windows authentication.  MFA protects against compromise using a token generated one-time password (OTP), or user certificate stored on a smart card, in conjunction with a user account and password.  Malware or hackers cannot use stolen passwords without the additional OTP or certificate.

MFA Introduction: Multi-factor (MFA) or two-form authentication is a system that requires multiple verification methods for user and administrator sign-ins.  MFA requires more than a simple user name and password. The process requires at least two of the following:

• Something logical (e.g., password).
• Something physical (e.g., smart card).
• Something biological (e.g., finger print reader).

Problem:  Compromise of administrator account credentials on domain-joined computers can jeopardize the integrity of the entire domain.  The compromise of remote access accounts can result in the access of sensitive information from external attackers.  Compromise is a consequence from malware, hackers, and additional threats.

Purpose:  The purpose of this MFA research is to:
• Safeguard administrator accounts from compromise.
• Protect remote access to internal networks.
• Secure email on phones and webmail.
• Do not compromise usability.

Significance:  MFA provides effective security control in two scenarios: (a) to secure administrator accounts and (b) to secure remote access.   Administrator accounts have a wide range of user rights; and compromise of one of these accounts can provide an intruder access to the entire Windows network.   MFA also provides an additional layer of security for users who require remote connectivity.

MFA enabled networks are less vulnerable to malware and hackers because stolen passwords are only useful with corresponding smart cards (or tokens).  In addition, MFA provides increased security because digital certificates and one-time passwords (OTP) are difficult to forge.

Applicable Use:  In most instances MFA can protect the following systems:

• Workstation logins.
• Server logins.
• Virtual private network (VPN) logins.
• Remote desktop services (RDP).
• Websites.
• Exchange ActiveSync (smart phone email).
• Outlook Web Access (OWA).
• Radius (e.g., 802.1x, including wireless and wired networks).

RSA SecureID:  RSA SecureID provides two-factor user authentication through the use of hardware (e.g., USB dongle) or software (e.g., smartphone app) tokens.  Token serial numbers are assigned to Active Directory (AD) users on a Radius server.  The tokens generate a random authentication code (i.e., OTP) at fixed intervals (e.g., 60 seconds).  The temporary OTP is unique for each token.  Employees enter the RSA OTP, along with their username and password, during the login process.

Figure 1.  RSA SecureID workflow.

RSA SecureID also strengthens administrator authentication to sensitive servers such as Domain Controllers (DCs), file servers, or databases.  Network administrators should already use dual accounts.  The domain user account is used to log onto workstations for daily tasks.  The domain admin account is used for administrative purposes.  Security is substantially improved when SecureID OTPs are required for all administrative changes.    

The SecureID access manager operates on either RSA appliances or virtual machines (VMs).  The VM servers are included with licensing fees.  At least two access manager servers should run to ensure high availability.  RSA agents are installed on all devices (e.g., workstations, servers, etc…) that require MFA.

Windows Azure MFA:  Windows Azure MFA uses a locally hosted MFA server (VM) in conjunction with an ADFS proxy server for user authentication.  The ADFS Proxy is a service that brokers a connection between external users and the ADFS server.

ADFS is a single sign-on (SSO) technology that can be used to authenticate a user into multiple applications over the course of a SSO.  ADFS allows cross-forest trusts and extends that trust between web applications.  SSO and ADFS ensures user passwords never leave on-premise local servers.  Passwords are never moved to the cloud.

Azure MFA is limited to Web-based and Radius-based authentication.  The service is intended to secure access to remote resources (e.g., RDP, VPN, and Web pages).  The service is not intended to secure administrative roles.

Figure 2.  Microsoft Azure MFA.

CBA Authentication:  Certificate-based (CBA) resources authenticates with user assigned secure socket layer (SSL)/ transport layer security (TLS) certificates.  The user certificate is used in place of entering user credentials.  By itself, CBA is not two-factor authentication. Two-factor authentication is based on something you have plus something you know. CBA is only based on something you have.  However, CBA can be considered MFA when combined with local logins or smart phone pins.

CBA has similar limitations to Azure MFA.  CBA authenticates remote resources (e.g., RDP or Outlook Web App) but it does not secure administrative roles.  Administrators assign user certificates to devices (e.g., laptops).  Private-keys protect assigned certificates and prevent unauthorized copying/exporting.  In the event a device is stolen or lost, the certificate also remains protected with the device login credentials (e.g., Windows), pin number (e.g., phones), and hard drive encryption.  Administrators can easily revoke user certificates when employees report the device as lost or stolen.
 
CBA can also secures Exchange ActiveSync.  Administrators import user certificates to Apple iOS and Windows 8 phones for Exchange authentication.  Exchange policy enforces ActiveSync authentication per user or per group.  Exchange policy also enforces smart phone encryption and can wipe the phone after X number of unsuccessful logins.

CBA requires an enterprise AD CA.  Organizations that do not use domain CAs may want to reconsider this valuable resource.  Windows technology  increasingly depends on SSL certificates.  There is high likelihood that most organizations will require a domain CA in their near future.

Smart Card Authentication:  Smart cards are similar to RSA SecureID tokens.  Smart cards allow robust MFA and can secure administrator access to internal production servers.  Smart card authentication of secondary actions enables better segregation of user and administrator accounts.  Smart cards also provides domain user accounts MFA to workstations, applications, and other local resources.  Smart card drivers and functionality is included with Windows; external agents are not necessary.

Smart cards require an enterprise AD CA infrastructure that can be used with CBA.  Administration is mostly accomplished with CA policies and group policies.  Smart cards use memory to store private keys and user certificates.  The private key cannot be extracted from a smart card.  Smart cards require a password in addition to certificate authentication.  Physical cards and readers are the only hardware expense.

Conclusion:  Each MFA solution introduces similar benefits.  The primary differences are administrative support, end-user devices, and cost.  MFA advantages are summarized (Table 3).  RSA SecureID has a good reputation and may be the easiest solution to implement.  The disadvantage to RSA is that third party agents are required on every server.  RSA is also the most expensive solution available.  Windows Azure MFA is affordable but it only protects remote access servers; it does not provide MFA for administrative accounts.  Smart card and CBA are the most affordable solutions.  Smart card implementation is moderately complicated because it requires AD CA infrastructure.  However, AD CA services will provide most organizations additional benefits in the near future.  Smart cards offer the best value because of their affordability and integration with Windows infrastructure.

MFA technologies are briefly compared (Table 1).