Service Accounts in Active Directory: These OG NHIs Could Be Your Weakest Link

While non-human identities (NHIs) in cloud and SaaS operations may be getting lots of attention right now, securing your Active Directory service accounts can go a long way in reducing risk. Here are three steps you can take right now.

NHI is the newest buzzword in identity so let’s start by defining what an NHI actually is. In the article “OWASP Non-Human Identities Top 10,” a non-human identity (NHI) is described as one that is “used to identify, authenticate, and authorize different software entities to access secured resources.” Some examples are service accounts (specifically Windows/Active Directory-based), API/Access keys, OAuth tokens, and cloud infrastructure workloads (virtual machines, managed databases, serverless functions, etc.).

The rise of Agentic AI and cloud native application development have changed the game for IT and security teams, leading to a massive sprawl in NHIs with disjointed, imperfect mechanisms to manage and secure them all.

Human identities are secured and managed with defined security practices — we can control authentication mechanisms and access to data via groups or roles and we have effective ways to monitor the activity generated by human identities.

NHIs are different. Because they’re used for software-to-software, machine-to-machine or software-to-machine interactions, they are often overscoped and overpermissioned, not guarded by mechanisms like multifactor authentication (MFA), shared between applications or systems and not monitored efficiently. Generally, IT teams tend to consider NHIs (specifically in Active Directory) as fairly stationary entities with permissions and activity that is static, as opposed to human identities which tend to be more dynamic in terms of their permissioning, entitlements and activities.

We summarize key concerns about NHIs in the video below:

While it’s exciting to chase the flashier cloud and SaaS NHIs, some of the fastest risk reduction steps you can take are in what we call “OG NHIs”: Active Directory service accounts. We all know that Active Directory is not (and never has been) an ideal world when it comes to cybersecurity. Even Microsoft itself has never been consistent in its recommendations for how to secure Active Directory (and thus those pesky service accounts) — anyone remember Red Forest setups?

Service account workload identities seem straightforward — this service will run as this logged on user account which has this scoped set of permissions that should never change (allegedly). The password will be set to be very complex and in an ideal IAM/PAM/IGA world the account will be fully managed with frequent password rotations and access reviews. 

In reality, service accounts run critical apps, often with broad privileges and no MFA. Years of “just make it work” changes leave behind service principal names (SPNs), delegations and exceptions that quietly accumulate into toxic combinations. Attackers look to exploit the intersections where stolen or misused credentials meet overlooked misconfigurations and overpermissioned resources. Start here... it’s where attackers get easy wins and where you can get the biggest, quickest reduction in exposure.

Here are three prominent issues or misconfigurations Tenable sees most often. Taking the time to remediate these will give you fast, measurable results.

1. Kerberoastable service accounts

• What it is: Kerberoasting is an abuse of the Kerberos protocol to harvest password hashes from Active Directory. If a user (service) account has an SPN set, any authenticated user can request service tickets for that account by specifying its SPN and the ticket granting service will return a ticket. That ticket is encrypted with the NTLM hash of the account’s password. This information can be taken offline to brute force crack the service account’s plaintext password.
• Why it matters: A Kerberoasting attack is performed offline and thus is virtually undetectable. In addition, service accounts often have elevated privileges and frequently do not have regular password resets, allowing adversaries to retain access for much longer periods than they could with a regular user account.
• How to remediate: Look for accounts in privileged groups (e.g. Domain Admins, Account Operators, etc) with SPNs set and switch them for an unprivileged account or, if possible, use a group managed service account (gMSA). Additionally, you should make sure the service ticket is encrypted using a strong algorithm such as AES instead of the default RC4.

2. Unconstrained Kerberos delegation

• What it is: You can set delegation on any computer or user account and that allows the account to impersonate another account to access resources. One example might be to access a back-end database server. By default user and computer accounts are set to “do not trust this computer for delegation” but sometimes accounts need to impersonate another account for application access. This can be done for any service on any computer in any domain within the forest or any domain or forest that is trusted — it’s called “unconstrained” delegation.
• Why it matters: When a user logs in to a server that has “Trusted for delegation” enabled, the domain controller sends a copy of that user's credentials to the server. This allows the server to authenticate on behalf of the user. However, if the server is compromised, an attacker can steal the credentials of all users who log in to the server and use them to authenticate on other resources. If an administrator logs in to the compromised machine, the attacker can escalate their privileges and become an administrator too.
• How to remediate: Examine the user or computer account for this setting (see screenshot below). Ideally this setting should have “Do not trust this computer for delegation” selected. This may vary depending on your internal security controls and use case.

3. Managed Service Accounts with dangerous misconfigurations

• What it is: Managed Service Accounts (MSAs) provide a secure way to manage Active Directory service accounts. An MSA has its own complex password which is maintained automatically, as computer accounts do. This feature should be deployed and correctly configured so that no illegitimate user account can compromise them (e.g. through "Kerberoasting" attacks)
• Why it matters: The MSA feature addresses the traditional service account security issue by providing service accounts that are automatically managed and have a strong password. However, depending on the privileges of this account, it can lead to an Active Directory compromise.
• How to remediate: Understanding risky permissions on an MSA (whether standalone or group-managed) can be difficult. Any delegation to the service account should be thoroughly examined and verified for accuracy and necessity.

Make service accounts and other NHIs part of your cyber hygiene routine

Cleaning up dormant accounts and PAM/IGA usage should continue to be significant parts of your Active Directory hygiene efforts. But don’t overlook the many NHI-related misconfigurations lurking in your AD environment like ticking time bombs, waiting for an attacker to discover them. Enlisting a solution like Tenable can not only help point out these misconfigurations but can also show you in detail what the attack paths are for all of your identities. This level of visibility and context is key in securing your organization against persistent threats. Don't let your Active Directory become an easy target for attackers like Scattered Spider. Proactively address these often-forgotten NHI risks to reduce your risk of exposure.

How Tenable can help

View the demo below to learn more about how Tenable can help against Kerberoasting. 

Learn more

• Visit our solutions page for more on how to discover and close Active Directory exposures before attackers can exploit them
• Request a demo of Tenable Identity Exposure