Active Directory Domain Services on Windows Azure Virtual

Active Directory Domain Services on Windows Azure Virtual Machines Why are we even discussing AD? • Windows Azure Terminology • Deployment Scenarios & Decisions • General Considerations •

Objectives • Talk about the notion of deploying AD DS on Windows Azure Virtual Machines • Shed some light on the areas of Windows Azure that: • • must be configured for a cross-premises Windows Azure cloud deployment differ in some way to the running DC’s on-premises • Emphasise how to optimise for cost and performance • Highlight the technical considerations for various deployment scenarios

First, a point of clarification • Is what we’re discussing here the same as Windows Azure Active Directory? • • No In this session, we’re discussing running traditional on-premises domain controllers on Windows Azure’s new Iaa. S virtual machines • What is Windows Azure Active Directory then? • • WAAD is a service that provides identity and access capabilities for cloud applications A version of the AD that is better suited to the cloud i. e. no central store, but claims based instead

Windows Active Directory (WAD) Windows Azure Active Directory (WAAD) • • Hosted on-premises or Cloud You manage the infrastructure and data • Services: • Authentication & Authorisation • Kerberos authentication • NTLM authentication • For more information, see Ulrik Bærholm’s session from yesterday (AZ 302) or http: //www. windowsazure. com/en-us/home/features/identity/ • • Hosted in the cloud only i. e. in our datacenters We manage the infrastructure, you manage the data • Services: • Authentication & Authorisation • Federated Authentication • WS-Federation • SAML

Why are we even discussing AD?

Why are we even discussing AD? Virtual Machines on Windows Azure vs On-premises • Cost (Significantly cheaper than on-premise hosting) • High availability (99. 9% uptime) • Security (Secure Microsoft datacenters) • “We will not disclose Customer Data to a third party (including law enforcement, government entity or civil litigant) except as directed by you or required by law. ” • Scalability (Resources available on the fly) • 1 million servers in Windows Azure, each with 48 cores and 96 GB RAM. This will be 5 million by 2017 • Flexibility (Best of both worlds - integration between on-premise and cloud)

Why are we even discussing AD? • What are some of the business drivers? • A support pre-requisite for other Applications or Services e. g. Share. Point • To serve as a substitute or failover for a site i. e. a DR site • To serve as an authentication mechanism for a cloud only data center • Remote branch office site with no I. T. presence and or infrastructure • Management of cloud VM’s eg. GPO’s or the new management console

Why are we even discussing AD? (continued) • Design aspect • The AD’s topology should be optimally defined – not just a DCPROMO • Placing Active Directory DCs in Windows Azure equates to running virtualized DCs • Windows Azure hypervisor fully supports VM-Gen. ID & snapshots (WS 2012 & 2012 R 2 only)

Windows Azure Terminology

Windows Azure Terminology • Windows Azure Virtual Machines • Iaa. S (Infrastructure as a Service) offering that allows you to deploy VMs in the cloud hosting virtually any server workload similarly to virtual machines on-premises • Windows Azure Virtual Network • the networking component that allows you to create and manage virtual networks in Windows Azure and securely connect them to your own on-premises network • Virtual IP address (VIP) • • an internet-facing IP address that is not bound to a specific computer or network interface card deployments are assigned a VIP for receiving network traffic which is redirected to a VM in the Windows Azure

Windows Azure Terminology • Dynamic IP address (DIP) • • • Not as obvious as you might first think This is the IP address that will be dynamically assigned to a virtual network adapter by Windows Azure the IP address persists with that same virtual machine for the entire lifetime of the deployment

Windows Azure Terminology • Service Healing “In the unlikely event of a change in cabin-pressure, oxygen masks will automatically drop from the ceiling above you…” • as unlikely and unplanned as they most certainly are, we still need to understand what happens • What is Service healing? • • • a process in which Windows Azure automatically restores VMs to a running state after it detects that a given service has failed Service-healing is one of the aspects of Windows Azure that contributes to availability and resiliency such an event is perceived by Active Directory domain controllers as an unplanned reboot

Windows Azure Terminology • What affect does service-healing have on domain controllers? • • the MAC address of the domain controller WILL change The CPU ID of the VM WILL also change the IP address of the VM will NOT change • requires that the VM is deployed on a Windows Azure virtual network writes to Active Directory’s DIT/logs/sysvol will NOT be lost • requires that the Windows Azure disk-type holding them does not provide write-behind caching (use “data-disks”, not “OS-disks”) • Do the preceding behaviors affect Active Directory? • • no, domain controllers take NO dependency on MAC address or CPU ID • again, ensure you deploy the Active Directory DCs on a Windows Azure virtual network ensure that writes to Active Directory’s databases are durable • use Windows Azure “data-disks”

Windows Azure Terminology • Affinity Groups • Is a Windows Azure feature that allows you to group components into the closest proximity to improve performance. • Availability Sets • Is a Windows Azure feature that allows you to place virtual servers in different physical rack locations for resiliency.

Deployment Scenarios & Decisions

Hybrid, Cloud only or both? • Hybrid Deployment (Extending existing AD) • • Applications need access to corporate directory data Applications need to authenticate users from a corporate directory

Hybrid, Cloud only or both? • Cloud Only Deployment (New & Isolated AD) • • Isolated from corporate AD Support cloud only applications and services

Hybrid, Cloud only or both? • Hybrid & Cloud (Existing AD federated/trust New & Isolated AD) • • Cloud applications need access to corporate directory data & isolated from corporate AD Cloud only applications need to authenticate users from corporate directory

Hybrid, Cloud only or both? • Network topology • Extension of Azure Virtual Network requires a VPN endpoint exposed from on-premises • Azure Virtual DC • • 14 GB Ram limit A single network adaptor • Backup and Restore • • • Create systemstate backups Use Availability Sets for multiple DC’s Do NOT snapshot or copy VHD files (pre WS 2012 & WS 2012 R 2)

General Considerations

• Is it safe to virtualize DCs? • Placement of the Active Directory database (DIT) • Optimizing your deployment for traffic and cost • Read-Only DCs (RODC) or Read-Writes? • Global Catalog or not? • Trust or Replicate? • IP addressing and name resolution • Geo-distributed cloud-hosted domain controllers

• Background • common virtualization operations such as backing up/restoring VMs/VHDs can rollback the state of a virtual DC • with Active Directory, this can introduce USN bubbles leading to permanently divergent state causing: • lingering objects • inconsistent passwords • inconsistent attribute values • schema mismatches if the Schema FSMO is rolled back • the potential also exists for security principals to be created with duplicate SIDs

DC 2 Timeline of events DC 1 TIME: T 1 Create Snapshot USN: 100 ID: A RID Pool: 500 - 1000 +100 users added TIME: T 2 USN rollback NOT detected: only 50 users converge across the two DCs 200 on one or the other DC All others. USN: are either DC 2 receives updates: USNs >100 RID Pool: 600 ID: Aprincipals 100 security (users in 1000 this example) with RIDs 500 -599 have conflicting SIDs DC 1(A) @USN = 200 TIME: T 3 T 1 Snapshot USN: 100 Applied! ID: A RID Pool: 500 - 1000 +150 more users created TIME: T 4 USN: 250 ID: A RID Pool: 650 - 1000 DC 2 receives updates: USNs >200 DC 1(A) @USN = 250

Virtualization conclusions • Use only Windows Azure Virtual Machines (Iaa. S) • as opposed to worker-role or web-role instances • virtual machines’ disk-writes are durable and designed for these workloads • Do not SYSPREP DCs • to get a DC in Azure, you could: • P 2 V a physical box and move it up there • move an existing virtual DC’s VHD file • build a new Windows Server instance and replicate/promote a new DC via DCpromo • use IFM (Install from Media) if concerned about performance

Placement of the Active Directory DIT • Active Directory DITs/sysvol should be deployed on data disks • “data disks” and “OS disks” are two distinct Azure virtual-disk types • they exhibit different behaviors (and different defaults) • unlike OS disks, data disks do not cache writes by default • NOTE: data disks are constrained to 1 TB • 1 TB > largest known Active Directory database • Why is this a concern? • write-behind disk-caching invalidates assumptions made by the DC • DC’s assert FUA (forced unit access) and expect the IO subsystem to honor it • FUA is intended to ensure sensitive writes make it to durable media • can introduce USN bubbles in failure scenarios

Optimizing your deployment for traffic and cost • Consider costs and deploy/configure accordingly • • • inbound/ingress traffic is free, outbound/egress traffic is not • standard Azure egress traffic costs apply nominal fee per hour for the gateway itself • can be started and stopped as you see fit • if stopped, VMs are isolated from corporate network RODCs will likely prove more cost effective

Optimizing your deployment for traffic and cost (continued) • DC-locator and ISTG (Intersite Topology Generator) • correctly defining and connecting Active Directory subnets and sites will influence your bottom-line • sites, site-links and subnets affect who authenticates where and DCs’ replication topology • ensure the cost between any on-premises site and the cloud-sites are appropriately dissuasive • i. e. the notion of “next closest site” (a common fallback mechanism used when locating DCs) should not conclude that the cloud is the next closest (unless it actually is)

Optimizing your deployment for traffic and cost (continued) • DC-locator and ISTG (Intersite Topology Generator) • ensure replication is scheduled (not “notify-”driven) • ensure replication traffic is optimally compressed (crank it up—domain controllers offer aggressive controls around compression of replication traffic) • align the replication schedule with latency tolerance • DCs’ replicate only the last state of a value so slowing replication down saves cost if there’s sufficient churn

Read-Only DCs (RODC) or Read-Writes • Using RODCs on Windows Azure is a no-brainer… or is it? • this isn’t really what they’re designed for • designed to be caching DCs used at physically insecure branch sites • your choice—do you categorize Windows Azure datacenters as insecure branch sites? • Is HBI/PII a concern? • RODCs do offer ROFAS (a filtered attribute set) which permits targeted attributes to be excluded from RO replicas • but RODCs introduce known and unknown app-compat issues which increases the test-burden and associated support costs

Read-Only DCs (RODC) or Read-Writes • Finally, RODCs NEVER replicate anything outbound • they need to populate cacheable secrets which requires on-demand traffic to obtain them as a user/computer authenticates • consider that the absence of outbound traffic through the lack of replication yields cost savings

Global Catalog (GC) or not? • GCs are necessary in multi-domain forests for authentication • workloads in the cloud that authenticate against a DC in the cloud will still generate outbound authentication traffic without one • used to expand Universal Group memberships • less predictable cost associated with GCs since they host every domain (in-part) • completely unpredictable cost if workload hosts Internet-facing service and authenticates users against Active Directory • could leverage “Universal Group Membership Caching” • predominantly replicates inbound only • outbound replication is possible with other GCs but can be avoided with the right site link costs

Trust or Replicate? • Choice: • add replica DCs in the cloud or build a new forest and create a trust? • Kerberos or Federated? • Motivators compatibility security (e. g. selective authentication & SID filtering) compliance/privacy (HBI/PII concerns) cost • replicate more or generate more outbound traffic as a result of authentication and query load • resiliency/fault-tolerance • if the link goes down, trusted scenarios are likely entirely broken • •

IP addressing • Azure VMs require that you configure the VM to use “DHCP leased addresses” • but leases never expire or move between VMs • this “non-static” configuration is the opposite of what most Active Directory administrators are used to doing • When an Azure VM leases an address, it is routable for the period of the lease • the period of the lease directly equates to the lifetime of the service so we’re good • traditional on-premises best practices for domain controller addressing do NOT apply • do NOT consider statically defining a previously leased address as a workaround • this will appear to work for the remaining period of the lease but once the lease expires, the VM will lose all communication with the network not good when it’s a domain controller

Name resolution • Name Resolution • deploy Windows Server DNS on the domain controllers • Azure DNS does not meet the complex name resolution needs of Active Directory (DDNS, CNAME, SRV records, etc. ) • DNS remains a critical configuration item for domain controllers and domain-joined clients • clients/DCs must be capable of registering and resolving resources within their own domains/forests and across trusts • since static addressing is not supported, these settings MUST be configured within the virtual network definition

IP addressing and name resolution summary 1. Deploy a Windows Azure Virtual Network 2. Use DHCP-leased addresses on your virtual DCs • this is NOT an option 3. Install and configure Windows Server DNS on the domain controller(s) in Windows Azure 4. Configure both the DCs’ and the domain-members’ DNS client resolver settings as follows: • Preferred DNS server: on-premises DNS IP address • Alternate DNS server: loopback address or another DNS server running on a DC on the same virtual network

Geo-distributed, cloud-hosted domain controllers Windows Azure • Azure offers an attractive option for geo-distribution of domain controllers • off-site fault-tolerance • physically closer to branch offices (lower latency) • But multiple virtual-networks are isolated from one another • requires one VPN tunnel from each virtual-network back to the corporate network on-premises • All replication would route through or bounce off of CORP domain controllers • may generate larger amounts of outbound traffic US Asia Windows Azure Virtual Networks HQ CORP

Summary/Review 1. Is it safe to virtualize DCs? • absolutely—just be aware of what is and is not supported around backup/restore, VHD copying, etc. 2. Placement of the Active Directory database (DIT) • use Windows Azure data-disks to eliminate concerns around lost-writes and lack of convergence (or disable write-caching) 3. Optimizing your deployment for traffic and cost • deploy and configure domain controllers according to the scenario’s requirements • long-standing approaches work from a purely technical standpoint but may be sub-optimal both performance- and cost-wise 4. Read-Only DCs (RODC) or Read-Writes? • another of those scenario-/requirements-specific questions • consider HBI/PII concerns, cost, app-compatibility

Summary/Review 5. Global Catalog or not? • only a question in multi-domain forests • for single-domain-forests, make all DCs GCs and be done with it 6. Trust or Replicate? • balance the requirements: resiliency, cost, compliance, security, etc. 7. IP addressing and name resolution • use only dynamic addresses • use/supplement your existing DNS service • Windows Azure DNS does not meet the complex name resolution needs of Active Directory 8. Geo-distributed, cloud-hosted domain controllers • note that virtual machines on separate virtual networks are isolated from one another

Demo Installing a replica Domain Controller in Windows Azure

Evaluation Scale: 1 = Very bad 2 = Bad 3 = Relevant 4 = Good 5 = Very Good! Questions: • Speaker Performance • Relevance according to your work • Match of technical level according to published level • Comments Evaluation Create a Text message on your phone and send it to 1919 with the content: Session Code DA 304 5 5 5 I liked it a lot Shaun Performance (1 to 5) Relevance (1 to 5) Match of technical Level (1 to 5) Comments (optional)

© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U. S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.