Free Trial *Internet Service Required
18 out of 20 rated this helpful - Rate this topic

Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines

Updated: March 25, 2013

The paper explains the important differences between deploying Windows Server Active Directory Domain Services (AD DS) and Active Directory Federation Services (AD FS) on-premises versus deploying them on Windows Azure Virtual Machines (VMs).

Table of Contents

This paper is intended for those already experienced with deploying Active Directory on-premises. The paper covers the differences between deploying Active Directory on Windows Azure Virtual Machines/Windows Azure Virtual Networks and traditional on-premises Active Directory deployments. Windows Azure Virtual Machines and Windows Azure Virtual Network are part of an Infrastructure-as-a-Service (IaaS) offering for organizations to leverage computing resources in the cloud.

For those that are not familiar with AD deployment, see the AD DS Deployment Guide or the AD FS 2.0 Deployment Guide as appropriate.

The paper assumes that the reader is familiar with the following concepts:

  • Windows Server AD DS deployment and management

  • Deployment and configuration of DNS to support a Windows Server AD DS infrastructure

  • Windows Server AD FS deployment, and management

  • Deploying, configuring and managing relying party applications (web sites and web services) that can consume Windows Server AD FS tokens

  • General virtual machine concepts, such as how to configure a virtual machine, virtual disks, and virtual networks

The paper highlights the requirements for a hybrid deployment scenario in which Windows Server AD DS or AD FS are partly deployed on-premises and partly deployed on Windows Azure Virtual Machines. The document first covers the critical differences between running Windows Server AD DS and AD FS on Windows Azure virtual machines versus on-premises, and important decisions that affect design and deployment. The rest of the paper explains guidelines for each of the decision points in more detail, and how to apply the guidelines to various deployment scenarios.

This paper does not discuss the deployment and configuration of Windows Azure Active Directory, which is a REST-based service that provides identity management and access control capabilities for cloud applications. Windows Azure AD and Windows Server AD DS are, however, designed to work together to provide an identity and access management solution for today’s hybrid IT environments and modern applications. To help understand the differences and relationships between Windows Server AD DS and Windows Azure AD, consider the following:

  1. You might run Windows Server AD DS in the cloud on Windows Azure Virtual Machines when you’re using Windows Azure to extend your on-premises datacenter into the cloud.

  2. You might use Windows Azure Active Directory to give your users single sign-on to Software-as-a-Service (SaaS) applications. Microsoft’s Office 365 uses this technology, for example, and applications running on Windows Azure or other cloud platforms can also use it.

  3. You might use Windows Azure Active Directory (its Access Control Service) to let users log in using identities from Facebook, Google, Microsoft, and other identity providers to applications that are hosted in the cloud or on-premises.

For more information about these differences, see Windows Azure Identity.

The fundamental requirements for deploying Windows Server Active Directory on Windows Azure Virtual Machines differ very little from deploying it in virtual machines (and, to some extent, physical machines) on-premises. For example, in the case of Windows Server AD DS, if the domain controllers (DCs) that you deploy on Windows Azure virtual machines are replicas in an existing on-premises corporate domain/forest, then the Windows Azure deployment can largely be treated in the same way as you might treat any other additional Windows Server Active Directory site. That is, subnets must be defined in Windows Server AD DS, a site created, the subnets linked to that site, and connected to other sites using appropriate site-links. There are, however, a number of differences that are common to all Windows Azure deployments and some that vary according to the specific deployment scenario. Three fundamental differences are outlined below and explained in more detail in the paragraphs that follow:

  1. Windows Azure virtual machines may need to be provided connectivity to the on-premises corporate network.

    To connect Windows Azure virtual machines back to an on-premises corporate network requires Windows Azure Virtual Network, which includes a site-to-site virtual private network (VPN) component able to seamlessly connect Windows Azure virtual machines and on-premises machines. This VPN component could also enable on-premises domain member computers to access a Windows Server Active Directory domain whose domain controllers are hosted exclusively on Windows Azure virtual machines. It is important to note though, that if the VPN fails, authentication and other operations that depend on Windows Server Active Directory will also fail. While users may be able to log on using existing cached credentials, all peer-to-peer or client-to-server authentication attempts for which tickets have yet to be issued or have become stale will fail.

    See Networking for a demonstration video and a list of step-by-step tutorials, including Create a virtual network with cross-premises connectivity.

    noteNote
    You can also deploy Windows Server Active Directory on a Windows Azure virtual network that does not have connectivity with an on-premises network. The guidelines in this topic, however, do assume that a Windows Azure virtual network is used because it provides IP addressing capabilities that are essential to Windows Server. Further details are described in the following paragraph.

  2. Static IP addresses are NOT supported on Windows Azure virtual machines.

    Dynamic addresses must therefore be used instead, which requires that you create a Windows Azure Virtual Network. At first glance, this appears contradictory to existing Windows Server Active Directory best-practices but because the dynamic IP addresses of Windows Azure virtual machines that are attached to a Windows Azure Virtual Network persist for the lifetime of the virtual machine, the Windows Server Active Directory requirements for IP addressing are met (as are those for DNS if co-located with the DC).

    In addition, Windows Azure Virtual Networks provide greater degrees of control over IP addressing and DNS.

    See IP addressing and DNS.

  3. Windows Azure provides two distinct disk types for virtual machines.

    The selection of the disk type is critical when deploying domain controllers. Windows Azure offers both “Operating System-disks” and “Data-disks.” Data-disks use write-through caching, guaranteeing durability of writes — this is fundamental to the integrity of any Windows Server Active Directory forest that has more than a single domain controller because the loss of a single write can affect the entire distributed system rather than just a single machine. Additional factors for consideration, and the scenarios in which they influence configuration and deployment choices, are discussed in detail throughout the remainder of this paper.

    See Placement of the Windows Server AD DS database and SYSVOL.

The following non-exhaustive list of terms defines various pertinent Windows Azure technologies and will help with comprehension of this document. For a complete glossary, see Windows Azure Glossary.

  • Windows Azure Virtual Machines: The IaaS offering in Windows Azure that allows customers to deploy VMs running nearly any traditionally on-premises server workload.

  • Windows Azure Virtual Network: The networking service in Windows Azure that lets customers create and manage virtual networks in Windows Azure and securely link them to their own on-premises networking infrastructure by using a virtual private network (VPN).

  • Virtual IP address (VIP): An internet-facing IP address that is not bound to a specific computer or network interface card. Cloud services are assigned a VIP for receiving network traffic which is redirected to a Windows Azure VM. A VIP is a property of a cloud-service which can contain one or more Windows Azure virtual machines. Also note that a Windows Azure virtual network can contain one or more cloud-services. VIPs provide native load-balancing capabilities.

  • Dynamic IP address (DIP): This is the IP address that will be dynamically assigned to the virtual network adapter of a Windows Azure virtual machine by DHCP. The IP address, however, will persist with that virtual machine for the entire lifetime of the deployment in the same manner as DHCP reservations are tied to individual MAC addresses. DIPs do not provide load-balancing capabilities.

  • Service healing: The process in which Windows Azure automatically returns a service to a running state again after it detects that the service has failed. Service healing is one of the aspects of Windows Azure that supports availability and resiliency. While unlikely, the result following a service healing incident for a DC running on a VM is similar to an unplanned reboot, but has a few side-effects:

    • The virtual network adapter in the VM will change

    • The MAC address of the virtual network adapter will change

    • The Processor/CPU ID of the VM will change

    • The IP configuration of the virtual network adapter will not change as long as the VM is attached to a virtual network and the VM’s IP configuration is defined as part of the virtual network or the VM itself (not the guest operating system)

    None of these behaviors affect Windows Server Active Directory though because it has no dependency on the MAC address or Processor/CPU ID, and all Windows Server Active Directory deployments on Windows Azure are recommended to be run on a Windows Azure virtual network as outlined above, which ensures that the IP address persists through service healing.

Deploying Windows Server Active Directory DCs on Windows Azure virtual machines is subject to the same guidelines as running DCs on-premises in a virtual machine. Running virtualized DCs is a safe practice as long as guidelines for backing up and restoring DCs are followed. For more information about constraints and guidelines for running virtualized DCs, see Running Domain Controllers in Hyper-V.

Hypervisors provide or trivialize technologies that can cause problems for many distributed systems, including Windows Server Active Directory. For example, on a physical server, you can clone a disk, or use unsupported methods to roll back the state of a server, including using SANs and so on, but doing that on a physical server is much harder than restoring a virtual machine snapshot in a hypervisor. While Windows Azure does not provide snapshot restore functionality, it does offer functionality that can result in the same undesirable condition; for example, you should not copy VHD files of DCs instead of performing regular backups because restoring them results in a similar situation to using snapshot restore features.

Such rollbacks introduce USN bubbles that can lead to permanently divergent state between DCs. That can, among others, cause:

  • Lingering objects

  • Inconsistent passwords

  • Inconsistent attribute values

  • Schema mismatches if the schema master is rolled back

For more information about how DCs are impacted, see USN and USN Rollback.

A virtual machine running on Windows Azure is very similar to a virtual machine running on Windows Server Hyper-V. The actual hypervisor used in Windows Azure is a modified version of the Windows Server hypervisor that has been optimized for the hardware and workloads demanded on Windows Azure. The important differences related to DCs on Windows Azure are:

  • 14 GB RAM limit

  • One network adapter

  • Although the Snapshot feature is not supported, it is possible, though not advisable, to copy a virtual machine’s disk file (or VHD). You should not copy a DC’s disk files for the reasons stated in the Installation method section.

Many Windows Server AD DS deployment scenarios are well-suited for deployment as VMs on Windows Azure. For example, suppose you have a company in Europe that needs to authenticate users in a remote location in Asia. The company has not previously deployed Windows Server Active Directory DCs in Asia due to the cost to deploy them and limited expertise to manage the servers post-deployment. As a result, authentication requests from Asia are serviced by DCs in Europe with suboptimal results. In this case, you can deploy a DC on a VM that you have specified must be run within the Windows Azure datacenter in Asia. Attaching that DC to a Windows Azure virtual network that is connected directly to the remote location will improve authentication performance.

Windows Azure is also well-suited as a substitute to otherwise costly disaster recovery (DR) sites. The relatively low-cost of hosting a small number of domain controllers and a single virtual network on Windows Azure represents an attractive alternative.

Finally, you may want to deploy a network application on Windows Azure, such as SharePoint, that requires Windows Server Active Directory but has no dependency on the on-premises network or the corporate Windows Server Active Directory. In this case, deploying an isolated forest on Windows Azure to meet the SharePoint server’s requirements is optimal. Again, deploying network applications that do require connectivity to the on-premises network and the corporate Active Directory is also supported.

noteNote
Since it provides a layer-3 connection, the VPN component that provides connectivity between a Windows Azure Virtual Network and an on-premises network can also enable member servers that run on-premises to leverage DCs that run as Windows Azure virtual machines on Windows Azure Virtual Network. But if the VPN is unavailable, communication between on-premises computers and Windows Azure-based domain controllers will not function, resulting in authentication and various other errors.  

  • For any Windows Server Active Directory deployment scenario that includes more than a single VM, we recommend using a Windows Azure virtual network for IP address consistency because statically-assigned addresses are not supported. Note that this guide assumes that DCs are running on a Windows Azure virtual network.

    IP address consistency on Windows Azure virtual network is achieved by using a third new conceptual type of IP address that is similar to DHCP reservations. Today, static IP addresses are assigned within the operating system to a specific network interface card. Dynamic addresses are leased automatically from DHCP servers according to the scopes defined on the DHCP server.

    A third conceptual type of address is introduced by Windows Azure virtual networks and differs only slightly from DHCP address allocation. With Windows Azure virtual machines, the VM must be configured to lease an IP address from DHCP. Unlike typical dynamic addresses, however, which may alter when a lease expires, the dynamic addresses on Windows Azure virtual networks are guaranteed for the lifetime of the virtual machine in much the same way as DHCP reservations work.

    ImportantImportant
    Configuring a static IP address within the VM will eventually result in complete loss of connectivity to it.

  • Deploying VMs on a virtual network does not imply (or require) connectivity back to an on-premises network; the virtual network merely enables that possibility. You must create a virtual network for private communication between Windows Azure and your on-premises network. You need to deploy a VPN endpoint on the on-premises network. The VPN is opened from Windows Azure to the on-premises network. For more information, see Windows Azure Virtual Network Overview and Tutorial 2: Creating a Virtual Network for cross-premises connectivity.

  • Regardless of whether you create a virtual network or not, Windows Azure charges for egress traffic but not ingress. Various Windows Server Active Directory design choices can affect how much egress traffic is generated by a deployment. For example, deploying an RODC limits egress traffic because it does not replicate outbound. For more information about traffic charges, see Windows Azure Pricing Overview.

  • It is important to note that there is no direct connectivity between separate Windows Azure virtual networks. That is, if you create two virtual networks, perhaps geographically distributed, communication between the Windows Azure VMs attached to them can only be achieved by connecting the two virtual networks to the same corporate network through the site-to-site VPN capability. Communication between the two virtual networks is then possible but only by routing traffic through the corporate network. Therefore, communication between geo-distributed DCs on separate virtual networks needs to traverse both virtual networks and your corporate network. For example, for a Windows Azure VM located on a virtual network in Asia to communicate with another Windows Azure VM on a virtual network located in South America, the end-to-end communication must traverse the internal network.

  • While you have complete control over what server resources to use for VMs on-premises, such as how much RAM, disk size, and so on, on Windows Azure, you must select from a list of preconfigured server sizes. For a DC, choose a size that allows you to attach at least two disks – one Operating System disk and one data disk. The disk is needed to store the Windows Server Active Directory database. For more information about the computing resources that are available, see 7 Things to Know About Windows Azure Capacity.

  • Virtualization safeguards and DC cloning features in Windows Server 2012 are NOT supported on this version of Windows Azure. Even if you run Windows Server 2012 on a Windows Azure VM, the virtual DC cloning feature will not work in your Windows Server Active Directory forest. Virtualization safeguards and virtual DC cloning require support for VM generation ID in both the hypervisor and the Windows Server operating system. Windows Azure does not currently support VM generation ID.

Three prominent advantages of deploying AD FS on Windows Azure are:

  • You can provide high availability for AD FS by using the native server load balancing capabilities of Windows Azure virtual machines.

  • You can more simply deploy a set of federated applications to employees and partners without the complexities and requirements inherent in deploying AD FS in a perimeter network.

  • You can deploy corporate domain controllers alongside AD FS on Windows Azure virtual machines, which provides additional guarantees of service availability in the event of unforeseen failures such as natural disasters. This is especially true for online services such as Microsoft Office 365 that can authenticate users directly from their on-premises corporate Active Directory.

Deploying Windows Server AD FS on Windows Azure is very similar to doing so on-premises, however, differences do exist. Any Windows Server AD FS requirement for Windows Azure Virtual Network to connect back to the on-premises network depends upon the relative placement of the roles. That is, if Windows Server AD FS is running on Windows Azure and its domain controllers are deployed only on-premises, then Windows Azure Virtual Network must connect the virtual machines back to the on-premises network using its site-to-site VPN capabilities.

  • If you deploy a Windows Server AD FS proxy server on a Windows Azure virtual machine, connectivity to the AD FS federation servers is needed. If they are on-premises, it is recommended that you leverage the site-to-site VPN connectivity provided by the virtual network to allow the proxy servers to communicate with their federation servers.

  • If you deploy a Windows Server AD FS federation server on a Windows Azure virtual machine, connectivity to Windows Server Active Directory domain controllers, Attribute Stores, and Configuration databases is required.

  • If you deploy Windows Server AD FS (or any other workload) on a Windows Azure virtual machine so that it can be reached directly from the Internet, it is necessary to configure the cloud service to expose public-facing ports that map to the AD FS http (80 by default) and https (443 by default) ports.

  • Similarly, if you deploy and configure Windows Server AD FS on Windows Azure virtual machines so that it can be reached directly from the Internet, it is also advisable to treat the cluster as though it were deployed on a perimeter network, which includes additional considerations such as server hardening or deploying Windows Server AD FS proxy instead of the Windows Server AD FS federation server role itself.

  • Charges are applied to all Windows Azure virtual machine egress traffic. If cost is the driving factor, it is advisable to deploy Windows Server AD FS proxy on Windows Azure, leaving the Windows Server AD FS federation servers on-premises. If Windows Server AD FS federation is deployed on Windows Azure virtual machines instead of Windows Server AD FS proxy, it could create unnecessary costs to authenticate intranet users.

  • Use of Windows Azure’s native server load balancing capabilities for high availability of Windows Server AD FS servers in your deployment is recommended. Windows Azure software load balancing is supported only by VIPs, not by DIPs. The load balancing provides probes that are used to determine the health of the virtual machines within the cloud service. In the case of Windows Azure Virtual Machines (as opposed to web or worker roles), a custom probe must be used since the agent that responds to the default probes is not present on Windows Azure virtual machines. For simplicity, you might use a custom TCP probe — this requires only that a TCP connection (a syn ack) be successfully established to determine virtual machine health. You can configure the custom probe to use any TCP port that is actively listening on your virtual machines. To do so, see Windows Azure load-balancer probe.

    noteNote
    Machines that need to expose the same set of ports directly to the Internet (such as port 80 and 443) cannot share the same cloud service. It is, therefore, recommended that you create a dedicated cloud service for your Windows Server AD FS servers in order to avoid potential overlaps between port requirements for an application and Windows Server AD FS.

The following section outlines commonplace deployment scenarios that draw attention to important considerations that must be taken into account. Each scenario has links to more details about the decisions and factors to consider.

Cloud-only AD DS deployment

Figure 1

SharePoint is deployed on a Windows Azure virtual machine and the application has no dependencies on corporate-network resources. The application does require Windows Server AD DS but does NOT require the corporate Windows Server AD DS. No Kerberos or federated trusts are required because users are self-provisioned through the application into the Windows Server AD DS domain that is also hosted in the cloud on Windows Azure virtual machines.

  • Network topology: Create a Windows Azure Virtual Network without cross-premises connectivity (also known as site-to-site connectivity).

  • DC deployment configuration: Deploy a new domain controller into a new, single-domain, Windows Server Active Directory forest. This should be deployed along with the Windows DNS server and must be configured and running before other virtual machines since its IP address must be known prior to configuring the other virtual machines DNS resolver settings.

  • Windows Server Active Directory site topology: Use the default Windows Server Active Directory site (all computers will be in Default-First-Site-Name)

  • IP addressing and DNS:

    1. Use DHCP-leased addresses (this is mandatory — static addresses are NOT supported)

    2. Install and configure Windows Server DNS on the domain controller(s) on Windows Azure.

    3. Configure your virtual machines DNS resolver settings and point them to the DC’s IP address. DNS resolver settings are configured using a Windows PowerShell cmdlet as described in the IP addressing and DNS section.

      noteNote
      The DNS resolver configurations tasks must be performed at the same time as you provision the virtual machines that will run the applications you host on Windows Azure. By specifying the DNS resolver settings during provisioning, the settings will persist on the VM through service healing.

  • Global Catalog: The first DC in the forest must be a global catalog server. Additional DCs should also be configured as GCs because in a single domain forest, the global catalog does not require any additional work from the DC.

  • Placement of the Windows Server AD DS database and SYSVOL: Add a data disk to DCs running as Windows Azure VMs in order to store the Windows Server Active Directory database, logs, and SYSVOL.

  • Backup and Restore: Determine where you want to store system state backups. If necessary, add another data disk to the DC VM to store backups.

Federation with cross-premises connectivity

Figure 2

A claims-aware application that has been successfully deployed on-premises and used by corporate users needs to become accessible directly from the Internet. The application serves as a web frontend to a SQL database in which it stores and retrieves data. The SQL servers used by the application are also located on the corporate network. Two Windows Server AD FS federation servers and a load-balancer have been deployed on-premises to provide access to the corporate users. The application now needs to be additionally accessed directly over the Internet by both business partners using their own corporate identities and by existing corporate users.

In an effort to simplify and meet the deployment and configuration needs of this new requirement, it is decided that two additional web frontends and two Windows Server AD FS proxy servers be installed on Windows Azure virtual machines. All four VMs will be exposed directly to the Internet and will be provided connectivity to the on-premises network using Windows Azure virtual network’s site-to-site VPN capability.

  • Network topology: Create a Windows Azure Virtual Network and configure cross-premises connectivity.

    noteNote
    For each of the Windows Server AD FS certificates, ensure that the URL defined within the certificate template and the resulting certificates can be reached by the Windows Server AD FS instances running on Windows Azure. This may require cross-premises connectivity to parts of your PKI infrastructure. For example if the CRL's endpoint is LDAP-based and hosted exclusively on-premises, then cross-premises connectivity will be required. If this is not desirable, it may be necessary to use certificates issued by a CA whose CRL is accessible over the Internet.

  • Cloud services configuration: Ensure you have two cloud services in order provide two load-balanced VIPs. The first cloud service’s VIP will be directed to the two Windows Server AD FS proxy VMs on ports 80 and 443. The Windows Server AD FS proxy VMs will be configured to point to the IP address of the on-premises load-balancer that fronts the Windows Server AD FS federation servers. The second cloud service’s VIP will be directed to the two VMs running the web frontend again on ports 80 and 443. Configure a custom probe to ensure the load-balancer only directs traffic to functioning Windows Server AD FS proxy and web frontend VMs.

  • Federation server configuration: Configure Windows Server AD FS as a federation server to generate security tokens for the Windows Server Active Directory forest created in the cloud. Set federation claims provider trust relationships with the different partners you wish to accept identities from, and configure relying party trust relationships with the different applications you want to generate tokens to.

    In most scenarios, Windows Server AD FS proxy servers are deployed in an Internet-facing capacity for security purposes while their Windows Server AD FS federation counterparts remain isolated from direct Internet connectivity. Regardless of your deployment scenario, you must configure your cloud service with a VIP that will provide a publicly exposed IP address and port that is able to load-balance across either your two Windows Server AD FS federation instances or proxy instances.

  • Windows Server AD FS high availability configuration: It is advisable to deploy a Windows Server AD FS farm with at least two servers for failover and load balancing. You might want to consider using the Windows Internal Database (WID) for Windows Server AD FS configuration data, and use the native server load balancing capability of Windows Azure to distribute incoming requests across the servers in the farm. Windows Azure’s native load-balancing is only supported when using an Internet-facing VIP; DIPs cannot be load balanced.

    For more information, see the AD FS 2.0 Deployment Guide.

Cross-premises AD DS deployment

Figure 3

An LDAP-aware application that supports Windows-integrated authentication and uses Windows Server AD DS as a repository for configuration and user profile data is deployed on a Windows Azure virtual machine. It is desirable for the application to leverage the existing corporate Windows Server AD DS and provide single-sign-on. The application is not claims-aware. Users also need to access the application directly from the Internet. To optimize for performance and cost, it is decided that two additional domain controllers that are part of the corporate domain be deployed alongside the application on Windows Azure.

  • Network topology: Create a Windows Azure Virtual Network with cross-premises connectivity. This will require that deploy a compatible VPN endpoint on the edge of the corporate network. For more information, see About VPN Devices for Virtual Network.

  • Installation method: Deploy replica DCs from the corporate Windows Server Active Directory domain. For a replica DC, you can run dcpromo on the VM, and optionally, use the Install From Media (IFM) feature to reduce the amount of data that needs to be replicated to the new DC during installation. For a tutorial, see Install a replica Active Directory DC in Windows Azure Virtual Network. Even if you use IFM, it may be more efficient to build the virtual DC on-premises and move the entire VHD to the cloud instead of replicating Windows Server AD DS during installation. For safety, it is recommended that you delete the VHD from the on-premises network once it has been copied to Windows Azure.

  • Windows Server Active Directory site topology: Create a new Windows Azure site in Active Directory Sites and Services. Create a Windows Server Active Directory subnet object to represent the Windows Azure virtual network and add the subnet to the site. Create a new site link that includes the new Windows Azure site and the site in which the Windows Azure virtual network VPN endpoint is located in order to control and optimize Windows Server Active Directory traffic to and from Windows Azure.

  • IP addressing and DNS:

    1. Use DHCP-leased addresses (this is mandatory — static addresses are NOT supported)

    2. Install and configure Windows Server DNS on the domain controller(s) on Windows Azure.

    3. Configure both the DCs’ and the domain-members’ DNS client resolver settings as follows:

      Preferred DNS server: on-premises DNS server

      Alternate DNS server: loopback address (if running the DNS server role) or another DNS server running on the same virtual network

      noteNote
      The initial DNS resolver configurations tasks must be performed at the same time as you provision the virtual machines that will run the applications you host on Windows Azure. DNS resolver settings are configured using a Windows PowerShell cmdlet as described in the IP addressing and DNS section. By specifying the DNS resolver settings during provisioning, the settings will persist on the VM through service healing.

      Once you have completed the deployment and configuration of all the virtual machines, it is optimal from a cost perspective to switch the preferred and alternate DNS resolvers on each virtual machine to ensure that name resolution occurs entirely in the cloud, eliminating any cost incurred by sending DNS traffic across the site-to-site VPN. The initial configuration of the DNS resolvers was necessary because the IP address of the virtual machine running the DNS server is not known until it has been deployed and configured.

  • Geo-distributed DCs: Configure additional virtual networks as needed. If direct communication is required between the virtual networks, both must be configured to use their site-to-site VPN capabilities and all traffic between them will be routed through the internal corporate network.

  • Read-only DCs: You might deploy an RODC in the Windows Azure site, depending on your requirements for performing write operations against the DC and the compatibility of applications and services in the site with RODCs. For more information about application compatibility, see Read-Only Domain Controllers Application Compatibility Guide.

  • Global Catalog: GCs are needed to service logon requests in multidomain forests. If you do not deploy a GC in the Windows Azure site, you will incur egress traffic costs as authentication requests cause queries GCs in other sites. To minimize that traffic, you can enable universal group membership caching for the Windows Azure site in Active Directory Sites and Services.

    If you deploy a GC, configure sites links and site links costs so that the GC in the Windows Azure site is not preferred as a source DC by other GCs that need to replicate the same partial domain partitions.

  • Placement of the Windows Server AD DS database and SYSVOL: Add a data disk to DCs running on Windows Azure VMs in order to store the Windows Server Active Directory database, logs, and SYSVOL.

  • Backup and Restore: Determine where you want to store system state backups. If necessary, add another data disk to the DC VM to store backups.

This table summarizes the Windows Server Active Directory technology areas that are impacted in the preceding scenarios and the corresponding decisions to consider and links to more detail below. Some technology areas might not be applicable to every deployment scenario, and some technology areas might be more critical to a deployment scenario than other technology areas.

For example, if you deploy a replica DC on a virtual network and your forest has only a single domain, then choosing to deploy a global catalog server in that case will not be critical to the deployment scenario because it will not create any additional replication requirements. On the other hand, if the forest has several domains, then the decision to deploy a global catalog on a virtual network could affect available bandwidth, performance, authentication, directory lookups, and so on.

 

Item Number

Windows Server Active Directory Technology Area

Decisions

Factors

1

Network topology

Do you create a virtual network?

Requirements to access Corp resources

Authentication

Account management

2

DC deployment configuration

  • Deploy a separate forest without any trusts?

  • Deploy a new forest with federation?

  • Deploy a new forest with Windows Server Active Directory forest trust for Kerberos?

  • Extend Corp forest by deploying a replica DC?

  • Extend Corp forest by deploying a new child domain or domain tree?

Security

Compliance

Cost

Resiliency and fault-tolerance

Application compatibility

3

Windows Server Active Directory site topology

How do you configure subnets, sites and site links with Windows Azure Virtual Network to optimize traffic and minimize cost?

Subnet and site definitions

Site link properties and change notification

Replication compression

4

IP addressing and DNS

How to configure IP addresses and name resolution?

Use Windows Azure DHCP leased addresses only

Install Windows Server DNS server

Configure DNS client using Windows PowerShell

5

Geo-distributed DCs

How to replicate to DCs on separate virtual networks?

No direct communication between geographically separate virtual networks

6

Read-only DCs

Use read-only or writeable DCs?

Filter HBI/PII attributes

Filter secrets

Limit outbound traffic

7

Global Catalog

Install global catalog?

For single-domain forest, make all DCs GCs

For multidomain forest, GCs are required for authentication

8

Installation method

How to install DC in Azure?

ImportantImportant
Do not use SYSPREP to clone DCs. Windows Server 2012 virtual domain controller cloning is NOT supported by Windows Azure virtual machines.

  • Dcpromo

-Or-

  • Move VHD of an on-premises virtual DC

9

Placement of the Windows Server AD DS database and SYSVOL

Where to store Windows Server AD DS database, logs, and SYSVOL?

Change Dcpromo.exe default values

ImportantImportant
These critical Active Directory files MUST be placed on Windows Azure Data Disks instead of Operating System disks that implement write caching.

10

Backup and Restore

How to safeguard and recover data?

Create system state backups

Do not copy or clone VHD files

11

Federation server configuration

Deploy a new forest with federation in the cloud?

Deploy AD FS on-premises and expose a proxy in the cloud?

Security

Compliance

Cost

Access to applications by business partners

12

Cloud services configuration

A cloud service is implicitly deployed the first time you create a virtual machine. Do you need to deploy additional cloud services?

Does a VM or VMs require direct exposure to the Internet?

Does the service require load-balancing?

13

Federation server requirements for public and private IP addressing (DIP vs. VIP)

Does the Windows Server AD FS instance need to be reached directly from the Internet?

Does the application being deployed in the cloud require its own Internet-facing IP address and port?

Create one cloud-service for each VIP that is required by your deployment

14

Windows Server AD FS high availability configuration

How many nodes in my Windows Server AD FS server farm?

How many nodes to deploy in my Windows Server AD FS proxy farm?

Resiliency and fault tolerance

In order to meet the IP address consistency and DNS requirements of Windows Server AD DS, it is necessary to first create a Windows Azure Virtual Network and attach your virtual machines to it. During its creation, you must decide whether to optionally extend connectivity to your on-premises corporate network, which transparently connects Windows Azure virtual machines to on-premises machines — this is achieved using traditional VPN technologies and requires that a VPN endpoint be exposed on the edge of the corporate network. That is, the VPN is initiated from Windows Azure to the corporate network, not vice-versa.

Note that additional charges apply when extending a virtual network to your on-premises network beyond the standard charges that apply to each VM. Specifically, there are charges for CPU time of the Windows Azure Virtual Network gateway and for the egress traffic generated by each VM that communicates with on-premises machines across the VPN. For more information about network traffic charges, see Windows Azure Pricing Overview.

The way you configure the DC depends on the requirements for the service you want to run on Windows Azure. For example, you might deploy a new forest, isolated from your own corporate forest, for testing a proof-of-concept, a new application, or some other short term project that requires directory services but not specific access to internal corporate resources.

As a benefit, an isolated forest DC does not replicate with on-premises DCs, resulting in less outbound network traffic generated by the system itself, directly reducing costs. For more information about network traffic charges, see Windows Azure Pricing Overview.

As another example, suppose you have privacy requirements for a service, but the service depends on access to your internal Windows Server Active Directory. If you are allowed to host data for the service in the cloud, you might deploy a new child domain for you internal forest on Windows Azure. In this case, you can deploy a DC for the new child domain (without the global catalog in order to help address privacy concerns). This scenario, along with a replica DC deployment, requires a virtual network for connectivity with your on-premises DCs.

If you create a new forest, choose whether to use Active Directory trusts or Federation trusts. Balance the requirements dictated by compatibility, security, compliance, cost, and resiliency. For example, to take advantage of selective authentication, you might choose to deploy a new forest on Windows Azure and create a Windows Server Active Directory trust between the on-premises forest and the cloud forest. If the application is claims-aware, however, you might deploy federation trusts instead of Active Directory forest trusts. Another factor will be the cost to either replicate more data by extending your on-premises Windows Server Active Directory to the cloud or generate more outbound traffic as a result of authentication and query load.

Requirements for availability and fault tolerance also affect your choice. For example, if the link is interrupted, applications leveraging either a Kerberos trust or a federation trust are all likely entirely broken unless you have deployed sufficient infrastructure on Windows Azure. Alternative deployment configurations such as replica DCs (writeable or RODCs) increase the likelihood of being able to tolerate link outages.

You need to correctly define sites and site links in order to optimize traffic and minimize cost. Sites, site-links and subnets affect the replication topology between DCs and the flow of authentication traffic. Consider the following traffic charges and then deploy and configure DCs according to the requirements of you deployment scenario:

  • There is a nominal fee per hour for the gateway itself:

    • It can be started and stopped as you see fit

    • If stopped, Windows Azure VMs are isolated from the corporate network

  • Inbound traffic is free

  • Outbound traffic is charged for according to Windows Azure Pricing Overview. You can optimize site link properties between on-premises sites and the cloud sites as follows:

    • If you are using multiple virtual networks, configure the site-links and their costs appropriately to prevent Windows Server AD DS from prioritizing the Windows Azure site over one that can provide the same levels of service at no charge. You might also consider disabling the Bridge all site link (BASL) option (which is enabled by default). This ensures that only directly-connected sites replicate with one another. DCs in transitively connected sites are no longer able to replicate directly with each other, rather, they must replicate through a common site or sites. If the intermediary sites become unavailable for some reason, replication between DCs in transitively connected sites will not occur even if connectivity between the sites is available. Finally, where sections of transitive replication behavior remain desirable, create site link bridges that contain the appropriate site-links and sites, such as on-premises, corporate network sites.

    • Configure site link costs appropriately to avoid unintended traffic. For example, if Try Next Closest Site setting is enabled, make sure the virtual network sites are not the next closest by increasing the cost associated of the site-link object that connects the Windows Azure site back to the corporate network.

    • Configure site link intervals and schedules according to consistency requirements and rate of object changes. Align replication schedule with latency tolerance. DCs replicate only the last state of a value, so decreasing the replication interval can save costs if there is a sufficient object change rate.

  • If minimizing costs is a priority, ensure replication is scheduled and change notification is not enabled this is the default configuration when replicating between sites. This is not important if you are deploying an RODC on a virtual network because the RODC will not replicate any changes outbound. But if you deploy a writable DC, you should make sure the site link is not configured to replicate updates with unnecessary frequency. If you deploy a global catalog server (GC), make sure that every other site that contains a GC replicates domain partitions from a source DC in a site that is connected with a site-link or site-links that have a lower cost than the GC in the Windows Azure site.

  • It is possible to further still reduce network traffic generated by replication between sites by changing the replication compression algorithm. The compression algorithm is controlled by the REG_DWORD registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Replicator compression algorithm. The default value is 3, which correlates to the Xpress Compress algorithm. You can change the value to 2, which changes the algorithm to MSZip. In most cases, this will increase the compression, but it does so at the expense of CPU utilization. For more information, see How Active Directory Replication Topology Works.

Windows Azure virtual machines require “DHCP-leased addresses” and, as noted earlier, this appears contradictory to existing best-practices. Because Windows Azure virtual network dynamic addresses persist with a virtual machine for the lifetime of the virtual machine, the requirements of Windows Server AD DS are met. While the use of static addresses may initially appear to function adequately, over time, using them will ultimately result in a complete loss of connectivity to the virtual machine and between affected virtual machines.

As a result, when you use a dynamic address on Windows Azure, you are in effect using a static IP address because it is routable for the period of the lease, and the period of the lease is equal to the lifetime of the cloud service. The IP address will persist even through the Windows Azure service healing process.

For name resolution, deploy your own (or leverage your existing) DNS server infrastructure; Windows Azure-provided DNS does not meet the advanced name resolution needs of Windows Server AD DS. For fault tolerance and performance reasons, it is optimal to install the Windows Server DNS service on the DCs running on Windows Azure. Windows Azure-provided DNS does not meet the name resolution needs of Windows Server AD DS. For example, it does not support dynamic SRV records, and so on. Name resolution is a critical configuration item for DCs and domain-joined clients. DCs must be capable of registering resource records and resolving other DC’s resource records.

noteNote
You cannot join on-premises computers to a Windows Server AD DS Active Directory domain that is hosted on Windows Azure directly over the Internet. The port requirements for Active Directory and the domain-join operation render it impractical to directly expose the necessary ports, and in effect, an entire DC, to the Internet.

We recommend you configure DNS resolver settings on VMs as follows:

  • Preferred DNS server: on-premises DNS server

  • Alternate DNS server: loopback address or another DNS server running on a DC on the virtual network

The DNS server infrastructure must be configured for the VMs when the VMs are provisioned at the deployment level, and configured by using Windows PowerShell (there is no web-based user interface to perform the operation in the Windows Azure portal), as shown in the following example.

Copy 
#Deploy a new VM and join it to the domain
#-------------------------------------------
#Specify my DC's DNS IP (10.4.3.1)
$myDNS = New-AzureDNS -Name 'ContosoDC13' -IPAddress '10.4.3.1'

# Operating System Image to Use
$image = 'MSFT__Sql-Server-11EVAL-11.0.2215.0-08022012-en-us-30GB.vhd'
$service = 'myazuresvcindomainM1'
$AG = 'YourAffinityGroup'
$vnet = 'YourVirtualNetwork'
$pwd = 'p@$$w0rd'
$size = 'Small'

#VM Configuration
$vmname = 'MyTestVM1'
$MyVM1 = New-AzureVMConfig -name $vmname -InstanceSize $size -ImageName $image | Add-AzureProvisioningConfig -WindowsDomain -Password $pwd -Domain 'corp' -DomainPassword 'p@$$w0rd' -DomainUserName 'Administrator' -JoinDomain 'corp.contoso.com'| Set-AzureSubnet -SubnetNames 'SubnetName'

New-AzureVM -ServiceName $service -AffinityGroup $AG -VMs $MyVM1 -DnsSettings $myDNS -VNetName $vnet

VMs register their DNS name automatically on startup or when there is a name change.

For more information about this example and another example that shows how to provision the first VM and install AD DS on it, see Install a new Active Directory forest on Windows Azure. For more information about using Windows PowerShell, see Getting Started with Windows Azure PowerShell and Windows Azure Management Cmdlets.

Windows Azure offers advantages when hosting multiple DCs on different virtual networks:

  • Multi-site fault-tolerance

  • Physical proximity to branch offices (lower latency)

But no direct communication exists between Windows Azure virtual networks. Any communication between different Windows Azure virtual networks must be routed through the on-premises network, which may generate large amounts of outbound traffic (and the costs associated with that traffic).

No connectivity between virtual networks

Figure 4

You need to choose whether to deploy read-only or writeable DCs. You might be inclined to deploy RODCs because you will not have physical control over them, but RODCs are designed to de deployed in locations where their physical security is at risk, such as branch offices.

Windows Azure does not present the physical security risk of a branch office, but RODCs might still prove to be more cost effective because the features they provide are well-suited to these environments albeit for very different reasons. For example, RODCs have no outbound replication and are able to selectively populate secrets (passwords). On the downside, the lack of these secrets might require on-demand outbound traffic to validate them as a user or computer authenticates. But secrets can be selectively prepopulated and cached.

RODCs provide an additional advantage in and around HBI and PII concerns because you can add attributes that contain sensitive data to the RODC filtered attribute set (FAS). The FAS is a customizable set of attributes that are not replicated to RODCs. You can use the FAS as a safeguard in case you are not permitted or do not want to store PII or HBI on Windows Azure. For more information, see RODC Filtered Attribute Set.

Make sure that applications will be compatible with RODCs you plan to use. Many Windows Server Active Directory-enabled applications work well with RODCs, but some applications can perform inefficiently or fail if they do not have access to a writable DC. For more information, see Read-Only DCs Application Compatibility Guide.

You need to choose whether to install a global catalog. In a single domain forest, you should configure all DCs as global catalog (GC) servers. It will not increase costs because there will be no additional replication traffic.

In a multidomain forest, GCs are necessary to expand Universal Group memberships during the authentication process. If you do not deploy a GC, workloads on the virtual network that authenticate against a DC on Windows Azure will indirectly generate outbound authentication traffic to query GCs on-premises during each authentication attempt.

The costs associated with GCs are less-predictable because they host every domain (in-part). If the workload hosts an Internet-facing service and authenticates users against Windows Server AD DS, the costs could be completely unpredictable. To help reduce GC queries outside of the cloud site during authentication, you can enable Universal Group Membership Caching.

You need to choose how to install the DCs on the virtual network:

Use only Windows Azure Virtual Machines for DCs (as opposed to Windows Azure “web” or “worker” role VMs). They are durable and durability of state for a DC is required. Windows Azure Virtual Machines are designed for workloads such as DCs.

Do not use SYSPREP to deploy or clone DCs. The ability to clone DCs is available only in Windows Server 2012. The cloning feature requires support for VMGenerationID in the underlying hypervisor. Hyper-V in Windows Server 2012 supports VMGenerationID, as do third-party virtualization software vendors. Windows Azure does not currently support VMGenerationID.

Select where to locate the Windows Server AD DS database, logs, and SYSVOL. They must be deployed on Windows Azure Data Disks. “Data Disks” and “Operating System Disks” are two distinct virtual-disk drive types for Windows Azure. They exhibit different behaviors (and different defaults).

noteNote
Windows Azure Data Disks are constrained to 1 TB.

Unlike Operating System disk drives, data disk drives do not cache writes by default. Data disk drives that are attached to a VM use write-through caching. Write-through caching makes sure the write is committed to durable Windows Azure Storage before the transaction is complete from the perspective of the VM’s operating system. It provides durability, at the expense of slightly slower writes.

This is important for Windows Server AD DS because write-behind disk-caching invalidates assumptions made by the DC. Windows Server AD DS attempts to disable write caching but it is up to the disk IO system to honor it. Failure to disable write caching may, under certain circumstances, introduce USN rollback resulting in lingering objects and other problems.

As a best practice for virtual DCs, store the database, logs, and SYSVOL on the either same data disk or separate data disks. Typically, this is a separate disk from the disk used for the operating system itself. The key takeaway is that the Windows Server AD DS database and SYSVOL must not be stored on a Windows Azure Operating System disk type. By default, dcpromo.exe installs these components in %systemroot% folder, which is NOT recommended for Windows Azure.

Be aware of what is and is not supported for backup and restore of a DC in general, and more specifically, those running in a VM. See Backup and Restore Considerations for Virtualized DCs.

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.

Do not copy or clone VHD files of DCs instead of performing regular backups. Should a restore ever be required, doing so using cloned or copied VHDs without Windows Server 2012 and a supported hypervisor will introduce USN bubbles.

The configuration of Windows Server AD FS federation servers depends in part on whether the applications that you want to deploy on Windows Azure need to access resources on your on-premises network.

If the applications meet the following criteria, you could deploy the applications in isolation from your on-premises network.

  • They accept SAML security tokens

  • They are exposable to the Internet

  • They do not access on-premises resources

In this case, configure Windows Server AD FS federation servers as follows:

  1. Configure an isolated single-domain forest on Windows Azure.

  2. Provide federated access to the forest by configuring a Windows Server AD FS federation server farm.

  3. Configure Windows Server AD FS (federation server farm and federation server proxy farm) in the on-premises forest.

  4. Establish a federation trust relationship between the on-premises and Windows Azure instances of Windows Server AD FS.

On the other hand, if the applications require access to on-premises resources, you could configure Windows Server AD FS with the application on Windows Azure as follows:

  1. Configure connectivity between on-premises networks and Windows Azure.

  2. Configure a Windows Server AD FS federation server farm in the on-premises forest.

  3. Configure a Windows Server AD FS federation server proxy farm on Windows Azure.

This configuration has the advantage of reducing the exposure of on-premises resources, similar to configuring Windows Server AD FS with applications in a perimeter network.

Note that in either scenario, you can establish trusts relationships with more identity providers, if business-to-business collaboration is needed.

Cloud services are necessary if you want to expose a VM directly to the Internet or to expose an Internet-facing load-balanced application. This is possible because each cloud service offers a single configurable VIP.

Each Windows Azure virtual machine receives a DIP. A DIP is a private address accessible only within Windows Azure. In most cases, however, it will be necessary to configure a VIP for your Windows Server AD FS deployments. The VIP is necessary to expose Windows Server AD FS endpoints to the Internet which will be used by federated partners and clients for authentication and ongoing management. A VIP is a property of a cloud service which contains one or more Windows Azure virtual machines. If the claims-aware application deployed on Windows Azure and Windows Server AD FS are both Internet-facing and share common ports, each will require a VIP of its own and it will therefore be necessary to create one cloud service for the application and a second for Windows Server AD FS.

For definitions of the terms VIP and DIP, see Terms and definitions.

While it is possible to deploy standalone Windows Server AD FS federation services, it is recommended to deploy a farm with at least two nodes for both Windows Server AD FS federation server and federation server proxy roles for production environments.

See AD FS 2.0 Deployment Topology Considerations in the AD FS 2.0 Design Guide to decide which deployment configuration options best suit your particular needs.

noteNote
In order to get load balancing for Windows Server AD FS endpoints on Windows Azure, configure all members of the Windows Server AD FS farm in the same cloud service, and use the load balancing capability of Windows Azure for HTTP (default 80) and HTTPS ports (default 443). For more information, see Windows Azure load-balancer probe.

Windows Server Network Load Balancing (NLB) is not supported on Windows Azure.

Windows Azure load-balancing is only supported when using a VIP. You cannot load-balance directly against the DIPs of two or more virtual machines.

Did you find this helpful?
(1500 characters remaining)

Community Additions

ADD
© 2013 Microsoft. All rights reserved.
facebook page visit twitter rss feed newsletter