Two-Factor Authentication

(1)

Two-Factor Authentication for Exchange Online Office 365 Dedicated & ITAR-Support Plans April 26, 2013

Two-Factor Authentication

(2)

Exchange Online Two-Factor Authentication

2

The information contained in this document represents the latest available subject matter available to Microsoft

Corporation as of the date of publication. Since Microsoft must respond to changing market conditions, this document should not be interpreted as a commitment of any type on the part of Microsoft. Further, Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

The content of this document is proprietary and confidential. The material is intended only for customers of the

dedicated and ITAR-support plans of Office 365 for enterprises. This content is provided to you under a Non-Disclosure Agreement and cannot be distributed without the express written permission of Microsoft Corporation. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in, or introduced into, a retrieval system or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise) or for any purpose without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft; the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or any other intellectual property. Reference http://www.microsoft.com/permission for additional information.

Descriptions in this document of the products of other companies, if any, are provided only as a convenience. Such references should not be considered an endorsement of a product by Microsoft or as an indication of support provided by Microsoft for a third party product. Microsoft cannot guarantee the accuracy of the third party references since product offerings of these companies may change over time. In addition, the descriptions are intended to be brief highlights to aid understanding rather than as thorough subject matter coverage. For authoritative descriptions of these third party products, please consult their respective manufacturer.

MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft and Windows are either registered trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, without the expressed written permission of the Microsoft Corporation.

(3)

3

About this guide 4

What is Two-Factor Authentication? 5

Functional Overview of 2FA within Exchange Online 6

User Authentication Scenario 6

Establishing a 2FA environment for Internet clients 8

Establishing a single sign-on experience for Intranet clients 9

Group Policy Object Configuration Method 9

Modifying the Site to Zone Assignment domain policy 9 Setting Integrated Windows Authentication Attribute 12

Manual Configuration Method 13

Internet Explorer Manual Configuration 13

Manual Configuration for Other Web Browser Types 14

Supporting the 2FA environment 15

User connectivity issues with the 2FA Portal 16

User browses to the wrong URL 16

User browses to a restricted URL 17

User exceeds the maximum number of logon attempts 18

Network Connectivity between 2FA Portal and Authentication Servers 19

Issues and Possible Causes: Outlook Web App Authentication Failed Error 19 Issues and Possible Causes: No Outlook Web App Login Page 20

Supporting Integrated Windows Authentication clients 22

Appendix A: RSA SecureID User Experience 24

(4)

4 About this guide

The content of this guide describes two-factor authentication (2FA) features for the dedicated and ITAR-support plan offerings of Exchange Online. The information provided represents features and functionality as of the date of publication. The guide addresses the following topics:

 An overview of 2FA fundamentals

 Requirements to establish a 2FA environment for Internet clients

 Steps to implement Integrated Windows Authentication for Intranet clients

 Support for the 2FA and Integrated Windows Authentication environments

Note: The reader of this document is assumed to be an IT Professional or member of a Service Desk staff that has familiarity with the following:

 Active Directory authentication fundamentals

 The 2FA solution chosen and deployed by the customer

(5)

5 What is Two-Factor Authentication?

Typical authentication practices that require only a password to access resources may not provide the appropriate level of protection for information that is sensitive or vulnerable. Two-factor authentication (2FA) is an authentication method that applies a stronger means of identifying the user. It requires users to submit two of the following three types of identify proofs:

Authenticate using something only you know

To access your corporate network you are required to provide a set of credentials that confirms your identity on the network. You satisfy the requirements of the first category when you provide a valid domain username and password.

Authenticate using something only you have

One option to satisfy the second category is to use a Smartcard and the associated PIN as credentials – an Automated Teller Machine (ATM) is this type of experience. Other PIN oriented experiences can involve the submission of a uniquely generated one-time use PIN displayed by a fob device or the use of a personal PIN to decipher a text or numerical string to produce an actual PIN for one-time access use.

Authenticate using a part of yourself

Another option to satisfy the second category is biometric authentication – literally using a part of your body to prove your identity. Some examples include the following:

 Having your finger scanned to verify your fingerprint.

 Using an ocular scan to verify your retina or iris.

 Facial or voice recognition.

Customers that subscribe to Exchange Online within a dedicated or ITAR-support plan of Office 365 for enterprises can enable and use the RSA SecurID product of EMC Corporation or the PINsafe product of Swivel Secure. The chosen 2FA solution will involve the use of the Microsoft Forefront Unified Access Gateway (UAG) of the Office 365 environment. The UAG will manage authentication processes and present a forms based authentication page that accepts the Active Directory credentials of the user and a 2FA passcode (RSA) or 2FA one-time password (PINsafe). UAG then manages the authentication processes involving the 2FA backend systems deployed by the customer within their environment. UAG also will provide the pathway to the Exchange Online Client Access server if the validation of authentication credentials is successful.

The use of 2FA is not required or provided for an Outlook Web App client on a corporate intranet. A customer can configure Integrated Windows Authentication to allow the Web browser based user to have a single sign-on experience to access Exchange Online.

(6)

6 Functional Overview of 2FA within Exchange Online

The 2FA functional concepts for the RSA SecureID and Swivel Secure PINsafe products are similar. The scenario below provides an overview of the processes to authenticate a Web browser based 2FA user attempting to connect to Outlook Web App of Exchange Online from outside of their corporate network.

User Authentication Scenario

(7)

7

1a. To load the page, John’s machine queries a public DNS server to resolve the public IP Address associated with https://securemail.contoso.com – the publicly accessible 2FA Portal. The address returned for the portal is a dedicated HTTPS URL namespace. This namespace is separate from URL namespaces that are reserved for services that do not require 2FA such as Exchange Web Services and remote procedure call (RPC) over HTTP.

1b. The 2FA Portal URL is https://securemail.contoso.com. John’s machine connects to this site and requests the default page.

1c. The 2FA Portal receives the request and serves a login screen which displays in John’s browser. John completes interaction with the 2FA server and provides the following as described below.

o RSA SecureID: Username, password, and the RSA passcode (personal four-digit PIN and the six-digit passcode displayed on the RSA fob) – see user experience in Appendix A.

o Swivel Secure PINsafe: Username, password, and the one time code derived by using a personal PIN – see user experience in Appendix B.

2. The 2FA Portal is configured to always pass security code information to a specific 2FA authentication server on Contoso’s network. The following security code validation steps are performed:

a. The 2FA Portal securely connects to the 2FA Authentication Server in Contoso’s corporate environment to verify the security code and authenticate the user. (Red)

b. The Authentication Server evaluates the code provided and if confirmed the server returns an authentication response to the 2FA Portal to complete the first authentication factor. (Green) 3. The 2FA Portal connects to a Domain Controller on the Contoso corporate network to verify the Active

Directory (AD) username and password of the user. The following domain credential validation steps are performed:

a. The 2FA Portal securely connects to a domain controller in the Contoso corporate environment using the Office 365 Managed Domain Active Directory trust to verify the username and password of the user. (Red)

b. The Domain Controller verifies the credentials and returns an authentication response to the 2FA Portal. (Green)

(8)

8 Establishing a 2FA environment for Internet clients

The following outlines the requirements to implement either an RSA SecureID or Swivel Secure PINsafe 2FA solution to support Web browser access to an Exchange Online environment using an Internet based client.

1. To use two-factor authentication with Exchange Online, a customer must provide (a) the RSA SecureID or Swivel Secure PINsafe back-end infrastructure within their on-premises environment and (b) the SSL certificate generated by a public certificate authority for the URL used for two-factor authentication. Microsoft provides, activates, and supports, the components that pass the authentication requests to this back-end infrastructure. 2. Only the “premium” (full client) version of Outlook Web App is supported; the use of the “light” version of

Outlook Web App with mobile devices is not supported. .

3. Suitable Web browsers for Outlook Web App when used in conjunction with a 2FA solution are described within the Office.com article Software requirements for Office 365 for business. Customers can consider using other browsers supported by their chosen 2FA solution; compatibility testing of these browsers with Office 365 is a customer responsibility.

4. The client Web browser used for Outlook Web App access must have the Outlook Web App URL for Exchange Online listed as a trusted local intranet site within the Web browser.

(9)

9 Establishing a single sign-on experience for Intranet clients

To provide a seamless “single sign-on” experience for an Intranet based client, specific configuration steps must be followed to enable the user’s validated credentials to be passed between the client Web browser and Exchange Online. When this configuration is established, Integrated Windows Authentication will be used to enable the Web browser of the client to interact with the Outlook Web App feature of Exchange Online. The two options available are (1) domain policy set through Group Policy object (GPO) feature of Active Directory or (2) the manual configuration method.

Group Policy Object Configuration Method

For client systems using the Internet Explorer (IE) Web browser, the Group Policy features of Active Directory can be used to propagate a Site to Zone Assignment domain policy to each IE browser. The domain policy will address the placement of specific site URLs in the Local Intranet zone defined for the browser.

Modifying the Site to Zone Assignment domain policy

The Site to Zone Assignment List policy setting associates sites to zones using the following values for the Internet Security zones: (1) Intranet zone, (2) Trusted Sites zone, (3) Internet zone, and (4) Restricted Sites zone. If you set this policy setting to Enabled, you can enter a list of sites and their related zone numbers. The association of a site with a zone ensures that the security settings for the specified zone are applied to the site.

1. Within your Active Directory environment, invoke the Local Group Policy Editor by executing the following:

gpedit.msc

Open the console tree to expose User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page

(10)

10

(11)

11

3. Within the Show Contents dialogue box, type the URL of the Outlook Web App URL for Exchange Online in the “Value name” field and type 1 as the “Value” – this represents the Intranet Zone as shown in the following table:

Zone Number Zone Name

1 Intranet Zone

2 Trusted Sites zone

3 Internet zone

4 Restricted Sites zone

The zone assignments for the user will be refreshed when the user logs onto their client system. An administrator can execute the following to have the values immediately applied:

gpudate /force

 Important: When the Site to Zone Assignment domain policy is enabled and applied, all existing URLs for all zones within Internet Explorer will be overwritten and the user will not be able to apply any changes. If other URL values must be set for other zones, these URLs should be added to the Show Contents

(12)

12 Setting Integrated Windows Authentication Attribute

Within the IE browser, the Enable Integrated Windows Authentication attribute also must be set. By default, this setting is enabled. If a GPO is required to force the attribute to be the correct value, EnableNegotiate is the registry key which must be set to true. The path to the attribute is displayed in the lower border area of the Registry Editor snapshot shown below.

When the policy has been applied, the Integrated Windows Authentication attribute should appear as being activated in the Internet Options view of IE as shown below.

(13)

13 Manual Configuration Method

The manual configuration method can be used for Internet Explorer (IE) and it must be used for all other Web browser types. The information provided below can be repurposed for end user use.

Internet Explorer Manual Configuration

The following steps describe the manual configuration method to establish a trust between an IE based client and the Outlook Web App URL for Exchange Online:

(14)

14

2. Within the next layer of the Local Intranet dialogue box, enter the Outlook Web App URL for Exchange Online within the “Add this website to the zone” field. Click the Add button and then Close or Ok to serially close all dialogue boxes.

Manual Configuration for Other Web Browser Types

Microsoft does not provide direct support for other Web types. To manually configure a Web browser other than IE, seek guidance from the manufacturer of the Web browser.

Note: As indicated above, the client system must be joined to the Active Directory account domain of the Customer forest; client systems that do not utilize Microsoft Windows are unable to meet this

(15)

15 Supporting the 2FA environment

Issues related to 2FA generally are either user errors or server errors. Customer Helpdesks & IT Pros are expected to identify the source of a 2FA issue, troubleshoot the issue to their level of responsibility, and escalate specific issues to the attention of Microsoft Online Services Support (MOSSUP) as appropriate. Troubleshooting guidance and a summary of support roles and responsibilities are included in this section.

As a quick reference, support guidance is provided within this section for the following issues:

 User connectivity issues with the 2FA Portal

 Network Connectivity between 2FA Portal and Authentication Servers

The table below provides an overview of support roles and responsibilities involving the customer and Microsoft. 2FA Support Roles and Responsibilities

Task Customer Microsoft

Account Maintenance  

Customer 2FA server issue  

End user Network connectivity issue  

Entitlement  

Password reset  

User education  

User error  

2FA Portal configuration  

2FA Portal network connectivity issues  

2FA Portal server configuration issue  

(16)

16 User connectivity issues with the 2FA Portal

User attempts to browse to the 2FA Website and receives an error.

User browses to the wrong URL

If a user navigates to the wrong website, a multitude of errors may appear. The user may receive an error stating the Internet Explorer cannot display the webpage:

Resolution

(17)

17 User browses to a restricted URL

If a user attempts to access a site on the 2FA server other than the default login site, they may see a “You have attempted to access a restricted URL” error:

Resolution

A restricted URL error means the user can in fact access the 2FA Portal but an incorrect URL was used. Suggested troubleshooting steps are the following:

1. Ensure that the user is typing in the correct URL. Verify “https” is being used.

2. Determine if the issue occurs from multiple network locations. For example, identify if connectivity is possible from a home environment and not a public location. If the connectivity experience varies, a network firewall rule probably is preventing the client machine from reaching the 2FA server. 3. Determine if the user experiences the same problem using another machine. If false, the user’s MAC

(18)

18 User exceeds the maximum number of logon attempts

User receives an error message stating they have exceeded the maximum number of login attempts.

Issue is likely due to the end user entering incorrect domain credentials, in correct password and passcode (RSA SecureID) or one time code (Secure Swivel PINsafe), use an incorrect PIN, or a combination of any of these incorrect entries. Users are allowed three (3) attempts to login successfully through the 2FA service. Once this maximum number of attempts is reached, the user’s account will appear to be locked in the browser.

Resolution

If the Outlook Web App login screen displays the “User validation error” message, the 2FA web page will block any subsequent logons in the current browser session. The user must close all instances of their browser, restart the browser, and attempt to login again.

(19)

19 Network Connectivity between 2FA Portal and Authentication Servers

A network connectivity failure between the 2FA Portal and either (a) the Authentication Server of the customer provided 2FA solution (b) the Active Directory domain controller of Office 365, or (c) the Client Access server of Exchange Online will result in users being unable to utilize Outlook Web App. Scenarios (a) and (b) are illustrated in the diagrams below.

Issues and Possible Causes: Outlook Web App Authentication Failed Error

The user enters the correct password and passcode (RSA SecureID) or one time code (Secure Swivel PINsafe) but receives an “Authentication Failed” message from Outlook Web App.

Incorrect authentication information or connectivity between the 2FA Portal and either the 2FA Authentication Server or the Active Directory domain controller are the likely causes.

(20)

20

Resolution

1. Verify that Outlook Web App is accessible from within the corporate network. If Outlook Web App is accessible, either have the use confirm their credential information or reset the user’s account. 2. If issue is unresolved, use a test account to attempt 2FA access and/or ask other users to attempt

access.

3. If the problem continues to persist, either connectivity between the 2FA Portal and the 2FA

Authentication Server or connectivity between the 2FA Portal and the customer's domain controller may be the cause. Escalate the issue to MOSSUP.

Issues and Possible Causes: No Outlook Web App Login Page

A network connectivity failure between the 2FA Portal and the Client Access server will result in users being able to enter credentials and authenticate but the Outlook Web App mailbox view will not render or display.

Network Connectivity Failure between 2FA Portal and Client Access server

If the Client Access server is not online or not functioning properly, the logon page will freeze for several seconds. Various Internet Information Service (IIS) errors will appear. The following are the most common:

(21)

21

Resolution

(22)

22 Supporting Integrated Windows Authentication clients

Once Web browser settings have been applied to the client to enable seamless interaction with the Outlook Web App feature of Exchange Online, a “single sign on” experience for the client will be possible. If a user is prompted for credentials, several aspects of the user’s environment should be examined before placing a request with Microsoft for support.

Two forms of authentication failure are the most common: (1) no prompt for credentials and an incomplete authentication process or (2) a prompt for credentials and a successful or unsuccessful manual completion of the authentication steps.

If no prompt for credentials occurs, the fault is likely to be the client, network, or Exchange Online environment. If the client and network appear to be operating satisfactorily, a service request can be placed with Microsoft Online Service Support.

If a prompt for credentials appears, the configuration of the client system is likely to be incorrect.

(23)

23

Selecting the Cancel button produces the following:

The following procedures should be addressed to attempt to resolve the authentication issue before contacting Microsoft Online Services Support:

1. Confirm that the user has manually entered correct credentials for the correct account domain within the Customer forest.

2. Confirm the client system is connected to the corporate network (Intranet or VPN) and that the client workstation is joined to the correct account domain within the Customer forest (use set USERDOMAIN command within a Command Prompt window on the client system to view domain setting).

3. For an IE user, confirm the Outlook Web App URL for Exchange Online appears in the Intranet Zone for the browser as described above (follow similar verification steps for other browser types).

4. For an IE user, confirm the Integrated Windows Authentication attribute is enabled within IE as described above (follow similar verification steps for other browser types).

5. If the user continues to be prompted for credentials, instruct the user to attempt to use a full Outlook client to access Exchange Online and note the result.

(24)

24 Appendix A: RSA SecureID User Experience

When a user is outside of the corporate network and tries to connect to Outlook Web App protected by an RSA SecureID 2FA solution, a 2FA logon page appears. The following is an outline of the user steps involved to complete the authentication process:

1. The passcode is generate using the user’s personal PIN and the token code generated by the RSA SecureID fob as shown in the example below.

Personal RSA PIN = 1234 | RSA Tokencode= 032848

Personal RSA PIN + RSA Tokencode = Passcode

The user types in their user name (CONTOSO\jdoe), their password, and passcode (1234032848). The user clicks Log On.

(25)

25

2. The user name and passcode are sent to the RSA Authentication Manager (Authentication Server) which is the system’s authentication engine. If authorized, the user’s domain credentials are then verified by a domain controller.

3. When the credentials have been verified, the user is authenticated and has access to their mailbox using Outlook Web App.

(26)

26 Appendix B: Swivel Secure PINsafe User Experience

Swivel Secure PINsafe is a 2FA solution based on a choice of single or multi-channel authentication solutions. The key combination used in this solution is the user’s PIN (a constant value) and the user’s security string (a random value). The PIN is used to extract digits from the security string to produce a one-time token code which is passed by the user to the PINsafe server and processed to complete the 2FA authentication process. When the security string is delivered via the authentication page on a web site, this is referred to as a single channel delivery (all authentication information is presented/entered via the Web browser). If the security string is delivered via an alternate communication method (e.g., an SMS text message to a mobile device) and is then used to produce the token code that is entered via the Web browser session, this method is referred to as multi-channel. The scenario below provides an example of the single channel authentication process from a user prospective. For this example, the user’s PIN is 1234.

1. The user is presented with the Outlook Web App logon page where he enters DOMAIN\user and tabs into the Password textbox. The Swivel Secure PINsafe Authentication Server then generates a random string and presents the user with an image.

(27)

27

3. When the credentials have been verified, the user is authenticated and has access to their mailbox using Outlook Web App.