QOMPLX Operations: Managing Privilege for Tier 0 Accounts

This is the latest in a series of blog posts we’re calling “QOMPLX Operations.” These posts are intended to provide security practitioners with best practices and insights needed to build effective, robust security operations center (SOC) teams. To learn more, download our free reports!

By Robert Souron

In Microsoft's administrative tier model, Tier 0 are administrative accounts, groups, domain controllers, and domains that have direct or indirect access to manage the Active Directory domain. We are going to discuss the primary Tier 0 accounts and groups, why they are important, and how you can protect them.

Built-In Administrator Accounts

The first on the list should be the built-in domain Administrator account. Too often this account is overlooked and forgotten once the domain is up and running. This account by default is a member of the Domain Admins and Administrators groups in the Domain.

If the domain is the forest-root domain, it is also a member of Enterprise Admins and should only be used for initial build and disaster recovery; lock this account down. Microsoft has guidance on the proper way to secure the built-in Administrator account setting, the account properties, and application of Group Policy.

Enterprise Administrator Accounts

If you are in a single-domain forest, you can think of the Enterprise Admin much the same as the Domain Admin with a few exceptions. Domain Admins by default become members of the Administrators group on all workstations and member servers where Enterprise Admins do not.

You must be an Enterprise Admin to authorize a DHCP server, although this can be delegated to a non-admin account. A DHCP server automatically assigns IP addresses, gateways, and other network configuration parameters.  Also if you want to have Active Directory Certificate Services, you must be an Enterprise admin; this can be delegated to a non-admin account if you wish. Certificates can be used to bind the identity of person, device, or service to a corresponding private key. If you have a multi-domain forest, the Enterprise Admin has full control of domains in the forest. This group should be empty except for the built-in Administrator account. You can also secure this group with Group Policy settings.

Domain Admins

This is the group most often associated with Active Directory. Domain Admins have full administrative rights on domain-joined servers and workstations. Although it is difficult to keep this group empty, every effort should be made to limit the number of Domain Admins in each domain. Microsoft has guidance on how to secure your Domain Admins group.

Also, be careful not to change the default nesting of these administrative groups, because these accounts and groups are used for support and for disaster recovery.

Protected Users Group Brings Added Security

If your Domain/Forest runs Windows Server 2012 R2 or higher, you can use the Protected Users group. DES and RC4 are not supported for users in the Protected Users group.

It’s important to be at the 2012 R2 functional level or higher to take advantage of key security improvements. Among these are:

1. Authentication using NTLM is not allowed. (See our post on the link between NTLM and human-directed ransomware campaigns.)
2. Weak cipher suites such as DES or RC4 are not permitted in Kerberos pre-authentication.
3. Constrained or unconstrained delegation is not permitted.
4. TGT service tickets older than four hours cannot be renewed.
5. DES and RC4 encryption suites are not used for the Protected Users group.
6. AES keys must reside in Active Directory for any users that are members of the Protected Users group.

Importantly: do not put computers or service accounts into the Protected Users group. It offers no local protection to these types of accounts. Rather, Managed Service accounts and group Managed Service accounts use Kerberos Constrained Delegation; adding these accounts to the Protected Users group will break their functionality.

Finally, any accounts added to the Protected Users group should change their password to make sure they are using the latest encryption algorithm. For AES 128 and AES 256 to be available, the Domain Functional level must be Server 2008 or higher.

Other Options to Protect Privileged Accounts

If you are functional level 2012 R2 or higher you can also take advantage of Authentication Policies and Silos by enabling dynamic access control in your Default Domain Controllers policy. This gives you the ability to define the computers privileged users, service accounts and other computers will be allowed to authenticate with.

If your administrators are using Windows 10 (64-bit Enterprise) Secure Access Workstations, you can enable Credential Guard. This utilizes Virtual Secure Mode (VSM), a feature that leverages the on-chip virtualization extensions of the CPU to isolate processes against tampering. This allows a copy of the Local Security Authority (LSA) to run in the VSM while making it significantly harder for malicious code running on the host OS to read or manipulate the data.

Another option for protecting privileged accounts is multi-factor authentication (MFA). Built into Windows 10, there are options such as Windows Hello for password-less authentication, or the separate MFA process for Azure. Microsoft also has its Authenticator app that generates time-based codes during two-factor authentication processes; third-party products from Duo, OKTA, and Google are also supported and provide a second form of authentication via SMS, one-time passwords, and PINs delivered via phone calls.

In an Administrative Tier model, Tier 0 can manage assets at all Tiers but should not be able to log on interactively to any asset outside of Tier 0.

(In the next post of this series, we will discuss Tier 1 accounts and groups.)