Highly Confidential

In environments characterized by great complexity or the crucial importance of the connected systems, authentication must be clearly regulated. The need for protection is particularly great for privileged accounts such as domain or organization administrators. Active Directory (AD) offers, among other things, the Protected Users group and authentication policies for this purpose.

AD entered the market about 20 years ago with Windows 2000 Server. However, it was to be 13 years before Server 2012 R2 introduced one of the biggest security enhancements in the form of Kerberos authentication for highly privileged accounts. Part of the new functionality, the special treatment of the Protected Users group, was automatically introduced on upgrading the domain function level and caused irritation in some cases. Other features such as authentication policies are still unknown to many administrators.

Protecting Highly Privileged Accounts

For the normal user who logs on to their workstation or a shared computer without system admin rights to perform their tasks with the help of application programs, a standard login by Kerberos is quite good enough. The ticket-granting ticket (TGT) issued at login time is valid for 10 hours by default and is silently renewed when it expires. In principle, you can log in to any client system in the forest, provided the default configuration has not been changed. If older devices are in use, NT LAN Manager (NTLM) authentication is also possible, if necessary, and in most cases, perfectly acceptable.

However, the situation is different for a highly privileged account (Figure 1). "Highly privileged" does not necessarily mean a domain or schema admin. IT managers also need to protect an account adequately that has wide-ranging administrative and data access privileges on a system other than AD itself. An SQL admin has the potential to steal or modify important business transaction data. A file server admin could possibly access confidential drafts from product development, and so on.

Figure 1: The service life of the TGT is limited to four hours for Protected Users.

Service accounts can also be a valid attack vector. These accounts often have deeper access to resources – both on the computer running the service and on the network – than regular users. What often complicates matters is that the passwords for these accounts do not expire. If the password-protecting data protection application programming interface (DPAPI) in Service Control Manager can be stolen, the attacker can exploit the rights of the account for a long time.

The problem of having to update the service account on many servers at the same time when the password changes can be partially countered by administrators who use group Managed Service Accounts (gMSA): Their password is regularly changed by authorized computers and automatically updated in the Service Control Manager [1]. However, the logon capability of such an account is not limited to certain computers per se, and if the automatically set password is known, it can be used anywhere.

Therefore, it is hugely important for the security of your IT environment to address the following issues for highly privileged accounts:

• On which systems can the account log in? A domain admin, Exchange admin, or SQL admin has no business using the PC in the warehouse, where malware or hackers can sniff their credentials.
• How long can an account use the TGT issued at login time? Is re-authentication necessary when it expires? To mitigate the risk, if a highly privileged Kerberos ticket is stolen, the ability to use it for authentication should be time-bombed.
• For service accounts, who is allowed to request a service ticket against services running under this account? Where is this account allowed to log in? For example, if the service account belongs to the database layer of a three-tier application, the only computers the account needs to log on to are the database servers, and the only computers and users that need to communicate with the database service are the application layer servers and their respective service accounts, as well as database administrators and their workstations. If necessary, it is still important that backup and monitoring systems can connect. Normal workstation PCs, on the other hand, have no reason to communicate directly with the back end of an application.
• For computer accounts, some services run in the security context of the executing machine. Here, too, it is important to be able to limit who is allowed to authenticate against these services and whether NTLM is allowed or Kerberos is enforced in the process.

In the early years of AD, security teams built very complex and nearly unmanageable constructs of permissions, policies, and firewall rulesets to enable this kind of granular segmentation. Server 2012 R2 made this work far easier.

Better Protection Through Protected Users

For highly privileged accounts, an easy way to tighten authentication was introduced with Server 2012 R2. When the Primary Domain Controller (PDC) Emulator flexible single master operation (FSMO) role is transferred to a domain controller running Server 2012 R2 (or newer), Windows creates a new global group – Protected Users – with a unique object ID within the domain (RID) 525. This group is not assigned permissions in AD or on individual systems. That said, the membership of a user account in this group causes some important changes to the behavior of logins for that account:

• None of the login methods (NTLM, Digest, CredSSP, Kerberos) store credentials in the clear or use the highly insecure NT one-way function, independent of the policy regarding delegation of default credentials.
• The login confirmation is not cached, so offline login with a protected account is not possible.
• Kerberos does not generate RC4 or DES keys.

The Protected Users group is available on all server operating systems from 2012 and on all client operating systems from Windows 8. Systems as of Windows 7/Server 2008 R2 were given a security update that also activated this feature in May 2014. However, the protection is only genuinely effective as of Server 2012 R2, which means the following restrictions apply to members of the group:

• NTLM authentication is not allowed.
• Delegation for the account is not allowed, whether limited or unlimited.
• DES or RC4 encryption types for Kerberos pre-authentication cannot be used.
• The TGT is valid for four hours and cannot be renewed. After four hours at the latest, the logged-in user must re-authenticate against a domain controller.

No exceptions exist for specific user groups such as domain or enterprise admins. Completely preventing an account from logging in is theoretically possible just by adding it to the Protected Users group. However, to do this, the domain must have been created before Server 2008, and the user password must have remained the same. As of Server 2008, an AES key is also generated each time the password is changed.

If an account was already created under Server 2000 or 2003 and the password was not changed since then, this account has no AES key and can no longer authenticate. This case is not that unlikely for "emergency admin accounts" that rarely log in. This type of account should not become a member of Protected Users, nor should computer or service accounts.

For all its hardening, the Protected Users group cannot prevent highly privileged accounts from logging on to machines where they have no business doing so. The granularity of the TGT lifetime or NTLM login authorization also leaves something to be desired: The only central policies are for the domain and the hard-wired configuration of the Protected Users group. The authentication policies provide for finer granularity, which is often necessary, and make the limits even more binding.

Enabling Authentication Policies

Authentication policies only become available after you upgrade AD to the 2012 R2 domain functional level or higher; then, you can design policies and assign them to different user and computer accounts. To take effect, you need to set two group policy settings. On domain controllers, it's the setting with the long name KDC support for claims, compound authentication and Kerberos armoring in the Administrative Templates | System | KDC computer configuration branch (Figure 2). The possible values are Supported , Not Supported , Always provide claims , and Fail unarmored authentication requests . Select Supported for the optimal combination of protection and compatibility with other systems that use AD authentication.

Figure 2: The value Supported is the most compatible setting for interoperating with other systems that use AD authentication.

To the clients – at least those running Server 2012 or Windows 8 or later – assign the Kerberos client support for claims, compound authentication and Kerberos armoring . It is located in the Administrative Templates | System | Kerberos computer branch. It can only be enabled or disabled; thus, compatibility is controlled solely on the domain controller side. To check whether the policy is enabled for a particular device, use whoami /claims. If you have Fine Grained Password Policies (FGPP) in use in your AD environment, you should fast become familiar with how authentication policies work.

On the one hand, this setup allows deviating values to be assigned to individual accounts or groups of accounts for parameters that are normally regulated globally per domain – in this case, the TGT lifetime and NTLM options. On the other hand, these settings are managed from the Active Directory Administration Center (ADAC), which also provides access to the AD recycle bin and dynamic access control.

The authentication policy comprises five sections. Depending on the purpose, entries are not always necessary in all sections:

• User login: TGT lifetime, NTLM login capability.
• Service ticket for user accounts: Which users or computers can request a service ticket for a service running under this user?
• Service registration: TGT life for gMSA.
• Service ticket for service accounts.
• Computer: TGT lifetime, limitations of the application.

For a policy to work for users or gMSA, you need to configure the TGT lifetime for that account type. If in doubt, use the value inherited from the domain or Protected Users membership.

If you enter a different value here, it applies. This way you can also set a longer TGT lifetime for the members of the Protected Users than the hard default of 240 minutes.