Transcript PowerPoint-præsentation

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 IaaS 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 (AZ302) 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 96GB 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. SharePoint
•
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-GenID & snapshots (WS 2012 & 2012R2 only)
Windows Azure
Terminology
Windows Azure Terminology
• Windows Azure Virtual Machines
•
IaaS (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
•
•
14GB 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 R2)
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
USN rollback NOT detected: only 50 users converge across the two DCs
All others are either on one or the other DC
100 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 instances
• virtual 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 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 1TB
• 1TB > 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
DA304 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, 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.