1. 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.

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

3. Identity management overview

4. 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

5. Identities for Microsoft Cloud Services
Microsoft Account
Organizational Account
User
Microsoft Account
Ex:
Organizational Account
Ex:
User

6. 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

7. Core identity scenarios

8. 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

9. 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

10. 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)

11. 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

12. 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

13. 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

14. 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.

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

16. 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.

17. 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

18. Windows Azure Active Directory
Microsoft Office
4/2/2017
Identity with other Cloud Services
Cloud Identity
Ex:
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:
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.

19. Deep dive

20. 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

21. 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

22. 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

23. Understanding client authentication path

24. 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

25. Microsoft Online Services
Identity federation
Authentication flow (passive/web profile)
Customer
Microsoft Online Services
User
Source ID
Logon (SAML 1.1) Token
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
Unique ID:

26. Microsoft Online Services
Identity federation
Authentication flow (MEX/rich client profile)
Customer
Microsoft Online Services
User
Source ID
Logon (SAML 1.1) Token
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
Unique ID:

27. Microsoft Online Services
Identity federation
Active flow (Outlook/Active Sync) always external
Customer
Microsoft Online Services
User
Source ID
Logon (SAML 1.1) Token
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
Unique ID:
Basic Auth Credentilas
Username/Password

28. But wait, there’s more!

29. 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.

30. 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 (
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
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.

31. 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

32. 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.

33. 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.

34. 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.

35. 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.

36. 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.

37. Multi-forest decision flowchart

38. 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