Active Directory is majorly impacted by hackers and intruders. The permissions model of Active Directory is so complex that an Active Directory administrator may not know what permissions are given in Active Directory for user accounts. It becomes more complex for administrators when they have thousands of objects in the Active Directory. For example, if you have 100k users in Active Directory it becomes difficult for you to maintain relationships of all users with the active directory permissions. Some of the users may be service accounts, some of the users may be admins and some may be just domain users, but challenge here is that how do you find out who has what access in Active Directory. Sometimes it becomes difficult in finding top risks in Active Directory and this is where this article comes handy. Looking at the Active Directory permissions there are various things to consider as listed below:
All permissions that you apply on an OU or Container may or may not be inherited by the child objects depending on the inheritance configured on the child objects. The permission model in Active Directory is designed to support what’s often referred to as “Granular Control.” While this level of control is powerful, it can also make it challenging to determine who has access to what.
For example, if User-A has explicit permissions to modify objects within an Organizational Unit (OU) that contains thousands of users, it may not be obvious from the OU’s delegation or permissions view whether User-A actually has those rights. This is because explicit permissions granted at a lower level might not be visible through standard OU delegation tools. Additionally, Active Directory includes low-level partitions and containers where users can be granted direct access. These structures are not always visible through the standard GUI tools available to administrators, making it difficult to identify who has control over them. In such cases, permissions can be overlooked, leading to potential security risks or administrative confusion.
We have been working with customers globally to conduct Active Directory risk assessments using SecID, gaining valuable insights throughout the evaluation process. During one such assessment, we discovered a noteworthy case: four users within an Organizational Unit had been granted explicit permissions to control 15 individual user accounts. This level of access was not visible when reviewing only the top-level OU permissions. To uncover these hidden permissions, we ran the SecID Risks Finder for Active Directory, which thoroughly analysed permission structures beyond the OU level. The tool generated a detailed report, clearly identifying the four users who had direct, explicit permissions, permissions that would have otherwise gone undetected through standard OU-level reviews. This highlights the importance of deep, granular visibility when assessing risks in Active Directory environments.
There is a common misconception that delegated rights can only be applied to Organizational Units and not to individual objects within them. This is incorrect. Delegated rights can be assigned directly to objects within OUs as well.
In general, delegated rights refer to permissions that are explicitly assigned (i.e., not inherited). These permissions are typically applied at the OU or container level, but they can also be set directly on objects.
For example, you can delegate the “Reset Password” permission on an OU so that it applies to all user objects within that OU. This is a delegated right. However, if someone later disables permission inheritance on a specific user object within that OU, the delegated right can still be applied directly and explicitly to that object.
Delegated rights can be found on OUs, containers, or individual objects in Active Directory under the following conditions:
In all of these cases, if a security entry has IsInherited set to FALSE, it means that the permission was explicitly assigned using Delegation wizard or using the security tab and is not inherited from a parent object. This is a key indicator of delegated rights in Active Directory.
When assessing risks in Active Directory, it’s not enough to simply extract permissions, you must interpret them correctly. This requires a solid understanding of how Active Directory permissions work and what default permissions are assigned during installation. For example, if you’re tasked with identifying who can transfer or seize FSMO roles, such as the PDC Emulator, you must know where to look. In this case, the Change PDC extended right exists only on the Domain partition. Therefore, your script or audit must target the security descriptors on the domain naming context, not elsewhere.
The distinction here is that Active Directory assigns default permissions to key built-in groups like Domain Admins or Enterprise Admins. These principals are granted broad permissions, such as Full Control or GenericAll on critical objects, including the Domain partition. Because of this, they inherently hold rights like Change PDC, Allocate RIDs, and other FSMO-related extended rights.
Here’s where many risk assessments go wrong: if your report flags these default assignments (e.g., Domain Admins having Change PDC rights) as security risks without context, the report becomes misleading. Not all permissions are a risk some are by design and essential for AD to function correctly.
To accurately identify real risks:
Ultimately, the accuracy of your risk report depends on both technical extraction of ACLs and a strong grasp of how AD security is structured by default. Without this, the results can be misinterpreted, leading to false positives and unnecessary concern over legitimate configurations.
Active Directory operates primarily based on attribute GUIDs, not attribute names. Every attribute in Active Directory is assigned a globally unique identifier (GUID), which the system uses internally to manage permissions and access control. Whether you’re auditing who can reset user or privileged account passwords, or identifying who has DCSync rights, each of these rights is tied to a specific GUID. This GUID, not the friendly attribute name, is what actually governs access.
When using tools like Get-ACL to enumerate permissions on an AD object, you’ll notice that the output does not display attribute names. Instead, it returns entries containing GUIDs, which can make accurate analysis more complex.
For example, a Get-ACL output might return something like the following:
Or you may see this also:
In this case, the ObjectType GUID represents a specific extended right, such as “Reset Password” or “Replicating Directory Changes”, but the GUID itself doesn’t reveal which one without further mapping. To properly interpret these results, it’s essential to cross-reference the GUIDs with their corresponding rights or attributes, typically using Microsoft documentation or tools that resolve GUIDs to human-readable names.
While examining Active Directory object permissions, you may notice that different entries contain varying values for ActiveDirectoryRights, ObjectType, InheritedObjectType, and ObjectFlags. However, one helpful aspect of Active Directory’s permission model is that certain permissions are returned in a human-readable format. For example, when reviewing permission entries, you might see values like “GenericAll” or “Self” under the ActiveDirectoryRights field. These represent actual permission levels assigned to the AD object, GenericAll indicating full control, and Self referring to permissions a user has over their own account.
The challenge, however, lies in understanding what those permissions actually apply to. While the permission name is readable, it doesn’t directly tell you which specific attribute or object it’s affecting, especially in the case of “Self” rights, which are often tied to specific attributes like changing one’s own phone number, email, or group memberships.
To determine the exact scope of these permissions, particularly when ObjectType contains a GUID, you must map that GUID back to the corresponding attribute or control right. Without this mapping, the true impact of the permission remains unclear.
Sometimes, you may encounter unresolved SIDs associated with abusable permissions in Active Directory. This typically occurs when a user or group that was previously granted permissions has since been deleted. While it can happen as part of regular account lifecycle management, it could also indicate malicious activity. For example, if an attacker compromises your Active Directory, they may create user accounts, assign them elevated permissions to critical objects, perform malicious actions, and then delete those accounts to cover their tracks. When this happens, the SID (Security Identifier) remains in the ACLs, but since the object no longer exists, it appears as an unresolved SID.
This is why it’s critical to regularly audit for unresolved SIDs—especially when assessing the aftermath of a potential security incident. The SecID Risk Finder for Active Directory can help identify such SIDs, flagging potential indicators of compromise or misconfiguration.
There are two common scenarios where unresolved SIDs may appear:
In either case, unresolved SIDs must be investigated. As part of any Active Directory forensic review, it’s essential to analyze all objects that were created, deleted, or modified during the suspected period of compromise. This ensures you have full visibility into what actions were taken and by whom, even if the original accounts no longer exist.
The SecID Risk Finder has 136 queries which you can execute to find risks in Active Directory. Some of the queries are explained here:
By default, built-in privileged groups such as Domain Admins, Enterprise Admins, and Administrators have Full Control permissions over Organizational Units (OUs) when Active Directory is first installed. These default permissions are intentionally designed to ensure that key administrative principals have unrestricted control over the directory environment. However, it’s important to understand that regular domain users should not have Full Control permissions on OUs unless explicitly required for a business need. Granting such broad access to standard users can introduce significant security risks, including accidental misconfigurations or intentional abuse.
In some scenarios, organizations choose to delegate Full Control to non-admin users—for example, to a business unit IT team responsible for managing users and resources within their own dedicated Organizational Unit. In this case, a custom delegation model may be implemented where specific users are granted elevated rights on that OU only.
While such delegation can be operationally useful, it should be done cautiously and with full auditing, ensuring the permissions are:
Tools like SecID Risk Finder can help identify users who have Full Control permissions on OUs, including cases where these permissions have been assigned outside of the default configuration.
One of the most critical risks in Active Directory is unauthorized users being able to reset passwords of privileged accounts (Tier-0 objects). Tier-0 includes Domain Admins, Enterprise Admins, domain controllers, high-value service accounts and other sensitive principals. Any user or group with the appropriate write permissions on a privileged account can reset its password without knowing the current password, which is a direct path to privilege escalation.
Simply checking for WriteProperty on a password attribute is not sufficient, because AD permissions are complex and there are multiple ways to obtain the ability to reset a password (for example GenericAll, WriteDACL, certain extended rights, or group-based delegation). A proper assessment must examine explicit and inherited permissions, extended rights (such as the Reset Password extended right), permissions granted via groups, and any indirect paths to Tier-0 objects.
The risks are severe: an attacker who can reset privileged passwords can take over the domain, create persistence, modify Group Policy, exfiltrate data, or disable security controls. Password resets often do not trigger immediate alerts, enabling stealthy abuse. Misconfigured reset rights also create compliance and audit issues.
Recommended actions are to regularly audit who can reset privileged passwords using tools that map GUIDs to rights, limit password-reset capability to authorized Tier-0 administrators only, apply the principle of least privilege, and monitor or alert on changes to permissions affecting Tier-0 objects.
By default, Administrators or Domain Admins have the ability to create, delete, and manage all Fine-Grained Password Policies (FGPPs) in Active Directory. This level of control is meant to be restricted to trusted, privileged accounts. If FGPPs are managed by unauthorized or unknown users, it introduces serious security vulnerabilities. These users could intentionally or unintentionally weaken password policies by:
Such changes make it easier for attackers to carry out brute-force or dictionary attacks. Even more dangerously, an attacker with access to FGPPs could apply weaker password settings specifically to privileged accounts (such as administrators or service accounts), enabling easier credential theft while remaining undetected.
This kind of targeted manipulation acts as a stealthy backdoor into the domain, allowing persistent access, even after broader security controls have been restored. In addition to technical risks, improper FGPP management can also lead to compliance violations, especially if the policies no longer align with standards like NIST, CIS, or internal organizational requirements. Because FGPPs are granular and not always visible through standard Group Policy review, misconfigurations often go unnoticed, until a security incident occurs.
Uncontrolled access to FGPPs undermines password security, weakens organizational defenses, and increases the risk of a full domain compromise. It is critical to limit FGPP management to authorized administrators only, audit changes regularly, and align policies with organizational security standards.
Similarly, there are other queries that you need to execute to ensure your Active Directory is secure:
By default, privileged accounts such as Domain Admins, Enterprise Admins, and SYSTEM have the ability to replicate secrets in Active Directory. This means they can perform domain replication operations that include sensitive data such as password hashes, Kerberos keys, and other authentication-related secrets.
There are two key permissions to be aware of when identifying who can replicate secrets:
These permissions enable the use of DCSync attacks, where an attacker simulates the behavior of a domain controller to extract password hashes and other sensitive information from Active Directory.
Why is this important? If unauthorized users are granted these rights, they can perform silent replication of secrets using tools like Mimikatz, extract the NTDS.dit database, and gain access to all domain user passwords, including those of administrators. This effectively gives an attacker full control of the domain.
It’s critical to regularly audit who has the rights to replicate secrets in Active Directory. Only highly trusted, Tier-0 administrative accounts should have this capability. Any misconfiguration or over-permissioning in this area represents a major security risk and must be corrected immediately to prevent domain compromise.
SecID Risk Finder for Active Directory can let you check below:
When Active Directory is set up, it creates default principals with predefined permissions. Before running the Risks Finder for Active Directory, it’s important to understand what permissions these default principals have in your environment. Typically, organizations create custom security groups, add users to those groups, and then assign the necessary permissions to these groups on Organizational Units, containers, or specific objects.
You, as the administrator, need to be aware of your custom security groups so you can exclude them from the Risks Finder results. This is crucial because Risks Finder does not inherently know which users or groups are legitimate, it simply reports on permission assignments. Without excluding your known custom groups, the Risks Finder report may include many false positives, making it less useful.
You have a risk in Active Directory if any of the following occur:
Understanding and managing these permissions carefully will help you maintain a secure Active Directory environment and get meaningful results from your Risks Finder scans.
Risk Finder is based on Microsoft’s delegation tier model found here.
SecID Technology Risks Finder is built to enhance the security of key technologies like Microsoft Active Directory, VMware, Hyper-V, Azure, and Microsoft 365 tenants. It includes powerful query modules such as “Who Can”, “Can a Single User”, and “View”. You can also create and run custom queries against your target environment. The output is a detailed report highlighting security issues and gaps. Once these gaps are identified, you can take corrective action to strengthen and secure your technology infrastructure.
For Active Directory, Technology Risks Finder offers below types of queries:
In SecID Technology Risks Finder, you can define the scope for your queries in Active Directory. There are four types of scopes supported:
You can execute individual queries in SecID
Try SmartProfiler Health Checks and start using AVD Troubleshooter.