Professional Documents
Culture Documents
What's New in Active Directory in Windows Server 2012 (WSV312)
What's New in Active Directory in Windows Server 2012 (WSV312)
Objectives / Takeaways
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
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
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
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
+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
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
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
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
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
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
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
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
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
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
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
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
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
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
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