2. Day 2 - Identify and SSO
•Download as PPTX, PDF•
2 likes•716 views
This document provides an overview of identity management options in Office 365 and describes the Synchronized Identity Model (DirSync), Federated Identity Model (SSO), and key considerations for each. It compares the models based on organization size and capabilities like single sign-on and management of credentials. The Synchronized Identity Model uses Azure Active Directory Connect to synchronize on-premises directories with Azure AD. The Federated Identity Model implements Security Assertion Markup Language for single sign-on using federation servers like Active Directory Federation Services.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (13)
Similar to 2. Day 2 - Identify and SSO
Similar to 2. Day 2 - Identify and SSO (20)
2. Day 2 - Identify and SSO
- 2. Overview of Identity Management in Office 365 Synchronize Identity Model (DirSync) 2 3 Explain Azure Active Directory 1 Federated Identity Model (SSO) 4 55
- 5. Self-service Single sign on ••••••••••• Username Identity as the control plane Simple connection Cloud SaaS Azure Office 365Public cloud Other Directories Windows Server Active Directory On-premises Microsoft Azure Active Directory
- 6. Azure Active Directory Connect* Microsoft Azure Active Directory Other Directories PowerShell LDAP v3 SQL (ODBC) Web Services ( SOAP, JAVA, REST) *
- 8. Cloud Identity Directory Synchronization Single identity suitable for medium and large organizations without federation Federated Identity Single federated identity and credentials suitable for medium and large organizations Single identity in the cloud Suitable for small organizations with no integration to on- premises directories
- 12.
- 13.
- 14.
- 15. Manage DirSync Activate Users Sync Directories Setup DirSync Activate DirSync Prepare for DirSync Enable password sync Initial password sync Password handling during activation Force a full sync Monitor events
- 16. Microsoft Online Services Logon Enabled User Object (Unlicensed) Mail-Enabled User (not Mailbox-Enabled) ProxyAddresses: SMTP: John.Doe@contoso.com smtp: John.Doe@contoso.onmicrosoft.com TargetAddress: John.Doe@contoso.com On-premises Active Directory DirSync Online Directory DirSync Web Service SharePoint Online Live ID Exchange Online Lync Online Sync Cycle Step 1: Import Users, Groups, and Contacts from source Active Directory forest Sync Cycle Step 2: Imports Users, Groups, and Contacts from Microsoft Online Services via AWS Sync Cycle Step 3: Export Users, Groups, and Contacts that do not already exist in Microsoft Online Services User Object Mailbox-Enabled ProxyAddresses: SMTP: John.Doe@contoso.com
- 17. Application Log, Event Source = Directory Synchronization Password synchronization starts retrieving updated passwords from the on-premises AD DS Event ID 650 Finished retrieving updated passwords from on-premises AD DS Event ID 651 success Failed to retrieve updated passwords from on-premises AD DS Event ID 652 error
- 18. Application Log, Event Source = Directory Synchronization Password synchronization starts informing Windows Azure AD that there are no passwords to be synced Event ID 653 Finishes informing Windows Azure AD that there are no passwords to be synced Event ID 654 success Failed to inform Windows Azure AD that there are no passwords to be synced Event ID 655 error** This occurs every 30 minutes if no passwords have been updated on-premises
- 19. Application Log, Event Source = Directory Synchronization Password synchronization detects password changes and tries to sync it to Windows Azure AD Event ID 656 User(s) whose password was successfully synced Result : Success Event ID 657 success User(s) whose password was not synced Result : Failed error ** Lists at least 1 user, at most 50 users
- 21. • Separate credential from on- premises credential • Authentication occurs via cloud directory service • Password policy is stored in Office 365 • Does not require on-premises server deployment • Same credential as on-premises credential • Authentication occurs via on- premises directory service • Password policy is stored on- premises • Requires on-premises DirSync server • Requires on-premises ADFS server
- 22. Cloud Identity Cloud Identity + DirSync Federated Identity Scenario Smaller organizations with or without on- premises Active Directory Medium to Large organizations with Active Directory on-premises Large enterprise organizations with Active Directory on-premises Benefits Does not require on-premises server deployment “Source of Authority” is on-premises Enables coexistence Single Sign-On experience “Source of Authority” is on-premises 2 Factor Authentication options Enables coexistence Limitations No Single Sign-On No 2 Factor Authentication options Two sets of credentials to manage Different password policies No Single Sign-On No 2 Factor Authentication options Two sets of credentials to manage Different password policies Requires on-premises DirSync server deployment Requires on-premises ADFS server deployment in high availability scenario Requires on-premises DirSync server deployment
- 27. Perimeter Network ADFS 2.0 Proxy Active Directory ADFS 2.0 ADFS 2.0 ADFS 2.0 Proxy Load balancer Load balancer Internal Network Basic Authentication (Active Profile) Passive Federation (Passive Profile)
- 28. Number of users Minimum number of servers Fewer than 1,000 users 0 dedicated federation servers 0 dedicated federation server proxies 1 dedicated NLB server 1,000 to 15,000 users 2 dedicated federation servers 2 dedicated federation server proxies 15,000 to 60,000 users Between 3 and 5 dedicated federation servers At least 2 dedicated federation server proxies
- 35. Lync 2010/ Office Subscription Active Sync Corporate Boundary Exchange Online AD FS 2.0 Server MEX Web Active AD FS 2.0 Proxy MEX Web Active Outlook 2010/2007 IMAP/POP Username Password Username Password OWA Internal Lync 2010/ Office Subscription Outlook 2010/2007 IMAP/POP OWA External Username Password Active Sync Username Password Basic auth proposal: Pass client IP, protocol, device name
- 36. ` Client (joined to CorpNet) Authentication platformAD FS 2.0 Server Lync Online Active Directory Customer Microsoft Online Services Logon (SAML 1.1) Token UPN:user@contoso.com Source User ID: ABC123 Auth Token UPN:user@contoso.com Unique ID: 254729
- 37. Customer Microsoft Online Services ` Client (joined to CorpNet) Authentication platformAD FS 2.0 Proxy Exchange Online Active Directory Logon (SAML 1.1) Token UPN:user@contoso.com Source User ID: ABC123 Auth Token UPN:user@contoso.com Unique ID: 254729 Basic Auth Credentilas Username/Password
- 38. ` Client (joined to CorpNet) Authentication platformAD FS 2.0 Server Exchange Online or SharePoint Online Active Directory Customer Microsoft Online Services Logon (SAML 1.1) Token UPN:user@contoso.com Source User ID: ABC123 Auth Token UPN:user@contoso.com Unique ID: 254729
- 39. • Use Windows 2012 R2 • Co-locate ADFS on domain controllers (no IIS needed) • You don’t need SQL unless you are greater than 90K users! • Use self-signed token signing certificates. Deployment • Deploy Web Application Proxy. Current Outlook/EAS need this to work. • AAD uses federation metadata endpoint that is internet accessible to keep token signing cert information up to date. • Don’t use sticky sessions on your Load Balancer • Configure SNI on load balancer or use HTTP health probes (MS14-08) Network • Enable extranet soft account lockout • Enable MFA with smartcards, Azure MFA or 3rd party MFA (SafeNet, RSA, Gemalto, LoginPeople …) • Enable client access policies in the prescribed manner. Security • Ensure that SPN (HOST/adfs.contoso.com) is set on ADFS service account • Customize illustration & logo to have a great end user experience • Enable ‘Keep Me Signed In’ option for better SSO Sign-In Experience
Editor's Notes
- Password Sync is a feature of the Windows Azure Active Directory (WAAD) Synchronization tool (DirSync). DirSync extracts user password hashes from the on-premises AD and synchronizes them to WAAD in a similar synchronization path that is used for synchronizing other user data (i.e. DisplayName, Email Addresses, etc.). Password sync enables users to log into their WAAD services (such as Office 365, InTune, CRM Online, etc.) using the same username/password used to log into the on-premises AD. Password sync part of the DirSync tool, it is not PCNS, and unlike some other password tools, there is no need to install software on DCs or reboot DCs.
- Password sync is a good alternative to AD FS SSO, especially for small and medium business. However, it does not provide the same functionality. We will do a little compare and contrast in a later slide. Password sync is currently only supported for customers with a single AD forest.
- When synchronizing passwords using the password sync feature, the plain text version of a user’s password is neither exposed to the password sync tool nor to Azure AD or any of the associated services. There is no requirement on the on-premises Active Directory to store the password in a reversibly encrypted format. A digest of the on-premises AD password hash is used for the transmission between the on-premises AD and Azure Active Directory. The digest of the password hash cannot be used to access resources in the customer's on-premises environment. When using password sync, the password complexity policies configured in the on-premises Active Directory override any complexity policies that may be defined in the cloud for synchronized users. This means any password that is valid in the customer's on-premises AD environment can be used for accessing Azure AD services. Passwords for users that are created directly in the cloud are still subject to password policies as defined in the cloud. If a user is in the scope of the password sync feature, the cloud account password is set to "Never Expire". This means that it is possible for a user's password to expire in the on-premises environment, but they can continue to log into cloud services using this expired password. The cloud password will be updated the next time the user changes the password in the on-premises environment.
- These are the typical steps for deploying DirSync. This talk does not discuss each step in detail, but rather focuses on password sync related tasks in each step. See http://technet.microsoft.com/en-us/library/hh967642.aspx for the DirSync roadmap and more details on each deployment step.
- See troubleshooting guide for more details: http://support.microsoft.com/kb/2855271
- See troubleshooting guide for more details: http://support.microsoft.com/kb/2855271
- See troubleshooting guide for more details: http://support.microsoft.com/kb/2855271 These event log entries refer to users by their “anchor” (a.k.a immutableID) value. To determine the user, use Get-MsolUser –All | Where {$_.immutableID –match “<anchor value>”} Beyond the Event IDs highlighted here, many of the password sync errors are documented as Evend ID 611.
- Cloud Identity: triển khai trên Cloud, không cần On-premise Federated Identity: triển khai có liên quan tới On-Premise The type of identity affects the user experience and administrative requirements
- Cloud identity: small organization và không có on-premise Cloud Indentity + Dirsync: tổ chức nhỏ và vừa có On-premise, phải có DirSync Server để sync AD ở On-premise Federated Identity: tổ chức lớn cần SSO,SoA, Cần HA AD FS, phải có DirSync Server để sync AD ở On-premise
- Tóm lại việc định danh như sau: Có 2 loại trong mô hình triển khai định danh: Managed domain và federated domain Domain phải public không dùng local cho lab Dùng Online Portal và hoặc PowerShell để add domain của tổ chức vào
- Mô hình SSO dùng cho môi trường federated domain : người dùng truy cập on-premise hoặc dùng cloud trên 1 name duy nhất và chứng thực 1 lần thay vì phải nhiều lần
- Policy control (manage password policies, workstation restrictions, lock-out controls, and more, without having to perform additional tasks in the cloud) Access control Reduced support calls (Forgotten passwords are a common source of support calls in all companies. If users have fewer passwords to remember, they are less likely to forget them) Security (Do thông tin người dùng nằm ở on-premise - User identities and information are protected because all of the servers and services used in single sign-on are mastered and controlled on-premises.) Support for strong authentication You can use strong authentication (also called two-factor authentication) with Office 365. However, if you use strong authentication, you must use single sign-on. There are restrictions on the use of strong authentication. For more information, see Configuring Advanced Options for AD FS 2.0 ( http://technet.microsoft.com/en-us/library/hh237448(WS.10).aspx ).
- AD FS 2.0 or above must be installed on a domain controller (DC). AD FS proxy and AD FS server cannot be set up on the same machine
- http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652539.aspx#bk_plandeploy ADFS can be installed onto an existing application server Including a domain controller A load balancer should still be deployed in perimeter network in front of ADFS proxies (thus, a dedicated load balancer)
- Determine Your AD FS 2.0 Deployment Topology http://technet.microsoft.com/en-us/library/gg982491(WS.10).aspx The Role of the AD FS Configuration Database http://technet.microsoft.com/en-us/library/ee913581(WS.10).aspx
- Office 365 has 3 endpoints: Active Profile, Passive Profile, MEX Endpoints provide access to the federation server functionality of ADFS, such as token issuance, and the publishing of federation metadata. Depending on the type of endpoint, you can enable or disable the endpoint or control whether the endpoint is published to federation server proxies.
- Cách chứng thực vào
- DO NOT REMOVE – These are notes for the attendees 1. User log vào máy tính, chứng thực User log vào máy desktop thì dịch vụ Microsoft Online Service Sign In tự startup lên và lên AP để hỏi) Client lên AP để kiểm tra service xem có phải registed federated domain không, nếu có thì trả về Metadata Exchange Endpoint để xác nhận Nếu trả về MEX thì client phải lên AD FS để request SAML token AD FS sẽ tạo ra Kerberos ticket nhúng trong SAML Token và gửi lại cho client để dùng cái token lên AP để xác thực vào dịch vụ 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 user now starts up Outlook
- DO NOT REMOVE – These are notes for the attendees The user logs on to their client desktop machine on their corporate network. (User log vào máy tính) The Client starts Outlook on their Desktop Machine. (Mở outlook) gửi lên Exchange Online để yêu cầu chứng thực) Ssau đó gửi user + pass lên) Exchange online sẽ đi lên AP để hỏi xem cái này có phải nằm trong tên miền federated domain khai báo không, nếu có xác nhận cho Exchange Online Exchange Online qua AD FS Proxy để request token Sau khi AD FS Proxy liên hệ AD để chứng thực và tạo ra ticket Kerberos thì tích hợp vào token gửi lại cho Exchange Online Exchange Online lấy token đó lên AP để chứng thực lại bằng Kerberos + public key (sau đó cấp ID cho user và tạo 1 token mới gửi lại cho Exchange Online) Exchange Online mở lại và dùng userID đó gửi lại cho người dùng)
- DO NOT REMOVE – These are notes for the attendees User truy cập OWA Service nói user cần ticket trên AP mới cho vào Client lên AP để hỏi ticket, AP nói không biết và kêu User lên AD FS trong nội bộ để xin ticket Client lên AD FS để request ticket login bằng NTLM token hoặc vé Kerberos, chứa torng 1 file gọi là SAML token Client dùng SAML token lên AP để check xem có phải federated domain hay không), nếu đúng thì AP tạo lại 1 token Client lấy ticket lên exchange online để mở xài dịch vụ)
- No single sign-on experience: Each time the user attempts to access Office 365, he is prompted to supply a valid user name and password User is logged on at work: The enterprise AD authenticates the user so she has a valid claim token. When the user accesses Office 365, the Office 365 federation gateway willacknowledge the claim token and will not produce a logon promptservices Remote worker on a VPN: a user presents his logon credentials during the VPN session initialization. The credentials are passed to the corporate network. After authenticated, the user possesses a claims token, as in Scenario 2. At this point, if the user opens his email or accesses the corporate intranet that is hosted in Office 365, the situation will be the same as it is for the worker in Scenario 2 Remote worker is not logged on to the corporate network: The user attempts to log on using her User Principal Name (UPN) user name. Office 365 recognizes that the user is trying to log on with a UPN suffix belonging to a domain that is federated and thus redirects the user to the AD FS server, as shown in Figure 3-13. The federation server presents a logon window to obtain the user ’s credentials. The user successfully Enters her credentials and is issued a valid claim token.
- Lưu ý mô hình SSO là để chứng thực bên dưới ad lên office 365 Còn Hybrid Exchange là liên kết giữa exchange onpremise và exchange online cloud