Active Directory (AD) does not have a good reputation among many IT security specialists, and more than one admin thinks it should be removed as soon as possible. Of course, survivorship bias plays a role in such thoughts – infrastructures that require high-caliber specialists to rescue the day are ultimately those where the greatest discrepancy between lure for attackers and the degree of hardening exists. In this article, I use the term "hardening" to refer both to IT infrastructures themselves and to the people and processes involved in managing them.

Active Directory can be run in a pretty much secure way if the organization involved is at least prepared to drop old habits and invest in a secure, state-of-the-art design instead of just in third-party tools. This way might not sound as sexy in the annual report as the latest extended detection and response (XDR), managed detection and response (MDR), or identity threat detection and response (ITDR) strategies, but it is likely to offer greater benefits.

When AD Is Not AD

To get the ball rolling, the term "insecure AD" typically means Active Directory Domain Services (ADDS) – that is, a directory service tied to Kerberos authentication and group policies. In some cases, the Active Directory Certificate Services (ADCS), Microsoft's implementation of a public key infrastructure (PKI), deals the final death blow to the security of the environment.

However, three other ADs belong to the Windows server family. First is the Active Directory Rights Management Service (ADRMS), a cryptography tool for protecting digital content such as documents, email, etc. The service is very rarely used in local environments but provides the technology basis for Azure Information Protection, which evolved into Microsoft Information Protection and finally Microsoft Purview Information Protection [1]. As a rule, ADRMS has no influence at all on the security of the infrastructure, apart from ingenious scenarios in which a stolen message is used for spear phishing to obtain privileged credentials.

Second, you need to look at the Active Directory Lightweight Directory Services (ADLDS) – formerly known as Active Directory Application Mode (ADAM) – which is an LDAP-compliant directory service that builds on ADDS multimaster replication mechanisms but does not support computer memberships, Kerberos, and group policies. Instead, the schema is freely configurable and can be used in scenarios for which ADDS is completely unsuitable. Additionally, the service can listen on any port and multiple instances of LDS can run side by side on the same Windows server. This server role can certainly enhance the security of an ADDS organization – for example, by enabling the creation of a metadirectory by IT managers for the DMZ and other potentially insecure scenarios and to avoid direct AD queries from insecure zones.

Third is the Active Directory Federation Services (ADFS), a Security Assertion Markup Language (SAML) and OpenID Connect-compliant identity provider (IdP) for federated authentication. In conjunction with applications that support SAML authentication (these are primarily applications with a web front end), a well-configured ADFS farm can significantly improve the security of the underlying AD. On the other hand, a poorly configured ADFS farm opens up completely new attack vectors and makes securing the entire environment all the more difficult. The situation becomes particularly precarious when ADFS is not only used on the enterprise LAN, but for external applications, as well (e.g., in conjunction with Entra ID).

Known Security Issues

Active Directory's bad reputation is not attributable to specific circumstances or players. Instead, it is a team effort: Microsoft set things off with design decisions that permanently dictated a specific development path. Above all, though, you need to look at default settings, which were already outdated at the time of their inception but had to kowtow to the manufacturer's philosophy at the time, according to which backward compatibility and user convenience took priority over all performance features and, more frighteningly, over security.

On the basis of Microsoft technology, architects, consultants, and book authors then wrote certain "design patterns" in stone, defining best practices for decades, although the world just kept on turning and Windows, AD, and the infrastructure underneath evolved with security aspects becoming increasingly important. Also, people who operate AD infrastructures contribute to insecure and unreliable everyday operations with their shortcuts, convenience practices, outdated tools, and bad scripting habits.

Although it is impossible to change the characteristics of the technology itself, it is important to be aware of them because they constitute the immovable framework of AD design and operation. The most important aspects that guide design decisions from a security perspective include:

• Write and management permissions in AD assigned to principals from AD itself. This is the technological basis for all privilege escalation attacks, including hijacking the entire AD forest.
• The difficult role of a domain controller (DC). It has its own machine identity but no security database of its own. It can replicate, but so can others.
• Replication mechanisms. Although each DC has its own copy of the AD domain, it can only work correctly if it knows that its copy is up to date and matches those of the other DCs in the domain. This complex situation opens hundreds of attack vectors, from denial of service to hijacking of the entire forest, or even neighboring forests.
• The ability to self-register in the AD-integrated DNS. This process is not tied to consistency checks and opens vectors for all kinds of name spoofing, which in turn is essential for man-in-the-middle attacks.
• Identical cryptography for NT LAN Manager (NTLM) and Kerberos RC4. The reason lies with the migration of NT domains to AD, the negative effects of which (e.g., the overpass-the-hash attack) are serious.

On the architecture side, you will come across some classics time and time again in daily practice. Many of these design anti-patterns result from people misunderstanding the role of domains, forests, and trust relationships, including misusing domains in a forest to give regional admin teams or individual parts of the company administrative sovereignty over their part of the AD. In reality, though, every domain admin is just one step away from becoming an enterprise or domain admin in another domain of the same forest. Administrative tasks can only be segmented by assigning permissions, and the overhead for implementing this in a separate domain is identical to that for a separate organizational unit (OU). The only part where things become a little more complex is group policies, but there are solutions for that as well.

Classic mistake number two is the misuse of domains to enable individual company units to log in to "their company." A sensible naming convention for email addresses, aligning the user principal name (UPN) with these, and "Facebook login" (for example) solves this apparent problem in a far better and more sustainable way, without having to maintain a dispersed domain structure. Zero-login methods that eliminate passwords, such as smartcards, security tokens, or Windows Hello for Business, are more convenient and secure, of course. Admittedly, a problematic constellation arises in an AD forest with several or sometimes even many domains, but I will go into that in more detail in a moment.

The number of worst practices firmly anchored in daily admin work and ongoing maintenance of numerous AD environments goes far beyond the scope of this article: systems that have remained unpatched for years, insecure public key infrastructure (PKI) configurations, enterprise admin accounts for desktop management and services such as SQL or SharePoint – the list goes on and on (Figure 1). Attempts to steer day-to-day administration in a more secure direction often fail because of attitudes that say, "we can't do that," "we've always done it this way," "the boss wants it that way," and "we're too small and insignificant to be hacked." The second of the 10 Immutable Laws of Security Administration [2] from the year 2000 is apropros: Security only works if the secure way also happens to be the easy way.

Figure 1: Security scans, like the Purple Knight scan shown here, demonstrate that the same classic mistakes keep occurring that make AD an easy target for attackers.

Three Attack Vectors

How can it be that cybercriminals often find it easy to take control of an organization's central identity service? Aside from security vulnerabilities in Windows and other software, in most cases, attackers don't even have to deploy the big guns. They use AD features to achieve their goals. To protect yourself against these attack techniques, you need to be clear about the benefits AD should add to your organization. Luckily, AD only has three basic functions:

• Lookup: Make information from the directory available over a defined protocol, including DNS information.
• Authentication: optionally with Kerberos or NTLM.
• Configuration of connected devices: with group policies or specific behavior on the basis of directory information, such as home drives or Windows Local Administrator Password Solution (LAPS).

According to MITRE ATT&CK [3], attackers derive their techniques from these three AD functions and deploy them in the following important tactical fields: reconnaissance and discovery (lookup); execution (configuration); persistence, privilege escalation and lateral movement (configuration, authentication); defense evasion (configuration, authentication); and credential access (authentication). Rarely is AD used as the intial access vector or for data theft (exfiltration), and the attacker's ultimate target (impact) is more or less never that of taking over control of AD. That said, an unhardened and poorly managed AD can provide valuable service to the attacker en route to their target.

AD's functional scope does not include identity management (the only reasonably reliable item of lifecycle information about an AD object is its creation date), access management (AD provides the technological basis for authorization with groups and optionally claims, but no genuine management functions), and configuration management (not only are management functions missing here, but also the possibility to compare the current with the desired state of the environment). These points are very often misunderstood, and other products that rely on Active Directory as their data storage and delivery mechanism can offer this functionality. Again, Active Directory itself is not the management system and was never intended to be one.