active directory domain services on windows azure virtual machines samuel devasahayam active...
TRANSCRIPT
Active Directory Domain Services on Windows Azure Virtual Machines
Samuel DevasahayamActive Directory Product GroupMicrosoft
SIA205
Agenda
Objectives
Why are we even discussing Active Directory?“Is there a session on running NOTEPAD.EXE in Windows Azure, too?” (no, there isn’t)
Vernacular… terminology specific to Windows Azure that will get us all on the same page
Considerations for a cloud-deployment… optimal configuration knobs and deployment topologies
Agenda
Objectives
Why are we even discussing Active Directory?“Is there a session on running NOTEPAD.EXE in Windows Azure, too?” (no, there isn’t)
Vernacular… terminology specific to Windows Azure that will get us all on the same page
Considerations for a cloud-deployment… optimal configuration knobs and deployment topologies
Objectives
Talk about the need to deploy AD in Windows Azure Virtual Machines
Shed some light on the areas of Active Directory that:are able to be configured for a more optimal Windows Azure cloud-deploymentdiffer in some way to their on-premises counterparts
Emphasize how to optimize for performance and cost
Highlight the technical considerations for various deployment scenarios
Agenda
Objectives
Why are we even discussing Active Directory?IMPLICATION: “there’s something specific to its deployment in Azure”
Vernacular… terminology specific to Windows Azure that will get us all on the same page
Considerations for a cloud-deployment… optimal configuration knobs and deployment topologies
Why are we even discussing Active Directory?
Identify some of the business-driverssupport pre-requisites of other application/serviceserve as substitute or failover for branch-office/HQ domain controllersetc.
Design considerationscertain Active Directory configuration knobs and deployment topologies are better suited to the cloud than others
Placing Active Directory domain controllers in Windows Azure equates to running virtualized domain controllers
HyperVisors provide or trivialize technologies that don’t sit well with many distributed systems… including Active Directory
Agenda
Objectives
Why are we even discussing Active Directory?IMPLICATION: “there’s something specific to its deployment in Azure”
Vernacular… terminology specific to Windows Azure that will get us all on the same page
Considerations for a cloud-deployment… optimal configuration knobs and deployment topologies
First, a point of clarificationIs what we’re discussing here the same as Windows Azure Active Directory?
NOin this session, we’re discussing running traditional on-premises domain controllers on Windows Azure’s new IaaS virtual machines
What is Windows Azure Active Directory then?A Microsoft cloud service that provides identity and access capabilities for applications on Windows Azure and Microsoft Office 365A multi-tenant cloud service on which Microsoft Office 365 relies on for its identity infrastructureAn Identity service that provides identity management and access control capabilities for your cloud applicationsAllows you to extend your existing on-premises Active Directory authentication to your cloud applicationssee http://www.windowsazure.com/en-us/home/features/identity/
General Windows Azure vernacular
Windows Azure Virtual MachinesIaaS (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 Networkthe 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 carddeployments are assigned a VIP for receiving network traffic which is redirected to a VM in the Windows Azure
Dynamic IP address (DIP)not as obvious as you might first thinkthis 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
One final Windows Azure termService-healing
“In the unlikely event of a change in cabin-pressure, oxygen masks will automatically drop from the ceiling above you…”
joking aside, let’s briefly discuss the unplanned eventsas 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 failedService-healing is one of the aspects of Windows Azure that contributes to availability and resiliencysuch an event is perceived by Active Directory domain controllers as an unplanned reboot… and Active Directory, like many distributed systems, is sensitive to being rolled back in time
One final Windows Azure termService-healing (cont.)
What affect does service-healing have on domain controllers?
the MAC address of the domain controller WILL changethe processor/CPU ID of the VM WILL also changethe IP address of the VM will NOT change
requires that the VM is deployed on a Windows Azure virtual networkwrites 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 processor/CPU ID
again, ensure you deploy the Active Directory DCs on a Windows Azure virtual networkensure that writes to Active Directory’s databases are durable
use Windows Azure “data-disks”
Agenda
Objectives
Why are we even discussing Active Directory?IMPLICATION: “there’s something specific to its deployment in Azure”
Vernacular… terminology specific to Windows Azure that will get us all on the same page
Considerations for a cloud-deployment… optimal configuration knobs and deployment topologies
When do I need AD on Windows Azure Virtual Machines?
Cloud Only Deployment (New & Isolated AD)Support applications accessible from the intranetIsolated from corporate ADE.g. Extranet Accessible SharePoint needing a local Active Directory
Hybrid Deployment (Existing AD)Applications needs access to corporate directory dataApplications need to authenticate users from corporate directory
Deploy DC in Separate Cloud Service
Cloud Service Configuration for AD
Cloud Service for AD ClientsLocation: North Central USName: app-cloudservice.cloudapp.netAffinity Group: ADAG
DeploymentVirtual Network: MyVNETDNS Ips: 192.168.1.4
Virtual MachineRole Name: advm1Subnet: AppSubnetIP Address: 192.168.2.4
Cloud Service for AD DomainsLocation: North Central USName: ad-cloudservice.cloudapp.netAffinity Group: ADAG
DeploymentVirtual Network: ADVNETDNS Ips: (On-Premise AD IP)
Virtual MachineRole Name: ad-dcSubnet: ADSubnetIP Address: 192.168.1.4
DIP
ADVNET
Domain Controller On-Premises
The Virtual Networkin Windows Azure
Gateway
SQL ServersIIS Servers
Site to Site VPN Tunnel
AD Authentication+
On-Premises Resources
Contoso.com Active Directory
Contoso Corp Network
IIS Servers
AD / DNS
SQL Servers
Exchange
S2S VPN Device
Contoso.com Active Directory
Load BalancerPublic IP
Domain Controller in the Cloud
The Virtual Networkin Windows Azure
Gateway
SQL ServersIIS Servers
Site to Site VPN Tunnel
AD Authentication+
On-Premises Resources
Contoso.com Active Directory
Contoso Corp Network
IIS Servers
AD / DNS
SQL Servers
Exchange
S2S VPN Device
Contoso.com Active Directory
AD / DNS
AD Auth
Load BalancerPublic IP
General considerations
Is it safe to virtualize DCs?Placement of the Active Directory database (DIT)Optimizing your deployment for traffic and costRead-Only DCs (RODC) or Read-Writes?Global Catalog or not?Trust or Replicate?IP addressing and name resolutionGeo-distributed cloud-hosted domain controllers
Is it safe to virtualize DCs?
Backgroundcommon virtualization operations such as backing up/restoring VMs/VHDs can rollback the state of a virtual DCwith Active Directory, this can introduce USN bubbles leading to permanently divergent state causing:
lingering objectsinconsistent passwordsinconsistent attribute valuesschema mismatches if the Schema FSMO is rolled back
the potential also exists for security principals to be created with duplicate SIDs
How Domain Controllers are ImpactedTim
elin
e o
f even
ts
TIME: T2
TIME: T3
TIME: T4
CreateSnapsh
ot
T1 SnapshotApplied!
USN: 100 ID: A
RID Pool: 500 - 1000
USN: 100 ID: A
RID Pool: 500 - 1000
USN: 250ID: A
RID Pool: 650 - 1000
+150 more users created
DC1(A)@USN = 200
DC2 receives updates: USNs >200
DC1(A)@USN = 250
USN: 200ID: A
RID Pool: 600- 1000
+100 users added
DC2 receives updates: USNs >100
DC
1
DC
2
TIME: T1
USN rollback NOT detected: only 50 users converge across the two DCsAll others are either on one or the other DC100 security principals (users in this example) with RIDs 500-599 have conflicting SIDs
Virtualization conclusions
Use only Windows Azure Virtual Machines (IaaS)as opposed to worker-role or web-role instancesvirtual machines’ disk-writes are durable and designed for these workloads
Do not SYSPREP DCs to get a DC in Azure, you could:
P2V a physical box and move it up theremove an existing virtual DC’s VHD filebuild a new Windows Server instance and replicate/promote a new DC via DCpromo
use IFM (Install from Media) if concerned about performance
Windows Server 2012 supports Virtual Domain Controller Cloning, Windows Azure does NOT (yet, no promises but stay tuned)
feature requires support in the underlying HyperVisor for VMgenerationIDWindows Azure does not currently support VMgenerationID
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 defaultNOTE: data disks are constrained to 1TB1TB > largest known Active Directory database == non-issue
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 itFUA is intended to ensure sensitive writes make it to durable mediacan 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 itselfcan be started and stopped as you see fitif 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/ISM (intersite topology generator and messenger)
correctly defining and connecting Active Directory subnets and sites will influence your bottom-linesites, site-links and subnets affect who authenticates where and DCs’ replication topologyensure 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)
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 sitesyour 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 replicasbut RODCs introduce known and unknown app-compat issues which increases the test-burden and associated support costs
Finally, RODCs NEVER replicate anything outboundthey do need to populate cacheable secrets which requires on-demand traffic to obtain them as a user/computer authenticatesconsider 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 membershipsless 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?
Motivatorscompatibilitysecurity (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-toleranceif 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 VMsthis “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 resolutiondeploy Windows Server DNS on the domain controllers
Azure DNS does not meet the complex name resolution needs of Active Directory (DDNS, 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 summary1. 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
Azure offers an attractive option for geo-distribution of domain controllers
off-site fault-tolerancephysically 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
Asia US
HQ
Windows Azure
CORP
Windows Azure Virtual
Networks
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 (cont.)
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
SIA, WSV, and VIR Track Resources
DOWNLOAD Windows Server 2012 Release Candidate
microsoft.com/windowsserver
#TESIA205 DOWNLOAD Microsoft System Center 2012 Evaluation
microsoft.com/systemcenterHands-On Labs
Talk to our Experts at the TLC
Resources
Connect. Share. Discuss.
http://europe.msteched.com
Learning
Microsoft Certification & Training Resources
www.microsoft.com/learning
TechNet
Resources for IT Professionals
http://microsoft.com/technet
Resources for Developers
http://microsoft.com/msdn
Evaluations
http://europe.msteched.com/sessions
Submit your evals online
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or 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.