John Gilham Principal Consultant

Agile IT

Key Components:

Synchronization (DirSync) and SSO Concepts

SSO Federation (ADFS 2.0)

Email Rich Co-Existance (On-Premise <-> Cloud)

Password policy controls for Microsoft Online IDs

Single sign-on with corporate credentials

Directory Synchronization updates

Role-based administration: Five administration roles Company Admin

Billing Admin

User Account Admin

HelpDesk Admin

Service Support Admin

“Admin on behalf of” for support partners

Contoso customer premises

1. Microsoft Online IDs

2. Microsoft Online IDs + Microsoft Online Services Directory Synchronization (DirSync)

3. Single Sign On (SSO) Federation + Directory Synchronization (DirSync

AD MS Online

Directory Sync

Identity Services

Provisioning platform

Lync Online

SharePoint Online

Exchange Online

Active Directory Federation Server

2.0

Trust

IdP Directory

Store

Admin Portal/ PowerShell

Authentication platform

Office 365 Desktop Setup

Microsoft Online Services

IdP

Appropriate for • Smaller orgs without AD

on-premise

Pros • No servers required on-

premise

Cons • No SSO • No 2FA • 2 sets of credentials to

manage with differing password policies

• IDs mastered in the cloud

Appropriate for • Medium/Large orgs with AD

on-premise

Pros • Users and groups mastered

on-premise • Enables co-existence

scenarios Cons • No SSO • No 2FA • 2 sets of credentials to

manage with differing password policies

• Single server deployment

Appropriate for • Larger enterprise orgs with

AD on-premise Pros • SSO with corporate cred • IDs mastered on-premise • Password policy controlled

on-premise • 2FA solutions possible • Enables co-existence

scenarios Cons • High availability server

deployments required

Office 365 Desktop setup required for rich clients ◦ Installs client and operating system updates to enable best sign-on experience

◦ Not required for Web kiosk scenarios (e.g. OWA)

Passwords prompts ◦ Can be saved for rich applications, can remain “signed in” for web applications

◦ Will prompt again when the password changes or expires

Single Sign Prompts ◦ Can bypass prompts by using “Smart Links”. Still requires password for non-

domain joined machines.

◦ Prompt for User Name must be in UPN format for realm discovery (no internal TLD such as .local or .loc)

◦ None Domain Joined Machines prompted for both Username Realm Discover and password (Active Directory credentials)

Win7/Vista/XP

SSO IDs (domain joined)

MS Online IDs

Outlook Web Application

SharePoint Web Application

ActiveSync, POP, IMAP, Entourage

Each session*

Outlook 2007 or 2010

Online ID Online ID Online ID

Win 7/Vista/XP

Office 2010, or Office 2007

SP2

Online ID

Each session*

Win7/Vista/XP

Lync Online

Online ID

Each session*

AD credentials AD credentials AD credentials AD credentials AD credentials

SSO IDs (non-domain joined) AD credentials AD credentials AD credentials AD credentials AD credentials

Authentication flow (Passive/Web profile)

`

Client

(joined to CorpNet)

Authentication platformAD FS 2.0 Server

Exchange Online or

SharePoint Online

Active Directory

Customer Microsoft Online Services

Logon (SAML 1.1) Token

UPN:user@contoso.com

Source User ID: ABC123

Auth Token

UPN:user@contoso.com

Unique ID: 254729

Authentication flow (MEX/Rich Client Profile)

`

Client

(joined to CorpNet)

Authentication platformAD FS 2.0 Server

Lync Online

Active Directory

Customer Microsoft Online Services

Logon (SAML 1.1) Token

UPN:user@contoso.com

Source User ID: ABC123

Auth Token

UPN:user@contoso.com

Unique ID: 254729

Active flow (Outlook/Active Sync)

`

Client

(joined to CorpNet)

Authentication platformAD FS 2.0 Server

Exchange Online

Active Directory

Customer Microsoft Online Services

Logon (SAML 1.1) Token

UPN:user@contoso.com

Source User ID: ABC123

Auth Token

UPN:user@contoso.com

Unique ID: 254729

Basic Auth Credentilas

Username/Password

Microsoft Online Services requirements ◦ MS Online business scenarios always use WS-*

WS-Trust provides support for rich client authentication

◦ Identity federation supported initially only through AD FS 2.0

Protocols supported ◦ WS-*, SAML1.1

◦ SAML-P coming later

Strong authentication (2FA) solutions ◦ Web applications via ADFS Proxy sign in page or other proxies

(UAG/TMG)

◦ Rich Clients dependent on configuration

1.Single server configuration

2.AD FS 2.0 server farm and load-balancer

3.AD FS 2.0 proxy server or UAG/TMG (External Users, Active Sync, Outlook)

Enterprise

DMZ

AD FS 2.0 Server Proxy

External user

Internal user

Active Directory

AD FS 2.0 Server

AD FS 2.0 Server

AD FS 2.0 Server Proxy

Structure Description Considerations

Matching domains Internal Domain and External domain are the same i.e. contoso.com

No special requirements

Sub domain Internal domains is a sub domain of the external domain i.e. corp.contoso.com

Requires Domains registered in order, primary then sub domains

.local domain Internal domain is not publicly “registered” i.e. contoso.local

Domain ownership can’t be proved, must use a different domain • Requires all users to get new

UPN. • Use SMTP address if possible

Multiple distinct UPN suffixes in single forest

Mix of users having login UPNs under different domains i.e. contoso.com & fabrikam.com

Currently requires multiple AD FS servers.

Multi Forest Multiple AD Forest Not currently supported.

High availability design for AD FS 2.0

Every User must have a UPN

UPN suffix must match a validated domain in Office 365

UPN Character restrictions ◦ Letters, numbers, dot, underscore or dash

◦ No dot before @ symbol

Users may need to understand that they must use UPN to logon to Office 365 Apps ◦ Can be hidden from users with smart links from domain machines

Number of options depending on needs ◦ Rich Applications without strong authentication ◦ Web apps with strong authentication (RSA etc) ◦ OS/ActiveSync devices without strong authentication

Three options:

Authentication Scheme Authentication limitations

AD FS proxy Requires integration of the strong authentication provider with the AD FS proxy login page.

None

Forefront TMG

Publish the AD FS server. Integration with some strong authentication providers is provided out of the box.

Supported but requires each path to be published separately

Forefront UAG SP1

Publish the AD FS server. Integration with a wide range of authentication providers out of the box, very flexible integration options.

Supported but requires each path to be published separately

Feature Simple Rich*

Mail routing between on-prem and cloud (recipients on either side)

Mail routing with shared namespace (if desired) - @company.com on both sides

Unified GAL

Free/Busy and calendar sharing cross-prem

Out of Office understands that cross-prem is “Internal” to the organization

Mailtips, messaging tracking, and mailbox search work cross-prem

OWA Redirection cross-premise (single OWA URL for both on-prem and cloud)

Preserve Auth header (ensure internal email is not marked as spam, resolve against GAL, etc)

EMC GUI tool (on-prem) used to manage cross-prem mailbox migrations

Mailbox moves support both onboarding and offboarding

No outlook reconfiguration or OST resync required after mailbox migration equires Exchange 2010 SP1 Hub+CAS on-prem and requires supplemental configuration steps (both on-prem and in the cloud)

Today’s

Focus

Cutover

◦ Executed over a weekend; switch the MX record ◦ All users moved as part of a

“big switch” to the cloud No option to pilot mailboxes

◦ No on-prem configuration or hardware requirement

Coexistence

◦ Executed over some longer period of time (a week, a month, a year, etc)

◦ No requirement to ever flip “a switch” – can run in coexistence scenario indefinitely

◦ Requires on-prem configuration and hardware

Today’s Focus

Answer Your Office 365 Questions

@Agile_IT

AgileIT.com/Blog