New features in Active Directory Domain Services in Windows Server 2012, Part 15: Deferred Index Creation

As already mentioned in the previous blog post on RID Improvements in Windows Server 2012, Active Directory environments are sometimes cathedrals of Microsoft technology; they're big, they're old and a lot of effort has been put into them to get them into the shape they're in today.

In these environments, changes in the indexability of objects and their attributes may sometimes have a big effect on the availability of Domain Controllers to serve clients and replicate changes. In these environments, index creation almost results in a Denial of Service (DoS) of Active Directory, when all Domain Controllers are semi-simultaneously busy (re)creating indices in the database. And isn't that ironic? These indices were built into Active Directory to speed up the performance in the first place.

So, when do changes in indexability of objects and attributes occur? Basically, three scenarios exist where Domain Controllers will (re)build indices:

• When a Domain Controller is shut down inappropriately, when a Domain Controller is restored from an improper backup or when a Domain Controller has been converted to a virtual machine without bringing it offline.
• When an Active Directory admin makes a change in the schema to make an attribute indexable.
• When an Active Directory admin performs a schema update, for instance to accommodate Domain Controllers running newer versions of Windows Server, or to introduce Exchange Server or Lync Server in the current environment.

In the latter two scenarios, Windows Server 2012 helps out.         

What's New

On Domain Controllers running Windows Server 2012, index creation can be deferred to a time when it's more convenient. The feature is called Deferred Index Creation.

DSHeuristic

The way the Active Directory team has built this into Windows Server 2012 is by using a bit in the DSHeuristic attribute in the Directory Services object.

Enabling Deferred Index Creation

Deferred Index Creation can be enabled by changing the 18th bit from 0 to 1. Here's how:

1. Run ldp.exe.
2. Click the Connection menu and click Connect. Use the default port 389. When connected, go back to the Connection menu and click Bind... Bind as an enterprise administrator.
3. Click the View menu and click Tree, then for the Base DN select the domain naming context from the drop-down list. Click Ok.
4. In the navigation pane, drill down into the CN=Configuration container, then CN=Services, CN=Windows NT and there click the CN=Directory Services object.
5. Double-click the CN=Directory Services object.
6. Check the object attribute listing on the right side to determine whether the dsHeuristics attribute is already set. If it is set, copy the existing value to the clipboard.
7. Right-click the Directory Service objects on the left side, and then click Modify.
8. As the attribute name, type dsHeuristics.
9. As a value, type 000000000100000001. Replace the zeros in the first part of the value with what you may already have in dsHeuristics. Make sure that you have the correct count of digits up to the "1"; To enable Deferred Index Creation the 18th bit needs to be set.
   
        Note:
        To verify that the correct characters are being modified, every tenth character
        must be set to the number of characters up to that point divided by ten;
        The tenth character must be 1, the twentieth character must be 2, the
        thirtieth character must be 3, and so on.
       
10. If the attribute already existed, click Replace in the Operation box. Otherwise, click Add.
11. Press ENTER on the right to the Operation group to add it to the LDAP transaction.
12. Click Run to apply the change to the object:
        
        
        
13. When successful, the output will be:
         
         ***Call Modify...
         ldap_modify_s(ld, 'CN=Directory Service,CN=Windows NT,CN=Services,
         CN=Configuration,DC=domain,DC=local',[1] attrs);
         Modified "CN=Directory Service,CN=Windows NT,CN=Services,
         CN=Configuration,DC=domain,DC=local".
    

After this change is replicated to all Domain Controllers, they will defer Index Creation by default. This will result in the following behavior:

• Windows Server 2012-based Domain Controllers will defer building indices until they receive the UpdateSchemaNow rootDSE mod. . This triggers the rebuilding of the schema cache.
• Windows Server 2012-based Domain Controllers will defer building indices until they are rebooted.  This requires that the schema cache be rebuilt and, in turn, the deferred indices.

In addition, any attribute that is in a deferred index state will be logged in the event Log every 24 hours on each of the Domain Controllers with Deferred Index Creation enabled. The following event-ids are used:

• event-id 2944: index deferred – logged once
• event-id 2945: index still pending – logged every 24 hours    

Performing a UpdateSchemaNow rootDSE mod

Having Deferred Index Creation enabled allows for greater control over which Domain Controller will build indices at what moment in time. However, rebooting Domain Controllers as a means seams worse than the initial problem, since without Deferred Index Creation, Domain Controllers would be unavailable, but wouldn't need to be rebooted.

With Deferred Index Creation enabled, Domain Controllers don't need to be rebooted, although in some scenarios it might be the easiest way. For instance when Schema Updates are part of a service window that also includes applying Windows Updates and thus rebooting servers.

Domain Controllers with Deferred Index Creation enabled can be set to build the indices with the UpdateSchemaNow rootDSE mod. Perform the following steps to do so:

1. Run adsiedit.msc.
2. Right-click the ADSI Edit text in the top of the left most pane and select Connect to... from the context menu.
3. Leave the Default Naming Context as name, but select the Select a well known Naming Context: option and change it to RootDSE from the pull down list.
4. Right-click the RootDSE and choose Update Schema Now from the context menu:
       
       
   

When the Domain Controller has built the index event-id 1137 is logged in the event log. It will indicate the index has been created. But you might already be familiar with this event-id, since it's not a new event-id.

New features in Active Directory Domain Services in Windows Server 2012, Part 14: RID improvements

Active Directory is a proven technology that has been around since Windows 2000 Server. Some Active Directory environments have been around since that time, while some others have even been around ever longer and started their lives as Windows NT 3.x or Windows NT 4.0 domains. With directory environments growing older, some limits of these environments come into sight.

In Active Directory Domain Services and Active Directory Lightweight Domain Services (or Active Directory Application Mode, ADAM, as we knew it in earlier times) one of the typical limits older environments might face is the maximum size of the RID Pool.

About Relative Identifiers (RIDs)

Relative Identifiers (RIDs) are used in Active Directory Domain Services and Active Directory Lightweight Domain Services to create objects within the namespace of the environment. Under the hood every object has a Security Identifier (SID), consisting of the SID Namespace of the domain and the Relative Identifier (RID):

Tip!
You can easily find the SID of a currently logged in user with the whoami.exe /user command.

About RID Pools and RID Pool blocks

Active Directory uses a multi-master model. Compared to NT4, you can write to the database on all Domain Controllers. This model requires certain roles to be unique. In Active Directory five roles, named the Flexible Single Master Operations (FSMO) roles are identified. FSMO roles are added to Domain Controllers.

The RID Pool Master FSMO role is one of them. The scope of the RID Pool Master FSMO role is the domain. Domain Controllers communicate with the RID Pool Master to acquire a RID Pool block so they can accommodate object creation in the multi-master model. Since every object in Active Directory has an unique SID, consisting of the Domain SID Namespace and the Relative Identifier (RID) to the namespace, each object creation requires a RID.

The RID Pool depletion challenge

When an Active Directory environment runs out of Relative Identifies (RIDs) , a situation called RID Pool exhaustion or RID Pool depletion occurs. This is a serious problem, since no new objects can be created after the local RID Pool blocks of the Domain Controllers,  are used up.

In an Active Directory domain, 2³⁰-1 (1,073,741,823 or roughly 1 billion) RIDs are available, resulting in a maximum of 2 billion objects, including users, computers, groups, domain trusts, fine-grained password policies and Managed Service Accounts (MSAs).

The make things worse, a couple of scenarios have been identified, where RID Pool blocks and thus the RID Pool is used up fast. In these scenarios a RID is taken from a RID Pool block, but is not used to create an object. A prime example is user creation, where the user didn't meet the policies set in the domain. An example of such a policy would be a password policy. Also, when a Domain Controller computer object was deleted and subsequently reanimated or restored, it would ask for a new RID Pool block every 30 seconds because of a missing rIDSetReference attribute and thus depleting the RID Pool in roughly 2 years...

Analyzing remaining RIDs in an environment

To analyze the state of an Active Directory environment, use the following command:

dcdiag /test:ridmanager /v | find /i "Available RID Pool"

The output will show you the used relative identifier compared to the maximum amount of available RIDs in the environment in the following format:

* Available RID Pool for the Domain is 1601 to 1073741823            

What's New

The RID Reuse Pool

Identified scenarios that lead to unusual fast RID Pool depletion have been fixed.

In Windows Server 2012, when RID leaked when object creation fails occurs, the RID is placed in a RID Reuse pool, instead of being leaked. Upon subsequent object creation, a RID is taken from the RID Reuse pool (if any available) instead of from the RID Pool block. Rebooting a Domain Controller clears the RID Reuse Pool.

Periodic RID Pool Consumption Warnings

When an Active Directory environment reaches RID Pool depletion, warnings will appear in the System log of the Domain Controller holding the RID Pool Master FSMO role. These warnings start at 10% depletion and become more frequent as the RID Pool is further depleted. These consumption warnings are found in the form of warnings in the System Log of Domain Controllers with event-id 16658 and source Directory-Services-SAM.

RID Pool Artificial Ceiling Protection

When the Domain Controller holding the RID Pool Master FSMO role has handed out RID Pool blocks corresponding to 90% of the RID Pool, it will stop handing out RIDs and RID Pool blocks. Additionally, at that moment, event-id 16657 with source Directory-Services-SAM is logged. This results in a soft ceiling to prevent full RID Pool depletion. This helps Active Directory admins to avoid further problems, since they will still be able to commission more Windows Server 2012-based Domain Controllers to get rid of Domain Controllers on older versions of Windows Server and/or to create trusts to migrate objects with the Active Directory Migration Tool (ADMT).

Tip!
This is a crucial moment in the life of the Active Directory environment and should trigger a meeting with all Active Directory admins and their managers to decide on the course to follow to keep the Active Directory healthy for a long time. This might be the moment to collapse that multi-resource forest environment or to migrate to a new Active Directory domain.

Domain Admins can override the ceiling by setting the msDS-RIDPoolAllocationEnabled attribute on the RID Manager$ object in the System container of the domain to true. Perform the following steps to achieve this:

1. Run LDP.exe
2. Click the Connection menu and click Connect for the Windows Server 2012-based Domain Controller holding the RID Pool Master FSMO role. Use the default port 389. When connected, go back to the Connection menu and click Bind. Bind as a domain administrator.
3. Click the View menu and click Tree, then for the Base DN select the domain naming context from the drop-down list. Click Ok
4. In the navigation pane, drill down into the CN=System container and click the CN=RID Manager$ object. Right click it and click Modify
5. In Edit Entry Attribute, type:
       
        MsDS-RidPoolAllocationEnabled
       
6. In Values, type (in upper case):
       
        TRUE
       
7. Select Replace in Operation and click Enter. This updates the Entry List.
8. Enable the Synchronous option, then click Run.
9. If successful, the LDP output window shows:

***Call Modify...
ldap_modify_ext_s(ld, 'CN=RID Manager$,CN=System,DC=domain,DC=tld',[1] attrs, SvrCtrls, ClntCtrls);
Modified "CN=RID Manager$,CN=System,DC=<domain>".     

Upper bound for RID Pool Block Sizes

As you might know, by default, a RID Pool block consists of 500 RIDs. In previous versions of Windows Server, the RID Pool block size could be configured by editing the registry on each Domain Controller. The RID Block Size (REG_DWORD) registry value located in HKLM\System\CurrentControlSet\Services\NTDS\RID Values could be used to that purpose.

in Windows Server 2012, the maximum permissible admin-configured RID block size is 15,000. This means that the RID Pool block size now has a maximum of 15,000 RIDs, independent of the value entered in the registry.

If a value greater than 15,000 is entered, it will use a RID Pool block size of 15,000. Additionally error 16653 with source Directory-Services-SAM will be logged at every boot to inform only RID Pool blocks of 15,000 RIDs are requested from the Domain Controller holding the RID Pool Master FSMO role.

Double the RID Pool

In Windows Server 2012, the 31st bit of the RID Pool can be enabled, enabling organizations to create a billion more objects, in addition to the original billion RIDs. By unlocking the 2³¹ bit increases the RID Pool to 2,147,483,647.

Unlocking the 31st bit of the RID Pool can be achieved by setting sidCompatibilityVersion to 1 using a RootDSE Modification:

1. Run LDP.exe
2. Click the Connection menu and click Connect for the Windows Server 2012-based Domain Controller holding the RID Pool Master FSMO role. Use the default port 389. When connected, go back to the Connection menu and click Bind. Bind as a domain administrator.
3. Click the Browse menu and click Modify
4. Ensure that DN is blank
5. In Edit Entry Attribute, type:
       
        SidCompatibilityVersion
       
6. In Values, type:
       
        1
       
7. Ensure that Add is selected in Operation and click Enter. This updates the Entry List
8. Select the Synchronous option, then click Run:
       
   
       
9. If successful, the LDP output window shows:
       
        ***Call Modify...
        ldap_modify_ext_s(Id, '(null)',[1] attrs);
        modified "".
       
10. When successful, Information event 16655 from source Directory-Services-SAM will be logged once in the System log of the Domain Controller. 

Requirements

For Lifting the RID Pool Artificial Ceiling Protection, the Domain Controller holding the RID Pool Master FSMO Role should be running Windows Server 2012.

Tip!
Since, for Domain Controller Cloning you might have already migrated the Domain Controller holding the PDC Emulator FSMO Role to Windows Server 2012 and KnowledgeBase article 223346 recommends to place the PDCe and RID Pool Master FSMO roles on the same server, this might not be such a harsh requirement.

When you want to enable the 31st bit of the RID Pool to effectively double the available RIDs, all Domain Controllers should be running Windows Server 2012. Previous versions of Windows Server on Domain Controllers should be patched or upgraded.

All the other features are local features to Windows Server 2012 and should be available per Domain Controller when you promote them.

New features in Active Directory Domain Services in Windows Server 2012, Part 13: Domain Controller Cloning

In the previous blogpost in this series I discussed virtualization-aware Active Directory. With the use of the newly introduced VM-GenerationID, virtual Domain Controllers can now detect when they are reverted back to an earlier state or when their virtual hard disk is reused. Let's look into the latter scenario a bit.

In Windows Server 2008 R2 and earlier, when you'd reuse a hard disk of a Domain Controller to create a new host on the same network, two Domain Controllers would exist with the same hostnames, IP addresses and invocationIDs. This would cause all sorts of problems.      

What's New

But actually, cloning a Domain Controller isn't even that counterintuitive. Sure, we've been conditioned to promote additional Domain Controllers with or without Install from Media (IfM), but in reality, when you have a standardized environment, dedicated Domain Controllers are 98% equal. Besides, it's not the process of promoting a server to a Domain Controller that takes up a lot of time. It's installing the Windows updates since the last Service Pack, installing drivers, installing anti-malware, backup, monitoring, UPS- and other management agents, configuring these updates, installing their updates and making sure they all work, that's the bulk of the work. No wonder, IT departments work with SLAs that permit them to work days to set up a new production server…

So how does configuring a replica Domain Controller within 10 minutes sound?

Because that's exactly what the Active Directory team has created in Windows Server 2012, building on top of the VM-GenerationID and virtualization safeguards. The feature is called Domain Controller Cloning, or DCCloning for short.         

Cloning Domain Controllers from the GUI (mostly)

Cloning a Domain Controller is done in seven steps:

1. Allow the source Domain Controller to be cloned

In the previous blogpost I explained how Active Directory in Windows Server 2012 is now virtualization-safe; Virtualization Admins no longer need to know which virtual machines to be careful with and Active Directory Admins no longer have to fear the work done by the Virtualization Admins.

For Active Directory Admins to keep control of their virtual Domain Controllers, they are the ones to authorize their servers for Domain Controller Cloning. When a Domain Controller is unauthorized, a Virtualization Admin cannot clone a virtual Domain Controller. (It will boot into the Domain Services Restore Mode).

Authorizing a Domain Controller for Domain Controller Cloning, it's computer object needs to be made a member of the Cloneable Domain Controllers global security group, located in the Users container.

Alternatively you can grant the DS-Clone-Domain-Controller extended right, as, under the hood, this is the right the Cloneable Domain Controllers group grants.

2. Resolve Service Principal Name issues

One of the limitations of Domain Controller Cloning is the ability to clone Service Principal Names (SPN). Therefore, you should manually check for SPNs on the Domain Controller before cloning a Domain Controller. The following PowerShell one-liner, when run on the source Domain Controller, shows you the Service Principal Names in use:

Get-ADServiceAccount –filter:"*"

Check the output of this command. When it returns one or more service accounts, make sure to either remove the associated service (temporarily) or convert the service account into a group Managed Service Account (gMSA).

3. Resolve problems with non-cloneable applications, agents and services

Applications, agents and services in use on Domain Controllers might pose a challenge when you clone a Domain Controller. Microsoft has done an incredible amount of work to make sure their services are cloneable. This work can be seen when examining C:\Windows\System32\DefaultDCCloneAllowList.xml. However, with new applications, agents and services being released by both Microsoft and other vendors, we are bound to bump into software that has not been tested, yet. To get a list of installed software that is not on the list of tested software (DefaultDCCloneAllowList.xml), perform the following PowerShell one-liner:

Get-ADDCCloningExcludedApplicationList

This command might return a set of applications and services that are not tested. Now, when the Domain Controller Cloning process runs into an application, agent of service that is not on the Default Domain Controller Clone Allow List (DefaultDCCloneAllowList.xml) it will feel it is not allowed to perform the clone. When the command doesn't detect any untested applications, agents or services, you and the Domain Controller are good to go to the next step. When the command returns programs or services, you need to resolve the issues. You can do this in two ways:

1. Uninstall the program or service (temporarily)
2. (Work with the software vendor to) Test the application, agent and/or service for cloning.

When following the second method and you feel the applications and services detected using the Get-ADDCCloningExcludedApplicationList command don't stand in the way of successful Domain Controller Cloning, you can add these applications to a Custom Domain Controller Clone Allow List (CustomDCCloneAllowList.xml). This last file uses the same syntax as the Default Domain Controller Clone Allow List, so it will look something like this:

Place the CustomDCCloneAllowList.xml file in the same folder as the Active Directory database (ntds.dit) on the source Domain Controller.

Note:
By default, the location of the Active Directory database is C:\Windows\NTDS.

4. Write the DcCloneConfig file

In this step we specify the configuration of the target Domain Controller; the Domain Controller that will be the result of Domain Controller cloning. For this purpose we write a DCCloneConfig.xml file.

As the basis for our file, we use C:\Windows\System32\SampleDCCloneConfig.xml:

As the file shows, it has predefined fields we can use to specify configuration information for the new Domain Controller. When you work with DHCP Reservations for your Domain Controllers, are fine with Microsoft-generated Domain Controller names and want the target Domain Controllers to show up in the same Active Directory site as the source Domain Controller, you can use this file as is and save it as DCCloneConfig.xml in one of the following locations:

• the same folder as the Active Directory database (ntds.dit) on the source Domain Controller.
• In the root of (virtual) removable media, such as virtual floppy drives (*.vfd files) or virtual CD- and DVD-drives (*.iso-files)

Note:
When you save DCCloneConfig.xml on removable storage, make sure the admin creating the clone (step 4) attaches the removable storage to the virtual machine, but does not make the virtual machine boot from the media.

When you want to specify environment-specific configuration settings, do so before saving the file.

Tip!
In Windows Server 2012 you can mount a virtual hard disk when it's not in use by a virtual machine by right-clicking it. This way, it's possible to insert the DCCloneConfig.xml file in a later stadium. Right before you start up the target Domain Controller for instance.

5. Copy the virtual hard disk of the source Domain Controller and base the target Domain Controller on it.

Now, the source Domain Controller is fully checked, prepped and authorized. A Virtualization Admin can now copy its virtual hard disk VHD and create a new Virtual Machine, with that virtual hard disk.

Tip!
The source Domain Controller does not need to be turned off for you to be able to make a copy of its virtual hard disk for the target Domain Controller.

6. Start the target Domain Controller

Now it's time to feed the virtual machine its DCCloneConfig.xml file when using removable media and start it up.

When successful, the target Domain Controller will boot up and display its progress in Domain Controller cloning:

7. Restore any (temporarily) removed functionality

After the Domain Controller is done cloning, log on and restore any (temporarily) removed applications, agents, services and Service Accounts.     

Automating Domain Controller Cloning with PowerShell

While using the Graphical User Interface (GUI) to prepare the source Domain Controller gives great control over the individual steps of the process, PowerShell can help to cover all the bases and get the process streamlined.

Below is information on performing the steps that error out using PowerShell commands:

1. Adding the source Domain Controller to the Cloneable Domain Controllers group

To add the source Domain Controller to the Cloneable Domain Controllers group through PowerShell, use the following PowerShell one-liner:

Add-ADGroupMember "Cloneable Domain Controllers" "cn=dc01,ou=Domain Controllers,dc=domain,dc=tld"     

2. Resolve Service Principal Name issues

As stated above, you can run Get-ADServiceAccount on the source Domain Controller, to get the list of Service Principal Names in use. To remove the Service accounts automatically, use the following PowerShell one-liner:

Get-ADServiceAccount –filter:"*" | Remove-ADServiceAccount 
-confirm:$false   

3. Resolve problems with non-cloneable applications, agents and services

You would typically run the Get-ADDCCloningExcludedApplicationList PowerShell Cmdlet to get a list of the programs and services blocking successful Domain Controller Cloning. The following PowerShell one-liner can be used to automatically create the CustomDCCloneAllowList.xml file in C:\Windows\NTDS:

C:\PS>Get-ADDCCloningExcludedApplicationList -GenerateXml -Path C:\Windows\NTDS –Force   

4. Write the DCCloneConfig file

At this stage, run the New-ADDCCloningConfigFile PowerShell Cmdlet. You do not need to specify any parameters if you don't want to. When you don't, this Cmdlet will create the cleanest of DCCloneConfig.xml files in the Active Directory database path. This specific DCCloneConfig.xml will use the following Domain Controller Cloning configuration:

• The target Domain Controller will be assigned IP-addresses through DHCP
• The target Domain Controller name will be automatically generated
• The target Domain Controller will show up in the same Active Directory site as the source Domain Controller

If you want to specify a name, Active Directory site or IP addressing information take a look at the parameters you can specify for New-ADDCCloningConfig, like the –SiteName,
–CloneComputerName and –Static –IPv4Address parameters. A sample PowerShell one-liner would look like:

New-ADDCCloneConfigFile -CloneComputerName "DC02" -SiteName "ADSite01" -Static -IPv4Address "10.0.1.2" -IPv4SubnetMask "255.255.255.0" -IPv4DefaultGateway "10.0.1.1" -IPv4DNSResolver "10.0.0.2"  

 

Requirements

To use the Domain Controller Cloning feature, you should take care of the following requirements:

• At least one Windows Server 2012-based Domain Controller needs to be configured to host the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role. This change should be replicated to all Domain Controllers in affected Active Directory sites.
• The source Domain Controller needs to be run on a VM-GenerationID-capable virtualization platform and the Integration Components / Tools need to be installed and running.
• The source Domain Controller needs to run Windows Server 2012.
• The source computer needs to be a member of the Cloneable Domain Controllers group or needs to be granted the DS-Clone-Domain-Controller extended right.
• The source Domain Controller cannot be assigned Managed Service Accounts (MSAs), unless these accounts are group Managed Service Accounts (gMSAs).
• Applications that are incompatible with cloning should be uninstalled or added to CustomDCCloneAllowList.xml.
• The information specified in DcCloneConfig.xml should be unique. When a duplicate or invalid computername is specified, when an IP address conflict is detected, when IP and DNS information is left out and there is no DHCP Server on the network, when only one WINS Server address is specified or when a typo is made in the Active Directory sitename, the Domain Controller Cloning feature will halt. 

Note:
You can only create replica Domain Controllers with Domain Controller cloning, not Read-only replica Domain Controllers.

Note:
After you clone a Domain Controller the DCCloneConfig.xml file gets renamed (appended with the date), so the server won't accidentally clone itself again.

New features in Active Directory Domain Services in Windows Server 2012, Part 12: Virtualization-safe Active Directory

In organizations with different teams being responsible for Active Directory management and management of the virtualization/hypervisor layer, it is not uncommon to seriously damage contents in Active Directory with snapshots. Virtualization Admins can easily cripple Active Directory by reverting a snapshot of a virtual Active Directory Domain Controller, since Active Directory, currently, is not virtualization-aware.

Microsoft has been advising people not to use snapshots or any of the fancy server virtualization features on virtual Domain Controllers, for that reason. But then, virtualization admins might not know which virtual servers are Domain Controllers. It's not entirely their fault, either, because sometimes Active Directory admins don't know which servers are Domain Controllers because of overly complex server naming, change after change in an undisclosed change management process and/or merger/acquisition scenarios.

Making Active Directory virtualization-aware and making Active Directory virtualization-safe, therefore, is a welcome feature for these organizations. Also, for less knowledgeable Active Directory Admins virtualizing Active Directory Domain Controllers, those features would prevent them from inadvertently introducing USN Rollbacks and Lingering Objects.

USN Rollbacks

Domain Controllers replicate changes. Whenever a change occurs on a Domain Controller, the Unique Serial Number (USN) of that Domain Controller increases. Each Domain Controller records the USNs it sees of its replication partners. This is recorded in the High Watermark Table. Replication partners are denoted using Invocation IDs in this table. The combination of USN and Domain Controller is captured as the up-to-dateness vector.

When you restore a Domain Controller to an earlier state, you would restore the USN to an earlier state. This is called an USN rollback.

Since its replication partners have seen a future USN for the Domain Controller and objects in Active Directory record the Domain Controller they originated on in the replication metadata, no changes on objects will be replicated out until the restored Domain Controller reaches the USN recorded in the High Watermark Table. This effect, called an USN Bubble, causes user accounts and computer accounts that are created on the restored domain controller to not exist on replication partners. Or, the password updates that originated there do not exist on replication partners.

Lingering Objects

When you delete an object in Active Directory it doesn't really get deleted, it gets tombstoned. In this process all but its most critical attributes (objectGUID, objectSid, nTSecurityDescriptor, uSNChanged and sIDHistory) are stripped and the changes are replicated between Domain Controllers. Only after the tombstone lifetime, the object gets deleted. This deletion takes place every 12 hours by the Garbage Collection process per Domain Controller.

In normal situations, the tombstone process allows Domain Controllers to have sufficient time to replicate the tombstones. However, when you restore a Domain Controller to a point in time beyond the tombstone lifetime, the process may fail and objects that you expect to have been deleted may still exist on some Domain Controllers. These objects are called lingering objects.

More information on both these problems can be found in the free whitepaper I wrote earlier this year:

What's New

Active Directory Domain Services is the first Windows Server Role to take advantage of the VM-GenerationID. This random 128bit identifier is a new feature of Hyper-V in Windows Server 2012 and is placed in the RAM of each virtual machine (VM). Every VM gets its own VM-GenerationID from the virtualization platform. The virtualization platform keeps the VM-GenerationID the same for a VM, unless the VM is reverted back to a snapshot.

A virtual Domain Controller, running Windows Server 2012 reads this value when it starts and before every write to the Active Directory database. It stores the value of VM-Generation ID in the msDS-GenerationID attribute of its object in the local Active Directory database.

For every write, the Active Directory service compares the VM-GenerationID in RAM with the ms-DS-Generation-Id attribute in the Active Directory database. If they match, no problem. If they don't match, the Domain Controller has either been reverted to a previous snapshot, or the virtual disk of the Domain Controller has been reused for a different Domain Controller.

In the case of a snapshot, the invocationID is renewed and the RID Pool block in use is discarded. This effectively designates the Domain Controller as a new replication partner for other Domain Controllers, so they can replicate in necessary changes to avoid USN Rollbacks and Lingering Objects.   

Exposing the VM-GenerationID

There are two ways to see the VM-GenerationID. The difficult way is to look in the Device Manager. When you fulfill the requirements (below) you will see a device called Hyper-V Generation Counter under System Devices:

As stated in the Virtual Machine Generation ID whitepaper, there is a way to substract the parts of the VM-GenerationID and construct it.      

Requirements

The virtualization safeguards incorporated around VM-GenerationID will help Domain Controllers prevent USN Rollbacks and Lingering Objects when you fulfill the following requirements:

• The virtualization platform used to run virtual Domain Controllers needs to support the VM-GenerationID feature.
• Virtual Domain Controllers need to run Windows Server 2012.

New features in Active Directory Domain Services in Windows Server 2012, Part 10: Improved KCD

Kerberos Constrained Delegation (KCD) is a feature in Windows Server that has been available since Windows Server 2003 through Kerberos extensions. It allows for clients to let an application or a service connect to other servers or services on its behalf. A client might use a front-end server, for example, that then needs to authenticate with a back-end server. The front-end server needs to authenticate to the back-end server with the client's credentials, because if it authenticated under its own service account, it would have different authorization than the user.

The Kerberos protocol includes a mechanism called delegation of authentication. When this mechanism is used, the client delegates authentication to the front-end server by informing the Key Distribution Center (KDC) that the front-end server is authorized to act on behalf of a specified Kerberos security principal, such as a user that has an Active Directory directory service account. The front-end server can then delegate authentication to the back-end server.

In the Windows 2000 delegation model, the Key Distribution Center (KDC) does not limit the scope of services that a Kerberos principal's identity can be delegated to. That is, after a service account is trusted for delegation, it can request service tickets on behalf of a given user to any other service accounts. With Kerberos Constrained Delegation (KCD), on the other hand, domain administrators can configure service accounts to only delegate to specific sets of service accounts. In Windows Server 2003 and higher, the ms-DS-Allowed-To-Delegate-To attribute is added to service accounts to help enforce KCD. This attribute lists the service principal names (SPNs) of other service accounts that a given service account is allowed to delegate to. When a Windows Server KDC processes a service ticket request via the constrained delegation extension, it will verify that the target service account is one that is listed in the ms-DS-Allowed-To-Delegate-To attribute.

Schematically, Kerberos Constrained Delegation (KCD) looks like:

        

What's New

Kerberos Constrained Delegation in Windows Server 2012 now supports cross-domain and cross-forest authentication scenarios.

Under the hood, Kerberos Constrained Delegation in Windows Server 2012 has moved the authorization decision to the resource-owners and this permits the back-end servers to authorize which front-end service accounts can impersonate users against their resources.

Also, there is a change in the required privileges, since you no longer need Domain Admin privileges to configure and manage Kerberos Constrained Delegation. It merely needs administrative privileges to the back-end service account.    

Requirements

If you want to use Kerberos Constrained Delegation (KCD) in cross-domain or cross-forest scenario, you need to fulfill the following requirements:

• Computers used by colleagues to access the service need to run Windows XP or later. These computers need to be domain-joined to a domain with Windows Server 2003-based Domain Controllers
• Front-end servers need to run Windows Server 2012
• One or more Domain Controllers in the front-end domain need to be running Windows Server 2012
• One or more Domain Controllers in the back-end domain need to be running Windows Server 2012  and the whole back-end server forest needs to prepared with the Windows Server 2012 schema update
• Back-end server accounts need to be configured with accounts that are permitted for impersonation
• Windows Server 2012 schema update in back-end server's forest
• Back-end application servers need to be running Windows Server 2003 or later

New features in Active Directory Domain Services in Windows Server 2012, Part 8: Group MSAs (gMSAs)

Back in Windows Server 2008 R2, Managed Service Accounts (MSAs) solved the problem of unsecure service accounts. Managing them was a nightmare, even if you knew what you were doing. Now, In Windows Server 2012, Microsoft addresses a couple of these challenges This blogposts shows how.   

What's New

Challenges with service accounts

We all use service accounts in our environments. These accounts allow us to run a service with the right amount of privileges. It also allows us to change the passwords for normal accounts, since these are not abused to run services.

However, there is also a downside to service accounts. Problems with service accounts pre-Windows server 2008 R2 include:

• Service account password changes are a nightmare and they tend to break stuff. Nonetheless, it is a best practice to change these passwords regularly.
• Passwords for service accounts are stored in plain text in registry. Sure, the passwords are protected, but still accessible if you know how.
• The Scope of service accounts is not easily set. Service accounts can often be used outside the intended scope, for instance to set up VPN connections are send mail through the (authenticated) SMTP gateway.

MSAs in Windows Server 2008 R2

Microsoft introduced the Managed Service Account (MSA) in Windows Server 2008 R2. This new object type (msDS-ManagedServiceAccount) is derived from the computer account object and lives in the Managed Service Accounts container under the domain root.

It offers a big benefit: just like with a computer account and the typical local system accounts, the managed service account will automatically change it password regularly. IT can also update its Service Principle Name (SPN) automatically.

From a security point of view, this means, in a worst case scenario, a sniffed (and decoded) password(hash) can only be used for a limited amount of time. It also means that when the account is only given the barely minimum privileges, an attacker cannot exploit a vulnerability in the service, beyond the service itself.

From a management point of view, it means you can create automatically changing service accounts per service per host. After renaming the host, the service will start like it did before.

To create and manage Managed Service Account, an Active Directory admin would use PowerShell. The typical command to create a Managed Service Account would look like this:

New-ADServiceAccount -Name MSA-Host1 -Path "CN=Managed Service Accounts,DC=domain,DC=tld"

Note:
While creating a Managed Service Account is also possible using Active Directory Users and Computers (ds.msc), this is not the ideal way to create these accounts.

Then, to assign the Managed Service Account to a host, the following PowerShell command would be used:

Add-ADComputerServiceAccount -Identity Host1
-ServiceAccount MSA-Host1

As a last step, install the Managed Service Account on the host, that hosts the service, in this case Host1:

Import-module Active Directory
Install-ADServiceAccount -Identity MSA-Host1

After this third step you can configure the service to run using the managed service account in the Services MMC Snap-in (services.msc).

gMSAs in Windows Server 2012

Alongside the Managed Service Account (MSA), in Windows Server 2012, a new type of object is being introduced: the group Managed Service Account. (msDS-GroupManagedServiceAccount)

gMSAs provide the same functionality as MSAs within the domain but also extends that functionality over multiple servers. When connecting to a service hosted on a server farm, such as IIS Network Load Balance farms, Exchange DAG members and SQL Failover Clusters, the authentication protocols supporting mutual authentication require that all instances of the services use the same principal. When group Managed Service Account are used as service principals, the Windows operating system manages the password for the account instead of relying on the administrator to manage the password.

gMSAs provide a single identity solution for services running on a server farm, or on systems behind Network Load Balance. By using gMSAs, services can be configured for the new gMSA object and the password management is handled by Windows.

Creating gMSAs

To be able to work with group Managed Service Accounts, first, the Key Distribution Services needs to be turned on on the Domain Controllers. This is a two-step procedure

Step 1. Configure the Group Key Distribution Service

First, you need to check whether the service is configured correctly on your Windows Server 2012-based Domain Controllers. For this, open the Active Directory Sites and Services MMC Snap-in (dssite.msc) and in the View menu check the Show Services Node option.

Then in the left pane, click to open the Services folder, then click to open the Group Key Distribution Service and drill down further by clicking on the Server Configuration node. Here you should see the Group Key Distribution Service Server Configuration object. When it exists, the service has been correctly registered.

In order for the Group Key Distribution Service to work, however, it needs root keys. In the Master Root Keys node under the Group Key Distribution Service node in Active Directory Sites and Services, check whether at least one exists. If not, use the following command to create them:

Add-KdsRootKey -EffectiveImmediately

Note:
Although the command specifies the Root Key to be effective immediately, you will actually have to wait 10 hours for it to become active. This ensures there is ample time to replicate the information to other Domain Controllers.

The command will output a Generally Unique Identifier (GUID) for the new Master Key. The new key should be visible with this GUID as its name in the Master Root Keys node under the Group Key Distribution Service node in Active Directory Sites and Services.

You will only need to create this first step once.

Step 2: Create a group (best practice)

When you want to dynamically scope the gMSA, it's a best practice to use a group. You can specify hosts allowed to consume the gMSA when you create the gMSA, but it's easier to create a group and make the servers a member of the group.

Note:
The servers need to be rebooted afterwards to pick up their new group memberships.

Step 3: Create the gMSA

To create a group Managed Service Account use the following PowerShell one-liner:

New-ADServiceAccount gMSA1 –DNSHostName MemberSrv1.domain.tld
-PrincipalsAllowedToRetrieveManagedPassword ShortGroupName

Note:
By default, a gMSA will change the password every 30 days, as defined in the msDS-ManagedPasswordInterval.

Step 4: Enable the gMSA for use on the hosts

On the host that hosts the service, execute the following command to make the gMSA available for selection in the Services MMC Snap-in (services.msc):

Install-ADServiceAccount gMSA1

Step 5: Specify the gMSA as the service account on the hosts

Now, in the Services MMC Snap-in (services.msc), specify the group Managed Service Account as the service account for the intended service:

    

Creating MSAs in Windows Server 2012

For Windows Server 2012, the Windows PowerShell cmdlets default to managing the group Managed Service Accounts instead of the server Managed Service Accounts. To create a 'normal' MSA instead of a gMSA, use the following PowerShell syntax:

New-ADServiceAccount MSA-Host1 -RestrictToSingleComputer    

Requirements

In order to create and use group Managed Service Accounts (gMSAs), you will need to meet the following requirements:

• Deploy at least one Windows Server 2012-based Domain Controller
  Even though gMSAs can authenticate to any Domain Controller in the environment, the passwords are computed by the Group Key Distribution Services (GKDS) running on Windows Server 2012-based Domain Controllers
     
• Active Directory Powershell on management servers
  Implement a Windows Server 2012-based member server with the Active Directory Module for Windows PowerShell feature installed. This feature is buried deep in the Remote Server Administration Tools, then Role Administration Tools and AD DS and AD LDS Tools.
    
• Active Directory PowerShell on management workstations
  Implement a Windows 8-based domain-joined workstation with the Remote Server Administration Tools (RSAT) package installed and Active Directory Module for Windows PowerShell feature installed. This feature is buried deep in the Remote Server Administration Tools, then Role Administration Tools and AD DS and AD LDS Tools.
    
• Recommended: Windows Server 2008 R2 Domain Functional Level
  For automatic password and SPN management to work, the Active Directory environment should be running the Windows Server 2008 R2 Domain Functional Level. If the domain is less than Windows Server 2008 R2 Domain Functional Level, automatic passwords will work, but automatic SPN management will not work, and SPNs will have to be maintained by administrators.

New features in Active Directory Domain Services in Windows Server 2012, Part 7: Fine-grained Password Policy GUI

Microsoft introduced the concept of Fine-grained Password Policies in Active Directory back in Windows Server 2008. From that day on, Active Directory admins could granularly roll out Password and Account Lockout Policies to groups and individual users. It was, however, such a painful experience, that many books suggested to use the free SpecOps Password Policy Basic tool to set fine-grained password policies, instead of using the built-in PowerShell commands.

What's New

Now, in Windows Server 2012, the Active Directory team has finally created a Graphical User Interface (GUI) for Fine-grained Password Policies. Just as the Active Directory PowerShell History Viewer and the Active Directory Recycle Bin, it's part of the Active Directory Administrative Center.

Note:
There are no changes under the hood for Fine-grained Password Policies. These policies are still only applicable to user objects and groups, not OUs.

Creating a Fine-grained Password Policy in the GUI

If you want to, you can create a Fine-grained Password Policy without a link within the Active Directory Administrative Center. For this purpose, open the Active Directory Administrative Console, using an account with sufficient permissions to create Fine-grained Password Policies.

In the left navigation pane, head to the System container under the domain root and from there drill deeper until you reach the Password Settings Container. This is where Fine-grained Password Policies live in Active Directory:

Now, you can use the New and then Password Settings commands from the task pane on the right, or simply right-click within the middle pane and make the same selections from the context menu to create a Fine-grained Password Policy.

In the Create Password Settings screen, you can give the Fine-grained Password Policy a meaningful name and a Precedence. (both fields are mandatory.)

Tip!
Precedence allows you to give Fine-grained Password Policies priority over other Fine-grained Password Policies. Fine-grained Password Policies applied to users directly always take precedence over Fine-grained Password Policies  applied to groups the user is a member of. If you work with multiple Fine-grained Password Policies, make sure the most important ones have value 1.

In the Directly Applies To section you can specify groups and/or users that will be subject to this Fine-grained Password Policy.

Assigning a Password Policy to a user in the GUI

To assign a Fine-grained Password Policy directly to a user, open the properties of a user account in the Active Directory Administrative Center. In the left pane, select Password Settings. Use the Assign… button to select a Fine-grained Password Policy:

Use the Check Names functionality to make picking easier and click OK when done.

Assigning a Password Policy to a group in the GUI

Assigning a Fine-grained Password Policy to a group is as straight-forward as assigning a Fine-grained Password Policy to a user. Open the properties of a group, scroll down to the Password Settings, or click it in the left pane and add/remove Password policies, as you seem fit:

View resultant password settings for a user

If, at any time, you're unclear which Fine-grained Password Policy applies to a user, use the built-in capabilities of the Active Directory Administrative Center to view the resultant password settings. For this feature, simply right-click a user, and select View resultant password settings… from the context menu:

This command will open the applied Fine-grained Password Policy for the user object.