Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 88

WSV312

What’s New in Active


Directory
in Windows Server 2012
Pete Calvert
@erucsbo
Agenda

Objectives / Takeaways

Areas of Investment / Our Broad Goals

New Features / Enhancements

Summary of Requirements
Objectives
Provide an understanding of…
the broad areas we have invested in and why
the business- and/or technical-challenges that led to each of the new
features

Provide detailed insights into the Active Directory features and…


define requirements and implementation specifics
highlight the value these features bring to your environment

Given the sheer volume of topics…


provide technically-deep content striving for a balance of breadth and
depth
provide you material that’s sufficiently complete & technically rich to be
useful outside of the session
High-Level Areas of Investment
Simplified deployment of Active Directory

Optimal deployment experiences in both private- and public-clouds

Increase consistency throughout the management experience

Accommodate business-driven security requirements through the


integration of:
file-classification
claims-based authorization
Our Broad Goals
Virtualization That Just Works
• All Active Directory features work equally well in physical, virtual or mixed environments

Simplified Deployment of Active Directory


• Complete integration of environment preparation, role installation and DC promotion into a single UI
• DCs can be deployed rapidly to ease disaster recovery and workload balancing
• DCs can be deployed remotely on multiple machines from a single Windows 8 machine
• Consistent command-line experience through Windows PowerShell enables automation of deployment tasks

Simplified Management of Active Directory


• GUI that simplifies complex tasks such as recovering a deleted object or managing password policies
• Active Directory Windows PowerShell viewer shows the commands for actions performed in the GUI
• Active Directory Windows PowerShell support for managing replication and topology data
• Simplify delegation and management of service accounts
New Features and Enhancements
Miscellaneous Management

Recycle Bin Dynamic


Simplified Deployment
User Interface Access Control

Virtualization-Safe Active Directory PowerShell Active Directory


Technology History Viewer User Interface Based Activation

Fine-Grained Password Policy


Rapid Deployment Kerberos Enhancements
User Interface

Active Directory Active Directory Replication & Group Managed Service


Platform Changes Topology Cmdlets Accounts
New Features and Enhancements
Miscellaneous

Simplified Deployment

Virtualization-Safe
Technology

Rapid Deployment

Active Directory
Platform Changes
Simplified Deployment
Background
adding replica DCs running newer versions of the Windows
Server operating system has proven to be:
time consuming
error-prone
complex
In the past, IT pros were required to:
obtain the correct (new) version of the ADprep tools
interactively logon at specific per-domain DCs using a variety of different
credentials
run the preparation tool in the correct sequence with the correct switches
wait for replication convergence between each step
Simplified Deployment
Solution
integrate preparation steps into the
promotion process
automate the pre-requisites between each of them
validate environment-wide pre-requisites
before beginning deployment
integrated with Server Manager and
remoteable
built on Windows PowerShell for command-
line and UI consistency
configuration wizard aligns to the most
common deployment scenarios
Simplified Deployment: What Changed?
… by integrating preparation and promotion processes &
Streamline the deployment process automating pre-requisites in-between

Minimize odds of deployment failures … by validating environment pre-requisites before deployment

… by providing remote capabilities for both preparation and


Minimize number of touch-points promotion processes

… by aligning the configuration wizard to the most common


Optimize for common deployment paths deployment scenarios

Bring consistency with other Windows Server … by integrating the full deployment experience with Server
roles deployment experiences Manager

Gain UI-consistency by leveraging an enhanced … by providing a deployment & configuration wizard that is
command-line experience built on top of Windows PowerShell
Simplified Deployment

Requirements
Windows Server 2012
target forest must be Windows Server 2003 functional level or
greater
introducing 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 quickly


yet “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 enhanced
NTDSUTIL’s IFMprep now includes an option to eliminate the
defragmentation pass
not the default, that remains as is
eliminates 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
New Features and Enhancements
Miscellaneous

Simplified Deployment

Virtualization-Safe
Technology

Rapid Deployment

Active Directory
Platform Changes
Virtualization-Safe Technology

Background
common virtualization operations such as
creating snapshots or copying VMs/VHDs
can rollback the state of a virtual DC
introduces 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
How Domain Controllers are Impacted

DC2
DC1
Timeline of events

Create USN: 100


TIME: T1
Snapshot ID: A RID Pool: 500 - 1000

+100
USNusers added NOT detected: only 50 users converge
rollback across the two DCs
TIME: T2 USN:
All others 200 on one or the other DC
are either
ID: Aprincipals
100 security RID Pool: 600in- this
(users 1000example)
DC2 receives updates:
with RIDs USNs >100
500-599 have conflicting SIDs
DC1(A)
@USN = 200
T1 Snapshot USN: 100
TIME: T3
Applied! ID: A RID Pool: 500 - 1000

+150 more users created

USN: 250 DC1(A)


TIME: T4
ID: A RID Pool: 650 - 1000 DC2 receives updates: USNs >200 @USN = 250
Virtualization-Safe Technology
Solution
Windows Server 2012 virtual DCs able to detect when:
snapshots are applied
a VM is copied
built on a generation identifier (VM-generation ID) that is
changed when virtualization-features such as VM-snapshot are
used
Windows Server 2012 virtual DCs track the VM-generation ID to
detect changes and protect Active Directory
protection achieved by:
discarding RID pool
resetting invocationID
re-asserting INITSYNC requirement for FSMOs
Virtualization-Safe Technology

Requirements
Windows Server 2012 DCs hosted on hypervisor platform that
supports VM-Generation ID
New Features and Enhancements
Miscellaneous

Simplified Deployment

Virtualization-Safe
Technology

Rapid Deployment

Active Directory
Platform Changes
Rapid Deployment
Background
deploying virtualized replica DCs is as labor-intensive as physical
DCs
virtualization brings capabilities that can simplify deployment
the 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 image
manually promoting a DC using:
over-the-wire: can be time-consuming depending upon size of directory
install-from-media (IFM): media-preparation and copying adds time & complexity
post-deployment configuration steps where necessary
Rapid Deployment: Domain Controller Cloning
Solution
create replicas of virtualized DCs by cloning existing ones
i.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-recovery
requires ONLY a single Windows Server 2012 virtual DC per domain to
quickly recover an entire forest
subsequent DCs can be rapidly deployed drastically reducing time to
steady-state
enables elastic provisioning capabilities to support private-cloud
deployments, etc.
Rapid Deployment: Cloning Flow
Clone VM Windows Server 2012 PDC
NTDS starts
Configure network settings IDL_DRSAddCloneDC
Obtain current
VM-GenID
Locate PDC Check authorization

If different from value in


DIT Create new DC object by
Call _IDL_DRSAddCloneDC(name, site) CN=Configuration
duplicating source DC objects
|--CN=Sites
(NTDSDSA, Server, Computer
Reset InvocationID, |---CN=<site
instances) name>
discard RID pool Save clone state (new name,
|---CN=Servers
password, site) |---CN=<DC Name>
Generate new DC machine
DCCloneConfig.xml |---CN=NTDS Settings
account and password
available? Promote as replica (IFM)

Dcpromo /fixclone Run (specific) sysprep


providers
Parse DCCloneConfig.xml
Reboot
Rapid Deployment: Domain Controller Cloning
Requirements
Windows Server 2012 virtual DC hosted on VM-Generation-ID-aware hypervisor
platforms
PDC FSMO must be running Windows Server 2012 to authorize cloning operation
source 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
whitelist
if installed component is not present in whitelist, cloning process fails and cloned-DC boots to DSRM
New Features and Enhancements
Miscellaneous

Simplified Deployment

Virtualization-Safe
Technology

Rapid Deployment

Active Directory
Platform Changes
Brief Terminology Level-Set
RootDSE mods
aka. operational attributes
LDAP’s answer to RPC

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

LDAP controls and matching rules


affect 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 Directory


RIDs (exposed)
DNTs (exposed but new to Windows Server 2012)
LIDs (not exposed)
RID Improvements

Background
a recent bout of cases involving RID depletion or complete global
RID-space exhaustion motivated an investigation into root cause
a couple of bugs were identified and fixed
the investigation also highlighted the need for general
improvements and concerns around finite scale limitations
RID Improvements
Account creation failure can cause the loss of 1 RID
a RID was leaked because a user was being created that didn’t meet policy
the 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 lost
reuse list is used preferentially over RID pool if entries exist
size 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 user
this is just another path (through domain join, for example) that permits the creation of computer accounts
the logic above is used in exactly the same way to eliminate the leak

Log event when a RID pool is invalidated


invalidation occurs via a rootDSE mod. and more natural scenarios, e.g. virtual DC safeties, DIT restoration
RID Improvements
Missing 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 pool
attribute isn’t populated
DC assumes no RID pool and requests a new one
DC receives RID pool from RID FSMO and attempts to write new RID block to its RID set  and fails because no
rIDSetReference exists
30 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 this
reincarnation populates the necessary attributes
Enforce a maximum cap on the RID policy RID Block Size
in the past, the RID block size was configurable on the RID FSMO’s registry and imposed no
upper bound
in Windows Server 2012, the maximum permissible admin-configured RID block size is 15,000
(values >15K == 15K)
RID Improvements

Periodic RID Consumption Warning


at 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,000
10% of remainder = 90,000,000
second event logged at 190,000,000
existing RID consumption plus 10% of remainder
events become more frequent as the global space is further
depleted
RID Improvements
RID 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 ceiling
an 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 TRUE
NOTE: it is set to TRUE by default (possibly obvious)
the soft ceiling is 90% of the global RID space and is not configurable
the soft ceiling is deemed as ”reached” when a RID pool containing the 90%
RID is issued
RID Improvements
Unlock 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 billion
irreversible 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:1
other DCs must be running Windows Server 2012 to exploit this
plan is, however, to backport it to Windows Server 2008 R2
downlevel 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 Creation
Adding indices to existing attributes resulted in DC performance issues, i.e.
DCs received schema update through replication
5 minutes later, DCs refresh their schema cache
 many/all DCs ~simultaneously begin building the index

Windows Server 2012 introduces new DSheuristic


18th byte but uses a zero-base, so some say the 19th byte
setting 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 once
2945: index still pending – logged every 24 hours
1137: index created – logged once (not a new event)
Expose DNTs on rootDSE
Active Directory’s DIT uses DNTs
if we think of the DIT as a spreadsheet, DNTs are very much like row numbers
finite address space == 2^31 (~2 billion)
DNTs are NOT replicated (a database-local concept)
never re-used (the value only ever increases)
DNTs are never re-serialized (or reclaimed) except during over-the-wire promotions
neither IFM or cloning will re-serialize them
once you run out, the DC must be demoted and re-promoted over-the-wire
determining the DNT for a given DC required that you dump its database or
programmatically interrogate the DIT
time consuming, impacts performance and disk space
Windows Server 2012 Active Directory exposes DNTs via:
rootDSE constructed attribute: approximateHighestInternalObjectID
perfmon counter, too
Off-Premises Domain Join

Extends offline domain-join by allowing the blob to accommodate


Direct Access prerequisites
Certs
Group Policies

What does this mean?


a computer can now be domain-joined over the Internet if the domain is
Direct Access enabled
getting the blob to the non-domain-joined machine is an offline process
and the responsibility of the admin
Connected Accounts

Background
a consumer-oriented feature
coupled with ModernUI
providing enhanced app-dev.
capabilities
provides an out-of-box ability to
interactively logon to Windows 8
as a “connected” Live ID
roams certain aspects of a user’s
profile between Windows 8
computers sharing the same
connected Live ID
Connected Accounts
Live ID logon to Windows with a connected Active
Directory user account is NOT supported
connecting local accounts on domain-joined
machines IS supported
SSO 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 account


this can be done retroactively or during the OOBE (page 2)

Connected local user WILL appear in Local Users and Groups


password change attempts will be blocked
Enhanced LDAP logging

Enhanced LDAP logging added in Windows Server 2012


existing 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 logging


additional logging logs entry and exit stats for a given API
we 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 ID
exit: 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


New LDAP Controls/Behaviors

Batched extended-LDAP operations (1.2.840.113556.1.4.2212)


Require server-sorted search use index on sort attribute (1.2.840.113556.1.4.2207)
DirSync_EX_Control (1.2.840.113556.1.4.2090)
TreeDelete control with batch size (1.2.840.113556.1.4.2204)
Include ties in server-sorted search results (1.2.840.113556.1.4.2210)
Return highest change stamp applied as part of an update (1.2.840.113556.1.4.2205)
Expected entry count (1.2.840.113556.1.4.2211)

… details on each of these new controls in the appendix of this deck


New Features and Enhancements
Miscellaneous Management

Recycle Bin Dynamic


Simplified Deployment
User Interface Access Control

Virtualization-Safe Active Directory PowerShell Active Directory


Technology History Viewer User Interface Based Activation

Fine-Grained Password Policy


Rapid Deployment Kerberos Enhancements
User Interface

Active Directory Active Directory Replication & Group Managed Service


Platform Changes Topology Cmdlets Accounts
New Features and Enhancements
Management

Recycle Bin Dynamic


User Interface Access Control

Active Directory PowerShell Active Directory


History Viewer User Interface Based Activation

Fine-Grained Password Policy


Kerberos Enhancements
User Interface

Active Directory Replication & Group Managed Service


Topology Cmdlets Accounts
Recycle Bin User Interface

Background
the Recycle Bin feature introduced with Windows Server 2008 R2
provided an architecture permitting complete object recovery
scenarios 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 Interface
Solution
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
Recycle Bin User Interface

Requirements
Recycle 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 Center
Objects requiring recovery must have been deleted within
Deleted Object Lifetime (DOL)
defaults to 180 days
New Features and Enhancements
Management

Recycle Bin Dynamic


User Interface Access Control

Active Directory PowerShell Active Directory


History Viewer User Interface Based Activation

Fine-Grained Password Policy


Kerberos Enhancements
User Interface

Active Directory Replication & Group Managed Service


Topology Cmdlets Accounts
Dynamic Access Control (DAC)

Background
today, it’s difficult to translate business-intent using existing
authorization model
no central administration capabilities
existing expression language makes it hard or impossible to fully
express requirements
increasing regulatory and business requirements around
compliance demand a different approach
Dynamic Access Control (DAC)
Solution
new central access policies (CAP) model
new claims-based authorization platform
enhances, not replaces, existing model
user-claims and device-claims
user+device claims = compound identity
includes traditional group memberships too
use of file-classification information in
authorization decisions
modern authorization expressions, e.g.
evaluation of ANDed authorization conditions
leveraging classification and resource properties in
ACLs
easier Access-Denied remediation
experience
access- and audit-policies can be defined
flexibly and simply, e.g.
IF resource.Confidentiality = high THEN audit.Success
WHEN user.EmployeeType = vendor
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 conditions
NOTE: leveraging classification and resource properties in ACLs requires the Windows Server 2012 schema
Access Denied Remediation
1 or more Windows Server 2012 DCs required for Kerberos claims
Central Access Policies (CAP) support
must 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 DCs
enough 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 Rules
for device-claims, compound ID must be switched on at the target service account
via Group Policy or directly editing the corresponding objects
downlevel 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

Background
AD 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 tickets
forced 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

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

Requirements
DAC enabled and configured
compound ID must be switched on
for the AD FS service account
Windows Server 2012 AD FS (v2.1)
New Features and Enhancements
Management

Recycle Bin Dynamic


User Interface Access Control

Active Directory PowerShell Active Directory


History Viewer User Interface Based Activation

Fine-Grained Password Policy


Kerberos Enhancements
User Interface

Active Directory Replication & Group Managed Service


Topology Cmdlets Accounts
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 deployments
complexity caused by lack of a graphical administration console

requires RPC traffic on the network which complicates matters


does 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 required
no RPC requirement, uses LDAP exclusively
includes 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 partition
represents proof of purchase
machines can be member of any domain in the forest
all Windows 8 machines will automatically activate
Active Directory-based Activation (AD BA)

Requirements
only Windows 8 or Windows Server 2012 machines can leverage
AD BA
KMS and AD BA can coexist
you still need KMS if you require downlevel volume-licensing
setup requires Windows 8 or Windows Server 2012 machine
requires Windows Server 2012 Active Directory schema, not
Windows Server 2012 domain controllers
New Features and Enhancements
Management

Recycle Bin Dynamic


User Interface Access Control

Active Directory Windows Active Directory


PowerShell History Viewer Based Activation

Fine-Grained Password Policy


Kerberos Enhancements
User Interface

Active Directory Replication & Group Managed Service


Topology Cmdlets Accounts
Active Directory Windows PowerShell History Viewer

Background
Windows PowerShell is a key technology in creating a consistent
experience between the command-line and the graphical user
interface
Windows PowerShell increases productivity
but requires investment in learning how to use it
Active Directory Windows PowerShell History Viewer
Solution
allow administrators to view the
Windows PowerShell commands
executed when using the
Administrative Center, e.g.
the administrator adds a user to a group
the UI displays the equivalent Active
Directory Windows PowerShell
command
Administrator’s can copy the resulting
syntax and integrate it into their scripts
reduces learning-curve
increases confidence in scripting
further enhances Windows
PowerShell discoverability
Active Directory Windows PowerShell History Viewer

Requirements
Windows Server 2012 Active Directory Administrative Center
Active Directory Web Service
running on a domain controller within the target domain
New Features and Enhancements
Management

Recycle Bin Dynamic


User Interface Access Control

Active Directory Windows Active Directory


PowerShell History Viewer Based Activation

Fine-Grained Password Policy


Kerberos Enhancements
User Interface

Active Directory Replication & Group Managed Service


Topology Cmdlets Accounts
Fine-Grained Password Policy

Background
the Fine-Grained Password Policy capability introduced with
Windows Server 2008 provided more granular management of
password-policies
in 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
Fine-Grained Password Policy

Solution
creating, editing and
assigning PSOs now
managed through the Active
Directory Administrative
Center
greatly simplifies
management of password-
settings objects
Fine-Grained Password Policy

Requirements
FGPP requirements must be met, e.g.
Windows Server 2008 domain functional level
Windows Server 2012 Active Directory Administrative Center
New Features and Enhancements
Management

Recycle Bin Dynamic


User Interface Access Control

Active Directory Windows Active Directory


PowerShell History Viewer Based Activation

Fine-Grained Password Policy


Kerberos Enhancements
User Interface

Active Directory Replication & Group Managed Service


Topology Cmdlets Accounts
Flexible Authentication Secure Tunneling
(FAST)
Background
offline dictionary attack against password-based logons possible
relatively well-known concern around Kerberos errors being
spoofed
clients may:
fallback to less-secure legacy protocols
weaken their cryptographic key strength and/or ciphers
Flexible Authentication Secure Tunneling
(FAST)
Solution
Kerberos in Windows Server 2012 supports Flexible Authentication Secure
Tunneling (FAST)
defined by RFC 6113
sometimes referred to as Kerberos armoring
provides a protected channel between a domain-joined client and DC
protects pre-authentication data for user’s AS_REQs
uses LSK (logon session key) from computer’s TGT as shared secret
note that computer authentication is NOT armored
allows DCs to return authenticated Kerberos errors thereby protecting them from spoofing
once all Kerberos clients and DCs support FAST (the admin’s decision to
make)
the domain can be configured to either require Kerberos armoring or use it upon request
must first ensure all or enough DCs are running Windows Server 2012
enable the appropriate policy
“Support CBAC and Kerberos armoring”
“All DCs can support CBAC and Require Kerberos armoring”
Flexible Authentication Secure Tunneling
(FAST)
Requirements
Windows Server 2012 servers
ensure that all domains the client uses including transited referral
domains:
enable the “Support CBAC and Kerberos armoring” policy for all Windows
Server 2012 DCs
have a sufficient number of Windows Server 2012 DCs to support FAST
enable “Require FAST” policy on supported clients
RFC-compliant FAST interop requires DFL 5
Kerberos Constrained Delegation (KCD)
Background
Kerberos Constrained Delegation (KCD) was introduced with Windows
Server 2003
KCD permits a service’s account (front-end) to act on the behalf of users in
multi-tier applications for a limited set of back-end services, e.g.
user accesses web site as user1
user requests information from web site (front-end) that requires the web server to query a
SQL database (back-end)
access to this data is authorized according to who accessed the front-end
in this case, the web service must impersonate user1 when making the request to SQL
front-end configured with the services (by SPN) to which it can impersonate
users
setup/administration requires Domain Admin privileges
KCD delegation only works for back-end services in the same domain as the
front-end service-accounts
Kerberos Constrained Delegation (KCD)

Solution
KCD in Windows Server 2012 moves the authorization decision to
the resource-owners
permits back-end to authorize which front-end service-accounts can
impersonate users against their resources
supports cross-domain, cross-forest scenarios
no longer requires Domain Admin privileges
requires only administrative permission to the back-end service-account
Kerberos Constrained Delegation (KCD)
Requirements
client’s run Windows XP or later
client domain DCs running Windows Server 2003 or later

front-end server running Windows Server 2012


1 or more DCs in front-end domain running Windows Server 2012

1 or more DCs in back-end domain running Windows Server 2012


back-end server account configured with the accounts that are permitted for
impersonation
not exposed through Active Directory Administrative Center
configured through Active Directory Windows PowerShell Cmdlet:
New/Set-ADComputer [-name] <string> [-PrincipalsAllowedToDelegateToAccount <ADPrincipal[]>]
New/Set-ADServiceAccount [-name] <string> [-PrincipalsAllowedToDelegateToAccount <ADPrincipal[]>]
Windows Server 2012 schema update in back-end server’s forest
back-end application server running Windows Server 2003 or later
New Features and Enhancements
Management

Recycle Bin Dynamic


User Interface Access Control

Active Directory Windows Active Directory


PowerShell History Viewer Based Activation

Fine-Grained Password Policy


Kerberos Enhancements
User Interface

Active Directory Replication & Group Managed Service


Topology Cmdlets Accounts
Group Managed Service Accounts (gMSA)

Background
Managed Service Accounts (MSAs) introduced with Windows
Server 2008 R2
clustered 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 gMSA
services running on multiple hosts can run under the same gMSA account
1 or more Windows Server 2012 DCs required
gMSAs can authenticate against any OS-version DC
passwords 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 computers
password-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)

Requirements
Windows Server 2012 Active Directory schema updated in forests
containing gMSAs
1 or more Windows Server 2012 DCs to provide password
computation and retrieval
only services running on Windows 8 or Windows Server 2012 can
use gMSAs
Windows Server 2012 Active Directory Module for Windows
PowerShell to create gMSA accounts
New Features and Enhancements
Management

Recycle Bin Dynamic


User Interface Access Control

Active Directory Windows Active Directory


PowerShell History Viewer Based Activation

Fine-Grained Password Policy


Kerberos Enhancements
User Interface

Active Directory Replication & Group Managed Service


Topology Cmdlets Accounts
Active Directory Replication & Topology
Cmdlets
Background
administrators require a variety of tools to manage Active
Directory’s site topology
repadmin
ntdsutil
Active Directory Sites and Services
etc.
results in an inconsistent experience
difficult to automate
Active Directory Replication & Topology
Cmdlets
Solution
manage replication and site-topology with Active Directory Windows
PowerShell
create and manage sites, site-links, site-link bridges, subnets and connections
replicate objects between DCs
view replication metadata on object attributes
view replication failures
etc.
provides a consistent and more easily scriptable experience
compatible and interoperable with other Windows PowerShell Cmdlets
Active Directory Replication & Topology
Cmdlets
Requirements
Active Directory Web Service (ADWS)
or Active Directory Management Gateway
(for Windows Server 2003 or 2008)
Remote Server Administration Tools (RSAT)
In Review
Easier to Manage

Windows Server 2012 In the past…


Managed Service Accounts for farms (gMSA) Managed Service Accounts work only on a
Support for cross-domain Kerberos single machine
Constrained Delegation Kerberos Constrained Delegation (KCD) works
Spoofing of Kerberos errors much more only within a single domain
challenging Kerberos errors able to be spoofed
Active Directory UI investments No support in Active Directory Administrative
support in Active Directory’s Administrative Center Center for Recycle Bin or Fine Grained
for managing deleted objects and Fine Grained Password Policies
Password Policies
PowerShell code must be written from scratch
ability to view Windows PowerShell scripts that
correspond to actions performed in the GUI Hodge-podge of incompatible command-line
Easier scripting of replication and topology tools and UIs used for managing replication
tasks using new Active Directory Windows and topology
PowerShell Cmdlets
In Review
Easier to Deploy

Windows Server 2012 In the past…


Safe virtualization Using snapshot features on virtual DCs results
Simplified deployment in a divergent Active Directory state
Integrated end-to-end deployment experience Active Directory environment preparation is
All deployment tasks are remoteable and overly complex requiring multiple steps
automatically target the correct FSMOs DC promotion requires multiple phases to
Input and environment validation throughout the complete
deployment process helps decrease failures
Full Windows PowerShell support for automated Deployment is not remoteable and requires
deployment interactive logon to multiple DCs
Rapid deployment of DCs using cloning Difficult to write automation scripts
AD FS deployment integration
Summary of Minimum Requirements
With this deployed… ... these features become available
• New Active Directory Administrative Center
• Windows PowerShell History Viewer
• Graphical Recycle Bin and FGPP management
+ First Windows Server 2012 domain-member • Richer authorization through DAC & FCI
• Active Directory-based Activation
(or Windows 8 with RSAT installed)
• Requires Windows Server 2012 schema extensions
• Active Directory Replication & Topology Cmdlets
• AD FS (v2.1)

• Simplified Deployment and Preparation


• Dynamic Access Control policies and claims
• Kerberos Claims in AD FS (v2.1)
+ First Windows Server 2012 DC • Cross-domain Kerberos Constrained Delegation
• Group Managed Service Accounts
• Virtualization-Safe for the Windows Server 2012 DC
• requires Hypervisor support for VM-Gen-ID

• Rapid virtual DC deployment through DC-cloning


+ Windows Server 2012 DC holds PDC FSMO role • requires Hypervisor support for VM-Gen-ID
Appendix
Enhanced LDAP logging

Note that the registry override technique uses the Microsoft-internal DSID of the source-
code file that implements the desired logging
DSID used in a non-traditional manner (though similar):
<dir ID><dir ID><file ID><file ID><logging level><logging level><logging level><logging level>
typically, it’s:
<dir ID><dir ID><file ID><file ID><line #><line #><line #><line #>
there are ~15 directories with 15+ potentially useful source files in each
source-code access is a MUST (and an ability to read the code is beneficial, too )

HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\”
Value [MULTI_SZ]: Logging Override
Data: 0C12FFFF (where FFFF says “log everything”)
New LDAP Controls/Behaviors
Batched extended-LDAP operations (1.2.840.113556.1.4.2212)
all operations within a given batch are treated as a single transaction, i.e. all succeed or all fail
primarily designed for a developer audience
possible with LDP but really not realistic
comprises a regular LDAP control and an unimaginably complex value
concatenation of the series of BER encoding of the ASN.1 descriptions of the desired LDAP operations  see, I told ya
useful for programmatic schema extensions since the entire list of updates could be batched
permits the entire set of updates to succeed or fail as a lump

Expected entry count (1.2.840.113556.1.4.2211)


LDAP control that requires a minimum and maximum value (again, BER encoded values so not trivial for the IT pro)
if fewer than minimum or more than maximum, results are returned up to the exception and rounded to the
nearest page size
useful for uniqueness and/or absence checking (min=1 & max=1 --OR-- min=0 & max=0)
when used in conjunction with batch processing…
it is possible to express conditional LDAP operations that fail or succeed as a transaction based on a supplied criteria
e.g. write email address <e1> to userX only IF <e1> is not already in use by anyone else
carve out a filter that queries for the email address within my desired scope within an expected entry count of “0”
New LDAP Controls/Behaviors
Require server-sorted search use index on sort attribute (1.2.840.113556.1.4.2207)
only impacts sorted searches
if query optimization does not result in a correctly sorted result set, then we revert to
using a simple index over the sort attribute  requires post-processing to satisfy
request
the term “correctly” is defined as the index’s natural sort criteria matches the specified sort criteria
eliminates the need for tempTable thereby increasing scale possibilities (good for large result sets because, in
the past, it would have simply failed)
on the flip side, causes performance problems for smaller result sets

DIRSync_EX_Control (1.2.840.113556.1.4.2090)
alters traditional DirSync behavior
forces the return of specified unchanged attributes
useful for a primarily developer audience only
New LDAP Controls/Behaviors
TreeDelete control with batch size (1.2.840.113556.1.4.2204)
ensures deletions do not slow convergence beyond system tolerance
today, batch size is hard-coded to 16K
new control exposes a mechanism to lower this hard-coded default (not raise it)
value must be between 2 and hard-coded limit of 16K
exposed as an LDAP control allowing the delete operation to declare its own batch size
requires that the value for the control be BER encoded

Return highest change stamp applied as part of an update (1.2.840.113556.1.4.2205)


similar to searchStats control in that when checked in, causes the result to contain additional
data housing the invocationID and highest USN allocated during the transaction
ITpro needs a tool to decode the resulting BER encoded series of key/value pairs
invocationID: 1.2.840.113556.1.4.2209
highestUSN: 1.2.840.113556.1.4.2208
useful for programmatically determining convergence between any two instances immediately
following an update
New LDAP Controls/Behaviors
Include ties in server-sorted search results [aka. “soft size limit”] (1.2.840.113556.1.4.2210)
within the context of a sorted search, two objects are considered “tied” if their attribute values
for the sorted attribute are the same, i.e. the objects are tied by virtue of the common value in
the sort attribute (same place in the index)
also termed “soft size limit”
value supplied for SOFT_SIZE_LIMIT must be less than LDAP size limit
search must be sorted in order for the notion of a “tie” to have any meaning
what does it do?
imagine paging through the Exchange GAL and requesting only a page at a time
you’d like to be able to get the next page from any DC (not become “sticky” with the same DC the request began
against)
to do so, you need to be sure where the last page ended, e.g. I’m on page 3 sorted on givenName and it ends with
Dean
what if there are multiple Deans?
“soft size limit” numerically governs the page-size but ensures that any duplicates of the last entry (Dean) are also
returned
unless that exceeded the hard-size limit
this allows the next page to be requested by filtering on “(&(givenName>=Dean)(!(givenName=Dean)))”
which, in turn, permits the page requests to be distributed across DCs
© 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.

You might also like