Top misconfigurations in Active Directory and Entra ID

Looking for an easy way to strengthen your cybersecurity posture? Check your Active Directory and Entra ID environment for the common but serious misconfigurations detailed below. By implementing the risk management strategies provided, you can reduce your risk of costly security breaches, downtime and compliance penalties.

Misconfiguration: Non-privileged users that are owners of privileged Entra ID applications

The problem

Entra ID applications can be massive security liabilities — indeed, adversaries are now regularly using applications that they take over to do their dirty work. For example, Midnight Blizzard, a threat actor group suspected to be tied to the Russian Foreign Intelligence Service, began its highly publicized attack on Microsoft by using the credentials of a compromised OAuth test application.

A key misconfiguration that makes it much easier for adversaries to compromise an Entra ID application is to assign a non-administrative account as an owner of the application. Application owners have a great deal of power: They can manage all aspects of Microsoft Entra configuration for the application, including single sign-on (SSO) options, provisioning and user assignments, as well as add or remove other owners.

Since regular user accounts are typically not protected as rigorously as privileged accounts, they are more likely to be taken over by malicious actors. And if an adversary manages to compromise the account of an application owner, they gain broad control over the application. And if the application has elevated privileges in the tenant, the risk to the organization skyrockets.

Risk management strategies

Organizations need to tightly control which accounts have ownership of applications — especially all applications with privileged access to critical data and systems. In particular, ownership of Entra ID applications that have extensive delegations over the tenant should be limited to administrative accounts with multifactor authentication (MFA) and other stringent security controls in place.

Misconfiguration: Entra ID applications with unconstrained Mail.ReadWrite and Mail.Send permissions

The problem

Administrators can empower an Entra ID application to take actions using its own identity, without a signed-in user, by granting it Microsoft Graph application permissions (also called app roles). In particular, apps can be granted the following application permissions:

  • ReadWrite — Enables the app to create, read, update and delete email
  • Send — Enables the app to send email

These application permissions can be quite useful, especially for background services or daemon apps. For instance, a ticket processing system might need to be able to read and send email using its own identity.

However, by default, granting the Mail.ReadWrite or Mail.Send permission to an application enables the app to perform the associated actions on all Exchange Online mailboxes in the organization. Therefore, if an attacker gains control of the application, they will have access to every mailbox. Imagine the damage an adversary could do by reading the CEO’s messages or sending messages from the CFO’s mailbox.

Risk management strategies

In keeping with the principle of least privilege, each Entra ID app should be granted only the access it requires to serve its intended purpose. For example, an app intended to serve a particular region or department should not have access to mailboxes from other parts of the organization.

Microsoft offers a straightforward method to limit an app’s access permission to only specific mailboxes: Put those mailboxes in a mail-enabled security group, and configure an application access policy for the group using the PowerShell cmdlet New-ApplicationAccessPolicy.

Misconfiguration: Decommissioning a server but never removing its service accounts

The problem

All too often, admins will decommission a server without removing its service accounts. This oversight introduces serious security risks. Service accounts are a key target for takeover by adversaries, for multiple reasons. First, service accounts are often granted elevated privileges to the sensitive data and other resources that hackers are after. Second, they can quite vulnerable to compromise because their passwords are rarely changed. And third, the activity of service accounts can easily slip under the radar of IT security teams or even be explicitly excluded from monitoring, enabling hackers to go undetected.

Risk management strategies

IT teams need to remember that decommissioning a server isn’t as simple as simply unplugging it. They need to establish and follow a comprehensive process in line with best practices, which includes removing its service accounts.

Misconfiguration: Entra Connect not being treated as a Tier Zero asset

The problem

More and more organizations are recognizing that it’s imperative to accurately identify and protect all their most mission-critical IT assets, known as Tier Zero. Tier Zero includes any asset that can exert control over Active Directory. The most obvious examples are highly privileged groups, such as Domain Admins, Account Operators and Backup Operators, and their members.

However, Tier Zero includes other assets as well. In particular, Entra Connect is a powerful tool that Microsoft provides for managing hybrid IT environments. Many organizations use Entra Connect to automatically synchronize identity data between their on-premises Active Directory environment and Entra ID. That way, users can use the same credentials to access both on-premises applications and cloud services such as Microsoft 365.

To provide this functionality, Entra Connect is granted DCSync permissions and access to the NT hashes of all accounts in the Active Directory domain. Therefore, it is clearly a critical asset that requires stringent risk management strategies. However, Entra Connect is all too often overlooked during Tier Zero classification. In fact, many admins are simply not aware of how powerful the DCSync permission is. An adversary who compromises an account with this permission may be able to exploit domain replication to access and manipulate domain data, and even compromise the integrity and availability of the Active Directory environment. Moreover, if Entra Connect is not properly protected as a Tier Zero asset, malicious actors can tamper with its configuration to move laterally to cloud systems or make those systems unavailable to users.

What’s worse, the account used for synchronization is easily identifiable: It starts with “MSOL” and its description always begins with the string “Account created by Microsoft Azure Active Directory Connect”.

Risk management strategies

Be sure to include Entra Connect in your list of Tier Zero assets and apply stringent security controls to it. In particular, use Credential Guard as well as LAPS (Local Admin Password Solution) so that the local administration account receives an individual password that only Tier Zero accounts have access to.

Misconfiguration: Not protecting AdminSDHolder

The problem

Another critical object that organizations often fail to properly protect is AdminSDHolder. This Active Directory object is automatically created in the System container of every Active Directory domain. It acts as a permissions template for privileged accounts: Every 60 minutes by default, the SDProp process applies the ACL of the AdminSDHolder object to all protected groups and their members, copying the template permissions over the current permissions.

While this functionality is designed to strengthen security by restoring standard permissions, it can be abused. If an adversary changes the ACL for AdminSDHolder, their modified permissions will be applied to privileged groups and users. For instance, they can add an account they control to the ACL and grant it extensive access rights. Moreover, even if an admin removes the rights, the access will be restored automatically every 60 minutes, giving the attacker persistent administrative access to Active Directory.

Risk management strategies

Modifying the AdminSDHolder ACL requires administrative rights, so one of the most important risk management strategies is to minimize the number of privileged accounts and ensure that all of those accounts are protected as Tier Zero assets.

It’s also essential to get alerts on any attempt to modify the AdminSDHolder object and promptly investigate and respond to them. Even better, invest in a change management solution that enables you to prevent changes to this critical object.

Misconfiguration: Allowing privileged users to log in to non-privileged computers

The problem

Another key issue that puts security at risk is allowing administrators to log in to user workstations and other non-privileged computers. Because these machines are not protected with the same rigorous risk management strategies as PAWs, the credentials of the privileged account are at greater risk of being compromised by malicious actors.

This misconfiguration happens frequently when an administrative tier model is not implemented. However, it can also occur when the tier model is based on a complex combination of GPOs and relies on local computer configuration, which makes it prone to errors and risk of being bypassed by local administrators.

Risk management strategies

Implement a tiered administrative model, ideally based on authentication policies. Be sure to adhere to the core principle that assets in one tier are not permitted to access resources in less protected (higher numbered) tiers.

Misconfiguration: Privileged user account homed in an OU that has a linked GPO that is not in Tier Zero

The problem

To correctly implement a tiered administrative model, organizations need to ensure that all objects stay in their tier, with no exceptions. Organizations typically recognize that every privileged user account belongs to Tier Zero, as does any organizational unit (OU) that includes a privileged account.

However, they can neglect to consider that Group Policy objects (GPOs) that are linked to their OUs. If a GPO that is not Tier Zero is linked to an OU that includes a privileged account, security risks increase because a GPO has control over all objects in the OUs it is linked to. In this case, the GPO can be used to take control of the privileged user account.

In addition, admins sometimes use the loopback function of Group Policy to apply user GPOs to computers. This approach can be useful in managing shared devices, but it introduces a security risk that is easy to miss: A Tier Zero user could log onto a machine and have a user GPO assigned to that computer behave as though the GPO were applying to the Tier Zero user.

Risk management strategies

Be rigorous when inventorying Tier Zero assets. Make sure that privileged accounts are homed only in OUs that are classified as Tier Zero; if you find any in OUs from another tier, move them to a Tier Zero OU. Check all the GPOs applied to each Tier Zero OU; if you find a GPO that is not Tier Zero, either reclassify it and protect it accordingly, or unlink it from the Tier Zero OU. And use the Group Policy loopback functionality with due caution.

Misconfiguration: Privileged security group nesting

The problem

IT pros need to be able to easily and accurately see who is a member of any privileged group. Group nesting obfuscates that clarity and can lead to user accounts having inappropriate privileged access rights. For example, having the group Domain Users as a member of the Remote Desktop Operators local group on a server is pure catnip for attackers.

Reduce your AD attack surface

Reduce your AD attack surface.

See where you’re exposed and how to remediate it.

Risk management strategies

All privileged groups should be flat; remove all group nesting.

Misconfiguration: Security groups with no owners or documented purpose

The problem

IT teams are typically ill-equipped to know precisely what permissions a given security group requires and exactly which users should be members. Unfortunately, many organizations have large numbers of security groups that lack a defined business owner and a clearly documented purpose. This can result in elevated security risks from overprovisioning, since users are often members of more groups than appropriate and groups regularly long outlive their usefulness.

Risk management strategies

Make sure that every security group has at least one owner, and document the purpose of the group in as much detail as possible. Have owners regularly review their groups and adjust their permissions and membership to enforce the principle of least privilege. Consider implementing group expiration policies that will remove a group unless the owner attests to the continued need for its existence.

Conclusion

A core element of any cybersecurity and cyber resilience strategy is to assess the environment for misconfigurations that increase the risk of breaches and downtime. If your organization has a hybrid Active Directory and Entra ID environment, be sure to check for each of the mistakes detailed above. Implementing the risk management strategies provided is a quick and effective way to improve your security posture.

Nine best practices to improve Active Directory security and cyber resilience

Active Directory (AD) is a prime target for attackers because of its importance in authentication and authorization. Learn best practices for defending your organization.

Get the Guide

About the Author

Natalija Buldakova

Natalija Buldakova is a certified IT professional and Sales Engineer at Quest Software, based in London, England. With nearly two decades of cross-industry experience, primarily utilizing the Microsoft technology stack, she empathizes with the challenges faced by IT project and BAU teams in managing IT infrastructure and navigating the impact of changes on business users. In her current role at Quest Software, Natalija leverages her expertise in IT Solutions Architecture and cybersecurity to ensure that Quest solutions enable customers to maximize the benefits of the technology, streamline IT operations, and enhance cyber resilience.

Related Articles