Protect Privileged Credentials in Windows Server 2012 R2 using the Protected Users Group

Many organizations have a proliferation of users holding domain admin credentials or other levels of privileges that go beyond the recommend standard user privileges. While I would always recommend that domain admin accounts should be kept to a minimum and never used for day-to-day computing, support or administrative tasks, it’s also wise to take extra steps to protect privileged accounts when they are released for use. In this Ask the Admin, I’ll describe how to add additional protection to privileged admin accounts in Windows Server 2012 R2.

• Related: Windows Server vNext Privileged Access Management

Windows Server 2012 R2 introduced several new technologies designed to help protect privileged credentials, which includes the Active Directory Protected Users group. New or existing users can be added to this global security group and prevents Windows 8.1 and Windows Server 2012 R2 devices from caching users’ credentials, providing additional protection against password theft. Users logged in to devices that support Protected Users are prevented from using:

• Cached credentials. For example, users cannot log in offline when there is no access to a domain controller.
• The Kerberos ticket-granting ticket (TGT) must be received when users log in and cannot be reissued automatically, preventing the use of long term keys.
• Default credential delegation (CredSSP), which stops credentials from being cached in plain text even if the Allow delegating default credentials policy is set.
• Windows Digest authentication.
• NT LanManager (NTLM) NTOWF, which is a function for generating keys based on user passwords.

Furthermore, if the domain functional level is Windows Server 2012 R2 or higher, Protected Users cannot:

• Renew Kerberos ticket-granting tickets longer than the original four-hour TTL.
• Log in using NTLM.
• Use DES or RC4 for Kerberos pre-authentication.
• Be delegated using constrained or unconstrained delegation.

Additionally, the protections afforded by the Protected Users group are only enabled on domain controllers if the domain functional level is Windows Server 2012 R2 or higher.

Kerberos with Advanced Encryption Standards (AES)

As DES or RC4 ciphers are not supported for Kerberos pre-authentication, AES keys must reside in Active Directory for any users that are members of the Protected Users group. To ensure accounts meet this requirement, all domain controllers should be running Windows Server 2008 or later. Before adding accounts to the Protected Users group, change their passwords to ensure the operation was carried out on a Windows Server 2008 domain controller (or later).

The Protected Users Group

If the Protected Users group doesn’t exist in your domain, then you will need to transfer the PDC emulator Flexible Single Master Operation (FSMO) role to a server running Windows Server 2012 R2. Once the Protected Users group has been created and replicated to all domain controllers in the domain, the PDC emulator FSMO role can be moved back to its original location. For more information on transferring FSMO roles, see Manage Flexible Single Master Operation (FSMO) Roles Using PowerShell on Petri IT Knowledgebase.

Computer and service accounts should not be added to the Protected Users group. Some of the protections provided by Protected Users can be enabled for these accounts by modifying NTLM policies, authentication policies and blocking delegation for accounts in Active Directory.

Users can be added to the Protected Users group using Active Directory Administrative Center (ADAC), Active Directory Users and Computers (ADUC), and PowerShell. There are no workarounds for the protections enabled, so this could potentially lock users out of systems or significantly reduce functionality in some circumstances. As such, before adding users to the Protected Users group, make sure that you carry out testing in a pre-production environment.