1 / 26

Office 365 Identity and Access Solutions

Office 365 Identity and Access Solutions. Session Objectives. Describe the different Identity Features Explain the Identity Architecture and Features Describe how federated authentication works Describe the various deployment scenarios Questions. Office 365 Identity features.

candice-black
Télécharger la présentation

Office 365 Identity and Access Solutions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Office 365 Identity and Access Solutions

  2. Session Objectives • Describe the different Identity Features • Explain the Identity Architecture and Features • Describe how federated authentication works • Describe the various deployment scenarios • Questions

  3. Office 365 Identity features • 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

  4. Authentication OptionsIT Administrator considerations Microsoft Online IDs Federated IDs (New) Manages password policy on-premise only Password reset for on-premise IDs only 2 Factor Auth integration options Requires additional on-premise servers to enable identity federation • Manages password policy in cloud & on-prem • Password reset for on-prem & MS Online IDs • No 2 Factor Auth integration

  5. Identity architecture: Identity options 1. Microsoft Online IDs 2. Microsoft Online IDs + DirSync Microsoft Online Services 3. Federated IDs + DirSync Identity Services Exchange Online Authentication platform Trust Contoso customer premises Active Directory Federation Server 2.0 SharePoint Online IdP IdP Provisioning platform MS Online Directory Sync AD Lync Online Directory Store Office 365 Desktop Setup Admin Portal

  6. Identity options comparison • 1. MS Online IDs • 2. MS Online IDs + Dir Sync • 3. Federated IDs + Dir Sync • 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

  7. Sign On Experience across apps and OSsFederated vs. Non-Federated Summary Office 2010, or Office 2007 SP2 SharePoint Online/Lync Online ActiveSync, POP, IMAP, Entourage • Office 365 Desktop setup required for rich clients • Installs client and operating system updates to enable best sign-on experience • Enables authentication support for rich clients • Not required for Web kiosk scenarios (e.g. OWA) • Passwords can be saved for Outlook on XP/Vista clients and Mobile devices etc. Outlook Web Application Outlook 2007 or 2010 Outlook 2007* Outlook2010 Win 7 Win 7 Vista/XP Win 7/Vista/XP Each session Each session Each session Each session Each session Once at setup MS Online IDs Online ID Online ID Online ID Online ID Online ID Online ID Federated IDs, (domain joined) No prompt* No prompt** No prompt Once per session*** No prompt Once per Session*** AD credentials

  8. Identity federation details

  9. Single Sign on setup

  10. DEMO: Federation Tool

  11. User Source ID NET ID Identity FederationAuthentication flow (Passive/Web profile) Customer Microsoft Online Services User Source ID

  12. User Source ID NET ID Identity FederationAuthentication flow (MEX/Rich Client profile) Customer Microsoft Online Services

  13. Basic Credential User Source ID NET ID Identity FederationAuthentication flow (EAS Basic Auth/Active profile) Customer Microsoft Online Services

  14. DEMO: SSO in Action

  15. Identity Details • 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 (with Shibboleth support) • Strong authentication (2FA) solutions • Web applications via ADFS Proxy sign in page or other proxies (UAG/TMG) • Rich Clients dependent on configuration

  16. AD FS 2.0 deployment options • Single server configuration • AD FS 2.0 server farm and load-balancer • AD FS 2.0 proxy server or UAG/TMG (External Users, Active Sync, Down-level Clients with Outlook) External user Active Directory AD FS 2.0 Server Proxy AD FS 2.0Server AD FS 2.0 Server AD FS 2.0 Server Proxy Internal user Enterprise DMZ

  17. Deployment options Identity federation • Domain conversion is a big switch. • Staged Rollout • Start with a Federated Domain and license users over time • Piloting Federation • Suitable for Existing production standard domain (running Directory Sync) containing production licensed users • Must use a different test domain, not sub-domain of an existing domain • Update Users UPN on premise to new Test domain • Must revert users back to a Managed domain at end of pilot

  18. Preparing for Identity Federation • Every User must have a UPN • UPN suffix must match a validated domain in Office 365 • UPN Character restrictions • Letters, numbers, dot 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 linksfrom domain machines

  19. Single Forest AD Structures • Matching domains • Internal Domain and External domain are the same Eg. contoso.com • Sub Domain • Internal domains is a sub domain of the external domain Eg. Corp.contoso.com • .Local Domain • Internal domain is not publicly “registered” Eg. Contoso.local • Multiple distinct UPN suffixes in Single forest • Eg, mix of users having login UPNs under contoso.com and fabrikam.com

  20. Single Forest Considerations • Matching domain • No special requirements • Sub Domain • Requires Domains registered in order, primary then sub domains • Local Domain • Domain ownership can’t be proved, must use a different domain • Requires all users to get new UPN • Multiple distinct domains • Requires additional switches to support a single ADFS server during setup (available at GA)

  21. Multi Forest Support • Key requirement to enable Single Sign On with multi forest • Various models being investigated • Single Account/Resources forests • Multiple separate Account forests with Single resource forest • Consolidated Sync forest (V1) • True Multi forest

  22. Single Account/Resource/Consolidated Forest • Initial tested configurations • Guidance via white paper • Goal to provide single sign on and co-existence • Considerations • Minimize customization/complexity for customers • Challenges • Location of objects Groups (DL Security), user, contacts • Attributes on the objects for co-existence • State of object, for example disabled/enabled • Source User ID co-ordination between Directory Sync and AD FS 2.0

  23. Strong Authentication • Currently supported scenarios • Rich Applications must not require second factor to authenticate • i.e. Logon to workstation with strong auth and then all connections are based on existing Kerberos tickets • Web Applications • Unsupported scenarios • Non-Domain Joined • (rich apps) • Mobile applications

  24. Alternative Proxies and Strong Authentication • Number of options depending on needs • Rich Applications without strong authentication • Web apps with strong authentication • Legacy OS/ActiveSync devices without strong authentication • Three options

  25. Q & A

More Related