Two-Factor Authentication IT Professional & Customer Service Desk Feature Guide Two-Factor Authentication for Exchange Online Office 365 Dedicated & ITAR-Support Plans April 26, 2013
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. 2
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 Appendix B: Swivel Secure PINsafe User Experience 26 3
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 How to configure the Web browser types in use within the customer environment 4
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. An overview of the authentication processes and a summary of operating environment requirements for 2FA are described below. User environment configuration steps and troubleshooting scenarios also are included. 5
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 John is not connected to his corporate network and needs to remotely access Outlook Web App within Exchange Online. Referring to the diagram below, an outline of the authentication steps involved follows. 6
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) 4. When the user s identity has been confirmed using the 2FA model, the user is then passed directly to the Client Access server (CAS) via the 2FA Portal. An Outlook Web App session starts on the CAS and loads the user s mailbox. In the background, the 2FA Portal encrypts the credentials and writes them to a cookie. With credentials stored in a cookie, John does not have to manually enter his credentials to access Exchange Online for the duration of the session. When the session ends, the cookie is invalidated and the credentials are no longer cached. 7
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. 5. Due to the need for a client system to be joined to the Active Directory account domain of the Customer forest, 2FA functionality cannot be used by Exchange ActiveSync (EAS) devices or any other mobile device. 8
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. Note: To prepare to execute the Site to Zone Assignment domain policy, contact your Service Delivery Manager to obtain the URL for the Outlook Web App URL of your Exchange Online environment. 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 9
2. Double click the Site to Zone Assignment List, check the Enabled option, and click the Show button in the middle left area of the dialogue box. 10
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 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 dialogue box by following the Local Group Policy Editor procedures described above. 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 11
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. Note: As noted at the bottom of the snapshot shown, any change to the Enable Integrated Windows Authentication attribute will take effect when IE is restarted. 12
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: 1. In your version of IE, select the drop-down leading to Internet Options. Select the Security tab and highlight Local Intranet. Select the Sites button and the Advanced button on the Local Intranet dialogue box that follows. 13
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 requirement. 14
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. Note: Microsoft Online Services Support is unable to reset the password or PIN associated with a user account. Any issue that requires a change to an individual user account, the account s password, or the PIN for the account must be addressed by your internal IT Help Desk. 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 15
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 1. Evaluate the address the user has typed and, if incorrect, provide correct URL. 16
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 address on their initial machine may be blocked by the network being used. 4. If the access issue persists, escalate the issue to MOSSUP. 17
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. If the user is still unable to login, reset the user s Active Directory account and/or their 2FA authentication account data. 18
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. 2FA Portal and Authentication Server Connection Failure 2FA Portal and Domain Controller Connection Failure 19
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: Error Screen The page cannot displayed Error Screen Cannot display the webpage 20
Resolution Customer Help Desk or IT Pro staff should attempt to access Outlook Web App from the internal corporate network. If an IIS error appears, escalate the issue to MOSSUP and provide a troubleshooting summary. If access to Outlook Web App is successful, Outlook Web App is assumed to be healthy and connectivity between the 2FA server and Outlook Web App server may be the problem. Also escalate this issue to MOSSUP and provide a troubleshooting summary. 21
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. Note: As indicated above, Microsoft only provides support for the Internet Explorer Web browser. The instructions provided below are generic and the use of IE is illustrated as an example. Specific error messages, user interface windows, and modification procedures for other Web browsers must be obtained from the manufacturer of the browser. 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. 22
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. If user access is not successful at any point in the steps above, include the result of each verification step in the Service Request placed with Microsoft Online Services Support. 23
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. Outlook Web App 2FA Logon Screen 24
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. User Mailbox in Outlook Web App 25
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. 2. The user enters their domain password then determines which number corresponds to their PIN (1234) the result is his one-time password. Based on the image, the user enters 3584 as their one-time password for the session and clicks Log On 26
3. When the credentials have been verified, the user is authenticated and has access to their mailbox using Outlook Web App. User Mailbox in Outlook Web App 27