2013 Microsoft Corporation. All rights reserved. Abstract This document is intended for system architects and IT professionals who want to understand the architecture and deployment options for extending the on premises Active Directory infrastructure with Windows Azure Virtual Machines to implement directory synchronization and single sign-on for Office 365.
This document is provided as-is. Information and views expressed in this document, including URL and other Internet website references, may change without notice. You bear the risk of using it. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. You may modify this document for your internal, reference purposes. 2013 Microsoft Corporation. All rights reserved. Microsoft, Active Directory, Office 365, SharePoint, SQL Azure, SQL Server, Windows, Windows Azure, and Windows Server are trademarks of the Microsoft group of companies. All other trademarks are the property of their respective owners.
Contents
1 2 3 EXECUTIVE SUMMARY .................................................................................................................. 5 INTRODUCTION ............................................................................................................................. 6 DEPLOYMENT SCENARIOS ........................................................................................................... 7 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 5 6 7 INTRODUCTION ................................................................................................................................................... 7 BEFORE YOU STARTIS THIS RIGHT FOR YOUR ORGANIZATION? .................................................................... 7 WINDOWS AZURE ACTIVE DIRECTORY............................................................................................................. 8 HIGH-LEVEL DESIGN CONSIDERATIONS ............................................................................................................ 9 SCENARIO 1: OFFICE 365 DIRECTORY INTEGRATION COMPONENTS DEPLOYED ON-PREMISES .............. 11 SCENARIO 2: OFFICE 365 DIRECTORY INTEGRATION COMPONENTS DEPLOYED IN WINDOWS AZURE . 13 SCENARIO 3: OFFICE 365 DIRECTORY INTEGRATION COMPONENTS DEPLOYED IN WINDOWS AZURE FOR CHECKPOINT: KEY REQUIREMENTS.................................................................................................................. 20 RISKS AND MITIGATIONS ................................................................................................................................. 22 COSTS ASSOCIATED WITH WINDOWS AZURE ............................................................................................... 25 VIRTUAL MACHINE OPERATING SYSTEM REQUIREMENTS ............................................................................ 25 VIRTUAL MACHINE SIZING .............................................................................................................................. 26 VPN NETWORK REQUIREMENTS ..................................................................................................................... 27 IP ADDRESSING AND NAME RESOLUTION ..................................................................................................... 27 ACTIVE DIRECTORY DOMAIN SERVICES ......................................................................................................... 28 DIRECTORY SYNCHRONIZATION SERVER ........................................................................................................ 29 DEPLOYMENT TO MULTIPLE WINDOWS AZURE DATA CENTERS .................................................................. 30
OPERATIONAL CONSIDERATIONS ............................................................................................ 33 CONCLUSION ................................................................................................................................ 34 APPENDIX ..................................................................................................................................... 35 7.1 7.2 GLOSSARY ......................................................................................................................................................... 35 WINDOWS AZURE SERVICE REFERENCES ....................................................................................................... 36
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
1 Executive Summary
Enterprise customers who adopt Office 365 often want to minimize their on-premises infrastructure requirements. Many enterprise customers want to utilize single sign-on (SSO) (http://technet.microsoft.com/enus/library/hh852486.aspx) through Active Directory Federation Services (AD FS) and the Windows Azure Active Directory Synchronization Tool. These technologies allow users to access the Office 365 service with their existing Active Directory credentials (user name and password). Traditionally, enabling SSO requires deploying servers and services on-premises. With the introduction of Windows Azure Virtual Machines, customers who require Active Directory federation have another Microsoft-supported choice for hosting these services. Running infrastructure components in Windows Azure has multiple benefits that include: Cloud strategy. Better aligns with your cloud strategy, helping to reduce on-premises hardware investments. Potential for reduced cost for hardware and software. Includes the potential to expand the conversion from capital expenditures to operational expenditures for the infrastructure services that are supporting your Office 365 deployment. You wont have to purchase additional servers and run them in your data centers or from a remote location. Rapid deployment. Infrastructure components can be deployed in a relatively short time, requiring little to no additional on-premises hardware resources. Improved business continuity. Federated users can continue to sign in to Office 365, even when the on-premises environment is temporarily unavailable. Scalability on-demand. If you require expansion or changes to your directory integration in the future, Windows Azure gives you the flexibility to make these changes rapidly, without additional on-premises investments. Site resiliency and disaster recovery. Possible scenarios include disaster recovery where Windows Azure is hosting redundant critical services for your infrastructure. This enables a failover in case theres an on-premises disaster. Flexibility. Components may be relocated, load-balanced, and distributed across multiple geographic regions. This reduces dependency on the corporate network.
Integrating Office 365 with your existing on-premises platforms requires careful planning, regardless of whether theyre implemented on-premises or in Windows Azure. Planning the implementation and management of these infrastructure components in the cloud is almost identical to the on-premises infrastructure. Well provide insights into the best implementation practices, an analysis of the advantages and disadvantages of the new Windows Azure solutions that are available, and a comparison to onpremises implementations. In some cases, Windows Azure will be the appropriate choice.
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
2 Introduction
Integrating an Office 365 deployment with existing services by using directory synchronization and SSO has in the past required an investment in on-premises hardware. This adds both time and cost to deployments that include this level of integration. For SSO, Office 365 requires the following core components: Active Directory Domain Services (AD DS) Active Directory Federation Services (AD FS) Directory synchronization services
We refer to these core components collectively as Office 365 directory integration components . To learn about these components, see Prepare for Single Sign On (http://technet.microsoft.com/enus/library/jj151786.aspx). In the past, weve recommended that customers host these components in one or more data centers alongside the existing Active Directory components that are often already deployed. With the release of Virtual Machines, you now have the option to deploy some or all these components in the cloud. Well guide you through the solution, potential benefits, requirements, and high-level planning tasks. Well focus exclusively on Office 365 infrastructure components that are required to support SSO with Office 365. Note Exchange Server roles that are used to support the Exchange hybrid mode arent supported on Virtual Machines. Weve intentionally excluded them from this document. The following are outside the scope of this document: Hosting Exchange services on Virtual Machines. Deployment of production Exchange servers on Virtual Machines is not supported. Shibboleth or other third-party SSO implementations. Windows Azure Active Directory and Office 365 support several security token services, including AD FS, Shibboleth Identity Provider (http://technet.microsoft.com/en-us/library/jj205456.aspx), and other third-party providers (http://technet.microsoft.com/en-us/library/jj679342.aspx). While it may be feasible to deploy Shibboleth or other third-party providers on Virtual Machines, these providers havent been tested by Microsoft and are outside the scope of this document. Multifactor or strong authentication. AD FS can be configured to enable a multifactor authentication scenario. While it may be feasible, its outside the scope of this document. Supportability should be validated through the third-party vendors. Multiforest topologies. The Windows Azure Active Directory Sync Tool supports only singleforest topologies. Consequently, multiforest topologies are outside the scope of this document. Deployment over multiple Windows Azure data centers. Its possible to deploy services beyond a single set of Windows Azure fault domains. This allows components to be deployed into multiple geographic regions. In some situations, this may improve authentication performance or increase the overall availability of the solution. Deploying directory integration services to a single Windows Azure data center will be sufficient for most Office 365 customers.
6
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
3 Deployment Scenarios
3.1 Introduction
When you deploy all the Office 365 federation components on Virtual Machines, you get some advantages over an on-premises deployment. These advantages include rapid implementation, predictable costs, and no additional on-premises servers being required. Alternatively, you can host a subset of the federation components in Windows Azure while deploying some components on-premises. Although additional options are possible, there are three optimal deployment scenarios: Scenario 1: All Office 365 SSO integration components deployed on-premises. This is the traditional approach; you deploy directory synchronization and AD FS by using on-premises servers. Scenario 2: All Office 365 SSO integration components deployed in Windows Azure. This is the new-cloud-only approach; you deploy directory synchronization and AD FS in Windows Azure. This eliminates the need to deploy on-premises servers. Scenario 3: Some Office 365 SSO integration components deployed in Windows Azure for disaster recovery. This is the mix of on-premises- and cloud-deployed components; you deploy directory synchronization and AD FS, primarily on-premises and add redundant components in Windows Azure for disaster recovery.
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure For more information about Office 365 user account types and to get a detailed description of cloud identities versus federated identities, see Office 365 User Account Management (http://technet.microsoft.com/en-us/library/jj819300.aspx). What business problems are you trying to solve? Deploying directory synchronization and AD FS components to Office 365 on Virtual Machines has a number of benefits. However, this deployment may add complexity to your infrastructure and may require additional expertise. You should consider deploying Office 365 directory integration components on Virtual Machines if its justified only by an actual business requirement. This justification may be to better align with your cloud strategy to avoid further on-premises hardware investments or as a necessary mitigation for an unreliable on-premises infrastructure. Are you comfortable with the requirements? There are several technical requirements that apply to the deployment of Office 365 directory integration components on Virtual Machines, as well as possible security implications. Use this document to help you thoroughly assess the effect on your infrastructure before you deploy Office 365 directory integration components on Virtual Machines. Note As you consider the possibility of deploying Virtual Machines to support your requirements, you should always consider the advantages and drawbacks of this model against the cloud identity model, which is where identities are stored in Windows Azure AD. When using cloud identities, AD FS isnt required, and dramatically simplifies your deployment.
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
Windows Azure supports virtual private networks (VPNs) by utilizing a Windows Azure Virtual Network (http://www.windowsazure.com/en-us/home/features/networking/). Virtual Network lets you provision and manage VPNs in Windows Azure as well as securely link to onpremises IT infrastructure. With Virtual Network, IT administrators can extend on-premises networks into the cloud with control over network topology, including configuration of DNS and IP address ranges for Virtual Machines.
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
Figure 1. Two availability sets with two Virtual Machines in each set For more information about Windows Azure fault domains and availability sets, see Manage Virtual Machine Availability (http://www.windowsazure.com/en-us/manage/windows/common-tasks/managevm-availability/). Separating the redundant servers for each component as previously described works for all the components discussed except the Windows Azure Directory Sync Tool. It doesnt support server redundancy. In the event of a virtual server failure, recovery steps may be needed. These steps are essentially the same for on-premises and cloud deployments of the tool. If the Windows Azure Directory Sync Tool temporarily stops working, directory synchronization resumes where it left off when the tool is working again. Should the server fail completely, directory synchronization wont resume until the Windows Azure Directory Sync Tool is reinstalled on a new virtual server.
10
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
AD FS Proxy
AD FS Proxy
Active Directory
AD FS
Directory Synchronization
AD FS
11
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure In the topology thats shown in Figure 2, customers deploy and operate Office 365 directory integration components on-premises. The on-premises AD FS infrastructure is published to the Internet through Federation Services proxies on the customers perimeter network. This topology includes the Office 365 directory integration components as shown in the following table. Component Directory synchronization server AD FS servers Federation Service proxy Quantity 1 2 or more 2 or more Location Customer corporate network Customer corporate network Customer perimeter network
We recommend at least two servers for all components that support redundancy as shown in the previous table. Your server capacity requirements may require additional virtual servers. For details, see AD FS capacity planning guidance (http://technet.microsoft.com/enus/library/gg749899(v=ws.10).aspx).
Planning recommendations and deployment considerations for directory synchronization and SSO are provided on TechNet: Directory integration documentation (http://technet.microsoft.com/enus/library/jj151781.aspx) Office 365 Deployment Guide: Deploy Single Sign On (http://technet.microsoft.com/enus/library/hh689731.aspx)
An in-depth whitepaper is also available here: Office 365 Single Sign-On with AD FS 2.0 whitepaper (http://www.microsoft.com/en-us/download/details.aspx?id=28971).
12
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
3.6 Scenario 2: Office 365 directory integration components deployed in Windows Azure
Deploying Office 365 directory integration components in Windows Azure is the secondary deployment scenario. The effect on the existing on-premises infrastructure is minimal. But the deployment of the directory integration components is faster due to the ability to deploy Virtual Machines on-demand. This option allows you to effectively support Office 365 federated identities without adding hardware to your on-premises infrastructure. We recommend this scenario for customers who want directory integration and need the agility of deploying these components online. Customers must also be able to manage the integration of Windows Azure with their existing environment.
13
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure Figure 3 shows the high-level architecture for this option.
VPN
Active Directory
Directory synchronization
AD FS
AD FS
AD FS Proxy
DATA CENTER 1
VPN Tunnel
Active Directory
VPN
14
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure In the topology shown in Figure 3, customers deploy and operate Office 365 directory integration components on Virtual Machines. AD FS is published to the Internet through AD FS proxies in Windows Azure. Client authentication traffic, for users that are connecting from any location, is handled by AD FS servers and proxies that are deployed on Windows Azure. This topology includes the Office 365 directory integration components as shown in the following table.
Component Active Directory domain controllers Quantity 2 per Active Directory domain 1 2 or more 2 or more 1 or 2 Location Windows Azure
We recommend at least two servers for all the components that support redundancy as shown in the previous table. Your server capacity demand may require additional virtual servers. For detail, see AD FS capacity planning (http://technet.microsoft.com/en-us/library/gg749899(v=ws.10).aspx). Note If your forest contains multiple domains, you need to deploy at least one domain controller for each domain into Windows Azure to ensure uninterrupted access to the service. For redundancy reasons, we recommend a pair of domain controllers for each Active Directory domain. This also reduces the authentication traffic traversing the VPN tunnel. We strongly recommend that you configure Federation Services so that internal users access the external AD FS proxy endpoints instead of internal AD FS endpoints. Using only external endpoints removes the VPN connection as a single point of failure for internal user authentication to Office 365. Using only external endpoints also means that additional authentication prompts may occur for users because AD FS treats all authentication requests as coming from users on the Internet. The alternative to the recommended approach above is to direct internal AD FS traffic over the VPN either directly or through the use of a DNS record or virtual IP. This removes the additional authentication prompts; however, its not the approach we recommend because it introduces the VPN as a single point of failure in the authentication path. Using a DNS record or virtual IP would allow quick remediation if VPN was unavailable. For more information about services failover in the event that VPN is unavailable, see scenario 3.
15
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
3.7 Scenario 3: Office 365 directory integration components deployed in Windows Azure for disaster recovery
Deploying Office 365 directory integration components across the on-premises environment and Windows Azure is the tertiary deployment scenario. AD FS and directory synchronization software are added to the existing on-premises infrastructure as well as being extended to Windows Azure. This option uses your on-premises environment for active use and Windows Azure for business continuity. Combined, they provide a redundant infrastructure for Office 365 directory integration services. We recommend this scenario for customers who want directory integration with their on-premises environment and desire a disaster recovery capability in the event their on-premises environment is unavailable.
16
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure Figure 4 shows the high-level architecture for scenario 3.
VPN
Active DIrectory
Directory synchronization
AD FS
AD FS
AD FS Proxy
VPN Tunnel
AD FS Proxy AD FS Proxy AD FS
AD FS
VPN
17
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure In the topology shown in Figure 4, customers deploy and operate Office 365 directory integration components on-premises and on Virtual Machines for redundancy. This topology includes the Office 365 directory integration components as shown in the following table. Component Directory synchronization server AD FS servers FSP Active Directory domain controllers Quantity 1 2 or more 2 or more 2 per Active Direction domain 1 2 or more 2 or more 1 or 2 Location Customer corporate network Customer corporate network Customer perimeter network Windows Azure
We recommend at least two servers for all components that support redundancy as shown in the previous table. Your specific server capacity demand may require additional virtual servers. For details, see AD FS capacity planning (http://technet.microsoft.com/library/gg749899(v=ws.10).aspx).
While your existing VPN connections and data centers are online and the directory integration components are functioning, directory synchronization is managed on-premises and authentication traffic takes place only through on-premises components. In case of a disaster, the failover between the on-premises infrastructure and the hosted infrastructure is a manual operation. The failover procedures for Federation Services and directory synchronization are different. At a high level, these procedures include: Federation Services failover. Requires DNS changes. Until the change is effective and DNS records are propagated, clients are affected and cant access Office 365 services. End-users still experience a downtime during the failover. Directory synchronization failover. Requires the re-installation of the Windows Azure Active Directory Sync Tool on a standby Virtual Machine. Because directory replication is required only for directory object changes, existing users can continue to use the service with little to no disruption until the service is restored.
While customers may consider setting up a cross-premises, high-availability (active/active) configuration, we dont recommend such topology for the following reasons: There is a one-to-one relationship between an Active Directory forest and the Office 365 tenant. Only a single instance of Windows Azure Active Directory Sync Tool can be deployed to manage that relationship. Installing more than one Windows Azure Active Directory Sync Tool to manage the relationship is unsupported.
18
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure Site-resilient AD FS configurations are supported; however, to be effective, these configurations require that global load-balancers are deployed in all active locations. This may not be practical because of the following issues: o Global load-balancing solutions support multi-data center topologies. In a crosspremises scenario, load-balancer components would need to be deployed on-premises and in Windows Azure. This ensures business continuity if the on-premises network is no longer available. While virtual load-balancers may be deployed in Windows Azure, such solutions havent been tested for the scope of this document. While DNS round-robin may easily be used for cross-premises deployments, we dont recommend this approach. It doesnt guarantee affinity and may result in increased authentication prompts.
19
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
Are you willing to deploy and operate a VPN connection between your corporate network and Windows Azure to support directory replication traffic? Are you comfortable with infrastructure as a service and infrastructure virtualization, or are you working with a trusted partner who is familiar with these technologies? Have you estimated the reoccurring costs for computing power, storage, and bandwidth, and compared it to your existing infrastructure charges?
20
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure We always recommend that you work with an experienced services professional for additional guidance and to address implementation details that are beyond the scope of this document. An Office 365 Deployment Partner or Microsoft Consulting Services can assist you. For a full list, see Why Work with an Office 365 Expert (http://office365.pinpoint.microsoft.com/en-US/WhyYouNeedanOffice365Expert).
21
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
The additional risks and possible mitigation that must be considered when hosting Office 365 directory integration components on Virtual Machines are listed in the following table. The indicated service degradation level applies in the scenario where Office 365 integration components are primarily active in Windows Azure. Risk Temporary VPN outage Severity Low Service Degradation Replication traffic is temporarily affected. Users can continue to log on. Mitigation Domain controllers must be deployed to Windows Azure. Federation Services must be configured to use external AD FS endpoints. Monitor connectivity between on-premises and Windows Azure. Single virtual machine outage (AD FS, AD FS proxies) Low No impact. Steps must be taken to restore the virtual machine that failed. If a single virtual machine is unavailable, it can be mitigated by deploying multiple instances of the server. Use availability sets and fault domains to avoid redundant instances being affected at the same time. Single virtual machine outage (directory synchronization) Medium Directory synchronization is interrupted. Monitoring of the directory synchronization services by default sends email to the tenant admin if updates arent detected during the default replication window. The customer can implement additional monitoring.
22
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure Risk Multiple Virtual Machine (AD FS, AD FS proxies) (Entire fault domain or availability set) Windows Azure data center service outage Critical Users are no longer able to sign in to Office 365. Severity Critical Service Degradation Users are no longer able to sign in to Office 365. Mitigation Each server from a service set should be deployed to a unique fault domain to isolate the effect of a single-rack failure.
Windows Azure takes several steps to ensure availability of the service. See Manage the Availability of Virtual Machines (http://www.windowsazure.com/ enus/manage/windows/commontasks/manage-vm-availability/). Additionally, Windows Azure allows deployments to span data centers to mitigate these types of outages.
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure Use a strong-password policynot only for domain accounts but also for the Active Directory service recovery account.
You should never directly expose an AD FS server to the Internet without going through a proxy solution for security reasons. Federation Services must be published through AD FS proxies. We recommend using the Windows Server security product baselines that are released for the Windows Server operating systems. These baselines, used with the Microsoft Security Compliance Manager (SCM) tool, enable you to define custom baselines for Windows Server. For more information, see Microsoft Security Compliance Manager (http://technet.microsoft.com/enus/library/cc677002.aspx). For more information about securing Windows Servers and domain controllers, see Secure Windows Server 2012 (http://technet.microsoft.com/library/hh831360).
24
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
4 Deployment Considerations
4.1 Costs associated with Windows Azure
You can see the pricing for Windows Azure services on the Windows Azure site (http://www.windowsazure.com/en-us/pricing/details). Licensing details arent included in this document because they may change over time. Windows Azure cost factors that you should consider include the following: The size and number of Virtual Machines. Windows Server licensing costs may be included. Compute hours dont include any Windows Azure storage costs that are associated with the Windows Server image running in Virtual Machines. These costs are billed separately. Windows Azure storage requirements. Charges apply for Windows Azure storage costs that are required for Virtual Machines. Windows Azure Virtual Network charges. Charges apply for the creation of a VPN connection between a Virtual Network and your VPN gateway. The charge is for each hour that the VPN connection is provisioned and available (a VPN connection hour). It should be 24 hours a day, seven days a week. All data transferred over the VPN connection is charged separately at the Window Azure standard data transfer rates. Network traffic. Outbound data is charged based on the total amount of data moving out of the Windows Azure data centers through the Internet in a given billing cycle. This applies to any traffic, including traffic that traverses the VPN tunnel. In this document, outbound directory synchronization traffic is expected to represent the most significant portion of the network traffic, depending on the amount of directory changes. Support. Windows Azure offers flexible support options for organizations of all sizes. Enterprises that deploy business-critical applications in Windows Azure should consider additional support options.
To help you estimate the overall cost of your solution, we have an online pricing calculator (http://www.windowsazure.com/en-us/pricing/calculator/?scenario=full).
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
As part of your deployment planning, these guidelines should be compared to the most recent product documentation and your own requirements to ensure you are appropriately sizing the Virtual Machines. The following resources are available to assist with capacity planning: Directory Synchronization: Prepare for directory synchronization (http://technet.microsoft.com/en-us/library/jj151831.aspx) Active Directory Federation Services: o o Planning for Federation Server Capacity (http://technet.microsoft.com/enus/library/b5efb78f-2d77-4549-a8e3-12f5ec389a60(v=ws.10)) AD FS 2.0 Capacity Planning Spreadsheet (http://www.microsoft.com/enus/download/details.aspx?id=2278)
SQL Server: Hardware and Software Requirements for Installing SQL Server 2008 R2 (http://technet.microsoft.com/en-us/library/ms143506(sql.105).aspx%23SEx64)
26
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
Important The VPN device cannot be behind a NAT. The VPN device must have an Internet-facing public IPv4 address. For a list of supported devices, see VPN Devices for Virtual Network (http://msdn.microsoft.com/enus/library/windowsazure/jj156075.aspx#bkmk_VPNDevice).
27
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
28
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure Align the replication schedule with latency-tolerance. Domain controllers replicate only the last state of a value. Slowing replication down saves costs if there are a lot of smaller object changes.
4.6.3 AD FS publishing
AD FS endpoints are used to provide clients with access to federated applications and services. Endpoints issue authentication tokens to clients after successful client authentication. You manage these endpoints on your AD FS servers, and securely publish them individually through an AD FS proxy server. Note To allow basic authentication clients to connect (including Outlook), your AD FS infrastructure must be accessible from the Internet. If not, no Outlook clients can authenticatenot even from their internal organizations network. To learn more about AD FS endpoints, see Plan for and deploy AD FS with SSO (http://technet.microsoft.com/en-us/library/jj151794.aspx).
If your on-premises Active Directory has over 50,000 objects, you must deploy the Windows Azure Active Directory Sync Tool with SQL Server. The Windows Azure Active Directory Sync Tool can be installed with SQL Server 2008 Standard or SQL Server 2008 R2. If SQL Server is required, it must be deployed on the same virtual machine as the Windows Azure Active Directory Sync Tool. This can affect the size of this virtual machine. The following is not supported: Deploying SQL Server on a different server than the Windows Azure Active Directory Sync Tool Using SQL Azure as the database back-end for the Windows Azure Active Directory Sync Tool
29
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure When deploying the Windows Azure Active Directory Sync Tool on Virtual Machines, the following table lists the configurations that are supported. Directory synchronization host Virtual machine Virtual machine Virtual machine Domain controller Supported?
Virtual machines: read/Write domain controller Virtual machines: Read-Only domain controller On-premises (connected through Virtual Network) Directory synchronization has a high latency tolerance, but intermittent connectivity issues between Windows Azure and on-premises may cause outages of directory synchronization and data that is out of date in Office 365.
When setting up and configuring directory synchronization, the server must be able to connect to at least one domain controller per domain.
For more details about requirements and deployment of directory synchronization, see Prepare for directory synchronization (http://technet.microsoft.com/en-us/library/jj151831.aspx). For guidance about deploying SQL Server on Virtual Machines, see Getting Started with SQL Server in Windows Azure Virtual Machines (https://www.windowsazure.com/en-us/manage/windows/commontasks/sql-server-on-a-vm).
30
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure Figure 5 shows a deployment in multiple data centers.
VPN
Active Directory
Directory synchronization
AD FS
AD FS
AD FS Proxy
DATA CENTER 2
Active Directory Directory synchronization AD FS Proxy
AD FS
VPN
AD FS
DATA CENTER 1
Deploying to multiple data centers with Windows Azure is a simple process; however, there are some drawbacks to that implementation: You need to deploy domain controller replicas in every data center. A separate VPN connection is required from every data center to your on-premises network. All virtual networks (and the associated replication traffic) are isolated from one another. This isolation generates larger amounts of outbound traffic than a single virtual network to a single Windows Azure data center. Complexity and costs increase.
For more information about using Windows Azure Traffic Manager, see Windows Azure Traffic Manager Overview (https://www.windowsazure.com/en-us/manage/windows/common-tasks/sqlserver-on-a-vm).
A single data center deployment is recommended for most customers because duplicating services to a second data center increases complexity and costs, but only marginally improving authentication performance and availability.
31
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure Windows Azure provides 99.9% availability for its individual components. When deploying redundant role instances in different fault and upgrade domains, Internet-facing roles are expected to be available at least 99.95% of the time. For more information, see the Service Level Agreements (http://www.windowsazure.com/en-us/support/legal/sla/).
32
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
5 Operational Considerations
5.1.1 VPN gateway management
We strongly recommend that you keep the VPN gateway active 24 hours a day, seven days a week. If you have to disconnect the gateway, you must ensure that you dont leave the gateway disconnected for more than 50% of your Active Directory Domain Services (AD DS) tombstone lifetime.
33
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
6 Conclusion
When implementing Office 365, you have lots of choices that let you implement the cloud on your terms. With the introduction of Windows Azure Virtual Machines, you have new options to reduce your onpremises footprint. This document presented a few scenarios and some guidelines to help you determine which approach is best for your organization. Although there are many benefits in deploying Office 365 integration components on Windows Azure, you must be prepared to support the increased complexity required for managing co-located domain controllers and other services, and the operation of the VPN channel thats required to enable these services. Always consider the simplest scenarios first. Should you choose to implement Office 365 directory integration components on Windows Azure, we recommend that you develop a detailed implementation architecture and plan. And, ensure that you thoroughly test and validate your solution so it meets your business requirements. Finally, consider consulting an experienced partner to help you with your journey.
34
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
7 Appendix
7.1 Glossary
Term claim Description A statement that one entity makes about itself or another subject. For example, the statement can be about a name, email, group, privilege, or capability. Claims have a provider that issues them (in this context, an Office 365 customer), and they are given one or more values. They are also defined by a claim value type and, possibly, associated metadata. A logical instance of Active Directory Federation Services 2.0 (AD FS 2.0). A Federation Service can be deployed as a standalone federation server or as a load-balanced federation server farm. The name of the Federation Service defaults to the subject name of the SSL/TLS certificate. The DNS name of the Federation Service must be used in the subject name of the SSL/TLS certificate. A federation server serves as part of a Federation Service that can issue, manage, and validate requests for security tokens and identity management. Security tokens consist of a collection of claims, such as a user's name or role. Two or more federation servers in the same network that are configured to act as one redundant Federation Service. A computer running Windows Server 2008 R2 that has been configured to act as an intermediary proxy service between a client on the Internet and a Federation Service that is located behind a firewall on an organizations network. To allow remote access to the services in Office 365, such as from a smart phone, home computer, or Internet kiosk, you need to deploy a federation server proxy. A dedicated application (such as Network Load Balancing (NLB)) or hardware device (such as a multilayer switch) used to provide fault tolerance, high availability, and load balancing across multiple nodes. For AD FS 2.0, the cluster DNS name that you create using this NLB must match the Federation Service name that you specified when you deployed your first federation server in your farm. A network configuration in Windows Azure that enables the administrator to securely connect the Windows Azure Virtual Machines to the onpremises network. A software implementation of a computer that supports the execution of a complete operating system. These usually emulate an existing architecture, and are built to provide a platform to run applications on.
35
Federation Service
federation server
Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure
36