IT PROS

Office 365: Planning and

Automating for Hybrid Identity

Scenarios in the Cloud A Geeks Guide to Dir Sync and ADFS with Tools,

Scripts and Deployment Hydration

Jeremy Chapman

@deployjeremy

Office and Office 365 STPM

Microsoft Office Division

Why Move to the Cloud?

What is Office 365? 93sJWAFfalse93sJWAFfalse93sJWAF

DEMO

Office 365 Admin Portal

Configuration Options

Cloud ID Directory Sync Federation Active Directory

Identity Services

On Premise

Infrastructure

Components and How it Works 1. Microsoft Online IDs

2. Microsoft Online IDs + Microsoft Online Services Directory Synchronization

3. Single Sign On + Directory Synchronization

AD

MS Online Directory

Sync

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

IdP

Microsoft Online

Services

Comparing Identity Options

Cloud ID

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

Cloud IDs + Dir Sync

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 Federated IDs + Dir

Sync

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 hybrid scenarios

• Location isolation

Cons

• High availability server

deployments required

Identity Federation Authentication flow (Passive/Web profile)

`

Client

(joined to CorpNet)

Authentication platformAD FS 2.0 Server

Exchange Online or

SharePoint Online

Active Directory

On Premise Microsoft Online Services

User

Source ID

Logon (SAML 1.1) Token

UPN:user@contoso.com

Source User ID: ABC123

Auth Token

UPN:user@contoso.com

Unique ID: 254729

General Requirements Federated Identity and Directory Synchronization

• Active Directory Forest Functionality level 2003

• Windows 2008 for AD FS 2.0 or above

• Windows 2003 or above for Directory Synchronization

– 64 bit for 2008 and above

• Support Virtualization

• Hybrid Deployments

– Exchange 2010 SP1 Client Access Server and associated

Schema

Converting a Domain to SSO • Recommended to start with Enterprise SSO, add and verify the domain before

Directory Sync is run.

• A one step operation for this domain and any sub domain

– Users must logon via AD FS and are converted at login, password lost at this point

• Ensure you prepare by

– Ensure Directory Sync is healthy

– Making sure all users have the right UPN in the cloud, remember a licensed user may not be

updated

– Make sure your AD FS server is accessible both internally and externally (required for Outlook

connections)

• After conversion

– Verify login both internally and externally

– Background operation will run to ensure all users have the right UPN

Identity Services On Premise

Infrastructure

Basic Steps to Single Sign On 1. Microsoft Online PowerShell Module for Windows

2. Connect to AD FS 2.0 and Microsoft Office 365

3. New-MsolFederatedDomain (returns details for proof of ownership)

4. New-MsolFederatedDomain

Provisioning

platform

Active Directory

Federation Server 2.0

Trust

Directory

Store

Admin Portal/

PowerShell

Authentication

platform

MSOL PowerShell

Module

Microsoft Online

Services

Add Domain

Required

TXT/MX Record

Add Trust

- Claim Rules

- User Source ID = AD ObjectGUID

Verify-Domain

- Active/Mex/Passive

- Token certs Current/Next

- Brand URI etc

Update

The Steps to SSO + DirSync 1. Deployment Readiness

2. Ensure UPNs match child domain name

3. Verify UPN values using PowerShell

4. Create DNS host record for ADFS

5. Create a new domain certificate on DC

6. Assign new cert to the default website

7. Install and configure ADFS 2.0 on a server

8. Distribute Sign-in Assistant to client

machines

9. Install the MSOL Module for PowerShell

10. Add the federated domain

11. Create a TXT record and verify the federated

domain

12. Add a federated subdomain

13. View active domains in the O365 portal

14. Assign license plan for the admin account

15. Activate Directory Sync

16. Install the Directory Sync Tool

17. Create a new OU and create new users

18. Create a new contact and DG in Exchange

19. Synchronize AD

20. Verify directory synchronization

21. Optional: Update user info and force DirSync

22. Update mail controls to shared domain

23. Activate online user subscriptions

24. Verify ID federation

25. Deploy GPO to add STS URL to Local

Intranet zone

1-3 Deployment Readiness

User Object Attributes

– Valid UPN suffix

– No special characters (except !@#~.-_^)

– Check for required missing attributes

– No dots before @

(user.jr.@microsoft.com)

Client Readiness

– Windows XP SP3 or newer

– Office 2007 SP2 or newer

Specifically

- Remove duplicate proxyAddress

and userPrincipalName

attributes.

- Update blank and invalid

userPrincipalName attributes

with a valid userPrincipalName.

- Remove invalid and

questionable characters in the

givenName, surname (sn),

sAMAccountName,

displayName, mail,

proxyAddresses, mailNickname,

and userPrincipalName

attributes.

DEMO

Office 365 Deployment Readiness Tool

Output

WARNING AS TEMPING AS IT SOUNDS,

SCRIPTING FIXES TO DIRECTORY

ATTRIBUTES CAN BREAK STUFF.

USE EXTREME CAUTION!

4. Create DNS host record for ADFS

5. Create a new domain cert on DC

6. Assign new cert to the default website

7. Install and configure AD FS 2.0 on a

server

7. Install and configure AD FS 2.0 on a

server

DEMO

Hydrate AD FS 2.0 Server(s)

Customize Office 2010 Subscription Clients

AD FS HW Config Based on User Counts

Number of users Suggested hardware configuration

Fewer than 1,000 users No dedicated federation server proxies

2 dedicated load-balanced AD FS servers

1,000 to 15,000 users 2 dedicated federation server proxies

15,000 to 60,000 users At least 2 dedicated federation server proxies

Notes: 5 servers per AD FS Farm

Open TCP port 443 for federation server and proxy communication

Use AD FS Capacity Planning Spreadsheet for Sizing Recommendations

8. Distribute Sign-in Assistant to client

machines

9. Install the MSOL Module for PowerShell

10. Add the federated domain

11. Create a TXT record in DNS

Important External DNS Values in Office

365 DNS record Purpose Value to use

TXT

(Domain

Validation)

This record is used for domain validation. It proves

that you own the domain but it doesn't direct incoming

mail for the domain to Office 365 service offerings.

Host: @ (domain name)

TXT Value: <text string>

The values that you need to enter are provided to you by the Microsoft

Online Services Portal add domain wizard.

Note: The wizard also gives you the option of using a MX record for domain

validation.

CNAME

(Exchange

Online)

This record allows Office Outlook clients to connect to

the Exchange Online service by using the

Autodiscover service. Autodiscover automatically finds

the correct Exchange Server host and configures

Outlook for the users.

Alias: Autodiscover Target: autodiscover.outlook.com For more information,

see Use a CNAME Record to Enable Outlook to Connect.

MX

(Exchange

Online)

This value directs all incoming mail for the domain to

the Exchange Online service.

Domain: contoso.com

Target Server <MX token>. mail.eo.outlook.com

Preference: 10

SPF (TXT)

(Exchange

Online)

This sender policy framework (SPF) record identifies

which of your email servers are authorized to transmit

email from your domain. This helps to prevent others

from using your domain to send SPAM or other

malicious email.

Values: v=spf1 include:outlook.com include: spf.messaging.microsoft.com

~all.

For more information, see Use an SPF Record to Validate E-mail Sent from

Your Domain.

Only existing FOPE customers need “include: spf.messaging.microsoft.com”

Note: If the firewall or proxy server blocks TXT lookups on an external DNS,

this record should also be added to the internal DNS record.

Important External DNS Values in Office

365 DNS record Purpose Value to use

SRV (Lync Online) This value is for SIP federation and allows your

Office 365 domain to share instant messaging (IM)

features with clients other than Windows Live

Messenger.

Service: _sipfederationtls Protocol: TCP Priority: 10 Weight: 1 Port: 5061

Target: Sipfed.online.lync.com

Note: If the firewall or proxy server blocks SRV lookups on an external DNS,

this record should also be added to the internal DNS record.

SRV (Lync Online) This SRV record is used by Microsoft Lync Online

to coordinate the flow of information between Lync

clients.

Service: _sip Protocol: TLS Priority: 100 Weight: 1 Port: 443

Target: sipdir.online.lync.com

CNAME (Lync

Online)

This CNAME record is used by the Lync 2010 client

to discover the Lync Online service and sign in.

Alias: sip Target: sipdir.online.lync.com

For more information, see Ensuring Your Network Works With Lync Online

CNAME (Lync

Online)

This CNAME record is used by the Lync 2010

mobile client to discover the Lync Online service

and sign in.

Alias: lyncdiscover

Target: webdir.online.lync.com

Host (A) This record is used for single sign-on. It indicates

the end point for your off-premises users (and on-

premises users if you choose) to connect to your

AD FS federation server proxies or load-balanced

VIP.

Target (example): sts.contoso.com

TXT

(Exchange

Federation)

Exchange federation for hybrid deployment TXT record 1: contoso.com and associated custom-generated domain proof

hash (ex. “Y96nu89138789315669824”)

TXT record 2: exchangedelegation.contoso.com and associated custom-

generated domain proof hash (for example, “Y3259071352452626169”)

12. Verify the federated domain

13. Add a federated subdomain

14. View active domains in the O365 portal

15. Assign license plan for the admin account

16. Activate Directory Sync

17. Install Directory Sync Tool (not on the DC)

WARNING THE DIRECTORY SYNC TOOL WILL

CREATE THE MSOL_AD_SYNC

ACCOUNT IN THE STANDARD

USERS OU IN AD. DON’T DELETE

IT!

18a. Create a new OU and create new users

18b. Assign Filterable Properties to OU

Members

19. Create a new contact and DG in Exchange

20. Synchronize Active Directory

WILL

WARNING YOU CAN SYNCHRONIZE UP TO 20,000

ACCOUNTS USING THE DIRSYNC TOOL. NEED

MORE? CALL US FOR AN EXCEPTION.

ALSO SQL EXPRESS WITH DIRSYNC CAN

HANDLE UP TO 50K USERS. USE FULL SQL IF

>50K USERS WILL BE SYNCING.

21. Verify Directory Synchronization

22a. Optional: update user info and force

DirSync

22b. Optional: update user info and force

DirSync

23. Update mail controls to shared domain

24. Activate online user subscriptions

25. Verify ID federation

25. Deploy GPO to add STS URL to Local Intranet

zone

Staging and Piloting Staged Rollout

– Start with a Federated Domain and license users over time

Piloting Federation

– Suitable for existing production standard domains (running Directory

Sync) containing production licensed users

– Must use a different test domain, not sub-domain of an existing domain

– Update existing/create new test user UPN on premise to new Test

domain

– Optionally revert users back to a Managed domain at end of pilot

– More information http://community.office365.com/en-us/w/sso/357.aspx

Converting a Domain back to Cloud IDs

Affects all users in the Domain and Sub Domains

Should be used with Caution

– Users may require a new password when converted back to Cloud based

IDs

• Password of users that did not login can use old password

– Runs through all AD users to convert them back to cloud based IDs, i.e.

can be long running

Share Password with users that were converted from Enterprise SSO to

Cloud IDs.

Sign in Experience for Single Sign On Rich clients applications with Microsoft Online Sign In Assistant.

– Lync, Office Subscriptions, CRM Rich client.

– Integrated experience when on a domain joined machine on the corporate network.

– Authenticates directly with AD FS server for internal clients and AD FS proxy for external

clients

Web based applications

– SharePoint Online, OWA, Office Rich Applications (Word, PowerPoint etc)

– Prompts for username to do realm discovery (click through)

• Keep me signed in to by pass prompt still need to authenticate externally to AD FS server

– Integrated authentication to AD FS server on Domain joined machine on the corporate

network

– Authenticates directly with AD FS server for internal clients and AD FS proxy for external

clients

– Smart links can help with username prompt for example

http://www.outlook.com/contoso.com

Sign On ExperienceWeb Clients • Office 2010, Office 2007

SP2 with SharePoint

Online

• Outlook Web Application

Remember me =Persisted

Cookie

Exchange Clients • Office 2010, Office 2007

SP2

• Active Sync/POP/IMAP

• Entourage

Can save credentials

Rich Applications (SIA) • Lync Online

• Office Subscriptions

• CRM Rich Client

Can save credentials

SSO IDs (domain joined)

MS Online IDs

No Prompt

Username and Password

Online ID

AD

credentials

SSO IDs (non-domain

joined)

Username and Password

AD

credentials

Username

Username and Password

Online ID

AD

credentials

Username and Password

AD

credentials

Username and

Password

Username and Password

Online ID

AD

credentials

Username and Password

AD

credentials

DEMO

User Sign-on Experience

Office and Office 365 Resources

http://technet.microsoft.com/en-us/office365/default

http://blogs.technet.com/b/office_resource_kit/

http://technet.microsoft.com/en-

us/office365/hh699847

thank you

Single Forest AD Structures and Considerations

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 • Smart Card issues

Multiple distinct UPN suffixes in single forest

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

• Must use SupportMultipleDomain switch in PowerShell

Multi Forest Multiple AD Forest Support being developed (H1 2012)