active directory domain services on windows azure virtual machines samuel devasahayam active...

38
Active Directory Domain Services on Windows Azure Virtual Machines Samuel Devasahayam Active Directory Product Group Microsoft SIA205

Upload: janice-lane

Post on 24-Dec-2015

226 views

Category:

Documents


1 download

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

Questions?

Thank [email protected]

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.