User identity, Account Provisioning, Directory Synchronization, Federation
Workshop Purpose and Objectives Workshop Purpose Plan for user identity and provisioning, including discussion of Active Directory Domain Services (AD DS) cleanup, *configuration of identity federations, and planning for the installation and configuration of the Microsoft Online Services Directory Synchronization (DirSync) tool Objectives Establish approach for adding and provisioning users for the service Understand and plan for Office 365 licensing activation Understand and plan for steps required to enable Directory Synchronization *Outline identity federation requirements and provide approach 2 *Denotes optional Service Enhancement features
Common Identity Platform Windows Azure Active Directory (WAAD or Azure AD) is the underlying identity platform for various Organizational cloud services Windows Azure Active Directory Authentication platform Directory store 3
User Identity and Account Provisioning Planning Workshop Topics Current Provisioning and Deprovisioning process Review current identity lifecycle tools and process Provision Users and License Activation Active Directory Synchronization *Identity Federation Review options to provision and license users Review requirements and drive planning considerations to implement synchronization between on-premises AD DS and the Office 365 environment Review requirements to support single sign-on 4 *Denotes optional Service Enhancement features
Current Provisioning and Deprovisioning Process HR System Manual process or automated through feed What is the most common login identity (AD, LDAP, etc) Employee creation Mailbox creation Groups Contractors Terminated Mailbox retention Provisioning Deprovisioning Workshop participants and outcomes Participants Technical Leads (AD DS and Provisioning) Outcome Draft user provisioning and licensing approach 5
Provision Users and License Activation Differences between account provisioning and licensing Provisioning Options License Activation Workshop participants and outcomes Participants Technical Leads (AD DS and Provisioning) Outcome Draft user provisioning and licensing approach 6
Provisioning Options Option Directory Synchronization Windows PowerShell Bulk Import Microsoft Online Services Portal Considerations Synchronizes users from the customer s AD DS infrastructure to the Microsoft Online Services environment Synchronizes security and mail-enabled groups *Allows for onboarding and offboarding of users when Exchange hybrid deployment is configured *Provides the infrastructure necessary to support single sign-on Allows mass import of users via Windows PowerShell command line interface scripting Does not allow for single sign-on Allows for an import of a comma-separated values (CSV) file to mass populate users Does not allow for single sign-on Provides a simple web interface to add and modify user accounts Cannot be used to modify users if Directory Synchronization is enabled *In a federation scenario that enables single sign-on, Directory Synchronization is the only provisioning option User identities can be mastered on-premises Existing end-user provisioning capabilities that integrate with on-premises AD DS can be used with Office 365 7 *Denotes optional Service Enhancement features
Office 365 Management cmdlets Management categories Manage users Manage group and role memberships Manage service principals Manage domains *Manage single-sign on Manage subscriptions and licenses Manage company information and service Manage Microsoft Exchange Online Description Used to perform a variety of tasks related to managing users, passwords, and user principal names (UPN). Used to perform a variety of tasks related to group and role membership, including adding a user to a role or group, creating groups, and removing groups. Used to perform a variety of tasks related to service principals. Used to perform a variety of domain management tasks, including creating or removing a domain. Used to perform tasks related to single sign-on, such as adding a new single sign-on domain to Office 365. Used to manage subscriptions, accounts, and licenses. Used to perform tasks related to managing your company s information and connecting to Office 365 for enterprises. There are also cmdlets for tasks performed by partner companies. Used to perform management tasks that are not available nor practical in the Exchange Administration Console (EAC). 8 *Denotes optional Service Enhancement features
Provisioning Gotchas DirSync must sync the objects to Office 365 before a license can be assigned Provisioning requires several steps in order to get a new user up and running in Office 365 Users should only be licensed for what customer is ready to support. SharePoint, Lync, OneDrive, Office Pro Plus may not be ready for consumption EAS, POP3, IMAP are all on by default when a mailbox is provisioned. Powershell would need to be run to turn these off as the mailbox is created Workshop participants and outcomes Participants Technical Leads (AD DS and Security) Microsoft has some sample scripts that can help provision users based on group membership Outcome Document plan to support single-sign and overall AD FS implementation approach. 9
Active Directory Synchronization Review requirements to drive planning considerations to implement synchronization between the on-premises AD DS and the Office 365 environment Directory Synchronization Overview Source of Authority AD DS Preparation *Multi-forest Deployment Considerations Workshop participants and outcomes Participants Technical Leads (AD DS and Network) Two-way Synchronization (write-back) Password Sync Outcome Document plan to modify Domain Controller infrastructure to support Office 365 requirements, implement Direct Synchronization appliance, and clean up required AD DS attributes 10 *Denotes optional Service Enhancement features
Directory Synchronization Overview Required permissions for installation Enterprise Administrator rights during the installation process. Nonprivileged AD DS account is required post-installation (this account is automatically created during installation). Review planning considerations for installation of the Directory Synchronization tool AD DS object considerations If a domain is verified on the tenant, by default, it will be possible to synchronize up to 300,000 AD objects (if no domain validated, no more than 50,000 objects). To sync more objects, the Office 365 support team will need to be contacted to open a service request with the number of objects to synchronize. Capacity planning For object count greater than 50,000, Microsoft SQL Server 2008 R2 or higher is required and can be installed on the same server as Dirsync. Follow-up actions and additional information from prior assessments Service Enablement Plan Considerations Review AD DS object count to be synchronized, and draft Directory Synchronization installation plan accordingly [List specific issues uncovered or context from prior assessments] 11
Directory Synchronization Hardware Requirements Active Directory Objects CPU Memory Hard Disk Full SQL Required? Less than 10,000 1.6 GHz 4 GB 70 GB No 10,000 50,000 1.6 GHz 4 GB 70 GB No 50,000 100,000 1.6 GHz 16 GB 100 GB Yes 100,000 300,000 1.6 GHz 16 GB 300 GB Yes 300,000 600,000 1.6 GHz 32 GB 450 GB Yes More than 600,000 1.6 GHz 32 GB 500 GB Yes This table includes SQL sizing if SQL is installed on same box than Dirsync (50.000 AD objects and more) If SQL is deployed on a dedicated server, use these numbers for SQL and size an additional server for DirSync with 2 cores, 4GB RAM and 72 GB disk 12
Source of Authority Office 365 requires a single source of authority for every object. Three scenarios exist for where source of authority is changed for an object. Activate: When you activate Directory Synchronization and then synchronize directories, the source of authority for any cloud object that is matched to an on-premises object is transferred from the cloud to your on-premises AD DS. Deactivate: When you deactivate Directory Synchronization, the source of authority is transferred from the on-premises AD DS to the cloud. Reactivate: When you reactivate Directory Synchronization, the source of authority is transferred from the cloud back to your onpremises AD DS (where it previously resided). Follow-up actions and additional information from prior assessments Service Enablement Plan Considerations Review concept of "source of authority" and the three scenarios it applies to (active, deactivate, reactivate). Review steps to ensure minimal directory data loss in the reactivate scenario by reviewing the globally unique identifier (GUID) and Simple Mail Transfer Protocol (SMTP) match logic. (online resource) [List specific issues uncovered or context from prior assessments] 13
Active Directory Preparation Review tasks needed to address remediation efforts. Outline plan for addressing all directory object preparation activities. Verify each user planning to use Office 365 has a valid and unique email address Remove duplicate values in the ProxyAddress attribute field and UserPrincipalName that exists in the forest Populate the following username attributes: First name Last name Display name Directory object preparation Use IDFix to remediate AD Follow-up actions and additional information from prior assessments Service Enablement Plan Considerations Review the state of the on-premises AD DS from previous assessments. Document remediation steps prior to first synchronization. [List specific issues uncovered or context from prior assessments] 14
Directory Object Preparation Guidance 15 Maximum number of characters: 20 Invalid characters:!#\$%\^&\{\}\\{`~"",\\/\[\]:@<>\+=;\?\* Note: If a user has an invalid samaccountname but a valid userprincipalname, the user account is created in Office 365. Note: If both the samaccountname and userprincipalname are invalid, the on-premises AD DS userprincipalname must be updated. samaccountname Maximum number of characters: 256 Invalid characters: [! #$ %&*+ / =? ^ ` { }] The mail attribute cannot contain any duplicate values. Note: If there are duplicate values, the first user with the value is synchronized. Subsequent users will not appear in the Microsoft Online Services Portal. You must modify the value not found the in portal, or modify both of the values in the on-premises directory in order for both users to appear in the Office 365 service. mail For mail-enabled objects and alternate addresses, the targetaddress attribute is required. This is especially true in third-party messaging migration and coexistence scenarios. If the targetaddress attribute is not present, the fallback is to the mail attribute. Maximum number of characters: 256 Invalid characters: [! #$ %&*+ / =? ^ ` { }] targetaddress Maximum number of characters: 64 Questionable characters:?@\+ givename sn (surname) Maximum number of characters: 64 Invalid characters: ""\\\[\]:><; and space mailnickname userprincipalname Maximum number of characters: 256 Questionable characters:?@\+ displayname Maximum number of characters: 256 Invalid characters: \)\(;><\]\[\\, Multi-value attribute proxyaddresses Maximum number of characters for username: 64 Maximum number of characters for domain name: 256 Invalid characters: }{ # * + ) ( > < / \ =? ` & character: Automatically changed to underscore: (_) @ character is required in each userprincipalname value. @ character cannot be first character in each value. Username cannot end with a period (.), an ampersand (&), a space ( ), or an at sign (@). Username cannot have a space ( ). Routable domains must be used. Unicode is converted to underscore characters. userprincipalname may not contain any duplicate values in the forest. Note: Before making changes to the attribute it is critical to validate that there are no applications dependent on the existing value such as smart cards, certificates, Unix, or Linux.
*Multi-forest Deployment Considerations Review options for a multi-forest AD DS implementation, including forest consolidation or a primary logon forest. Evaluate consolidation - In general, there is more overhead required to maintain multiple forests. Unless the organization has security constraints that dictate the need for separate forests, consider simplifying the on-premises environment prior to deploying Office 365. Required Multiforest Synchronization- Dirsync appliance cannot be used, required Office 365 supported MA Additional multi-forest options can be provided through FIM-based solutions in place of the standard Directory Synchronization software appliance. Follow-up actions and additional information from prior assessments Remediation Checklist Review if multi-forest scenario is applicable. Document remediation steps prior to first synchronization. Considerations [List specific issues uncovered or context from prior assessments] 16 *Denotes optional Service Enhancement features
Two-Way Synchronization (write-back aka Hybrid) Two-way synchronization (or write-back) is required for Office 365 features and functionality such as cloud-based archiving, safe and blocked senders configuration, and cloud voice mail Filtering coexistence Enables two-way synchronization onpremises filtering and online safe and blocked sender data from clients MSExchBlockedSendersHash, SExchSafeRecipientsHash, MSExchSafeSendersHash Online archive Allows archiving of mail in Office 365 MSExchArchiveStatus Mailbox offboarding Allows online mailboxes to move back on-premises ProxyAddresses *Enabled Unified Messaging online voice mail Indicates to Lync communications software when user has a voice mail in Office 365 MSExchUCVoiceMailSettings Delegates Allows delegation of a user s mailbox Follow-up actions and additional information from prior assessments Service Enablement Plan Considerations Review business requirements to determine if two-way synchronization is to be enabled. Document steps to support the appropriate features outlined. [List specific issues uncovered or context from prior assessments] 17 *Denotes optional Service Enhancement features
Core identity scenarios with Office 365 Cloud identity Cloud identity with directory & password synchronization Federated identity ADFS Federated identity 3 rd Party IDM Single cloud identity Single identity but separate credentials suitable for medium and large organizations Single identity utilizing AD credentials & password. Required for MFA and access controlled environments Single identity utilizing AD credentials & password. Required for MFA and access controlled environments
Identity federation Review requirements to enable single sign-on. Identify tasks required to enable in-scope scenarios covering user experience and align customer s AD DS implementation for federation. Identity Federation Requirements Infrastructure Design Workshop participants and outcomes Participants Technical Leads (AD DS and Security) User Experience by Location Namespace Considerations and Acceptable Domains Virtualization and Capacity Planning Outcome Document plan to support single-sign and overall AD FS implementation approach. 19
DirSync with Password Sync Description Not Single Sign On (SSO), but user experience nearly identical to ADFS, password cached for Outlook and Lync Substantially less complex, less hardware, networking, and only a single server to monitor Password is synched to cloud, Microsoft becomes responsible for login Password can be used across cloud properties No longer need to route any traffic back on premises like ADFS Password Changes/Deactiveated users are high priority and force a sync Concerns Security concerns, we sync the hash, we reverse the hash and we obfuscate it beyond that Account lockouts not replicated to cloud, DirSync syncs Account Disabled Password expiry on-premises will not result in password expiry in the cloud No auditing logs for logins Limited two factor (2FA) authentication coming soon Requires customer Portal to change passwords No High Availability, but not critical in current form No way to control access via ADFS claims 20
3 rd Party IDM Description Not all 3 rd party IDM s are equally integrated Not a formal logo program Some 3 rd parties entering this space without a formal relationship with Office 365 Product Group Concerns Active (Outlook, Lync) vs Passive (OWA) applications Some have issues with remapping UPN and cause AUTOD issues Others have issues with multiple federated namespaces Not true SAML, uses WSFED in many cases 21
Identity Federation Requirements User Principal Name (UPN) available in AD since Windows 2000, it is not tied to Sam Account Name UPN Required! Workshop participants and outcomes Participants Technical Leads (AD DS and Security) Office 365 leverages email domains to uniquely identify customers in multi-tenant environment UPN = eadams@contoso.local SAM Account = contoso\eadams SMTP =ellen.adams@contoso.com Message to Users: Users can now login to everything with their email addresses! (Office 365, Windows, Applications ) Outcome Document plan to support single-sign and overall AD FS implementation approach. 22
Identity federation requirements Single Active Directory forest The onpremises infrastructure must meet the following requirements to implement AD FS. AD FS deployed on Windows 2008 R2 Server or higher Supported client operating system and service packs Unique third-party SSL certificate for AD FS proxy server to allow: Remote workers to access the service without a virtual private network (VPN) For ActiveSync devices Outlook clients running on Windows XP or Windows Vista, or any version of Windows XP, Windows Vista, and Windows 7, where NEGO2 (Nego2 HTTP Authentication Protocol) is not implemented For IMAP clients For POP clients Windows PowerShell 2.0 to provide remote access to the AD FS server Follow-up actions and additional information from prior assessments Service Enablement Plan Considerations Review requirements to support identity federation. Capture necessary actions to be taken in the Prepare phase to support identity federation. [List specific issues uncovered or context from prior assessments] 23
User experiences A user s experience with single sign-on varies, based on how the user s computer is connected to the organization s network and how an administrator has configured AD FS. Sample configurations are as follows: Work computer on a corporate network. When users are at work and signed into the corporate network, single sign-on allows them to access the services in Office 365 with their corporate credentials. Roaming with a work computer. For users who are logged onto domain-joined computers with their corporate credentials, but who are not connected to the corporate network (for example, a work computer at home or at a hotel), single sign-on allows them to access the services in the Office 365. Home or public computer. When the user is using a computer that is not joined to the corporate domain, the user must sign in with corporate credentials to access the services in the Office 365 suite. AD FS federation server proxies are required in this scenario. Non domain-joined computer on a corporate network. This configuration is similar to the one previously described, except that AD FS federation server proxies are not required in this scenario. Follow-up actions and additional information from prior assessments Service Enablement Plan Considerations Review user experiences that are deemed required, and plan AD FS design accordingly. [List specific issues uncovered or context from prior assessments] 24
Virtualization and capacity planning Capacity planning for AD FS is the process of forecasting peak usage periods and planning or scaling-up the AD FS server deployment to meet those load requirements. AD FS supports software virtualization of both the federation server and federation-server proxy roles. To account for redundancy, Microsoft recommends that each AD FS virtual machine be stored on a separate physical virtual server. Number of users Suggested hardware configuration For additional AD FS capacity planning guidance, please refer to Planning for AD FS Server Capacity. Fewer than 1,000 No dedicated federation server proxies. Two dedicated load-balanced AD FS servers. 1,000 to 15,000 Two dedicated federation server proxies. 15,000 to 60,000 At least two dedicated federation server proxies. More than 60,000 Use the AD FS Capacity Planning Spreadsheet. Follow-up actions and additional information from prior assessments Service Enablement Plan Considerations Review anticipated user count for AD FS capacity planning. Document anticipated hardware needs or virtualization approach, if necessary. [List specific issues uncovered or context from prior assessments] 25
Office 365 identity-federation standard design The Office 365 identity-federation standard design represents a baseline implementation for providing the single sign-on experience. Outlines the standard design from Microsoft Services for establishing identity federation with Office 365. The provided architecture does not represent the only available option but, instead, the standard design that Microsoft Services recommends and implements. Specific requirements or constraints that are not satisfied within the standard design should be discussed and addressed. Out of scope for the standard design: Office 365 cloud identities that are used for authentication (user identities that are managed fully in the cloud without integration with on-premises AD DS) Operations guidance to run the identity federation and Directory Synchronization infrastructure Advanced requirements that would require custom design, such as: Multiple forest topologies Strong authentication or two-factor authentication Geo-redundancy support for federation services Follow-up actions and additional information from prior assessments Service Enablement Plan Considerations Review the Office 365 identity federation standard design documentation, and validate it with the existing enterprise requirements for single sign-on. [List specific issues uncovered or context from prior assessments] 26
Standard design logical view AD FS is the logical component that implements the federation standards required to configure identity federation between the on-premises Active Directory forest and Office 365. Directory Synchronization for Office 365 performs synchronization of AD DS objects (users, groups, and contacts) from one on-premises AD DS into one Office 365 tenant directory. Windows Azure Active Directory represents the multi-tenant directory service in the cloud. Office 365 Authentication Platform represents the authentication platform that constitutes the relying party for the federation with the onpremises Active Directory forest. Office 365 Provisioning Web Service exposes a web service interface used by on-premises Directory Synchronization to synchronize data with the Microsoft Online Directory Services. Client components use three different authentication flows in federated identity scenarios, based on the type of client: The active profile is used with Microsoft Outlook and Exchange ActiveSync devices. The metadata exchange (MEX) is used with Microsoft Lync and the Office Pro Plus Subscription Agent. The passive profile is used with web browsers and other Office applications such as Microsoft Word, Excel, and PowerPoint. 27
Standard design physical view Active Directory Federation Server is a specific role service of AD FS, designed to implement the federation protocols, to define and manage relying parties, and to provide tokens in response to requestors. Active Directory Federation Proxy or Application Proxy is a specific role service of AD FS, designed to publish the AD FS on the Internet, for federation relationships involving external relying parties. Directory Synchronization Server continuously synchronizes the Active Directory forest onpremises with Office 365. Domain Name System (DNS): The Office 365 identity federation standard design prescribes a split-dns design for the AD FS internal and external load balanced endpoints. This essentially means that the same external fully qualified domain name (FQDN) (typically sts.contoso.com) must be resolved differently for internal and external resolvers. Internal clients (internal DNS) must resolve the AD FS external FQDN to the load balanced end point of the internal AD FS federation servers. External resolvers (public DNS) must resolve the AD FS external FQDN to the load balanced end point of the AD FS proxy servers. 28 Additional AD FS proxy considerations and a list of required ports and protocols are provided in the Office 365 Identity Federation Standard Design documentation.
Understanding client authentication path OWA Internal AD FS 2.0 Server MEX Web Active Outlook 2013 IMAP/POP AD FS 2.0 Proxy MEX Web Active Lync 2013/ Office Subscription Active Sync Username Password Basic auth proposal: Pass client IP, protocol, device name Corporate Boundary Username Password Lync 2013/ Office Subscription Exchange Online Username Password OWA External Active Sync Username Password Outlook 2013 IMAP/POP
Identity federation Authentication flow (passive/web profile) Customer Microsoft Online Services Active Directory AD FS 2.0 Server Logon (SAML 1.1) Token UPN:user@contoso.com Source User ID: ABC123 Authentication platform Auth Token UPN:user@contoso.com Unique ID: 254729 ` Client (joined to CorpNet) Exchange Online or SharePoint Online
Identity federation Authentication flow (MEX/rich client profile) Customer Microsoft Online Services Active Directory AD FS 2.0 Server Logon (SAML 1.1) Token UPN:user@contoso.com Source User ID: ABC123 Authentication platform Auth Token UPN:user@contoso.com Unique ID: 254729 ` Client (joined to CorpNet) Lync Online
Identity federation Active flow (Outlook/Active Sync) always external Customer Microsoft Online Services Active Directory AD FS Logon (SAML 1.1) Token UPN:user@contoso.com Source User ID: ABC123 Authentication platform AD FS Proxy Auth Token UPN:user@contoso.com Unique ID: 254729 ` Client (joined to CorpNet) Basic Auth Credentilas Username/Password Exchange Online
Namespace considerations and acceptable domains Support for multiple top domains is available within AD FS AD FS has an update rollup that works in conjunction with SupportMultipleDomain switch to support multiple top-level domains for UPN suffixes. Note: the SupportMultipleDomain switch is not required when you have a single top-level domain and multiple subdomains. Only routable domains can be used with an AD FS deployment. Examples of nonroutable domains are the following:.local.loc.internal Follow-up actions and additional information from prior assessments Service Enablement Plan Considerations Review whether multiple namespaces are in use, and determine whether the SupportMultipleDomain AD FS switch is needed. Review whether the UPN suffix is required for instances in which the customer has implemented AD DS with an internal namespace. [List specific issues uncovered or context from prior assessments] 33
Client access control AD FS 2.0 Server AD FS 2.0 Proxy Passiv e Active Passiv e Active Browser Internal Browser External Web Auth (OWA, SharePoint) Outlook and ActiveSync Auth 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 Outlook 2010/2007 ActiveSync ActiveSync Outlook 2010/2007
Identity federation Recap and next steps Provision Users and License Activation Active Directory Synchronization Identity Federation Complete planning for: Federation design for user experience requirements. AD FS infrastructure design (validate if Standard Design will meet requirements). Namespace and domains for federated identities. Service Enablement plan to be completed for Assess phase completion checkpoint (mmm/dd). 35
Questions? 2013 Microsoft Corporation. All rights reserved. Microsoft, Access database software, Active Directory directory service, ActiveSync technology, ActiveX controls, Excel spreadsheet software, InfoPath information gathering program, Internet Explorer Internet browser, Lync communications software, Office 365 hosted productivity software, OneNote note-taking program, Outlook 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or messaging and collaboration client, PowerPoint presentation software, RoundTable communications and archival system, SharePoint services, SQL Server software, Windows operating system, 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 Windows Azure technology platform, Windows Intune software and services, Windows Server operating system, and Windows Vista operating system and other product names are or may be 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 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 after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION 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