Multi-Factor Authentication for OWA in Exchange Online...

Mutli-Factor Authentication in Exchange Online Dedicated

Legacy 2013 Platform Release

Office 365 Dedicated & ITAR-Support Plans

© 2015 Microsoft Corporation. All rights reserved.

of 29

Dedicated and ITAR-support Plans

Multi-Factor Authentication for OWA

in Exchange Online Dedicated

Applies to: Exchange Online Dedicated – Legacy 2013 Platform Release

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.





of 29


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





of 29


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.................................................................................................................................. 10

Outlook Web App Mailbox Policy Control ......................................................................................................................... 11

Client session termination considerations .......................................................................................................................... 11

Limitations ....................................................................................................................................................................................... 12

Supporting the Multi-Factor Authentication environment ............................................................................................... 13 Frequently Asked Questions ......................................................................................................................................................... 14 Appendix A: Optional MFA Implementations ........................................................................................................................ 16

RSA SecureID or Swivel Secure PINsafe .......................................................................................................................... 16

Azure Multi-Factor Authentication ................................................................................................................................... 16

Personal Identity Verification (PIV) and Common Access Card (CAC) ................................................................ 18

Appendix B: Alternative single sign-on support for intranet clients ............................................................................. 19 Group Policy Object Configuration Method ...................................................................................................................... 19

Modifying the Site to Zone Assignment domain policy ........................................................................................... 20

Setting Integrated Windows Authentication Attribute ............................................................................................. 23

Manual Configuration Method ............................................................................................................................................... 25

Internet Explorer Manual Configuration ......................................................................................................................... 25

Manual Configuration for Other Web Browser Types ............................................................................................... 26

Supporting Integrated Windows Authentication clients ............................................................................................... 27





of 29


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.





of 29


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.





of 29


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.

http://technet.microsoft.com/en-us/library/jj679342.aspx

http://social.technet.microsoft.com/wiki/contents/articles/2592.windows-root-certificate-program-members-list-all-cas.aspx

http://social.technet.microsoft.com/wiki/contents/articles/2592.windows-root-certificate-program-members-list-all-cas.aspx





of 29


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

https://sts3.microsoftonline.com/FederationMetadata/2007-06/FederationMetadata.xml.

ITAR-support Environments

https://sts2.microsoftonline.com/FederationMetadata/2007-06/FederationMetadata.xml

https://msdn.microsoft.com/en-us/library/azure/Dn532272.aspx

https://msdn.microsoft.com/en-us/library/azure/Dn532272.aspx

http://azure.microsoft.com/en-us/documentation/videos/intro-to-microsoft-azure-ad-premium/







of 29


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.





of 29


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.





of 29


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





of 29


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.

https://technet.microsoft.com/en-us/library/Dd297989%28v=EXCHG.150%29.aspx

https://technet.microsoft.com/en-us/library/Dd297989%28v=EXCHG.150%29.aspx





of 29


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.

http://go.microsoft.com/fwlink/?LinkId=389607





of 29


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.

https://sharepoint.partners.extranet.microsoft.com/sites/MMS%20Knowledge%20Base/Release%20Docs/Exchange/Exchange%20Upgrades/EXO-D%20Platform%20Upgrades.htm

https://sharepoint.partners.extranet.microsoft.com/sites/MMS%20Knowledge%20Base/Release%20Docs/Exchange/Exchange%20Upgrades/EXO-D%20Platform%20Upgrades.htm

https://sharepoint.partners.extranet.microsoft.com/sites/MMS%20Knowledge%20Base/Customer%20Playbooks/Forms/AllItems.aspx?RootFolder=%2fsites%2fMMS%20Knowledge%20Base%2fCustomer%20Playbooks%2fCustomer%20Operations%20and%20Handbooks&FolderCTID=&View=%7bEFF29E54%2d49C8%2d4B95%2dBED1%2d16AB7C5F4896%7d





of 29


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.







of 29


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).





of 29


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

https://gallery.emc.com/docs/DOC-2475?viewTab=collateral&version=7




https://kb.swivelsecure.com/wiki/index.php/Microsoft_ADFS_Integration

https://kb.swivelsecure.com/wiki/index.php/ADFS_3_Authentication

https://kb.swivelsecure.com/wiki/index.php/ADFS_3_Authentication

http://www.windowsphone.com/en-us/store/app/phonefactor/0a9691de-c0a1-44ee-ab96-6807f8322bd1

https://play.google.com/store/apps/details?id=com.phonefactor.phonefactor&feature=search_result

https://itunes.apple.com/us/app/phonefactor/id475844606?mt=8





of 29


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.

http://technet.microsoft.com/en-us/library/d1d3b349-b545-4ea7-ab39-86634742f1ac#fraudalert

http://technet.microsoft.com/en-us/library/d1d3b349-b545-4ea7-ab39-86634742f1ac#fraudalert

http://technet.microsoft.com/en-us/library/dn280946.aspx

http://technet.microsoft.com/en-us/library/dn280946.aspx

http://technet.microsoft.com/en-us/library/dn280946.aspx#BKMK_8





of 29


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.





of 29


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.





of 29


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.





of 29






of 29


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.





of 29


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.





of 29


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.





of 29


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.





of 29


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.





of 29


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.





of 29


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:





of 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.

Multi-Factor Authentication for OWA in Exchange Online...

Documents

Transcript of Multi-Factor Authentication for OWA in Exchange Online...