office365 adapter
TRANSCRIPT
© 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 EXECUTIVE SUMMARY...........................................................................5
2 INTRODUCTION....................................................................................6
3 DEPLOYMENT SCENARIOS.....................................................................7
3.1 INTRODUCTION..................................................................................................7
3.2 BEFORE YOU START–IS THIS RIGHT FOR YOUR ORGANIZATION?....................................7
3.3 WINDOWS AZURE ACTIVE DIRECTORY...................................................................8
3.4 HIGH-LEVEL DESIGN CONSIDERATIONS....................................................................9
3.5 SCENARIO 1: OFFICE 365 DIRECTORY INTEGRATION COMPONENTS DEPLOYED ON-PREMISES
11
3.6 SCENARIO 2: OFFICE 365 DIRECTORY INTEGRATION COMPONENTS DEPLOYED IN WINDOWS AZURE 13
3.7 SCENARIO 3: OFFICE 365 DIRECTORY INTEGRATION COMPONENTS DEPLOYED IN WINDOWS AZURE FOR DISASTER RECOVERY..................................................................................16
3.8 CHECKPOINT: KEY REQUIREMENTS.......................................................................20
3.9 RISKS AND MITIGATIONS....................................................................................22
4 DEPLOYMENT CONSIDERATIONS..........................................................25
4.1 COSTS ASSOCIATED WITH WINDOWS AZURE.........................................................25
4.2 VIRTUAL MACHINE OPERATING SYSTEM REQUIREMENTS............................................25
4.3 VIRTUAL MACHINE SIZING..................................................................................26
4.4 VPN NETWORK REQUIREMENTS..........................................................................27
4.5 IP ADDRESSING AND NAME RESOLUTION...............................................................27
4.6 ACTIVE DIRECTORY DOMAIN SERVICES................................................................28
4.7 DIRECTORY SYNCHRONIZATION SERVER................................................................29
4.8 DEPLOYMENT TO MULTIPLE WINDOWS AZURE DATA CENTERS...................................30
5 OPERATIONAL CONSIDERATIONS.........................................................33
6 CONCLUSION......................................................................................34
7 APPENDIX..........................................................................................35
7.1 GLOSSARY.....................................................................................................35
7.2 WINDOWS AZURE SERVICE REFERENCES...............................................................36
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/en-us/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 won’t 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 there’s 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 they’re 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.
We’ll 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 on-premises implementations. In some cases, Windows Azure will be the appropriate choice.
4
2 Introduction
5
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/en-us/library/jj151786.aspx ).
In the past, we’ve 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. We’ll guide you through the solution, potential benefits, requirements, and high-level planning tasks.
We’ll 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 aren’t supported on Virtual Machines. We’ve 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 haven’t 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, it’s 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 single-forest topologies. Consequently, multiforest topologies are outside the scope of this document.
Deployment over multiple Windows Azure data centers. It’s 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
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.
3.2 Before you start–is this right for your organization?
Before you decide to deploy Office 365 directory integration components on Virtual Machines, you should take the time to consider the following:
Do you actually require AD FS?
Office 365 doesn’t require every customer to deploy directory synchronization services or AD FS. In reality, most organizations require only cloud identities, where users receive cloud credentials for signing in to Office 365 services. The cloud ID password policy is stored in the cloud with the Office 365 service. Cloud credentials are separate from other desktop or corporate credentials.
Using cloud identities, one optional server may be deployed to support directory synchronization from your on-premises Active Directory. In environments with just a few users, directory synchronization isn’t required. Users may be provisioned manually through the Office 365 portal.
Federated identities, on the other hand, enable users to sign in to Office 365 services by using their Active Directory credentials. The corporate Active Directory authenticates the users, and then stores and controls the password policy.
Deploying AD FS requires additional expertise, introduces complexity, and has higher operational costs.
7
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 it’s 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 isn’t required, and dramatically simplifies your deployment.
3.3 Windows Azure Active Directory
Windows Azure AD provides identity management and access control capabilities for cloud services such as Office 365. Windows Azure AD capabilities include a cloud-based store for directory data and a core set of identity services, including user logon processes, authentication services, and Federation Services. The identity services that are included with Windows Azure AD easily integrate with your on-premises Active Directory deployments and fully support third-party identity providers.
It’s important to clearly distinguish Windows Azure AD as an identity platform for Office 365 from Active Directory deployments on Virtual Machines. Both are discussed in this document. For details, see Windows Azure Active Directory Identity (http://www.windowsazure.com/en-us/home/features/identity/ ).
If you’re an IT professional, a system architect, or a developer who wants a deeper understanding of managing online and federated identities, see Active Directory from on-premises to the cloud (http://www.microsoft.com/en-us/download/details.aspx?id=36391 ) .
8
3.4 High-level design considerations
3.4.1Active Directory domain controllers
If you choose to deploy Office 365 directory integration components on Virtual Machines, we recommend that you deploy one or more Active Directory domain controller replicas of your on-premises Active Directory in Windows Azure. Deploying these replicas to Virtual Machines eliminates the cross-premises network connection as a single point of failure in the deployment. This has the added benefit of faster logon because the logon traffic doesn’t need to traverse the cross-premises network connection for each logon attempt.
Although it’s possible to deploy AD FS on Virtual Machines in Windows Azure and leave the domain controllers on-premises, we strongly discourage it. Separating your domain controllers from your AD FS may introduce latency into the authentication chain. This creates a real-time dependency on the network connectivity for these two services. Placing domain controllers on Virtual Machines within Windows Azure mitigates these risks.
Domain controllers in Windows Azure should be placed in a separate Active Directory site. This introduces some additional Active Directory replication latency. The default replication delay between Active Directory sites is 3 hours (180 minutes). The default synchronization schedule between Active Directory and Office 365, by using the Windows Azure Active Directory Sync Tool, is also 3 hours.
Consequently, it may take up to 6 hours for a change made on-premises to replicate to Office 365, unless the replication delay is adjusted. For more information, see How Active Directory Replication Topology Works (http://technet.microsoft.com/en-us/library/cc755994(v=WS.10).aspx ) .
For general guidance about running Active Directory services on Virtual Machines, see Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines (http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx#BKMK_Scenarios ).
3.4.2VPN network connectivity
Network connectivity is required between Virtual Machines and your on-premises corporate network. Such connectivity should always take place over a private network for security reasons.
Caution Domain controllers that are installed on Virtual Machines in Windows Azure should:
Never use a publicly routable endpoint.
Always use a private network.
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 on-premises 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.
9
3.4.1Component redundancy and availability
When you implement services on Virtual Machines, you have to expand the existing on-premises management and monitoring process to these services. The management and monitoring can traverse the VPN that you set up to connect to Windows Azure.
For improved availability, multiple Virtual Machines are used for most components. By using multiple Virtual Machines, services remain available during local network failures, local disk hardware failures, and any planned downtime that Windows Azure may require.
When multiple Virtual Machines are connected in a cloud service, an availability set should be used to ensure that the Virtual Machines are located in different fault domains. This is similar to ensuring two redundant servers were located on physically different server racks in your on-premises data center.
Figure 1 depicts two availability sets with two Virtual Machines in each set.
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/manage-vm-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 doesn’t 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 won’t resume until the Windows Azure Directory Sync Tool is reinstalled on a new virtual server.
10
3.5 Scenario 1: Office 365 directory integration components deployed on-premises
Deploying Office 365 directory integration components on premises (without the use of Windows Azure) is the primary deployment scenario. It’s covered in the Office 365 documentation (http://technet.microsoft.com/en-us/library/hh852466.aspx). This scenario is presented here for you to compare it to the deployment scenarios that include Windows Azure.
We recommend scenario 1 for customers who:
Want to deploy on-premises infrastructure components
Don’t want to introduce Virtual Machines into their environment
Figure 2 shows the high-level architecture for this scenario.
Figure 2. High-level architecture (without Windows Azure) for scenario 1
11
In the topology that’s 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 customer’s perimeter network. This topology includes the Office 365 directory integration components as shown in the following table.
Component Quantity Location
Directory synchronization server 1 Customer corporate network
AD FS servers 2 or more Customer corporate network
Federation Service proxy 2 or more 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/en-us/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/en-us/library/jj151781.aspx)
Office 365 Deployment Guide: Deploy Single Sign On (http://technet.microsoft.com/en-us/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
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
Figure 3 shows the high-level architecture for this option.
Figure 3. High-level architecture for Windows Azure for scenario 2
14
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 Quantity Location
Active Directory domain controllers 2 per Active Directory domain
Windows Azure
Directory synchronization server 1 Windows Azure
AD FS servers 2 or more Windows Azure
AD FS proxy 2 or more Windows Azure
VPN router 1 or 2 Customer corporate network
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, it’s 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
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
Figure 4 shows the high-level architecture for scenario 3.
Figure 4. High-level architecture for disaster recovery for scenario 3
17
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 Quantity Location
Directory synchronization server 1 Customer corporate network
AD FS servers 2 or more Customer corporate network
FSP 2 or more Customer perimeter network
Active Directory domain controllers 2 per Active Direction domain
Windows Azure
Standby directory synchronization server 1 Windows Azure
AD FS 2 or more Windows Azure
AD FS proxy 2 or more Windows Azure
VPN router 1 or 2 Customer corporate network
18
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 can’t 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 don’t 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.
19
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 cross-premises 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 haven’t been tested for the scope of this document.
o While DNS round-robin may easily be used for cross-premises deployments, we don’t recommend this approach. It doesn’t guarantee affinity and may result in increased authentication prompts.
20
3.8 Checkpoint: key requirements
Use the following table to help you determine if using Virtual Machines for Office 365 directory integration components are appropriate for your organization.
Question Guidance
Have you evaluated both cloud identities and federated identities by reviewing the Office 365 documentation and an Office 365 trial?
If you haven’t done so yet, you should review the Office 365 documentation (http://technet.microsoft.com/en-us/library/hh852466.aspx). Consider setting up an Office 365 trial to evaluate cloud identities for your organization.
Come back to this document at a later stage of your evaluation.
Are cloud identities sufficient for your user needs?
If cloud identities satisfy your business requirements, you don’t require an AD FS infrastructure. You may possibly require directory synchronization, which you should deploy on-premises.
This document won’t help with on-premises–only deployments of directory integration.
Do you already operate an AD FS infrastructure on-premises?
If you already operate an AD FS infrastructure, consider using your existing infrastructure for use with Office 365.
Are you willing to deploy domain controllers to Windows Azure?
If you aren’t willing to deploy domain controllers to Windows Azure, you shouldn’t deploy Office 365 directory integration components on Virtual Machines.
Are you willing to deploy and operate a VPN connection between your corporate network and Windows Azure to support directory replication traffic?
If you aren’t willing to deploy and operate a VPN connection for Windows Azure connectivity, you shouldn’t deploy Office 365 directory integration components on Virtual Machines.
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?
Windows Azure and virtualization may add complexity to your environment. You should be familiar with these technologies or work with a partner who can assist you.
Have you estimated the reoccurring costs for computing power, storage, and bandwidth, and compared it to your existing infrastructure charges?
Before deciding on a deployment strategy, you should estimate the costs that are associated with Windows Azure services.
21
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).
22
3.9 Risks and mitigations
The risks of running all or part of the Office 365 directory integration components on Virtual Machines are similar to running these components on-premises and the same mitigation principles apply. Most risks are based on some or all the servers going down or becoming unavailable. We recommend the same mitigation techniques to address these issues, including:
Deploying two or more AD FS servers for all roles deployed
Prepare a plan to re-install the Windows Azure Directory Synch Tool in the event of a failure
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 Severity
Service Degradation
Mitigation
Temporary VPN outage
Low Replication traffic is temporarily affected.
Users can continue to log on.
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 aren’t detected during the default replication window.
The customer can implement additional monitoring.
23
Risk Severity
Service Degradation
Mitigation
Multiple Virtual Machine (AD FS, AD FS proxies)
(Entire fault domain or availability set)
Critical Users are no longer able to sign in to Office 365.
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 data center service outage
Critical Users are no longer able to sign in to Office 365.
Windows Azure takes several steps to ensure availability of the service. See Manage the Availability of Virtual Machines (http://www.windowsazure.com/en-us/manage/windows/common-tasks/manage-vm-availability/).
Additionally, Windows Azure allows deployments to span data centers to mitigate these types of outages.
24
3.9.1VPN network availability
We strongly recommended that you ensure your VPN connection is always active (24 hours a day, seven days a week). This connection will need to be monitored in the same way you would monitor any other site-to-site network connection. If the connection is unavailable, directory replication to the domain controllers in Windows Azure stops functioning; directory changes don’t synchronize. As a result, your users cannot log on.
3.9.2Domain controller and AD FS security
By default, only a Remote Desktop Protocol (RDP) endpoint is accessible from the Internet, allowing Remote Desktop access to the domain controller. After your VPN is set up, you should disable the access to the RDP endpoint on the domain controllers and manage them exclusively through VPN. This blocks all outside access to the domain controllers that are running in Windows Azure.
Managing a domain controller on Virtual Machines is similar to managing a domain controller in the on-premises perimeter network. Here are some basic recommendations to get you started:
Don’t expose any endpoints to the Internet if they’re not needed. Remove the default Remote Desktop endpoint from the configuration. Allow connectivity only to the domain controllers through the VPN tunnel.
Monitor the security event log for suspicious logon patterns. For more information about how to monitor and detect a potential attack, see Security Auditing Overview (http://technet.microsoft.com/en-us/library/hh849642.aspx).
Use a strong-password policy—not 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/en-us/library/cc677002.aspx ).
For more information about securing Windows Servers and domain controllers, see Secure Windows Server 2012 (http://technet.microsoft.com/library/hh831360).
25
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 aren’t 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 don’t 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 ).
4.2 Virtual Machine operating system requirements
When this document was written, Office 365 directory integration components are supported on Windows Server 2008 R2 and Windows Server 2012.
Detailed system and software requirements are documented here:
Directory synchronization (http://technet.microsoft.com/en-us/library/jj151831.aspx )
Active Directory Federation Services (http://technet.microsoft.com/en-us/library/jj151786.aspx )
26
27
4.3 Virtual Machine sizing
Virtual Machine sizing guidelines are provided for the Office 365 directory integration component in the following table. More details about the resources included in the small-, medium-, and large-size Virtual Machines can be found in Windows Azure Virtual Machines ( http://msdn.microsoft.com/en-us/library/windowsazure/jj156003.aspx ).
Server role <5,000 users 5,001–15,000 users
15,001–50,000 users
>50,000 users
Domain controller
Small
plus 1 data disk
Medium
plus 1 data disk
Large
plus 1 data disk
Large
Plus 1 data disk
AD FS server Small Small Medium Large
AD FS proxy Small Small Medium Large
Directory synchronization server
Medium Medium Medium Large
Plus 1 data disk for the SQL Server® database
Plus 1 data disk for SQL Server logs
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 Planning for Federation Server Capacity ( http://technet.microsoft.com/en- us/library/b5efb78f-2d77-4549-a8e3-12f5ec389a60(v=ws.10) )
o AD FS 2.0 Capacity Planning Spreadsheet ( http://www.microsoft.com/en- us/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 )
28
4.4 VPN network requirements
To connect the on-premises network to the Virtual Machines, you must configure a VPN. This requires a VPN device on-premises that’s directly published to the Internet. Network address translation (NAT) isn’t supported at this time.
The VPN device must support the following features:
Internet Key Exchange v1 (IKEv1).
Establish Internet Protocol Security (IPsec) associations in tunnel mode.
NAT traversal (NAT-T).
AES 128-bit encryption function, the SHA-1 hashing function, and Diffie-Hellman Perfect Forward Secrecy in Group 2 mode.
The VPN device must fragment packets before it encapsulates the data with the VPN headers.
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/en-us/library/windowsazure/jj156075.aspx#bkmk_VPNDevice).
4.5 IP Addressing and name resolution
You need to configure the Virtual Machines to use Dynamic Host Configuration Protocol (DHCP)-leased addresses. Windows Azure ensures that leases never expire or move between Virtual Machines. This non-static configuration is the opposite of what most Active Directory administrators are used to doing, but it’s a requirement for the Virtual Machines to work seamlessly with the VPN and on-premises servers.
Important Do not consider statically defining a previously leased address. This will appear to work for the remaining period of the lease, but when the lease expires, the Virtual Machines will lose all communication with the network and will be disconnected from the network.
You will need to deploy Windows Server DNS on the domain controllers. Windows Azure DNS doesn’t meet the complex name resolution needs of the Active Directory Dynamic Domain Name System (DDNS), service records (SRV records), and so on. As with on-premises deployments of Windows Server, Active Directory DNS remains a critical configuration item for domain controllers and domain-joined clients.
29
4.6 Active Directory Domain Services
4.6.1Deployment guidelines on Windows Azure
Detailed guidelines for virtualizing and deploying Active Directory domain controllers and AD FS on Windows Azure are maintained in Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines ( http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx ) .
We recommend that you use these guidelines for general guidance about deploying domain controllers on Virtual Machines.
Important Read/write domain controllers must be deployed. Read-only domain controllers aren’t supported for use with directory synchronization.
The following principles should be observed:
If your Active Directory forest contains more than one user domain, you must deploy at least one domain controller for each domain into Windows Azure. This ensures uninterrupted access to the service and reduces the authentication traffic that traverses the VPN tunnel.
We recommend that you deploy at least two AD FS servers and two AD FS proxy servers to achieve the best availability of the AD FS service.
Domain controllers and AD FS servers should never be exposed directly to the Internet and should only be reachable through VPN.
AD FS proxies must be used to publish AD FS servers to the Internet.
We recommend that you deploy domain controllers and AD FS servers as a single affinity group to reduce latency between components. For more information, see Affinity Groups (http://msdn.microsoft.com/en-us/library/windowsazure/jj156085.aspx ).
4.6.2Active Directory sites, subnets, and replication traffic
To optimize your deployment, consider fine-tuning the domain-controller–locator and intersite topology generator (ISTG) and intersite messaging service (ISM) traffic:
Define and connect Active Directory subnets and sites correctly.
Ensure that the link cost between any on-premises site and the Windows Azure site is higher than the on-premises site link costs. A higher link cost means that on-premises computers are less likely to traverse the VPN connection to connect to a domain controller in Windows Azure for on-premises operations.
Ensure that replication is scheduled as opposed to being notification-driven.
Ensure that replication traffic is using the appropriate amount of compression. Domain controllers offer a variety of replication traffic compression tools. For more information, see Active Directory Replication Tools and Settings (http://technet.microsoft.com/en-us/library/cc739941(v=WS.10).aspx).
30
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.3AD 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 authenticate—not even from their internal organization’s 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).
4.7 Directory synchronization server
Enabling integrated global address list (GAL) or an integrated GAL and SSO requires integrating your on-premises Active Directory forest with your Office 365 tenant by using the Windows Azure Active Directory Sync Tool. You must be able to meet the following minimum requirements to deploy the Windows Azure Active Directory Sync Tool:
The Windows Azure Active Directory Sync Tool must be installed on a domain-joined computer in the forest that you want to integrate with Office 365.
The computer cannot be a domain controller.
You need enterprise administrator credentials to configure the Windows Azure Active Directory Sync Tool.
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
31
When deploying the Windows Azure Active Directory Sync Tool on Virtual Machines, the following table lists the configurations that are supported.
Directory synchronization host
Domain controller Supported?
Virtual machine Virtual machines: read/Write domain controller
Yes
Virtual machine Virtual machines: Read-Only domain controller
No
Virtual machine 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.
Yes
Not recommended
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/common-tasks/sql-server-on-a-vm ) .
4.8 Deployment to multiple Windows Azure data centers
You have the option to deploy Virtual Machines in multiple Windows Azure data centers across multiple geographic regions. The Windows Azure Traffic Manager can distribute authentication traffic across those data centers, enabling users to use the AD FS service closest to their location, avoiding network latency issues and logon delays.
32
Figure 5 shows a deployment in multiple data centers.
Figure 5. Deployment in multiple Windows Azure data centers
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/sql-server-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.
33
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/).
34
5 Operational Considerations
5.1.1VPN 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 don’t leave the gateway disconnected for more than 50% of your Active Directory Domain Services (AD DS) tombstone lifetime.
5.1.2Virtual Machine management considerations
Managing Virtual Machines in Windows Azure is very similar to managing servers in your on-premises network. Server configuration management, software installation, and security updates can all be performed by using the tools you are using on-premises, such as Microsoft System Center Configuration Manager (SCCM) or Windows Server Update Services (WSUS). Security updates can also use the built-in Windows® Update Service Client because all Virtual Machines in Windows Azure have outbound Internet connectivity. Using an existing on-premises management solution requires the virtual network connection to be operational 24 hours a day, seven days a week.
5.1.1Domain controller virtualization
Deploying Windows Server Active Directory domain controllers on Windows Azure Virtual Machines is subject to the same guidelines as running domain controllers on-premises in a virtual machine. Running virtualized domain controllers in either situation requires operational procedures for backing up and restoring domain controllers within your organization.
For information about virtualizing domain controllers, see Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines (http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx#BKMK_Safe ).
Create system state backups by using only backup software that is specifically aware of backup requirements for Windows Server AD DS, such as Windows Server Backup. Specifically, it’s important to note that you should never copy or clone .vhd files of domain controllers instead of performing regular backups. Should a restore ever be required, doing so using cloned or copied .vhd files will introduce issues that can lead to a permanently divergent state between domain controllers.
35
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 on-premises 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 that’s 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.
36
7 Appendix
7.1 Glossary
Term Description
claim 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.
Federation Service
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.
federation server
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.
federation server farm
Two or more federation servers in the same network that are configured to act as one redundant Federation Service.
federation server proxy
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 organization’s 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.
network load balancer
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.
Virtual Private Network
A network configuration in Windows Azure that enables the administrator to securely connect the Windows Azure Virtual Machines to the on-premises network.
Virtual Machine (Windows Azure Virtual Machine)
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.
37
7.2 Windows Azure service references
7.2.1Windows Azure
Windows Azure is an open and flexible cloud platform that enables you to quickly build, deploy, and manage applications across a global network of Microsoft-managed data centers. You can build applications by using any language, tool, or framework. And you can integrate your public cloud applications with your existing IT environment.
For more information about the Windows Azure platform, take a look at an overview of Windows Azure (http://www.windowsazure.com/en-us/home/features/overview/ ) .
7.2.2Windows Azure Virtual Machines
With Windows Azure, you can easily bring your own customized Windows Server or Linux images or select them from a gallery. Retain full control of your images and maintain them as required by your organization. Windows Azure also helps to migrate your applications and infrastructure without changing existing code, making it faster to move SharePoint®, SQL Server, or Active Directory Domain Services to the cloud—saving you time and money.
For more information on Windows Azure Virtual Machines see Windows Azure Infrastructure Services (http://www.windowsazure.com/en-us/home/scenarios/virtual-machines/ ).
7.2.1Windows Azure Virtual Network
Windows Azure Virtual Network lets you provision and manage VPNs in Windows Azure as well as securely link these with on-premises 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.
For more information on Windows Azure Virtual Networks, see Windows Azure Networking (http://www.windowsazure.com/en-us/home/features/networking/ ).
7.2.2Windows Azure Traffic Manager
Windows Azure Traffic Manager enables you to control the distribution of user traffic to Windows Azure-hosted services. Traffic Manager works by applying an intelligent policy engine to the DNS queries on your main organization domain name. Update the DNS resource records that your organization owns to point to the Traffic Manager domain. Traffic Manager policies that are attached to those domains then resolve DNS queries on your main organization domain name to the IP addresses of specific Windows Azure-hosted services that are contained in the Traffic Manager policies.
For more information about using Windows Azure Traffic Manager, see Windows Azure Traffic Manager Overview (http://msdn.microsoft.com/en-us/library/windowsazure/hh744833.aspx ) .
38