New features in Active Directory Domain Services in Windows Server 2012 R2, Part 2: Protected Users

In Active Directory, all Domain Controllers are equal, but some are more equal than others. As you gain experience in managing networking environments, you’ll find the same principle is true for user accounts: all user accounts are equal, but some are more equal than others…

For instance, some colleagues to whom these accounts belong, require you to resolve an issue faster, simply because they are more important in your environment (or feel they are). They have mailboxes in a different (highly available) Exchange database that is faster to recover items from, etc.

It’s not all about importance, too. From a security point of view, accounts can also be more sensitive than others. How do we deal with these? Since Windows Server 2008, we assign more strict password policies to user accounts and groups within Active Directory with the Fine-Grained Password Policies functionality. And, you can always use Group Policies to disallow interactive logons and network logons to user accounts and groups in Active Directory on Organizational Units (OUs) with certain domain-joined devices.

Even with all these opportunities, however, there’s no way you could 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 they log on to.

 

Introducing Protected Users

To achieve these goals, Microsoft has introduced a new feature in Active Directory Domain Services (AD DS) in Windows Server 2012 R2: the Protected Users group.

The Protected Users Global Security Group (click for original screenshot)

The Protected Users global security group in the Users container triggers non-configurable 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).

These protections come in two stages:

  1. Client-side protection
    The first stage of protection is triggered when a user account with membership of the Protected Users group is used to authenticate to a Windows 8.1-based device (or up) or a Windows Server 2012 R2-based host (or up).
  2. Domain Controller protection
    In addition to the client-side protection, Domain Controller protection applies, when a user account with membership of the Protected Users group is used to authenticate to a Windows 8.1-based device (or up) or a Windows Server 2012 R2-based host (or up) and the user account resides in an Active Directory domain with the Windows Server 2012 R2 Domain Functional Level (DFL).

Note:
When authentication to devices with Operating Systems prior to Windows 8.1 or servers with Operating Systems prior to Windows Server 2012 R2, no protections apply.

The table below gives you an overview of the protections available:

Note:
The default Kerberos TGTs lifetime setting of four hours is optionally configurable by using Authentication Policies and Silos, which can be accessed through the Active Directory Administrative Center (dsac.exe). This is something I’ll be discussing in the next part of this series.

 

Configuring Protected Users

Enabling the protection offered by membership of the Protected Users group, is as easy as making sensitive user accounts members of this group.

 

Requirements

To benefit from the additional protections, that membership of the Protected Users group offers, you need to comply with these requirements:

  • To gain the Protected Users Security Group, the Active Directory schema needs to be extended to Windows Server 2012 R2 (version 69).
  • To replicate the Protected Users group, the Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role needs to run Windows Server 2012 R2.
  • Users need to authenticate on Windows 8.1-based devices (or up) or Windows Server 2012 R2-based servers (or up) to a Domain Controller that runs at least Windows Server 2012 R2.
  • For Domain Controller protection, the Active Directory domain needs to operate on the Windows Server 2012 R2 Domain Functional Level (DFL).

Note:
The Protected Users group can be applied to Active Directory domains that are set to a Domain Functional Level (DFL) for an operating system earlier than Windows Server 2012 R2. This allows the added security that is achieved by using the Protected Users group to be applied throughout the domain. To do this, promote the Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role to Windows Server 2012 R2, and then allow the upgraded PDC to replicate the Protected Users group to other Domain Controllers. When the replication completes, the PDC can be set back to any available Domain Functional Level (if desired), and the Domain Controller-based protections are automatically applied.

 

Concluding

The Protected Users global security group in the Users container triggers non-configurable 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).

Use membership of this group to limit the availability of outdated authentication protocols, weak encryption algorithms and delegation to sensitive user accounts.

Further reading

Protected Users Security Group
How to Configure Protected Accounts
What’s New In AD and Identity Management in Windows Server 2012 R2, Part 2
Don’t be the next Target – Protect your Active Directory
Active Directory Features in Different Versions of Windows Server
Active Directory Forest and Domain Levels
Windows 8.1 Security Improvements

Series Navigation

<< New features in Active Directory Domain Services in Windows Server 2012 R2, Part 1: IntroductionNew features in Active Directory Domain Services in Windows Server 2012 R2, Part 3: Authentication Policies and Authentication Policy Silos >>

leave your comment

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