Advances in Active Directory since Windows Server 2003

Reading Time: 6 minutes

In six months time, on July 14 2015, Microsoft ends the extended support for Windows Server 2003. After 11 years and 6 months (Windows Server 2003 became generally available on May 28th, 2003) the plug is pulled on updates to the product and the support information on TechNet, MSDN and its KnowledgeBase.

Running Active Directory on Operating systems that lack support is a pretty bad idea and considered a bad practice among many of the people and writers in the IT industry.

Active Directory is the cornerstone of every Microsoft-oriented networking environment. This, alone, should be the reason to migrate to a next version of Windows Server for your Active Directory Domain Controllers. However, in my opinion, merely upgrading for support may not offer the largest benefits to your organization. Taking advantage of the advances made in Active Directory since Windows Server 2003, does.

So, please, take advantage of these new and improved features that were added to Active Directory since Windows Server 2003 (in chronological order):

 

Fine-grained Password Policies

Initial version: Windows Server 2008
Recommended version: Windows Server 2012

Certain accounts in Active Directory should use stronger passwords. You can’t expect the concierge to change his/her 12-character complex password every 42 days, and be somewhat productive, though. Where password policies in Windows 2000 Server and Windows Server 2003-based Active Directory environments were domain-scoped only, in Windows Server 2008 (and up) you can apply password (and account lockout) settings (objects) to specific Active Directory user objects and global security groups.

Note:
Fine-grained password policies cannot be applied to Organizational Units (OUs).

With fine-grained password policies, you can have multiple password policies in a single Active Directory domain.

This functionality is unlocked through the Windows Server 2008 Active Directory schema. However, AdsiEdit or 3rd party tooling is needed to manage fine-grained password policies on platforms earlier than Windows Server 2008 R2. This latter platform introduced PowerShell Cmdlets to manage these policies.

You will want to use the Active Directory Administrative Center (dsac.exe) on Windows Server 2012 (or up) or from the Windows 8 (or up) Remote Server Administration Tools (RSAT), since this tool provides a Graphical User Interface (GUI) to manage fine-grained password policies.

 

Read-only Domain Controller

Initial version: Windows Server 2008

Windows Server 2008 (and up) installations can be promoted to Read-only Domain Controllers in addition to the (default) Read/Write Domain Controllers.

Read-only Domain Controllers (RoDC) can be considered compromised by default. Accordingly, the RoDC features many security measures, including read-only access to Active Directory and DNS, separation of administrative priviliges (so branch office admins can perform some tasks, but not in the local Active Directory database or DNS) and Password Replication Policies (PRPs).

RoDCs cater to the kitchen cupboard server scenario, that many admins are faced with in branch offices, Some perimeter networks, or DMZs, are also perfect places for RoDCs.

The requirements for RoDCs are pretty straightforward: You’ll need at least one Windows Server 2008-based Read/Write Domain Controller (or up) for the RoDC(s) to communicate with.

 

Active Directory Recycle Bin

Initial version: Windows Server 2008 R2
Recommended version: Windows Server 2012

Accidentally deleting objects from Active Directory is unfortunate. Prior to Windows Server 2008 R2, when you wanted to undelete an object, you would reanimate it. The resulting object would have the same security identifier (SID) but would be stripped from group memberships and the likes. Authoritative restores were the true answer but were difficult, time consuming and required Domain Controller reboots.

The Windows Server 2008 R2 Forest Functional Level (FFL) introduced the Active Directory Recycle Bin. In order to use this functionality, all Domain Controllers need to run Windows Server 2008 R2 (or up) and the functional levels need to be Windows Server 2008 R2 (or up).

However, just with the Fine-grained Password Policies, management of the Active Directory Recycle Bin was quite the ordeal before Windows Server 2012. The Active Directory Administrative Center (dsac.exe) on Windows Server 2012 (or up) or from the Windows 8 (or up) Remote Server Administration Tools (RSAT) introduces a graphical way to enable the Active Directory Recycle Bin and manage the functionality.

 

Managed Service Accounts

Initial version: Windows Server 2008 R2
Recommended version: Windows Server 2012

Did you know that when you provide (domain) credentials for a service, those credentials are stored in the Windows Registry in a way that is not very secure?
Furthermore, these accounts, typically, are not limited to one machine and have privileges. Changing their passwords breaks the service everywhere.

To address this situation, Windows 7 and Windows Server 2008 R2 can use Managed Service Accounts (MSAs). These virtual domain accounts don’t get their credentials stored and are limited to services on one domain-joined machine. When you want automatic password and SPN management for these MSAs, you’ll want the Windows Server 2008 R2 Domain Functional Level.

When you want to use MSAs on multiple hosts for the same service, you’ll need the group Managed Service Accounts (gMSAs) introduced with Windows 8 and Windows Server 2012.

 

Active Directory PowerShell Manageability

Initial version: Windows Server 2008 R2
Recommended version: Windows Server 2012 R2

Windows Server 2008 R2 saw the advent of the PowerShell Active Directory Module. This started the revolution of managing Active Directory on the PowerShell. Since then, an additional ADDSDeployment Module was added to deploy Active Directory and many new PowerShell Cmdlets have been added to the modules. Active Directory’s new go-to management tool, the Active Directory Administrative Center (dsac.exe) is even completely built upon PowerShell.

The latest ActiveDirectory module features the most PowerShell Cmdlets, so you’ll want to use it. The ActiveDirectory and ADDSDeployment PowerShell modules on Windows Server 2012 (or up) or from the Windows 8 (or up) Remote Server Administration Tools (RSAT) include the latest features. You can use them in many ways.

 

Virtualization safeguards & DC Cloning

Initial version: Windows Server 2012

Virtualization has proven to be an easy way to wreck Active Directory. In the pre-Windows Server 2012 era, Microsoft recommended to treat virtualized Domain Controllers as physical hosts, restraining from using snapshots, cloning, etc.

Virtualized Windows Server 2012-based Domain Controllers (and up) leverage the Virtual Machine Generation Identifier (VM-GenerationID) provided by all major virtualization platforms to detect when it is reverted to a snapshot. This prevents USN Rollbacks and Lingering Objects. Additionally, the same VM-GenerationID functionality can be used to safely clone virtualized Domain Controllers for fast deployment and recovery.

Any virtualized Domain Controller running Windows Server 2012 (and up) has the virtualization safeguards, when it has the integration tools installed for the virtualization platform and the latter supports VM-GenerationID. For Domain Controller Cloning, additionally, the Domain Controller running the PDCe FSMO role needs to run Windows Server 2012 (or up) and needs to be available when cloning.

 

Dynamic Access Control

Initial version: Windows Server 2012

In environments with high amounts of group memberships you might experience token bloat issues. In complex file server authorization scenario’s, additionally, you might lose track of who has access where. Dynamic Access Control in Windows Server 2012 introduces claims in Kerberos, so you can authorize access to files and folders, based on any attribute for objects in Active Directory.

You’ll need at least one Domain Controller needs to run Windows Server 2012 or up. File Servers, where you want to use claims-based access control need to be running Windows Server 2012, or up. 3rd party storage vendors may also support the feature.

When you want to use Compound Identity, to authorize access based on attributes of the domain-joined device used, Kerberos Armoring (FAST) is required.

 

Protected Users

Initial version: Windows Server 2012 R2

From a security point of view, accounts and devices can be more sensitive than others. More strict password policies to user accounts and groups with the Fine-Grained Password Policies functionality and Group Policies to disallow interactive logons and network logons to user accounts and groups in Active Directory on Organizational Units (OUs) on certain domain-joined devices were considered solutions to these challenges.

However, there was no way to restrict sensitive accounts in terms of the lifetime of the Ticket Granting Tickets (TGTs), restricting more vulnerable authentication protocols (like NTLM), encryption standard to use in the pre-authentication process, the ability to be (constrainedly) delegated, or criteria for the devices sensitive accounts log on to.

The Protected Users global security group in the Users container in environments with the Windows Server 2012 R2 schema triggers these types of protection on devices and servers running Windows Server 2012 R2 and Windows 8.1, and on Active Directory Domain Controllers in domains running the Windows Server 2012 R2 Domain Functional Level (DFL).

 

Authentication Policies and -Silos

Initial version: Windows Server 2012 R2

When the Protected Users group isn’t granular enough to cater to the needs of your environment, Authentication Policies and Authentication Policy Silos can be used.

Authentication policy silos tie user objects and computer objects together using a claim with the name of the silo to apply the authentication policy. When the requirements set in the authentication policy are met, the policy applies to Kerberos Ticket Granting Ticket (TGT) lifetime and renewal. When they are not met, no (TGT) is issued and, thus, logon is denied, effectively creating silos for objects.

 

Concluding

Active Directory in Windows Server has seen numerous improvements. Depending on your environment you can take advantage of these. Business Cases for upgrading Domain Controllers might see financial benefits from these features.

The list above is not a full list of new features in Active Directory since Windows Server 2003.

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.