Advanced Active Directory Services Windows Server 2012

Advanced Active Directory Services

Windows Server 2012

21 год на рынке IT образования!

17 лет с Microsoft 1991 – 2013

WWW.STARS-S.RUАлексей Кибкало

Введение в Windows Server 2012 ADDS.Что нового в Active Directory?

Alex A. Kibkalo

Miscellaneous

Management

New Features and Enhancements

Recycle Bin User Interface

Virtualization-Safe Technology

Active Directory Replication & Topology Cmdlets

Active DirectoryPlatform Changes

Dynamic Access Control

Active Directory Based Activation

Group Managed Service Accounts

Rapid Deployment Kerberos Enhancements

Active Directory PowerShell History Viewer User

Interface

Fine-Grained Password Policy User Interface

Simplified Deployment

Miscellaneous



Rapid Deployment



Simplified DeploymentBackground

adding replica DCs running newer versions of the Windows Server operating system has proven to be:

time consumingerror-pronecomplex

In the past, IT pros were required to:obtain the correct (new) version of the ADprep toolsinteractively logon at specific per-domain DCs using a variety of different credentialsrun the preparation tool in the correct sequence with the correct switcheswait for replication convergence between each step

Simplified DeploymentSolution

integrate preparation steps into the promotion process

automate the pre-requisites between each of them

validate environment-wide pre-requisites before beginning deploymentintegrated with Server Manager and remoteablebuilt on Windows PowerShell for command-line and UI consistencyconfiguration wizard aligns to the most common deployment scenarios

Simplified Deployment: What Changed?… by integrating preparation and promotion processes & automating pre-requisites in-between

… by validating environment pre-requisites before deployment

… by providing remote capabilities for both preparation and promotion processes

… by aligning the configuration wizard to the most common deployment scenarios

… by integrating the full deployment experience with Server Manager

… by providing a deployment & configuration wizard that is built on top of Windows PowerShell

Streamline the deployment process

Minimize odds of deployment failures

Minimize number of touch-points

Optimize for common deployment pathsBring consistency with other Windows Server roles deployment experiencesGain UI-consistency by leveraging an enhanced command-line experience


RequirementsWindows Server 2012target forest must be Windows Server 2003 functional level or greaterintroducing the first Windows Server 2012 DC requires Enterprise Admin and Schema Admin privileges

subsequent DCs require only Domain Admin privileges within the target domain

Simplified Deployment ++DC Promotion Retry Logic

Since Windows 2000, DCpromo has been intolerant of transient network failures

caused promotions to fail if the network (or helper DC) “hiccupped”

Windows Server 2012 promotion employs an indefinite retry

“indefinite” because no sufficiently meaningful set of metrics available from which to assert “sufficient progress”

so we’ve deferred the decision of “failure” to the administrator

Simplified Deployment ++Enhanced Install-from-media (IFM) options

Goal of IFM deploy a DC more quicklyyet “IFM prep” in NTDSUTIL executed a mandatory offline defragmentation pass

a maintenance task that our data suggests virtually nobody uses on existing production DCs

yielded an oftentimes much smaller DIT (which is great) but at the expense of time

In Windows Server 2012, NTDSUTIL’s IFMprep enhancedNTDSUTIL’s IFMprep now includes an option to eliminate the defragmentation pass

not the default, that remains as iseliminates potentially hours (or days) of media preparation time

DIT will be larger (whitespace, not fragmentation) increasing copy time if slow-links involved

Simplified Deployment ++AD FS V2.1 is in-the-box

AD FS v2.0 shipped out-of-band downloaded from http://microsoft.com

AD FS (v2.1) ships in-the-box as a server-role with Windows Server 2012

integrated with Windows Server 2012 Dynamic Access Control

http://microsoft.com/

Miscellaneous



Rapid Deployment




Backgroundcommon virtualization operations such as creating snapshots or copying VMs/VHDs can rollback the state of a virtual DCintroduces 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 ImpactedTi

mel

ine

of e

vent

s

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

DC1

DC2

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-Safe TechnologySolution

Windows Server 2012 virtual DCs able to detect when:snapshots are applieda VM is copied

built on a generation identifier (VM-generation ID) that is changed when virtualization-features such as VM-snapshot are usedWindows Server 2012 virtual DCs track the VM-generation ID to detect changes and protect Active Directory

protection achieved by:discarding RID poolresetting invocationIDre-asserting INITSYNC requirement for FSMOs


RequirementsWindows Server 2012 DCs hosted on hypervisor platform that supports VM-Generation ID

Miscellaneous


Rapid Deployment




Rapid DeploymentBackground

deploying virtualized replica DCs is as labor-intensive as physical DCs

virtualization brings capabilities that can simplify deploymentthe result & goal of promoting additional DCs within a domain is an ~identical instance (a replica)

excluding name, IP address, etc.deployment today involves many (arguably redundant) steps

preparation & deployment of sysprep’d server imagemanually promoting a DC using:

over-the-wire: can be time-consuming depending upon size of directoryinstall-from-media (IFM): media-preparation and copying adds time & complexity

post-deployment configuration steps where necessary

Rapid Deployment: Domain Controller CloningSolution

create replicas of virtualized DCs by cloning existing onesi.e. copy the VHD through hypervisor-specific export + import operations

simplify interaction & deployment-dependencies between HyperVisor and Active Directory admins

note that the authorization of clones remains under Enterprise/Domain Admins’ control

a game-changer for disaster-recoveryrequires ONLY a single Windows Server 2012 virtual DC per domain to quickly recover an entire forestsubsequent DCs can be rapidly deployed drastically reducing time to steady-state

enables elastic provisioning capabilities to support private-cloud deployments, etc.

NTDS starts

Obtain current VM-GenID

If different from value in DIT

Reset InvocationID, discard RID pool

DCCloneConfig.xml available?

Dcpromo /fixclone

Parse DCCloneConfig.xml

Configure network settings

Locate PDC

Call _IDL_DRSAddCloneDC(name, site)

Check authorization

Create new DC object by duplicating source DC objects(NTDSDSA, Server, Computer instances)

Generate new DC machine account and password

Save clone state (new name, password, site)

Promote as replica (IFM)

Run (specific) sysprep providers

Reboot

Clone VM Windows Server 2012 PDC

IDL_DRSAddCloneDC

CN=Configuration|--CN=Sites

|---CN=<site name>|---CN=Servers

|---CN=<DC Name> |---CN=NTDS Settings

Rapid Deployment: Cloning Flow

Rapid Deployment: Domain Controller Cloning

RequirementsWindows Server 2012 virtual DC hosted on VM-Generation-ID-aware hypervisor platformsPDC FSMO must be running Windows Server 2012 to authorize cloning operationsource DC must be authorized for cloning

through permission on domain head – “Allow DC to create a clone of itself”add the source DC’s computer account to the new “Cloneable Domain Controllers” group

DCCloneConfig.XML file must be present on the clone DC in one of:directory containing the NTDS.DIT default DIT directory (%windir%\NTDS) removable media (virtual floppy, USB, etc.)

commonplace Windows Server 2012 services that are co-located with DCs are supported, e.g. DNS, FRS, DFSR

additional services/scheduled tasks installed on the clone-source must be added to an admin-extensible whitelistif installed component is not present in whitelist, cloning process fails and cloned-DC boots to DSRM

Miscellaneous


Rapid Deployment




Brief Terminology Level-SetRootDSE mods

aka. operational attributesLDAP’s answer to RPC

Constructed attributestypically imposes a compute burden—the answer is “constructed” based on something elsequery processor will reject anything other than a base-scoped filter that includes a constructed attributetypically not defined in the schema—known only to the code

LDAP controls and matching rulesaffect the way the query processor handles things, e.g.

return deleted objects (a control that is checked in along with the query)bitwise comparison (a matching rule) (searchFlags:1.2.840.113556.1.5.807:=1)

Finite address spaces within Active DirectoryRIDs (exposed)DNTs (exposed but new to Windows Server 2012)LIDs (not exposed)

RID Improvements

Backgrounda recent bout of cases involving RID depletion or complete global RID-space exhaustion motivated an investigation into root causea couple of bugs were identified and fixedthe investigation also highlighted the need for general improvements and concerns around finite scale limitations

RID ImprovementsAccount creation failure can cause the loss of 1 RID

a RID was leaked because a user was being created that didn’t meet policythe RID was allocated, the user created, failed to meet policy user deleted RID leaked

fixed in Windows Server 2012 by maintaining an in-memory bucket of RIDs that are available for reuse

note that if the DC is rebooted, the reuse list is lostreuse list is used preferentially over RID pool if entries existsize of the reuse list bound by the maximum number of user-creation attempts that simultaneously hit a failure case

our projections indicate single-digit size, i.e. nothing to take into account in sizing exercises

Prevent RID allocation during failed computer account creation by privilege by standard domain userthis is just another path (through domain join, for example) that permits the creation of computer accountsthe logic above is used in exactly the same way to eliminate the leak

Log event when a RID pool is invalidatedinvalidation occurs via a rootDSE mod. and more natural scenarios, e.g. virtual DC safeties, DIT restoration

RID ImprovementsMissing rIDSetReferences value will lead to RID pool exhaustion

attribute not correctly recreated when a DC’s computer account is deleted, later detected by the DC and reincarnated

DC checks attribute for pointer to its RID poolattribute isn’t populatedDC assumes no RID pool and requests a new oneDC receives RID pool from RID FSMO and attempts to write new RID block to its RID set and fails because no rIDSetReference exists30 seconds later, DC repeats process burning through <RID block size> RIDs on each attempt

a single offending DC will eat through the entire global RID space in ~2 years using default RID block size of 500

in Windows Server 2012, you guessed it – we fixed thisreincarnation populates the necessary attributes

Enforce a maximum cap on the RID policy RID Block Sizein the past, the RID block size was configurable on the RID FSMO’s registry and imposed no upper boundin Windows Server 2012, the maximum permissible admin-configured RID block size is 15,000 (values >15K == 15K)

RID Improvements

Periodic RID Consumption Warningat 10% of remaining global space, system logs informational event

first event at 100,000,000 RIDs used, second event logged at 10% of remainder

remainder = 900,000,00010% of remainder = 90,000,000

second event logged at 190,000,000existing RID consumption plus 10% of remainder

events become more frequent as the global space is further depleted

RID ImprovementsRID Manager artificial ceiling protection mechanism

think of this as a soft ceiling blocks further allocations of RID pools

when hit, system flips msDS-RIDPoolAllocationEnabled on the RID Manager$ object to FALSE administrator flips back to TRUE to override

log an event indicating we’ve reached the ceilingan additional warning is logged when the global RID spaces reaches 80%

the attribute can only be set to FALSE by the SYSTEM and is mastered by the RID FSMO (i.e. write it against the RID FSMO)

DA can set it back to TRUENOTE: it is set to TRUE by default (possibly obvious)

the soft ceiling is 90% of the global RID space and is not configurablethe soft ceiling is deemed as ”reached” when a RID pool containing the 90% RID is issued

RID ImprovementsUnlock 31st bit in the global RID space

yes–we actually did it… and yes again, we tested the living s… well, we really tested it a lot doubles global RID space from 1 billion to 2 billionirreversible action so take care

CANNOT be authoritatively restored (unless it’s the only DC in the domain)31st bit is unlocked via a rootDSE mod (requires Windows Server 2012 RID FSMO)

sidCompatibilityVersion:1other DCs must be running Windows Server 2012 to exploit this

however is backported it to Windows Server 2008 R2 in KB2642658downlevel DCs will receive pools that use the higher order bit but will refuse to issue RIDs to new principals from within it, i.e. the DCs are good for everything other than creating new principals

they will, for example, happily authenticate users with RIDs above 1 billion

Deferred Index CreationAdding indices to existing attributes resulted in DC performance issues, i.e.

DCs received schema update through replication5 minutes later, DCs refresh their schema cache

many/all DCs ~simultaneously begin building the index

Windows Server 2012 introduces new DSheuristic18th byte but uses a zero-base, so some say the 19th bytesetting it to 1 causes any Windows Server 2012 DC to defer building indices until:

it receives the UpdateSchemaNow rootDSE mod. (triggers rebuild of the schema cache)it is rebooted (which requires that the schema cache be rebuilt and, in turn, the deferred indices)

any attribute that is in a deferred index state will be logged in the Event Log every 24 hours

2944: index deferred – logged once2945: index still pending – logged every 24 hours1137: index created – logged once (not a new event)

Off-Premises Domain Join

Extends offline domain-join by allowing the blob to accommodate Direct Access prerequisites

CertsGroup Policies

What does this mean?a computer can now be domain-joined over the Internet if the domain is Direct Access enabledgetting the blob to the non-domain-joined machine is an offline process and the responsibility of the admin

Connected Accounts

Backgrounda consumer-oriented feature coupled with ModernUI providing enhanced app-dev. capabilitiesprovides an out-of-box ability to interactively logon to Windows 8 as a “connected” Live IDroams certain aspects of a user’s profile between Windows 8 computers sharing the same connected Live ID

Connected AccountsLive ID logon to Windows with a connected Active Directory user account is NOT supported

connecting local accounts on domain-joined machines IS supportedSSO to Live-supported web sites still functions as does profile sync, etc.Group Policy setting can disable Live ID connected accounts completely

Server SKUs do NOT support connected accounts

Note that Windows 8 client applications that are built to use ModernUI are able to leverage a rich set of features specific only to connected accounts

Connected Accounts

Object Picker and Windows as a whole will correctly display the Live ID, not the local account

any legacy applications will still see the NT-style account name

Administrator must associate the Live ID with the target accountthis can be done retroactively or during the OOBE (page 2)

Connected local user WILL appear in Local Users and Groupspassword change attempts will be blocked

Enhanced LDAP logging

Enhanced LDAP logging added in Windows Server 2012existing LDAP logging capabilities deemed insufficient unable to isolate/diagnose root cause of many behaviors/failures with existing logging

Enabled through registry via logging overrides or level 5 LDAP loggingadditional logging logs entry and exit stats for a given APIwe now also track the entry and exit tick making it feasible to determine sequence of events

entry: logs the operation name, the SID of the caller’s context, the client IP, entry tick and client IDexit: logs the operation name, the SID of the caller’s context, client IP, entry and exit tick and client ID

… further details on this in the appendix of this deck

Miscellaneous

Management








Rapid Deployment Kerberos Enhancements


Interface




Management






Kerberos Enhancements


Interface




Backgroundthe Recycle Bin feature introduced with Windows Server 2008 R2 provided an architecture permitting complete object recoveryscenarios requiring object recovery via the Recycle Bin are typically high-priority

recovery from accidental deletions, etc. resulting in failed logons / work-stoppages

the absence of a rich, graphical interface complicated its usage and slowed recovery

Recycle Bin User InterfaceSolution

simplify object recovery through the inclusion of a Deleted Objects node in the Active Directory Administrative Center

deleted objects can now be recovered within the graphical user interface

greatly reduces recovery-time by providing a discoverable, consistent view of deleted objects


RequirementsRecycle Bin’s own requirements must first be satisfied, e.g.

Windows Server 2008 R2 forest functional level Recycle Bin optional-feature must be switched on

Windows Server 2012 Active Directory Administrative CenterObjects requiring recovery must have been deleted within Deleted Object Lifetime (DOL)

defaults to 180 days

Management







Interface




Dynamic Access Control (DAC)

Backgroundtoday, it’s difficult to translate business-intent using existing authorization modelno central administration capabilitiesexisting expression language makes it hard or impossible to fully express requirementsincreasing regulatory and business requirements around compliance demand a different approach

Dynamic Access Control (DAC)Requirements

Windows 8 or Windows Server 2012 file servers (no DCs necessary yet)modern authorization expressions, e.g.

evaluating ANDed authorization conditionsNOTE: leveraging classification and resource properties in ACLs requires the Windows Server 2012 schema

Access Denied Remediation1 or more Windows Server 2012 DCs required for Kerberos claims

Central Access Policies (CAP) supportmust enable the claims-policy in a Domain Controller-scoped policy, e.g. Default Domain Controllers Policy

once configured, Windows 8 clients might use only Windows Server 2012 DCsenough DCs must be deployed to service the load imposed by uplevel clients and servers (piling-on)

Windows Server 2012 Active Directory Administrative Center to administer CAPs and CAPRs

CAPR = Claims Access Policy Rulesfor device-claims, compound ID must be switched on at the target service account

via Group Policy or directly editing the corresponding objectsdownlevel clients require DFL 5 in order to receive claims from a KDC

in the absence of that, uplevel servers able to use S4U2Self to obtain claims-enabled ticket on caller’s behalf

note that Authentication Mechanism Assurance (AMA) SIDs/claims and device authorization data not available since context around authentication method and device already lost

Kerberos Claims (DAC) in AD FS

BackgroundAD FS v2.0 is able to generate user-claims directly from NTtokens

also capable of further expanding claims based on attributes in Active Directory and other attribute stores

in Windows Server 2012, we know that Kerberos tickets can also contain claims

but AD FS 2.0 can’t read claims from Kerberos ticketsforced to make additional LDAP calls to Active Directory to source user-attribute claims

cannot leverage device-attribute claims at all

Kerberos Claims (DAC) in AD FS

SolutionAD FS (v2.1) in Windows Server 2012 now able to populate SAML tokens with user- and device-claims taken directly from the Kerberos ticket

RequirementsDAC enabled and configuredcompound ID must be switched on

for the AD FS service accountWindows Server 2012 AD FS (v2.1)

Management







Interface




Active Directory-based Activation (AD BA)Background

today, Volume Licensing for Windows/Office requires Key Management Service (KMS) servers requires minimal training

turnkey solution covers ~90% of deploymentscomplexity caused by lack of a graphical administration console

requires RPC traffic on the network which complicates mattersdoes not support any kind of authentication, the EULA prohibits the customer from connecting the KMS server to any external network

i.e. connectivity-alone to the service equates to activated

Active Directory-based Activation (AD BA)Solution

use your existing Active Directory infrastructure to activate your clients

no additional machines requiredno RPC requirement, uses LDAP exclusivelyincludes RODCs

beyond installation and service-specific requirements, no data written back to the directory

activating initial CSVLK (customer-specific volume license key) requires:one-time contact with Microsoft Activation Services over the Internet (identical to retail activation)key entered using volume activation server role or using command line.repeat the activation process for additional forests up to 6 times by default

activation-object maintained in configuration partitionrepresents proof of purchasemachines can be member of any domain in the forest

all Windows 8 machines will automatically activate

Active Directory-based Activation (AD BA)

Requirementsonly Windows 8 or Windows Server 2012 machines can leverage AD BAKMS and AD BA can coexist

you still need KMS if you require downlevel volume-licensingsetup requires Windows 8 or Windows Server 2012 machine requires Windows Server 2012 Active Directory schema, not Windows Server 2012 domain controllers

Management







Active Directory Windows PowerShell History Viewer




BackgroundWindows PowerShell is a key technology in creating a consistent experience between the command-line and the graphical user interfaceWindows PowerShell increases productivity

but requires investment in learning how to use it

Active Directory Windows PowerShell History ViewerSolution

allow administrators to view the Windows PowerShell commands executed when using the Administrative Center, e.g.

the administrator adds a user to a groupthe UI displays the equivalent Active Directory Windows PowerShell commandAdministrator’s can copy the resulting syntax and integrate it into their scripts

reduces learning-curveincreases confidence in scriptingfurther enhances Windows PowerShell discoverability


RequirementsWindows Server 2012 Active Directory Administrative CenterActive Directory Web Service

running on a domain controller within the target domain

Management










Fine-Grained Password Policy

Backgroundthe Fine-Grained Password Policy capability introduced with Windows Server 2008 provided more granular management of password-policiesin order to leverage the feature, administrators had to manually create password-settings objects (PSOs)

it proved difficult to ensure that the manually defined policy-values behaved as desired resulted in time-consuming, trial and error administration


Solutioncreating, editing and assigning PSOs now managed through the Active Directory Administrative Centergreatly simplifies management of password-settings objects


RequirementsFGPP requirements must be met, e.g.

Windows Server 2008 domain functional levelWindows Server 2012 Active Directory Administrative Center

Management










Group Managed Service Accounts (gMSA)

BackgroundManaged Service Accounts (MSAs) introduced with Windows Server 2008 R2clustered or load-balanced services that needed to share a single security-principal were unsupported

MSAs not able to be used in many desirable scenarios

Group Managed Service Accounts (gMSA)Solution

introduce new security principal type known as a gMSAservices running on multiple hosts can run under the same gMSA account1 or more Windows Server 2012 DCs required

gMSAs can authenticate against any OS-version DCpasswords computed by Group Key Distribution Service (GKDS) running on all Windows Server 2012 DCs

Windows Server 2012 hosts using gMSAs obtain password and password-updates from GKDS

password retrieval limited to authorized computerspassword-change interval defined at gMSA account creation (30 days by default)like MSAs, gMSAs are supported only by the Windows Service Control Manager (SCM) and IIS application pools

scheduled tasks are supported

Group Managed Service Accounts (gMSA)

RequirementsWindows Server 2012 Active Directory schema updated in forests containing gMSAs1 or more Windows Server 2012 DCs to provide password computation and retrievalonly services running on Windows 8 or Windows Server 2012 can use gMSAsWindows Server 2012 Active Directory Module for Windows PowerShell to create gMSA accounts

Management











Backgroundadministrators require a variety of tools to manage Active Directory’s site topology

repadminntdsutilActive Directory Sites and Servicesetc.

results in an inconsistent experiencedifficult to automate

Active Directory Replication & Topology CmdletsSolution

manage replication and site-topology with Active Directory Windows PowerShell

create and manage sites, site-links, site-link bridges, subnets and connectionsreplicate objects between DCsview replication metadata on object attributesview replication failuresetc.

provides a consistent and more easily scriptable experiencecompatible and interoperable with other Windows PowerShell Cmdlets


RequirementsActive Directory Web Service (ADWS)

or Active Directory Management Gateway (for Windows Server 2003 or 2008)

Remote Server Administration Tools (RSAT)

In ReviewEasier to Manage

Windows Server 2012Managed Service Accounts for farms (gMSA)Support for cross-domain Kerberos Constrained DelegationSpoofing of Kerberos errors much more challengingActive Directory UI investments

support in Active Directory’s Administrative Center for managing deleted objects and Fine Grained Password Policiesability to view Windows PowerShell scripts that correspond to actions performed in the GUI

Easier scripting of replication and topology tasks using new Active Directory Windows PowerShell Cmdlets

In the past…Managed Service Accounts work only on a single machineKerberos Constrained Delegation (KCD) works only within a single domainKerberos errors able to be spoofedNo support in Active Directory Administrative Center for Recycle Bin or Fine Grained Password PoliciesPowerShell code must be written from scratchHodge-podge of incompatible command-line tools and UIs used for managing replication and topology

In ReviewEasier to Deploy

Windows Server 2012Safe virtualizationSimplified deployment

Integrated end-to-end deployment experienceAll deployment tasks are remoteable and automatically target the correct FSMOsInput and environment validation throughout the deployment process helps decrease failuresFull Windows PowerShell support for automated deployment

Rapid deployment of DCs using cloningAD FS deployment integration

In the past…Using snapshot features on virtual DCs results in a divergent Active Directory stateActive Directory environment preparation is overly complex requiring multiple stepsDC promotion requires multiple phases to completeDeployment is not remoteable and requires interactive logon to multiple DCsDifficult to write automation scripts

Advanced Active Directory Services Windows Server 2012

Documents

Transcript of Advanced Active Directory Services Windows Server 2012