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
Similaire à 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
Supporting architecture office 365 on windows azure Jethro Seghers
Similaire à 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 (20)
WSO2's API Vision: Unifying Control, Empowering Developers
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
2. 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
8. Components and How it Works
1. Microsoft Online IDs
2. Microsoft Online IDs + Microsoft Online Services Directory Synchronization
3. Single Sign On + Directory Synchronization
Trust
Exchange Online
Authentication
Active Directory Admin Portal/ platform IdP SharePoint Online
IdP
Federation Server 2.0 PowerShell
AD
MS Online Directory Provisioning Directory Lync Online
Sync platform Store
Identity Services
Office 365 Desktop Setup
On Premise Microsoft Online
Infrastructure
Services
9. Comparing Identity Options
Appropriate for Appropriate for Appropriate for
• Smaller orgs without AD on- • Medium/Large orgs with AD • Larger enterprise orgs with
premise on-premise AD on-premise
Pros Pros Pros
• No servers required on- • Users and groups mastered • SSO with corporate cred
premise on-premise • IDs mastered on-premise
• Enables co-existence • Password policy controlled
Cons scenarios on-premise
• No SSO • 2FA solutions possible
• No 2FA Cons • Enables hybrid scenarios
• 2 sets of credentials to • No SSO • Location isolation
manage with differing • No 2FA
password policies • 2 sets of credentials to Cons
• IDs mastered in the cloud manage with differing • High availability server
password policies deployments required
• Single server deployment
Federated IDs + Dir
Cloud ID Cloud IDs + Dir Sync
Sync
10. Identity Federation
Authentication flow (Passive/Web profile)
User
Source ID
Active Directory
AD FS 2.0 S Logon (SAML 1.1) Token
erver Authentication platform
UPN:user@contoso.com
Source User ID: ABC123
Auth Token
UPN:user@contoso.com
Unique ID: 254729
`
Exchange Online or
Client
S harePoint Online
(joined to CorpNet)
On Premise Microsoft Online Services
11. 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
12. 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
13. 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
Microsoft Online
Add Trust Services
- Claim Rules
- User Source ID = AD ObjectGUID
Authentication
Trust Admin Portal/
platform
PowerShell
Update
Active Directory Required Provisioning
TXT/MX Record
Directory
Federation Server 2.0 platform Store
MSOL PowerShell Add Domain
Module Verify-Domain Identity Services
On Premise - Active/Mex/Passive
- Token certs Current/Next
Infrastructure - Brand URI etc
14. The Steps to SSO + DirSync
1. Deployment Readiness 12. Add a federated subdomain
2. Ensure UPNs match child domain name 13. View active domains in the O365 portal
3. Verify UPN values using PowerShell 14. Assign license plan for the admin account
4. Create DNS host record for ADFS 15. Activate Directory Sync
5. Create a new domain certificate on DC 16. Install the Directory Sync Tool
6. Assign new cert to the default website 17. Create a new OU and create new users
7. Install and configure ADFS 2.0 on a server 18. Create a new contact and DG in Exchange
8. Distribute Sign-in Assistant to client 19. Synchronize AD
machines 20. Verify directory synchronization
9. Install the MSOL Module for PowerShell 21. Optional: Update user info and force DirSync
10. Add the federated domain 22. Update mail controls to shared domain
11. Create a TXT record and verify the federated 23. Activate online user subscriptions
domain
24. Verify ID federation
25. Deploy GPO to add STS URL to Local
Intranet zone
15. 1-3 Deployment Readiness
User Object Attributes Specifically
– Valid UPN suffix - Remove duplicate proxyAddress
– No special characters (except !@#~.-_^) and userPrincipalName
– Check for required missing attributes attributes.
– No dots before @ - Update blank and invalid
(user.jr.@microsoft.com) userPrincipalName attributes
Client Readiness with a valid userPrincipalName.
– Windows XP SP3 or newer - Remove invalid and
– Office 2007 SP2 or newer questionable characters in the
givenName, surname (sn),
sAMAccountName,
displayName, mail,
24. 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
29. Important External DNS Values in Office
365
DNS record
TXT
Purpose
This record is used for domain validation. It proves
Value to use
Host: @ (domain name)
(Domain that you own the domain but it doesn't direct incoming TXT Value: <text string>
Validation) mail for the domain to Office 365 service offerings. 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 This record allows Office Outlook clients to connect to Alias: Autodiscover Target: autodiscover.outlook.com For more information,
(Exchange the Exchange Online service by using the see Use a CNAME Record to Enable Outlook to Connect.
Online) Autodiscover service. Autodiscover automatically finds
the correct Exchange Server host and configures
Outlook for the users.
MX This value directs all incoming mail for the domain to Domain: contoso.com
(Exchange the Exchange Online service. Target Server <MX token>. mail.eo.outlook.com
Online) Preference: 10
SPF (TXT) This sender policy framework (SPF) record identifies Values: v=spf1 include:outlook.com include: spf.messaging.microsoft.com
(Exchange which of your email servers are authorized to transmit ~all.
Online) email from your domain. This helps to prevent others For more information, see Use an SPF Record to Validate E-mail Sent from
from using your domain to send SPAM or other Your Domain.
malicious email. 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.
30. 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 Service: _sipfederationtls Protocol: TCP Priority: 10 Weight: 1 Port: 5061
Office 365 domain to share instant messaging (IM) Target: Sipfed.online.lync.com
features with clients other than Windows Live Note: If the firewall or proxy server blocks SRV lookups on an external DNS,
Messenger. this record should also be added to the internal DNS record.
SRV (Lync Online) This SRV record is used by Microsoft Lync Online Service: _sip Protocol: TLS Priority: 100 Weight: 1 Port: 443
to coordinate the flow of information between Lync Target: sipdir.online.lync.com
clients.
CNAME (Lync This CNAME record is used by the Lync 2010 client Alias: sip Target: sipdir.online.lync.com
Online) to discover the Lync Online service and sign in. For more information, see Ensuring Your Network Works With Lync Online
CNAME (Lync This CNAME record is used by the Lync 2010 Alias: lyncdiscover
Online) mobile client to discover the Lync Online service Target: webdir.online.lync.com
and sign in.
Host (A) This record is used for single sign-on. It indicates Target (example): sts.contoso.com
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.
TXT Exchange federation for hybrid deployment TXT record 1: contoso.com and associated custom-generated domain proof
(Exchange hash (ex. “Y96nu89138789315669824”)
Federation) TXT record 2: exchangedelegation.contoso.com and associated custom-
generated domain proof hash (for example, “Y3259071352452626169”)
42. WARNING
YOU CAN SYNCHRONIZE UP TO 20,000
ACCOUNTS USING THE DIRSYNC TOOL. NEED
WILL
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.
51. 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
52. 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.
53. 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
54. Sign On Experience
Rich Applications (SIA) Web Clients Exchange Clients
• Lync Online • Office 2010, Office 2007 • Office 2010, Office 2007
• Office Subscriptions SP2 with SharePoint SP2
• CRM Rich Client Online • Active Sync/POP/IMAP
• Outlook Web Application • Entourage
MS Online Username and Password Username and Password Username and Password
IDs Online ID Online ID Online ID
SSO IDs Username and Password Username and Password Username and Password
(non-domain AD AD AD
joined) credentials credentials credentials
SSO IDs No Prompt Username Username and
(domain joined) AD AD Password
AD
credentials credentials credentials
Can save credentials Can save credentials
Remember me =Persisted
Cookie
58. Single Forest AD Structures and Considerations
Structure Description Considerations
Matching domains Internal Domain and External domain are No special requirements
the same i.e. contoso.com
Sub domain Internal domains is a sub domain of the Requires Domains registered in order,
external domain i.e. corp.contoso.com primary then sub domains
.local domain Internal domain is not publicly Domain ownership can’t be proved,
“registered” i.e. contoso.local must use a different domain
• Requires all users to get new UPN.
• Use SMTP address if possible
• Smart Card issues
Multiple distinct UPN Mix of users having login UPNs under • Must use SupportMultipleDomain
suffixes in single different domains switch in PowerShell
forest i.e. contoso.com & fabrikam.com
Multi Forest Multiple AD Forest Support being developed (H1 2012)