Module 16

Office 365 Single

Sign-on
Presenter name
Presenter role

Conditions and Terms of Use

Microsoft Confidential

This training package is proprietary and confidential, and is intended only for uses described in the training materials. Content and software is provided
to you under a Non-Disclosure Agreement and cannot be distributed. Copying or disclosing all or any portion of the content and/or software included in
such packages is strictly prohibited.
The contents of this package are for informational and training purposes only and are provided "as is" without warranty of any kind, whether express or
implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, and non-infringement.
Training package content, including URLs and other Internet Web site references, is subject to change without notice. Because Microsoft must respond
to changing market conditions, the content should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the
accuracy of any information presented after the date of publication. Unless otherwise noted, the companies, organizations, products, domain names, email addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product,
domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

Copyright and Trademarks

2014 Microsoft Corporation. All rights reserved.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject
matter in this document. Except as expressly provided in written license agreement from Microsoft, the furnishing of this
document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
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.
For more information, see Use of Microsoft Copyrighted Content at
http://www.microsoft.com/about/legal/permissions/
Microsoft, Internet Explorer, Outlook, OneDrive, Windows Vista, Zune, Xbox 360, DirectX, Windows Server and
Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
Other Microsoft products mentioned herein may be either registered trademarks or trademarks of Microsoft Corporation in the
United States and/or other countries. All other trademarks are property of their respective owners.

Overview

In this module we will cover single sign-on and the various

identity and domain management options available to you in
Office 365
Identity Management
Domain Management
Claims Based Authentication Overview
Active Directory Federation Services

Objectives

After completing this module, you will be able to:

Describe the difference between managed and federated
domains
Understand the AD FS authentication process
Install and configure AD FS

Identity
Management

Identities
for
Microsoft
Cloud
Services

A Common
Identity
Platform for
Organization
al Accounts

Azure Active Directory is the underlying identity

platform for the various cloud services that use
Organizational Accounts
7

Core
Identity
Scenarios
with Office
365

The end to
end Microsoft
Stack

Cloud
Identity

Cloud identities are online accounts, with the user account and
password stored within the Azure Active Directory
Online administrators manage the identities through the
Office 365 Admin Center or through PowerShell
Administrators and end-users manage their passwords in
Office 365
Users usually end up managing two accounts (on-premises
and cloud)
The methods for cloud identity creation are:
Directory Synchronization (if using AD on-premises)
Office 365 Admin Center to create users manually
Bulk importation using a .csv file or via PowerShell using the
New-MsolUser cmdlet

10

Cloud Identity
with Password
Synchronizati
on

Unlike standard Cloud Identities previously described,

administrators will create and manage the identities and
passwords within the on-premises Active Directory
Directory Synchronization (DirSync) replicates objects and
passwords (in an encrypted non-reversible hash form), up to
Office 365
Password policy controlled on-premises
This enables same sign-on experience at lower cost than
federation
An additional server is required for the directory and password
synchronization process
User provisioning needs to be performed via DirSync

12

Federated
Identity

Federated Identities provides a more sophisticated approach for

authentication to the Office 365 services:
Single identity and sign-on for both on-premises and office
365 services using domain credentials
Identities are mastered on-premises with a single point of
management
DirSync is used to synchronize directory objects into Office
365
Claims and Secure Token based authentication methods used
Client access control can be used to restrict access to Office
365
Strong factor authentication options for additional security
with AD FS
Recommend highly available on-premises servers to support
user authentication (AD FS servers, AD FS proxies, load
balancers)
13

Federation
Options

15

Multi-Factor
Authentication

16

Multi-Factor
Authenticati
on for Office
365

Multi-factor authentication increases the security of user

logins for cloud services above and beyond just a password
Users are required to acknowledge a phone call, text
message, or an app notification on their smartphone after
correctly entering their password
Only after this second authentication factor has been satisfied
can a user sign in successfully

17

Enabling
Multi-Factor
Authenticati
on

On the users and groups page in the Office 365 admin center,
you can enroll users for multi-factor authentication by clicking
the Set Multi-factor authentication requirements: Set up
link.

18

Multi-Factor
End User
Experience

After being enabled for multi-factor authentication, the next time a user signs in, they
see a message asking them to set up their second authentication factor
Any of the following may be used for the second factor of authentication.

Call my mobile phone. The user receives a phone call that asks them to press the
pound key. Once the pound key is pressed, the user is logged in

Text code to my mobile phone. The user receives a text message containing a
six-digit code that they must enter into the portal

Call my office phone. This is the same as Call my mobile phone, but it enables the
user to select a different phone if they do not have their mobile phone with them

Notify me through app. The user configured a smartphone app and they receive a
notification in the app that they must confirm the login. Smartphone apps are
available for Windows Phone, iPhone, and Android devices

Show one-time code in app. The same smartphone app is used. Instead of
receiving a notification, the user starts the app and enters the six-digit code from the
app into the portal

19

App
Passwords for
Multi-Factor
Authenticatio
n

When your account is enabled for multi-factor authentication, you will not be able
to use non-browser applications such as Microsoft Outlook, Lync, and Windows
PowerShell because these clients do not natively support multi-factor
authentication

In order to continue to use your applications, you must set up App Passwords for
your clients.

Once a user has logged in with multi-factor authentication, they will be able to
create one or more App Passwords for use in Office client applications

An App Password is a 16-character randomly generated password that can be

used with an Office client application as a way of increasing security in lieu of the
second authentication factor

After youve created an App Password for an Office desktop application, such as
Outlook, it is indicated in a list in your account

The App Password is what the user needs to enter when challenged for
authentication by the Office desktop applications
20

Domain
Management

21

Overview of
Domains

Office 365 uses the concept of Managed and Federated

domains. The domain type refers to the authentication method
associated with the domain
Managed domains:
Passwords are stored in Office 365 and users authenticate
against Azure Active Directory
Federated domains:
Passwords are stored on-premises and users authenticate against
their on-premises Active Directory using their domain credentials
Managed domains can be converted to Federated domains and
vice versa. This process converts the user object in Office 365,
changing the login behavior as a result

22

Default
Microsoft
Online
Domain

As previously covered, all Office 365 tenants are assigned a

default domain name in the form of
contoso.onmicrosoft.com
Contoso is the domain name you specified during the sign
up process
This is a managed domain
You cannot convert this domain to a Federated domain
This domain provides immediate access to email and
services as soon as users are licensed
MX, AutoDiscover, and SIP DNS records are automatically
created
You can add other custom domains that you own to Office
365 at any time and configure these as default

23

Custom
Domains

Custom domains are those that you add to your Office 365 tenant

Custom domains added through the Office 365 Admin Center are by
default set as managed domains

Converting a custom managed domain to a federated domain needs to

be done via PowerShell: Convert-MsolDomainToFederated -DomainName
contoso.com

Alternatively you can add your custom domain as federated directly

without converting it by running: New-MsolFederatedDomain
-DomainName contoso.com

Adding custom domains does not impact or change mail routing onpremises

Custom domains are automatically added as Accepted Domains in

Exchange Online so mail can be accepted for this domain immediately
after the domain is added and verified in Office 365
24

Adding
Custom
Domains

Add

Verify

Add
Add the
the domain
domain via
via the
the Portal
Portal or
or PowerShell
PowerShell
Domain
Domain status
status goes
goes to
to Pending
Pending Verification
Verification

Create
Create aa TXT
TXT or
or MX
MX record
record in
in the
the public
public DNS
DNS zone
zone
Office
Office 365
365 verifies
verifies TXT
TXT record
record exists
exists proving
proving ownership
ownership

Configure
Configure domain
domain intent
intent for
for the
the new
new domain
domain in
in Office
Office 365
365
Create or
or change
change the
the MX
MX and
and AutoDiscover
AutoDiscover DNS
DNS records
records
Configure Create
25

Claims Based
Identity Overview

26

What is
SAML?

Security Assertion Markup Language (SAML) is an XML-based

standard for exchanging authentication and authorization
data between trusted partners
SAML is encapsulated in a security token
SAML contains signature data in order to prove who issued the
token
In AD FS, we use X.509 certificates to digitally sign the
security tokens

27

What is a
Claim?

A claim is a statement about one entity that is asserted by some

other entity to be true
In the case of Office 365 and AD FS, the claim is based on two
Active Directory user attributes that are replicated by DirSync
to the cloud
UserPrincipalName
ObjectGUID
The userPrincipalName value must match a federated
domain
The ObjectGUID is a rename safe identifier that is used to
hard match the on-premises Active Directory object to the
same object in the Azure Active Directory as created by the
DirSync tool

28

Security
Tokens

Claims about a user are inserted into a security token

Security tokens are consumed by relying parties, in this case
Office 365 is the relying party, and relies on the on-premises
Active Directory to authenticate the user first
Security tokens are generated by an issuer (AD FS)
It is the issuers responsibility to:
Verify the users identity
Obtain the claims data from Active Directory
Create the token
Encrypt the token

29

Relying
Party Trust

Not like an Active Directory trust

Relying Party:
An AD FS 2.0 federation service, a third-party federation solution,
an application or a service that consumes claims
Relying Party Trust :
A trust object that is created to maintain the relationship with
another Federation Service, application, or service (in this case
Office 365) that consumes claims from your organizations
Federation Service
The addition of a federated domain results in the automated creation
of relying party trust with the Office 365 Identity Platform
The federated domain information in Office 365 contains the URL end
points of the on-premises AD FS environment, so that clients can be
redirected appropriately for authentication
The URL end points for your federated domain can be obtained by
running
Get-MsolDomainFederationSettings -DomainName contoso.com
30

Authenticati
on Process

1. Federated user attempts to access Office 365, user is redirected back

to the AD FS end point
2. The users successfully authenticates against AD FS
3. A security token is issued by AD FS to the Office 365 Identity Platform
containing a claim about the value of two attributes for the user in
question, (userPrincipalName and ObjectGUID)
4. The Office 365 Identity Platform will decrypt the token and match the
user to a shadow identity (created by DirSync) in Azure AD
5. This shadow identity will contain the same values for those two
attributes as on-premises thus matching the user per the claim
6. The token is consumed and the user is allowed access to the Office
365 services
31

Alternate
Login ID

By default, federation with Office 365 requires users to have a UPN

that matches their publicly routable federated domain name (i.e.
user@contoso.com)

If your on-premises UPNs are using non-routable domains (i.e.

contoso.local) or your cannot change your existing UPN's to match
your public domain due to application dependencies then youcannot
use your on-premises UserPrincipalNames attribute to authenticate
your users to Azure AD

To solve this problem, you can now enable the alternate login ID
functionality which allows you to configure a sign-in experience where
this alternate login ID is an attribute of a user object in AD other than
the UPN that can be set to the public routable federated domain

Using the 'mail' attribute for alternate login ID functionality

isstronglyrecommended

32

Configuring
Alternate
Login ID

Requires Windows 2012 R2 ADFS with KB2919355 installed

Choose an alternate attribute to use for the logon ID (mail)

Configure your AD FS claims provider trusts to enable alternate

login ID
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY"
-AlternateLoginID mail -LookupForests contoso.com

Update the ADFS Claims Issuance Rules to reference the new

attribute

Update the Active Directory Connector in DirSync and change

the UserPrincipalName Data Source Attribute to Mail

33

Active Directory
Federation Services

34

AD FS
Prerequisite
s

An installation of AD FS requires:
Windows Server 2008 (SP2), Windows Server 2008 R2, or Windows Server 2012
Internet Information Services (IIS) 7 or 7.5 depending on the Windows Server
version
Microsoft .NET Framework 3.5 SP1
AD FS RTW (Release To Web) download. Windows Server 2012 includes the
correct AD FS version as a role
Update Rollup 3 for AD FS is recommended in order to take advantage of new
features such as Multi Issuer Support and Client Access Policies

The AD FS endpoints need to be accessible from the internet and secured with a
public certificate:
You can reverse publish AD FS through TMG or equivalent 3rd party product

The Azure DirSync Tool:

AD FS has no dependency on this tool itself, but Directory Sync needs to be
running and synchronizing user objects for the SSO authentication against
Office 365 to work
Can be installed either before or after AD FS is configured
35

AD FS
Federation
Servers

There are two deployment types for AD FS 2.0 federation servers:

A stand-alone federation server is a single instance of the federation

service. You typically create a stand-alone federation server when your
production environment is small or if you are evaluating the AD FS 2.0
technology

A (load-balanced) federation server farm contains multiple federation

servers, which host the same instance of a federation service. Conversely,
you typically create a farm when you require high availability and load
balancing
Creating a new federation service for a farm scenario will cause the first
computer in the farm to be the primary federation server for the farm,
all other servers are marked as secondary

Note: It is important to provide a highly available AD FS solution when used

with Office 365. If AD FS is unavailable users will not be able to access any
Office 365 resources. We recommend the use of at least two federation
servers in a load-balanced configuration and two federation proxies
36

AD FS
Federation
Server
Proxy

Proxy placement:
Perimeter network
Firewall requirements for the Proxy:
HTTPS port 443
DNS requirements for the Proxy:
Must use the same URL as the internal AD FS 2.0 server
Use split DNS for external users
Use HOSTS file on the proxy for resolving internal AD FS 2.0
Role of the Proxy:
Presents a forms based authentication page to external users (if using a browser)
Collect and submit the user credentials to AD FS on-premise (claims provider)
Security token redirection to Office 365 (relying party)
The Proxy Server does not:
Generate tokens
Sign tokens
Proxy Authentication:
Uses a long-lived SAML token to authenticate itself to the AD FS farm
37

AD FS
Database

AD FS 2.0 configuration information is stored in a database:

A default install of either a stand-alone federation server or farm stores its

configuration information locally in the Windows Internal Database (WID)

In an AD FS farm, the database is read/write on the primary federation

server and read-only on all secondary federation servers

Secondary federation servers connect to and synchronize the data with the
primary federation server in the farm, by polling every 5 minutes, to check
whether any data has changed

The secondary federation servers exist to provide fault tolerance for the
primary federation server while also acting to load-balance access requests
Configuration information can alternatively be stored in a SQL Server database,
which provides additional capabilities:

The ability to scale out using more than 5 federation servers (the limit for
WID per farm)

SAML artifact resolution (Not used in Office 365)

SAML token replay detection, which protects the integrity of authentication

requests by making sure that the same token is never used more than once

38

AD FS
Deploymen
t Options

Standalone Federation server

AD FS Farm with Windows Internal Database (WID)
AD FS Farm with WID and proxy server(s)
AD FS Farm with Microsoft SQL Server
AD FS Farm with SQL Server and geo-redundancy

40

AD FS
Authenticatio
n Options

AD FS servers use Integrated Windows authentication

Domain joined machines will seamlessly authenticate to the
AD FS farm without prompting
Consumes logged-on Active Directory credentials
AD FS proxy servers use forms-based authentication
Displays a Web login page where external users provide their
Active Directory credentials
With AD FS proxy servers you can use two-factor authentication
Only supports Web-browser access
Applications such as Outlook and ActiveSync do not support
2FA

41

Configuring
AD FS

The final process to configure AD FS is to setup the trust between

the internal domain(s) and the Office 365 Identity Platform:
This is called the Relying Party Trust
This will allow the users requests for authentication to be
redirected back to the on-premises AD FS 2.0 federation service
URL
Configuring the trust involves adding a federated domain using the
New-MsolFederatedDomain or Convert-MsolDomainToFederated
cmdlets:
These cmdlets are installed with the Azure Active Directory
Module for Windows PowerShell
After adding the domain, you need to create a public DNS TXT
record to verify domain ownership
The newly registered domain then propagates out to the Office
365 services
43

AD FS
Configured

45

Federated
Authenticatio
n in Office
365

The are three authentication profiles for a Federated Identity depending on what
client is being used:

Browser (WS-Federation Passive Profile) endpoint is /adfs/ls/

The Web browser is redirected to the Office 365 sign-in service, where you
type your corporate ID in the form of a UPN
The sign-in service determines that you are part of a federated domain and
offers to redirect you to the on-premise AD FS 2.0 service for authentication
If you are logged on to the computer (domain joined), you are authenticated
using Integrated Windows Authentication and AD FS 2.0 generates a SAML
1.1 logon token, which the Web browser posts to Office 365

Outlook and EAS (Basic Authentication/Active profile) endpoint is

/adfs/services/trust/2005/usernamemixed
The Outlook client passes basic authentication credentials over SSL to
Exchange Online
Exchange Online proxies the authentication request token to the Office 365
identity platform, and then to the on-premises AD FS

46

Federated
Authenticatio
n in Office
365
(continued)

Lync (WS-Trust Active Profile) endpoint is

/adfs/services/trust/mex/
The Microsoft Online Services Sign-in Assistant (installed
by the Office 365 Desktop Setup application) contains the
Windows service MSOIDSVC.exe that obtains a security
token from AD FS and sends this to the Office 365 identity
platform on behalf of Lync

47

Exchange Online proxies the users credentials to

the Office 365 identity platform which then
authenticates against the public facing AD FS
proxy /adfs/services/trust/2005/usernamemixed
endpoint on the users behalf

Client
Authenticati
on Flow
User signs in with
Lync

External Network

Browser connects to the

/ADFS/ls endpoint and
automatically authenticates to
the AD FS farm using integrated
windows authentication (no
prompt)

User accesses one of

the Office 365 services
with a browser
Lync redirects to authenticate
against the
/adfs/services/trust/mex/ endpoint.
The Microsoft
Online
SignBrowser
is redirected
toServices
the public
in Assistant
authenticates
facing
AD FS proxy
/ADFS/ls to AD FS
on behalf
of Lync
and based
obtains a
endpoint
where
forms
Client uses
Basic aauthentication
and
security
token that
then
page
is the
displayed
which
the user
sends
username
andispassword
to
submitted
back
to
the
Office
365
will
Exchange
need toOnline
provide
securely
credentials
over
HTTPS
for
Identity Platform

48

Third Party
Browser
leveraging
and ADFS

3rd party browsers cannot SSO using ADFS by default

End user sees additional authentication prompt

SSO experience made possible by disabling Extended

Protection Token Check on each federation server in farm:

Set-ADFSProperties -ExtendedProtectionTokenCheck None

49

Deploying
Password
Sync as a
backup for
Single SignOn

When deploying AD FS it is important to understand that any issues that impact

AD FS functionality will prevent users from accessing Office 365

In light of this you can now elect to deploy the Password Sync feature for your
federated domain(s) to provide a backup solution for your Single Sign-On
infrastructure

If your AD FS infrastructure becomes unavailable, you can now "switch" to using

the synchronized password hashes for user sign-in while you resolve your incident

The process of switching is to convert the federated domain back to standard

using the Convert-MsolDomainToStandard cmdlet

Switching from Single Sign-On to using Synchronized Passwords for Sign-In is not
instantaneous

When AD FS functionality is restored the domain can be reverted back to

federated by running the Convert-MsolDomainToFederated cmdlet (relatively
instantaneous)

50

Lab: Install and

Configure ADFS

51

Module
Review

Where is the password stored for an Office 365 federated

user?
What is the difference between an Active and Passive profile?
Why must the users UPN match the federated domain?

52

Module
Summary

In this Lesson, you learned:

About the installing and configuring AD FS to provide
single sign-on to Office 365
How to add a federated domain in Office 365
The authentication flow differences between clients

54

 2013
2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks
in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of
this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and
Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation.MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR
STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION