Multi-Factor Authentication for OWA in Exchange Online Dedicated

Transcription

1 Multi-Factor Authentication for OWA in Exchange Online Dedicated Applies to: Exchange Online Dedicated Topic Last Modified: 18-Nov-2015 Within the Dedicated and ITAR-support plan offerings of Office 365 for enterprises, multi-factor authentication (MFA) is an optional feature set available for use with Outlook Web App (OWA) (now being referred to as Outlook on the Web) of Exchange Online. MFA utilizes a federated authentication model to provide an additional level of security when an Internet or intranet Web browser based client attempts to access OWA. The feature set described within this document applies only to the Exchange Server 2013 release of Exchange Online. To implement MFA, your organization must utilize a Security Token Service (STS) to establish a federated relationship with the Microsoft STS used to support your service plan, i.e., either the Office 365 Dedicated Federation Hub or the Office 365 ITAR-support Federation Hub. In addition to username/password authentication, you can select other supplemental MFA solutions (third party vendor, Microsoft Azure, and internal customized options of your choice) to challenge a Web browser based client to provide additional identity proofs. When client identity has been verified and approved by your MFA implementation, the Security Assertion Markup Language (SAML) tokens returned to the Federation Hub will allow OWA client authentication with Exchange Online to complete. Page 1 of 29

2 Important: 1. The content of this article is updated periodically. If the article is downloaded, periodically checking the Office 365 Dedicated Release Collateral repository for an updated version. 2. Not all generally available documentation produced by Microsoft to describe the features and functionality of Exchange Server 2013 is applicable to the Dedicated and ITAR-support plan offerings of Office 365 for enterprises. Content accessible via links provided on this page are reliable sources. 3. Unless otherwise stated in the material, all references to dedicated plans or Exchange Online Dedicated also apply to the International Traffic in Arms Regulations (ITAR-support) version of Exchange Online. 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 Your chosen MFA solution Configuration steps for Web browser types in use within your environment Page 2 of 29

3 What is Multi-Factor Authentication?... 4 MFA federated authentication functional overview... 5 Establishing a Multi-Factor Authentication environment... 6 Select and configure a federated authentication infrastructure... 6 Select a multi-factor authentication implementation... 7 Establish federated trust... 7 Networking Requirements... 8 Client access and authentication considerations... 8 Preserving Delegated Mailbox Access Outlook Web App Mailbox Policy Control Client session termination considerations Limitations Supporting the Multi-Factor Authentication environment Frequently Asked Questions Appendix A: Optional MFA Implementations RSA SecureID or Swivel Secure PINsafe Azure Multi-Factor Authentication Personal Identity Verification (PIV) and Common Access Card (CAC) Appendix B: Alternative single sign-on support for intranet clients Group Policy Object Configuration Method Modifying the Site to Zone Assignment domain policy Setting Integrated Windows Authentication Attribute Manual Configuration Method Internet Explorer Manual Configuration Manual Configuration for Other Web Browser Types Supporting Integrated Windows Authentication clients Page 3 of 29

4 What is Multi-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. Multi-factor authentication (MFA) is an authentication method that applies a stronger means of identifying the user. It requires users to submit a combination 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 possess One option to satisfy the second category is to use a Smartcard and the associated Personal Identification Number (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 a code for one-time access use. Authenticate using a part of yourself Another multi-factor option is biometric authentication literally using a part of your body to prove your identity. Some examples include the following: Scan of your finger to verify your fingerprint. An ocular scan to verify your retina or iris. Facial or voice recognition. Compromising multiple authentication factors presents a significant challenge for attackers. Even if an attacker manages to learn a user's password, it is useless if the attacker does not also possess the trusted device or unique biometric feature. Conversely, if the user happens to lose the device used for MFA access, the finder of that device will not be able to use it unless he or she also knows the user's password. Page 4 of 29

5 MFA federated authentication functional overview Customers that subscribe to Exchange Online Dedicated can select and enable MFA options that are compatible with the required federated authentication elements for Office 365 Dedicated. The diagram below illustrates interaction between a Web browser based Internet or intranet user, Exchange Online Dedicated, the customer chosen MFA solution, and elements of the federated authentication infrastructure. The Web browser can be invoked on a thick client or mobile device. For an OWA client that has already authenticated on a corporate intranet, a customer may decide that the added use of MFA is not required. If your STS supports Integrated Windows Authentication, contact your vendor to confirm an MFA configuration can be created to allow your Web browser based intranet clients to have a single sign-on (SSO) experience to access Exchange Online Dedicated. Alternatives to support SSO are the configuration of the Group Policy Object (GPO) feature of Active Directory or the manual configuration of trust between a Web browser client and OWA see Appendix A for additional information. Page 5 of 29

6 Establishing a Multi-Factor Authentication environment The material below outlines the requirements to implement a federated authentication environment to support MFA. Select and configure a federated authentication infrastructure A Security Token Service (STS) is required for your environment. The STS can be a server implementation housed within your on-premises environment or the functionality can be provided by a third party service provider. A Microsoft Active Directory Federation Services (AD FS) server (version 2.0 or 3.0) can be used or an alternative third party product can be considered. See the TechNet article Use third-party identity providers to implement single sign-on for a list of third party providers that are verified as compatible with Office 365. Your STS implementation must meet the following requirements: The STS must support the WS-Federation identity federation specification and the WS-Trust security token management specification including the issuance of security tokens conforming to Secure Access Markup Language (SAML) 1.1 or a later release. All federation identity provider STS certificates (encryption, signing, and Transport Layer Security (TLS)) must be issued by, and chained to, a publicly trusted root authority. For a specific list of such root authorities, see the Microsoft TechNet wiki article Windows Root Certificate Program - Members List (All CAs). The SSL certificate for the URL used for MFA must be provided to Microsoft. Page 6 of 29

7 Notes: 1. To support MFA, the Premium release of Azure Active Directory is required. See Azure Active Directory editions and Intro to Microsoft Azure AD Premium for more information. 2. When your organization migrates to the vnext platform release of Exchange Online Dedicated, Microsoft recommends the implementation of federated authentication. The STS you choose to support MFA can be used to support federated authentication for your vnext environment. 3. If your chosen STS solution is an AD FS release, several (but not all) features of the AD FS feature set can be applied within Office 365 Dedicated. Consult with your Microsoft Premier Support representative to gain access to technical resources that can provide appropriate guidance. 4. If your chosen STS solution is being provided by a third party, engage with your vendor s support or professional services team to understand your options for differentiated authentication experiences based upon client location, client or device type, user credentials, etc. Select a MFA implementation Beyond submission of username/password for authentication, clients can be prompted by MFA solutions provided by third party vendors, Microsoft Azure, and internal customized options of your choice. See the Appendix A: Optional MFA Implementations for examples. Establish federated trust When your federated infrastructure is online, your STS can gain access to the Office 365 Dedicated Federation Hub via a metadata URL. The metadata for the Federation Hub can be viewed at the following locations: Dedicated Environments ITAR-support Environments Page 7 of 29

8 If your organization publishes your STS federation metadata on the Internet, a federated trust can be easily established between your STS and the Federation Hub due to your token signing certificate being a component of the federation trust data. If the metadata information is not published, it will be requested by Microsoft when your MFA configuration is established. To test basic federated routing using the Microsoft Claim Check application on the Federation Hub, contact your Microsoft Service Delivery Manager to place a Configuration Request to gain test access. Notes: 1. The Office 365 Dedicated Federation Hub is only accessible via the Internet; a private network connection is not supported. 2. In preparation for MFA activation, Microsoft will provide detailed documentation that explains specific trust configuration details for your environment. Networking requirements All MFA connections are initiated from a client. The connections are HTTPS and initiated via TCP port 443. Each client must be able to access the Federation Hub via the Internet to exchange SAML tokens. In addition, each client must be able to communicate with your STS (located within your intranet or on the Internet) to exchange SAML tokens. Client access and authentication considerations When your underlying MFA infrastructure and functionality have been validated, new Office 365 Dedicated customers will use the URL mail.<your_company_name>.com to access Exchange Online Dedicated (e.g., mail.contoso.com). If your MFA implementation replaces a two-factor authentication deployment, the established namespace URL for two-factor authentication can be re-used for the MFA implementation. Coordination of URL use will be addressed by the Deployment Program Management team of Office 365 Dedicated. Typical authentication scenarios for an OWA client involve either access from the Internet or your corporate intranet. An Internet client is challenged using the MFA scenarios that you selected. Shown below is an example of authentication options presented to an Internet client by a corporate STS. Page 8 of 29

9 For an intranet client, Integrated Windows Authentication can be considered to establish a single sign-on (SSO) experience. If your STS supports Integrated Windows Authentication, contact your vendor to confirm an MFA configuration can be implemented. Alternatively, Appendix B: Alternative single sign-on support for intranet clients describes SSO configuration options for your clients involving the Group Policy Object (GPO) feature of Active Directory or the manual configuration of trust between a Web browser client and OWA. Note: If an Internet Explorer browser is used to successfully establish an OWA/MFA session, a subsequent instance of Internet Explorer (either as another tabbed window, a fresh invocation of the browser, or an In-Private browsing session) will utilize the session cookie of the active OWA/MFA session. The result will be direct access to another OWA instance of the active user. Page 9 of 29

10 Preserving delegated mailbox access Access to delegated resources can be established in a number of ways. A user can be granted either Send As, Full Mailbox, or both levels of permission. These permissions can be granted to individual users and to groups. With the change to federated authentication, some of your users and groups may lose access to shared resources until you perform the Access Control List (ACL) updates required to preserve access. When using federated authentication to access OWA, the group memberships of the customer-forest user are not forwarded to the OWA service via a SAML claim. Instead, the OWA MFA service only obtains the customer-forest SID of the user, the customer-forest User Principal Name (UPN) of the user via SAML claim, and the cloud forest groups associated with the user via cloud directory lookup. Only these data are used to evaluate access to a delegated resource. As a result, in order for a user to successfully use Send As or Full Access permissions, the resource mailbox ACL must contain either (a) the cloud representation of the on-premises groups of the user or (b) the customer Domain\Account that is affiliated with the user. Having either permission type will ensure that the MFA access token will contain values that correspond with the permission values assigned to the managed mailbox. Additional resources and information for updating the target mailbox permissions will be provided in your Customer Environment Configuration (CEC) document provided by Microsoft. Resource mailboxes with user-based access For each resource mailbox, you must ensure that every user access control entry (ACE) that refers to a cloud-forest user is duplicated by an ACE that refers to a customer-forest user. This may require the addition of new ACEs. Resource mailboxes with group-based access For each resource mailbox, you must ensure that every user ACE that refers to a customer-forest group is duplicated by an ACE that refers to a cloud-forest group. This may require the following: Moving the group in question into scope of MMSSPP synchronization Mail-enabling the group in question to trigger MMSSPP to replicate it Addition of a new ACE for the cloud-forest replica of the group in question Page 10 of 29

11 Outlook Web App mailbox policy control If your STS is capable of detecting whether an OWA client is accessing your network from an intranet or Internet location (e.g., based upon whether a client is within, or outside of, your intranet IP address range), the additional SAML claim value insidecorporatenetwork generated by your STS can be used by Exchange to apply OWA mailbox policy restrictions. The true or false condition is processed by the Office 365 Dedicated Federation Hub to inform Exchange Online Dedicated to apply specific OWA mailbox restrictions. An example of a restriction is to block the ability to download message attachments. For additional guidance on how to set OWA mailbox policies, see Set- OwaMailboxPolicy or contact your Microsoft Premier Support representative. Client session termination considerations When a client terminates an OWA session by using the Sign-out function of OWA, the session cookie used by OWA will be invalidated. The actual sign-out message will vary based upon browser type and STS. An example of the sign-out provided by AD FS for an Internet Explorer client is shown below. Page 11 of 29

12 Note: The ANSI 2013 platform release of Exchange Online Dedicated is configured to use a 15 minute inactivity timeout for public client connections and an overall session timeout (regardless of inactivity) of 8 hours for non-mfa OWA clients accessing the service from the Internet. The MFA inactivity and overall session timeout settings applied by the Office 365 Dedicated Federation Hub is an eight (8) hour period (private client setting). If you migrated from an earlier release of the Exchange cloud service to the Exchange 2013 cloud release, your settings should flow to the new environment. Verify your settings following your migration and contact your Microsoft Service Delivery Manager for assistance if adjustments are required. Limitations 1. Suitable Web browsers for OWA when used in conjunction with a MFA solution are described within Office 365 System Requirements. Customers can consider using other browsers supported by their chosen MFA solution; compatibility testing of these browsers with Office 365 Dedicated is a customer responsibility. 2. The user experience for Internet Explorer 8 or an older version of this browser is OWA light. 3. The Windows PC version of the Safari Web browser is not supported. 4. Within the legacy platform release of Exchange Online Dedicated, MFA support is not provided for (a) the mobile version of OWA for Apple or Android mobile devices (also referred to as MOWA) or (b) the Outlook for ios or Outlook for Android applications. A Web browser on a mobile device can be used to access OWA of Exchange Online Dedicated and to interact with MFA functionality. 5. Issues arising from (a) the use of third-party MFA products on your premises or (b) your chosen STS implementation will not be considered as service impacting incidents under the Service Level Agreement (SLA) for Exchange Online Dedicated. Page 12 of 29

13 Supporting the MFA environment Problems that arise with MFA typically are attributed to issues with an element of the federated infrastructure. Your Help Desk and your IT Pro staff are expected to perform preliminary troubleshooting an MFA issue, attempt to resolve the issue to their level of responsibility, and escalate to Microsoft Online Services Support (MOSSUP) specific issues that relate to Microsoft infrastructure as appropriate. Troubleshooting guidance and a summary of support roles and responsibilities are included in this section. Before an issue is escalated, refer to the list of Known Issues list held within the Exchange Online Platform Upgrades area of the Customer Extranet site to determine if the reason for an issue is known and if procedures are available to work around the problem. Also check the Technical Scenarios Matrix for scenarios that match your particulate issue(s) and the Microsoft Support articles that may be applicable. Page 13 of 29

14 Frequently Asked Questions The questions below include answers for topic areas outside of the base material for the multi-factor authentication implementation for Exchange Online Dedicated. 1. How does the Office 365 Dedicated Federation Hub relate to the Azure Active Directory (AAD) service? a. The Office 365 Dedicated Federation Hub does not integrate with the synchronization aspects of AAD nor does it facilitate authentication to services dependent on AAD such CRMOnline, InTune etc. b. Establishing a federated trust with the Office 365 Dedicated Federation Hub does not replace the Microsoft Federation Gateway (MFG) or AAD trust requirements for other services. 2. If we already have an STS, what are the changes that are required from an Identity / STS perspective to support MFA? a. You must integrate your MFA solution with the on-premises STS. b. You must ensure that your STS is on the supported list (Use third-party identity providers to implement single sign-on). c. You should assume all OWA traffic will increase the load on the STS infrastructure; scale up/out the STS as needed. 3. What about federated authentication support for other services such as Lync Online, SharePoint Online, or other messaging clients? a. Sharepoint Online Dedicated is in the process of designing support for SAML claims for customer accounts contact your Microsoft Service Delivery Manager for additional information. b. Other messaging clients are out of scope at this time; standard Active Directory trusts and protocols for authentication are still available for these clients at this time. Page 14 of 29

15 4. If we are already an existing Exchange Online Dedicated customer, what options will exist for testing during cutover to the new STS and new Exchange 2013 environment? a. Prior to mailbox migration, you can arrange to verify basic federated authentication functionality using the Microsoft Claim Check application provide by the Office 365 Dedicated Federation Hub contact your Microsoft Service Delivery Manager to place a CRAS submission to request test access. Testing with an actual mailbox can occur when an initial mailbox has been migrated to Exchange Online Dedicated. 5. Will users be prompted for authentication from inside the corporate network? a. Your organization can decide whether to support Integrated Windows Authentication from within the corporate network (as described in Appendix B) or force a login involving your STS logon (e.g., forms based authentication or multi-factor authentication). Page 15 of 29

16 Appendix A: Optional MFA Implementations Several optional implementations for MFA are described in the section. RSA SecureID or Swivel Secure PINsafe If your organization previously used the RSA SecureID or Swivel Secure PINsafe with an earlier release of Exchange Online Dedicated, federated authentication versions of either product are available. The following reference material is available from each vendor when used in conjunction with a Microsoft AD FS server as an STS: MFA Product AD FS 2.0 Release Information AD FS 3.0 Release Information RSA SecureID Microsoft Active Directory Federation Service (see AD FS 2.0 material) Microsoft Active Directory Federation Service (see AD FS 3.0 material) Swivel Secure PINsafe Microsoft ADFS 2 Integration Microsoft ADFS 3 Authentication Azure Multi-Factor Authentication If your STS is a Microsoft AD FS 2.0 or 3.0 release, access to additional MFA services also can be achieved through integration with the Azure Multi-Factor Authentication service. Azure MFA provides flexibility for users and backup options if users cannot pass authentication by using their preferred method. The following Azure MFA options are available: Multi-Factor Authentication apps are available for Windows Phone, Android, and IOS devices. A user can download the free app from the device store and activate it by using a code received during setup. When the user signs in, a notification is pushed to the app on their mobile device. The user taps to approve or deny the authentication request. Cellular or Wi-Fi access is required for installing and setting up the app. After the app is installed, it can operate in the following modes to provide the additional security that a multi-factor authentication service can provide: o Notification. In this mode, the Multi-Factor Authentication app prevents unauthorized access to accounts and stops fraudulent transactions. It accomplishes this by using a push notification to the phone or registered device. The user simply views the notification and, if it is legitimate, selects Authenticate; otherwise, the user can choose to deny, or choose to deny and report, the fraudulent notification. For information about Page 16 of 29

17 reporting fraudulent notifications, see How to configure and use Fraud Alert for Azure Multi-Factor Authentication. o One-Time Passcode. In this mode, the Multi-Factor Authentication app can be used to generate an Open Authentication (OAuth) passcode. The user can then enter this passcode along with the username and password to provide the second form of authentication. The One-Time Passcode option is useful in instances of spotty phone coverage. Automated phone calls can be placed by the Multi-Factor Authentication service to any phone either landline or mobile. The user simply answers the call and presses the pound key (#) on the phone to complete the sign-in. Text messages can be sent by the Multi-Factor Authentication service to any mobile phone. Each text message contains a one-time passcode. The user is prompted to either reply to the text message by using the passcode or to enter the passcode on the sign-in screen. If an AD FS server is used as your STS, see Walkthrough Guide: Manage Risk with Additional Multi- Factor Authentication for Sensitive Applications to prepare your MFA environment and also see the Windows Azure Multi-Factor Authentication section of the same article for Azure MFA implementation guidance. Notes: 1. Only phone-call and text-message options are currently available for the Multi-Factor Authentication SDK. 2. If you pursue utilizing any of the options available in the Azure MFA feature set, note that some of the capabilities described in the feature collateral may not apply to an Office 365 Dedicated implementation. Attempting to link MFA functionality to Azure Active Directory, attempting to enable/disable MFA on a per user basis, or attempting to use PowerShell features within Azure, as examples, will not work since OWA within Exchange Online Dedicated is not integrated with cloud directory services. The features described above and the collateral links provided for these features are relevant. To gain extended knowledge regarding applicable Azure MFA features for your environment, consult with your Microsoft Premier Support representatives. Page 17 of 29

18 Personal Identity Verification (PIV) and Common Access Card (CAC) Federation-based Personal Identity Verification (PIV) and Common Access Card (CAC) solutions for ITAR-support plan customers also are viable MFA solutions. Contact your Microsoft Service Delivery Manager to discuss PIV and CAC implementation scenarios. For all cases involving third-party vendor elements, confirm compatibility of your chosen MFA solution with each third-party involved. If your organization prefers to consolidate STS and MFA functionality on the same physical server, also consult with your solution provider(s). Your Microsoft Service Delivery Manager can assist with providing general MFA implementation guidance. Page 18 of 29

19 Appendix B: Alternative single sign-on support 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 Dedicated. 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 (OWA) feature of the cloud service. The two options available are (1) domain policy set through Group Policy object (GPO) feature of Active Directory or (2) the manual Web browser configuration method. Notes: 1. If MFA is enabled within your environment, your STS must be capable of identifying an intranet user access request and subsequently provide the required SAML claim to support the completion of the single sign-on experience. 2. If your STS is set to recognize an intranet connection attempt and also set to not require federated authentication for intranet clients, a basic authentication pop-up box will appear to accept the credentials of the user if the client browser is not configured for Integrated Windows Authentication. 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 for a new Exchange Online Dedicated environment, contact your Service Delivery Manager to obtain the OWA URL for the environment. Page 19 of 29

20 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. Execute the following: 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 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. Page 20 of 29

21 Page 21 of 29

22 3. Within the Show Contents dialogue box, add the URL of your Security Token Service (STS) 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. Page 22 of 29

23 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 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. Page 23 of 29

24 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. Page 24 of 29

25 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 OWA 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. Page 25 of 29

26 2. Within the next layer of the Local Intranet dialogue box, enter the OWA 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. Page 26 of 29

27 Supporting Integrated Windows Authentication clients Once Web browser settings have been applied to the client to enable seamless interaction with the OWA 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. Page 27 of 29

28 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: Page 28 of 29

29 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. If using the GPO method, confirm the Integrated Windows Authentication attribute is enabled within Internet Explorer as described above (follow similar verification steps for other browser types). 4. For the manually configured Internet Explorer method, confirm the OWA URL for Exchange Online Dedicated and your STS URL appear in the Intranet Zone for the browser 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 Dedicated 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. Page 29 of 29