Securing authentication tokens by preventing delegation of admin accounts

The underlying capabilities provided by Kerberos authentication in Active Directory means that access tokens can be delegated to users and computers for various purposes. Attackers can capitalize on the built-in capabilities of Active Directory with impersonation and delegation to compromise sensitive resources. This article details the recommended settings in Active Directory that mitigate the risk associated with account delegation on insecure computers and administrator accounts.

Access tokens and impersonation levels

In a client-server environment, a special token called the impersonation token allows a thread to execute in the security context of a user or computer.

Certain network services running in the environment determine the assigned permissions and access levels based on impersonation. For example, when certain server services run, they briefly use the impersonation token to determine the assigned privileges and the resources a user can access.

When this impersonation is invoked, it means the client has allowed the server to act as a client on its behalf. There are different levels of impersonation that Microsoft refers to as impersonation levels. Each level dictates the authority given to the server to act on behalf of the client.

There are four impersonation levels:

• Anonymous – The client is anonymous to the server. While the server can impersonate the client, the impersonation token doesn’t include any information about the client.
• Identify – The system default level is configured for Identify. With this level, the server can impersonate the client’s identity to perform access control list (ACL) checks.
• Impersonate – The server can impersonate the client and its security context with the impersonate level. The server can access local resources as the client’s identity. With remote resources, it can only access resources that are on the same computer as the server.
• Delegate – The delegate is the most powerful and dangerous of the impersonation levels. If selected, the server can impersonate the client’s credentials, both local and remote. These can be passed to all computers.

You can learn more about impersonation levels from Microsoft here: Impersonation Levels (COM) – Win32 apps | Microsoft Learn.

Using the delegate impersonation level has additional requirements for use. These include:

• The client must set the impersonation level to RPC_C_IMP_LEVEL_DELEGATE
• The server account must be marked with the “Trusted for delegation” attribute in the Active Directory Service
• All the servers and clients in question must be running in the domain

Security implications of delegable admins

Using freely available tools, attackers only need to compromise a client and access a standard account. Once they have their foot in the door, they can use tools like Meterpreter to list the available delegate tokens. Privileged accounts with delegation tokens available can lead to the attacker being able to steal a privileged user token, such as a domain admin account. Once the attacker has a domain admin-level account, the possibilities are endless.

Once they have high-level privileged accounts, they often go after backup files that may contain prized targets, such as backups of the NTDS.DIT database of Active Directory. If found, they can copy the database offsite and run an offline tool to compromise accounts in the organization further.

The “Account is sensitive and cannot be delegated” setting

Microsoft has provided a setting in Active Directory Domain Services that can help mitigate the issue. In addition, an Active Directory setting is recommended to be enabled for privileged accounts in the domain. The setting is “account is sensitive and cannot be delegated” within the account properties.

When configured, this setting strips the delegate-level token from the user, removing the user credentials. When configured, the logon becomes an ANONYMOUS login with no resource permissions.

When computers trusted for delegation are compromised, attackers can use these to access data stored on other servers using delegated credentials. Therefore, Microsoft recommends using the “account is sensitive and cannot be delegated” setting on any insecure computer that has little or no physical security or administrator accounts, such as Domain Admins.

Domain Admin accounts have tremendous domain privileges and basically unlimited access to server resources and data in the organization. In addition, if any computers are trusted for delegation, you can use constrained delegation and other techniques to help mitigate risk when delegation is used.

Specops Delegable Admins report

For security purposes and to bolster your organization’s cybersecurity posture, it is crucial to have visibility of admin accounts that do not have the setting configured, “Account is sensitive and cannot be delegated.” While you can create PowerShell scripts to query the various attributes of users and computers in the domain, there is a much easier way. Specops Password Auditor (free) provides a built-in report called “Delegable Admins.”

With the Delegable Admins report, Specops Password Auditor provides quick visibility to all admin-level accounts. Organizations interested in securing authentication tokens will find this report useful for helping to audit for accounts that should be marked as “sensitive and cannot be delegated” in their environment.

In addition to the Delegable Admins report, it provides many other features and reports that are useful to bolster Active Directory account security, including findings accounts with compromised passwords.

Delegation and impersonation FAQs