Office 365 Identity June 2013 Microsoft Office365 4/2/2017 © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

1 2 3 4 Agenda Identity management overview Core identity scenarios Deep dive on federation and synchronization Additional features 1 2 3 4

Identity management overview

What is identity management? Identity management deals with identifying individuals in a system and controlling access to the resources in that system Integral components of identity and access management Authentication Authorization Verifying that a user, device, or service such as an application provided on a network server is the entity that it claims to be. Determining which actions an authenticated entity is authorized to perform on the network

Identities for Microsoft Cloud Services Microsoft Account Organizational Account User Microsoft Account Ex: alice@outlook.com Organizational Account Ex: alice@contoso.com User

Common Identity platform for Organizational Accounts Windows Azure Active Directory is the underlying identity platform for various cloud services that use Organizational Accounts Directory store Authentication platform Windows Azure Active Directory

Core identity scenarios

Cloud Identity Windows Azure Active Directory Authorization OAuth2 SAML-P WS-Federation Metadata Graph API Authentication Office 365 Admin Portal Office Activation Service Authorization Exchange Mailbox Access … Spreadsheet CSV Import

Directory & Password Sync Windows Azure Active Directory OAuth2 SAML-P WS-Federation Metadata Graph API Authentication Office 365 Admin Portal Office Activation Service Authorization Exchange Mailbox Access … On Premises DirSync Active Directory

Directory Synchronization Options DirSync Office 365 Connector PowerShell & Graph API Suitable for Organizations using Active Directory (AD) Provides best experience to most customers using AD Supports Exchange Co-existence scenarios Coupled with ADFS, provides best option for federation and synchronization Supports Password Synchronization with no additional cost Does not require any additional software licenses Suitable for large organizations with certain AD and Non-AD scenarios Complex multi-forest AD scenarios Non-AD synchronization through Microsoft premier deployment support Requires Forefront Identity Manager and additional software licenses Suitable for small/medium size organizations with AD or Non-AD Performance limitations apply with PowerShell and Graph API provisioning PowerShell requires scripting experience PowerShell option can be used where the customer/partner may have wrappers around PowerShell scripts (eg: Self Service Provisioning)

Federated Identity Windows Azure Active Directory On Premises OAuth2 SAML-P WS-Federation Metadata Graph API Authentication Office 365 Admin Portal Office Activation Service Authorization Exchange Mailbox Access … Active Directory Federation Services One way trust Active Directory DirSync On Premises

Core identity scenarios with Office 365 Cloud Identity no integration to on-premises directories Windows Azure Active Directory On-Premises Identity Dirsync & Password Sync* Directory & Password Synchronization*  Integration without federation* Windows Azure Active Directory Federated Identity On-Premises Identity Federation Single federated identity and credentials Windows Azure Active Directory Directory Sync * Password Synchronization may not be available at GA, the target is to update the service by 1HCY2013

Federation options ADFS Third-party STS Shibboleth (SAML*) Works with AD Third-party STS Works with AD & Non-AD Shibboleth (SAML*) Works with AD & Non-AD Suitable for medium, large enterprises including educational organizations Recommended option for Active Directory (AD) based customers Single sign-on Secure token based authentication Support for web and rich clients Microsoft supported Phonefactor can be used for two factor auth Works for Office 365 Hybrid Scenarios Requires on-premises servers, licenses & support Suitable for medium, large enterprises including educational organizations Recommended where customers may use existing non-ADFS Identity systems with AD or Non-AD Single sign-on Secure token based authentication Support for web and rich clients Third-party supported Phonefactor can be used for two factor auth Works for Office 365 Hybrid Scenarios Requires on-premises servers, licenses & support Verified through ‘works with Office 365’ program Suitable for educational organizations j Recommended where customers may use existing non-ADFS Identity systems Single sign-on Secure token based authentication Support for web clients and outlook only Microsoft supported for integration only, no shibboleth deployment support Requires on-premises servers & support Works with AD and other directories on-premises * Broader SAML implementations will be supported in 1H CY2013

Partners in the Program * Web only means that with these identity providers only web clients would work. Rich clients like Outlook, Lync will not work.

Federation with Identity Partners Flexibility Confidence Coordinated Support Reuse Investments Verified by Microsoft Partner + Microsoft Corporation. Internal Use Only.

Microsoft Office 4/2/2017 ‘Works with Office 365’ Program for third party identity providers to interoperate with Office 365 Objective is to help customers that currently use Non-Microsoft identity solutions to adopt Office 365 © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

Identity Roadmap Shibboleth (SAML) Support Available now New Works with Office 365 Partners Ping, Optimal IDM, Okta, IBM available now Novell, CA and Oracle in 1H CY2013 DirSync for Multi-forest AD Available now thru’ MCS and Partners Sync Solution for Non-AD using FIM Password Synchronization for AD 1H CY2013 Broader SAML Support

Windows Azure Active Directory Microsoft Office 4/2/2017 Identity with other Cloud Services Cloud Identity Ex: alice@contoso.com Windows Azure Active Directory Identity managed in Windows Azure AD single sign-on for Office 365 and other cloud services federated with single cloud identity ISV Applications or SAAS providers can integrate using APIs on Windows Azure AD Currently in Technical Preview ISV apps or SAAS providers Cloud Identity Ex: alice@contoso.com User © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

Deep dive

High-level architecture Cloud identity + directory synchronization Single sign on + directory synchronization Contoso customer premises AD MS Online Directory Sync Provisioning platform Lync Online SharePoint Exchange Active Directory Federation Server 2.0 Trust IdP Directory Store Admin Portal/ PowerShell Authentication platform

Protocols Office 365 uses Web Services (WS-*) Protocols supported WS-Trust provides support for rich client authentication Identity federation supported only through ADFS 2.0 Protocols supported WS-*, SAML1.1(SAML1.1 token) SAML-P (SAML 2.0) platform support Strong authentication (2FA) solutions Web applications via ADFS Proxy sign in page or other proxies (UAG/TMG) Rich Clients dependent on configuration

Client Endpoints Active Federation (MEX) Applies to rich clients supporting ADFS Used by Lync and Office Subscription client Clients will negotiate authentication directly with on-premises ADFS server Basic Authentication (Active Profile) Applies to clients authenticating with basic authentication Used by ActiveSync, Outlook 2007/2010, IMAP, POP, SMTP, and Exchange Web Services Clients send “basic authentication” credentials to Exchange Online via SSL. Exchange Online proxies the request to the on-premises ADFS server on behalf of the client Passive Federation (Passive Profile) Applies to web browsers and documents opened via SharePoint Online Used by the Microsoft Online Portal, OWA, and SharePoint Portal Web clients (browsers) will authenticate directly with on-premises ADFS server

Understanding client authentication path

Sign on experience Rich Applications (SIA) Can save credentials Lync Office Subscriptions CRM Rich Client Can save credentials Web Clients Office with SharePoint Online Outlook Web Application Remember me =Persisted Cookie Exchange Clients Outlook Active Sync/POP/IMAP Entourage Can save credentials Username and Password Cloud Identity Username and Password Username and Password Online ID Online ID Online ID Federated Identities (non-domain joined) Username and Password Username and Password Username and Password AD credentials AD credentials AD credentials Federated Identities (domain joined) No Prompt Username Username and Password AD credentials AD credentials AD credentials

Microsoft Online Services Identity federation Authentication flow (passive/web profile) Customer Microsoft Online Services User Source ID Logon (SAML 1.1) Token UPN:user@contoso.com Source User ID: ABC123 DO NOT REMOVE – These are notes for the attendees The user tries to access an Office 365 Service (like OWA Exchange from IE) The service tells the client that it needs a service ticket signed by the Authentication platform, so go get a ticket from there The client goes to the Authentication platform (AP) asking for a service ticket. The AP says it can’t sign you in, it needs a login token signed by your on-premise STS (security token services). In this case this is Active Directory Federation Services 2.0 The client goes to the AD FS 2.0 Server to request a login token. AD FS 2.0 server contacts your AD, getting an NTLM token or Kerberos ticket for you, and then transforms this into a login SAML token (containing claims about the logged in user – their username/UPN and their userSourceID) which it then signs The client presents this signed SAML token to the AP which it opens. The AP checks that the token is indeed signed by the trusted authority for the federated domain through the public key that was shared during the trust establishment. The AP then transforms the userSourceID into a unique identifier or NetID; and then the AP creates a new transformed token, which it signs – which forms the service ticket The client presents the service ticket to the relying party service. The relying party service opens the ticket, checking that it is signed by the trusted party (the AP) based on a shared public key. It looks at the NetID claim and searches for a user in its directory with that NetID. [The NetID was set as part of provisioning/creating the user, and synchronized to the service.] Once found, the service can apply the necessary access control checks before allowing the user access to services. Auth Token UPN:user@contoso.com Unique ID: 254729

Microsoft Online Services Identity federation Authentication flow (MEX/rich client profile) Customer Microsoft Online Services User Source ID Logon (SAML 1.1) Token UPN:user@contoso.com Source User ID: ABC123 DO NOT REMOVE – These are notes for the attendees The user logs on to their client desktop machine on their corporate network. The client service (Microsoft Online Services Sign in assistant service) starts up and gets the logged on user’s domain by looking at the domain suffix of their UPN. The client service calls a home realm discovery service on the Authentication platform (AP). The AP checks to see if that domain is a registered federated domain. If not it returns nothing; if it is, the AP returns the Meta-data Exchange endpoint (MEX endpoint) on the registered federation server (the org’s AD FS 2.0 server). If nothing is returned the client service is done. If a MEX endpoint is returned the client service contacts the MEX endpoint, which returns a list of WS-Trust endpoints exposed by the AD FS 2.0 server. The client service chooses the most appropriate authentication endpoint type and requests a SAML1.1 token. The AD FS 2.0 server gets the logged on user’s NTLM token or Kerb ticket and transforms it into a SAML1.1 token (containing claims/assertions about the logged in user – their username/UPN and their userSourceID) which it then signs The SAML token is returned to the client service, which now requests a service token from the federation server, providing the SAML1.1 token it received from AD FS 2.0. The AP checks that the token is indeed signed by the trusted authority for the federated domain through the public key that was shared during the trust establishment. The AP then transforms the userSourceID into a unique identifier or NetID; and then the AP creates a new transformed ticket granting token (TGT) which is sent back to the client The client service now caches this TGT ready for use by the client applications. The user now starts up Outlook Lync 2010 attempts to connect to Lync Online (via Windows Integrated Auth and the SSPI layer using Negotiate), but Lync Online challenges for a service ticket (that was signed by the Authentication platform). Lync requests the a service ticket from the client service. The client service contacts the FG presenting the TGT to get a service specific signed ticket and then presents it to Lync Online over a secure channel. Lync Online opens the ticket, checking that it is signed by the trusted party (the AP) based on a shared public key. It looks at the NetID claim and searches for a user in its directory with that NetID. [The NetID was set as part of provisioning/creating the user, and synchronized to the service.] Once found, the service can apply the necessary access control checks before allowing the user access to services. Auth Token UPN:user@contoso.com Unique ID: 254729

Microsoft Online Services Identity federation Active flow (Outlook/Active Sync) always external Customer Microsoft Online Services User Source ID Logon (SAML 1.1) Token UPN:user@contoso.com Source User ID: ABC123 DO NOT REMOVE – These are notes for the attendees The user logs on to their client desktop machine on their corporate network. The Client starts Outlook on their Desktop Machine. The Client sends a request to Exchange Online and is challenged for Basic Credentials. The Client responds with Basic Credentials. Exchange Online calls a home realm discovery service on the Authentication platform (AP). The AP checks to see if that domain is a registered federated domain. If it is the AP returns the Active endpoint on the registered federation server (the org’s AD FS 2.0 server). Exchange Online proxies the basic auth Credentials from the client to the AD FS 2.0 Active endpoint and requests a SAML1.1 token. The AD FS 2.0 server gets the basic auth credentials, authenticates the user against AD and gets a Kerberos ticket. The ADFS server transforms the Kerberos ticket into a SAML1.1 token (containing claims/assertions about the user – their username/UPN and their userSourceID) which it then signs The SAML token is returned to the Exchange Online service, which now requests a service token from the AP, providing the SAML1.1 token it received from AD FS 2.0. The AP checks that the token is indeed signed by the trusted authority for the federated domain through the public key that was shared during the trust establishment. AP then transforms the userSourceID into a unique identifier or NetID; AP then creates a new service token (containing the NetID) which it signs and sends back to Exchange Online. Exchange Online opens the token, checking that it is signed by the trusted party (the AP) based on a shared public key. It looks at the NetID claim and searches for a user in its directory with that NetID. [The NetID was set as part of provisioning/creating the user, and synchronized to the service.] Once found, the service can apply the necessary access control checks before allowing the user access to services. Auth Token UPN:user@contoso.com Unique ID: 254729 Basic Auth Credentilas Username/Password

But wait, there’s more!

Microsoft Office 4/2/2017 User Soft Delete Simple list of deleted users that are restorable Easily restore previously deleted users Smart enough to handle conflicts during bulk restoration Handle case when the user’s domain is no longer available during restore © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

Shibboleth 2.X with Office 365 Tech Ready 15 4/2/2017 Shibboleth 2.X with Office 365 What is the Shibboleth Identity Provider (IdP)? Open source software package providing similar functionality as ADFS (e.g. SSO, Authentication, SAML 2.0) Popular implementation of SAML 2.x with Higher Education institutions world-wide Shibboleth is managed by the Shibboleth Consortium (http://www.shibboleth.net/index.html) Latest version is 2.3.6 How do customers with a Shibboleth IdP* interoperate with Office 365? Setup a SAML 2.0 federation between Office 365 and their Shibboleth IdP Deploy DirSync for user provisioning with AD and deploy MSOMA+FIM for user provisioning from non-AD Supported Clients Web Client Email Rich Clients Shibboleth 2.x IdP Shibboleth 2.x IdP Non-AD MSOMA + FIM AD MSOMA + FIM Contoso.edu Fabrikam.edu * This means that only Shibboleth implementation of SAML is supported, not any SAML implementation © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

Client access control Limit access to Office 365 based on network connectivity (internet versus intranet) Block all external access to Office 365 based on the IP address of the external client Block all external access to Office 365 except Exchange Active Sync; all other clients such as Outlook are blocked. Block all external access to Office 365 except for passive browser based applications such as Outlook Web Access or SharePoint Online

Scoping & filtering for Synchronization Microsoft Office365 4/2/2017 Scoping & filtering for Synchronization Customers can exclude objects from synchronizing to Office 365 Scoping can be done at the following levels: AD Domain-based Organizational Unit-based User Attribute based Additional filtering capabilities will become available with the O365 Connector. © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

Windows Azure Active Directory Microsoft Office 4/2/2017 Multi-forest AD Windows Azure Active Directory Multi-forest AD support is available through Microsoft-led deployments Multi-forest DirSync appliance supports multiple dis-joint account forests FIM 2010 Office 365 connector supports complex multi-forest topologies Federation using ADFS DirSync on FIM AD AD AD On-Premises Identity Ex: Domain\Alice User © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

Windows Azure Active Directory Microsoft Office 4/2/2017 Non-AD Synchronization Windows Azure Active Directory Preferred option for Directory Synchronization with Non-AD Sources Non-AD support with FIM is available through Microsoft-led deployments FIM 2010 Office 365 connector supports complex multi-forest topologies Federation using Non- ADFS STS Office 365 Connector on FIM Non-AD (LDAP) On-Premises Identity Ex: Domain\Alice User © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

4/2/2017 © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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. © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

Tech Ready 15 4/2/2017 Appendix © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

Multi-forest decision flowchart

Client access control Limit access to Office 365 based on network connectivity (internet versus intranet) Block all external access to Office 365 based on the IP address of the external client Block all external access to Office 365 except Exchange Active Sync; all other clients such as Outlook are blocked. Block all external access to Office 365 except for passive browser based applications such as Outlook Web Access or SharePoint Online Key Control Scenarios Outlook and ActiveSync Auth Web Auth (OWA, SharePoint) Passive Active Browser External AD FS 2.0 Proxy Passive Active Browser Internal AD FS 2.0 Server Outlook 2010/2007 ActiveSync ActiveSync Outlook 2010/2007