Password requirement settings are not enforced on the reported accounts. While GPOs may override this setting, there are various scenarios where this may not be the case. For example, if the account had an empty password set before the policy was implemented. It’s a best practice to set it on the account as well as the GPO. You could audit this by supplying an empty password or looking at the password hashes from your domain controller as the hashes are not salted.

Accounts with reversible passwords store their passwords in a format that can be easily decrypted to reveal the original plaintext password. Attackers can retrieve these passwords using methods like DCSync attacks, potentially gaining unauthorized access to systems and resources within the domain.

Kerberos Pre-Authentication is a critical security mechanism that prevents attackers from easily obtaining Kerberos ticket-granting information. When Pre-Authentication is disabled, attackers can exploit vulnerabilities like AS-REP Roasting, allowing them to perform offline brute-force attacks on passwords, increasing the risk of unauthorized access. Ensuring that all accounts, especially administrative ones, have Pre-Authentication enabled is essential to maintaining secure access controls within Active Directory environments.

Kerberoasting is an attack technique where attackers extract service account credentials from a Kerberos ticket. By requesting a service ticket for a target account, attackers can obtain the ticket and perform an offline brute-force attack to crack the password. This method exploits weak service account passwords and can lead to unauthorized access of critical systems and data. What increases the danger of this attack is that any AD user can request the tickets.

One or more accounts have a weak explicit certificate mapping in the altSecurityIdentities attribute. Mappings by subject, by issuer, or by email (RFC822) are weak because an attacker who can obtain or craft a certificate with a matching subject, issuer, or email can authenticate as the mapped account. Strong mappings, which bind to the certificate serial number plus issuer, the subject key identifier, or the public key hash, are not affected.

Constrained delegation with protocol transition enabled allows a service to impersonate users across different protocols, such as NTLM, potentially without their Kerberos tickets. If applied to a domain controller, this delegation can enable an attacker to impersonate high-privileged accounts, such as domain admins, and take control of the domain by accessing critical services like LDAP.

The Guest account is a well-known default account in Active Directory that allows access to the domain without a password. By default, this account has limited privileges. However, it can be used to gain initial access to your network and subsequently used as a launchpad to perform reconnaissance and privilege escalation attacks.

Allowing NTLMv1 or LM authentication on domain controllers poses a significant security risk, as these outdated protocols are vulnerable to cryptographic attacks. Attackers can capture and exploit NTLMv1 hashes to impersonate users and gain unauthorized access to critical systems, potentially compromising the entire domain through attacks like coerced authentication.

Non-expiring passwords in the Domain Admins group pose a risk, as these static credentials can be easily targeted by attackers with credential-based attacks. Passwords that are not rotated for long periods of time increase the likelihood for compromise and persistence.

Some AD attributes are used to store credential information within Active Directory, potentially in cleartext or using weak encryption methods. This poses a significant security risk, as these attributes can be queried by unauthorized users, allowing attackers to retrieve passwords and gain unauthorized access to systems.

Stale administrative passwords provide attackers with additional opportunities to perform credential-based attacks and if compromised, can prolong system access.

Resource-based constrained delegation allows designated principals to obtain Kerberos service tickets to an account on behalf of other users via the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. An attacker who controls a listed principal, or who can write this attribute, can impersonate privileged users to the account and take it over. RBCD configured on a domain controller or the krbtgt account is equivalent to full domain compromise.

The krbtgt account is a crucial component in the Kerberos authentication system in Active Directory, as its password is used to sign Kerberos tickets. A stale krbtgt password increases the risk of a “Golden Ticket” attack, where attackers can forge valid Kerberos tickets, granting unauthorized access to any resource in the domain.

Stale passwords provide attackers with additional opportunities to perform credential-based attacks and can prolong access to systems if compromised.

Password expiration is not enforced on the reported accounts. The longer a password is in use, the longer attackers have to crack password hashes, actively control the account, or perform credential-based attacks against them. These accounts are often service accounts which typically have additional privileges and are targeted by attackers.

One or more service accounts with service principal names do not support AES Kerberos encryption (msDS-SupportedEncryptionTypes lacks AES, or is unset). These accounts may receive service tickets encrypted with weaker algorithms such as RC4, which are more practical to crack offline. Service accounts should support AES and use strong, regularly managed passwords.

Constrained delegation allows services to impersonate users when accessing specific resources on their behalf, but misconfigured or decommissioned service accounts with constrained delegation pose a significant security risk. Attackers with the ability to modify Service Principal Names (SPNs) can exploit these configurations to escalate privileges and move laterally within the environment, gaining unauthorized access to sensitive resources.

The LM hash (LAN Manager hash) is an outdated and insecure password hashing algorithm that is easily cracked to reveal clear-text passwords. If LM hashes are in use, attackers can exploit this weakness to gain unauthorized access to systems.

One or more accounts that require smart card authentication have not had their underlying password changed for an extended period. Although interactive sign-in requires a smart card, the account still has an NT hash that can remain valid until the password changes. These accounts should have their passwords rotated to reduce pass-the-hash and credential reuse risk.

DES is an outdated and weak encryption algorithm that is easily cracked, due to its weak 56-bit key length. Attackers can exploit this weakness by cracking Kerberos tickets encrypted with DES, allowing them to steal user credentials and escalate privileges within the domain.

Accounts with non-standard Primary Group IDs (PGID), may indicate hidden or misconfigured group memberships. The Primary Group ID is typically set to default values, such as Users (513/514), Computers (514/515), and Domain Controllers (516/521). Attackers can exploit non-standard PGIDs to obscure privileged access or bypass membership audits, making it difficult to detect unauthorized access or escalation.

Not enabling Kerberos armoring leaves the Kerberos authentication process vulnerable to pre-authentication attacks, such as AS-REP Roasting. Kerberos armoring enhances the security of the protocol by protecting the pre-authentication steps and ensures stronger protection during authentication.

One or more non-standard principals have dangerous control over privileged Active Directory objects. Permissions such as full control, ownership, password reset, or permission modification can provide administrative influence without visible privileged group membership. These hidden control paths, often referred to as "shadow admins" should be treated as privileged access and removed unless explicitly required.

This is a critical security issue where low-level users can exploit certificate request settings to impersonate higher-privileged accounts, like domain administrators. This occurs when certificate templates are configured with weak permissions that allow users to input key identity details themselves. If these conditions align, users can request certificates that allow them to assume the identity of others.

The DnsAdmins group grants administrative control over the DNS service, which commonly runs on domain controllers. Improper or unnecessary membership can allow a user to modify DNS service behavior and potentially execute code with elevated privileges. Membership should be treated as equivalent to Domain Admin and kept empty or limited to fully trusted Tier 0 administrators.

Each privileged user account increases the attack surface. Organizations are urged to follow best practices such as least privilege, particularly involving administrative accounts.

The absence of LAPS (Local Administrator Password Solution) means that local administrator passwords across workstations and servers are not securely managed, leaving them vulnerable to password reuse and compromise. Without LAPS, attackers who gain access to one local admin password or password hash may use it to escalate privileges across multiple machines within the domain

By default, non-administrative users can add up to 10 computer accounts to the domain. This capability allows basic users to introduce uncontrolled machines into the domain, which can be exploited by attackers to gain unauthorized access or launch additional attacks.

One or more privileged objects are owned by a principal that is not a standard Tier 0 administrative owner. The owner of an object has the implicit right to modify its permissions, so a non-privileged owner can grant themselves full control regardless of the object's current DACL.

One or more accounts contain privileged security identifiers (such as Domain Admins, Enterprise Admins, or Administrators) in the sIDHistory attribute. Because Windows can honor sIDHistory during authentication, an account may retain privileged access without appearing as a member of the privileged group. Privileged sIDHistory entries should be investigated and removed unless they are tied to an active, documented migration.

One or more privileged accounts are not protected from Kerberos delegation as they lack the "Account is sensitive and cannot be delegated" flag or not members of the Protected Users group. When these accounts authenticate to a service trusted for delegation, that service may be able to obtain and reuse their Kerberos tickets. For highly privileged accounts such as Domain Admins, compromise of a delegated service can lead to full domain compromise.

A Read-Only Domain Controller (RODC) with SYSVOL write access allows changes to be made to critical system files, such as Group Policy Objects (GPOs), which can then propagate to writable domain controllers. This could enable an attacker to modify domain-wide policies and potentially take control of the domain.

The AdminSDHolder object has non-standard permissions that grant dangerous control to one or more principals. Because AdminSDHolder permissions are periodically applied to protected administrative accounts and groups, improper access can propagate across privileged objects. This condition can create both privilege escalation and persistence risk within the domain.

Non-standard users with DCSync permissions pose a significant security risk, as they can replicate credentials for any account within the domain, including domain administrators. Attackers who obtain these privileges can execute a DCSync attack, extracting NTLM password hashes and Kerberos keys without triggering typical authentication-based alerts. This access enables adversaries to conduct credential theft attacks such as Golden Ticket and Silver Ticket attacks, granting long-term control over Active Directory.

One or more privileged objects allow a non-standard principal to write shadow credential data through the msDS-KeyCredentialLink attribute or equivalent control permissions. This access can allow a user to add alternate authentication material and authenticate as the target account without knowing its password. When the affected object is privileged, this can create a direct path to domain compromise.

Unconstrained delegation allows a service or account to impersonate any user that interacts with it by caching their Kerberos ticket-granting tickets (TGT). This creates a significant security risk, as attackers who compromise a service trusted for unconstrained delegation can extract these TGTs and impersonate privileged accounts, leading to domain take over.

One or more group managed service accounts allow their managed password to be retrieved by broad or low-privileged principals such as Authenticated Users, Domain Users, Domain Computers, or Everyone. If an unauthorized user can read the gMSA password via the msDS-GroupMSAMembership attribute, may be able to recover the service account password and impersonate the service. Password retrieval rights should be limited only to the systems that require the account.

Administrator accounts that don’t adhere to the principle of least privilege (has an email address assigned) may be at risk of performing both routine and administrative tasks under the same account, increasing exposure to attacks. Without proper separation of privileges, a compromised admin account could lead to unauthorized access, lateral movement, or privilege escalation within the domain.

The Built-in Administrator account is highly privileged and should be used only for initial setup or disaster recovery. Recent activity on this account could signal a security breach or improper use, as it shares its password with the Directory Services Restore Mode, making it a prime target for attackers.

Computer Account Detected in Privileged Group indicates that a computer account has been granted membership in a domain privileged group, such as Domain Admins. This poses a significant security risk, as compromising the computer account could allow an attacker to gain elevated privileges and control over critical domain resources. Normally, computer accounts should not have such elevated access.

Disabled privileged accounts present a security risk when they retain group memberships that grant elevated access. Attackers who gain control of such accounts can re-enable them and immediately inherit their previous privileges, bypassing normal escalation processes. Since disabled accounts are often overlooked in security monitoring, they are prime targets for exploitation, allowing adversaries to operate with high-level access while evading detection.

Administrator accounts that have not been used for a significant period, typically over 90 days, create a broader attack surface. These accounts, if compromised, can allow attackers to gain elevated access unnoticed, as they are often overlooked during routine security checks. Unused privileged accounts should be reviewed and decommissioned if no longer necessary.

An administrative group containing a Foreign Security Principal (SPN) indicates that an account from another domain has been granted elevated privileges within your domain. This can create a security risk, as Foreign Security Principals may not be subject to the same auditing and monitoring controls, potentially allowing attackers to abuse these privileges without detection.

The Protected Users group is designed to provide enhanced security for privileged accounts by limiting the use of vulnerable authentication methods like NTLM and reducing exposure to credential theft attacks. If privileged accounts are not members of this group, they remain susceptible to common attacks such as credential caching, Kerberos delegation, and weaker encryption algorithms.

When the RODC Privileged Group is not protected, privileged credentials can be replicated to Read-Only Domain Controllers (RODCs), increasing the risk of credential theft. RODCs are often deployed in less secure environments, making them more vulnerable to attacks. If privileged accounts are allowed in the Password Replication Policy, attackers can steal these credentials and gain elevated access to the domain.

RODCs (Read-Only Domain Controllers) should not have the ability to retrieve credentials for privileged groups. Privileged groups have RIDs lower than 1000, and if these accounts can be exposed on an RODC, it increases the risk of credential theft or impersonation.

RODCs (Read-Only Domain Controllers) may expose privileged user credentials by caching them. The attribute msDS-RevealedUsers tracks users whose credentials have been revealed to the RODC. If a privileged user’s credentials are cached, it poses a risk, as RODCs are often deployed in less secure environments.

Risky LAPS read permissions occur when non-administrative users have access to the Local Administrator Password Solution (LAPS) passwords, stored in the ms-Mcs-AdmPwd attribute. This exposure allows non-administrative users to retrieve local administrator passwords, enabling lateral movement across systems in the domain. Improperly configured read or write permissions on computer accounts can undermine LAPS, leading to potential domain-wide compromises.

One or more group managed service accounts have not rotated their managed password within the expected interval (default is 30 days). Stale gMSA passwords can indicate orphaned accounts, misconfigured host permissions, or services that are no longer properly maintaining the account. These accounts should be reviewed to confirm they are still in use and rotating as expected.

The "Pre-Windows 2000 Compatible Access" group grants access to certain legacy calls, which can expose vulnerabilities if improperly configured. Custom membership in this group, particularly the addition of accounts beyond the default settings, can increase the risk of unauthorized access to sensitive domain resources by exploiting legacy protocols.

Default Microsoft operator groups, such as "Account Operators" and "Server Operators," have elevated permissions that provide access to critical domain resources. Misuse of these groups can introduce privilege escalation pathways, allowing attackers to make unauthorized changes that compromise the security and stability of the domain.

The "Pre-Windows 2000 Compatible Access" group grants access to certain legacy protocols and services. If this group includes "Authenticated Users," it increases the risk of exploitation through vulnerabilities in outdated protocols, potentially allowing unauthorized access to sensitive resources within the domain.

Possible duplication of Active Directory domain accounts can occur when multiple objects share the same attributes, such as Distinguished Name (DN) or sAMAccountName. These conflicts can arise from synchronization issues, administrative errors, or replication inconsistencies, potentially leading to authentication failures or security gaps. Attackers can exploit duplicate accounts to evade detection, abuse unintended privileges, or create persistence within the environment.

The "Schema Admins" group allows members to modify the Active Directory schema, which defines the structure of AD objects. These changes are permanent and can have far-reaching consequences. For security, this group should remain empty unless a schema update is necessary, and membership should be strictly controlled.

No group managed service accounts were identified in the domain. This may indicate that services continue to rely on traditional service accounts with static passwords, which are often difficult to rotate and protect. Group managed service accounts rotate their own passwords automatically and cannot be used for interactive logon. gMSAs should be considered for eligible services to reduce password management and credential theft risk.

Enabling anonymous access to Active Directory allows unauthenticated users the ability to query and gather information about the domain. This provides attackers with the ability to enumerate accounts, computers, and other AD objects, giving them critical information to plan attacks such as password spraying or brute-force attacks, potentially leading to unauthorized access.

One or more Active Directory trusts are configured with attributes that weaken the expected security boundary between domains or forests. These settings can relax SID filtering, delegation, or trust isolation controls and may allow privileges to cross the trust in unintended ways. Trust configurations should be reviewed to confirm they are required and securely constrained.

A Domain Controller with a stale update indicates that the system has not been patched or rebooted in an extended period, leaving it vulnerable to known exploits and threats. Regular updates are crucial for securing Active Directory environments, as attackers can exploit unpatched vulnerabilities to gain unauthorized access or escalate privileges.

When LDAP signing is not enforced on domain controllers, the LDAP traffic is vulnerable to man-in-the-middle (MitM) attacks, where attackers can intercept and modify requests between clients and servers. This allows attackers to manipulate LDAP queries, potentially gaining unauthorized access or modifying sensitive directory data, such as adding users to privileged groups.

Deprecated, unsupported, or otherwise legacy operating systems often do not receive security patches and may have known exploits available. Many legacy operating systems are unable to support modern day security features which increase the difficulty of securing them.

Deprecated, unsupported, or otherwise legacy operating systems often do not receive security patches and may have known exploits available. Many legacy operating systems are unable to support modern day security features which increase the difficulty of securing them.

The SIDHistory attribute allows user and computer accounts to retain access to resources from their previous domain during migrations. However, if not cleared after migration, this attribute can be exploited by attackers to gain unauthorized access to resources in the new domain by leveraging the old SID, posing a security risk.

Domain Controller accounts rotate passwords every 30 days as per the Microsoft default. This increases the risk of attacks like DCSync, where attackers can extract password hashes and use them to compromise the domain through attacks like Silver Tickets.

This indicates a trust relationship between domains or forests is not protected using SID Filtering. This can allow attackers to abuse SID History to impersonate privileged users from a trusted domain or forest, leading to unauthorized access. SID Filtering prevents this by blocking any accounts that attempt to use SID History attributes across trust boundaries.

The SID History attribute allows the account to retain access rights from its previous domain. If the original domain is no longer active, the SID History is unnecessary and could pose a security risk by providing unauthorized access through outdated privileges.

Anonymous NSPI (Name Service Provider Interface) access allows unauthenticated users to query Active Directory, potentially exposing sensitive information like user lists. If exposed, especially over the internet via protocols like RPC over HTTP, attackers could exploit this access to enumerate users and target them for further attacks.

When a DNS zone allows transfers, it enables attackers to retrieve the DNS record set, exposing sensitive information about the network infrastructure. This can lead to further attacks, such as man-in-the-middle attacks or the exploitation of services within the network by gaining detailed knowledge of the domain's resources.

Disabling LDAPS channel binding creates a vulnerability where an attacker can perform relay attacks by intercepting and forwarding LDAP packets through an LDAPS connection without proper verification. Channel binding helps secure LDAPS by tying the TLS channel to the LDAP authentication process, preventing unauthorized packet relay.

A legacy domain functional level indicates that the Active Directory environment is operating at an older functional level, such as Windows Server 2012 or lower. These older levels do not support many of the modern security features introduced in more recent versions, leaving the domain vulnerable to potential attacks.

An NT4 Compatible Trust refers to a legacy trust relationship between an Active Directory domain and an older NT4 domain. This type of trust uses outdated protocols that lack modern security features, making it vulnerable to attacks such as credential forwarding and man-in-the-middle attacks.

When the outdated and insecure NT File Replication Service (NTFRS) protocol is active, it can replicate the SYSVOL share, which contains critical files like Group Policy Objects (GPOs) and login scripts. NTFRS is vulnerable to exploitation, and attackers could manipulate SYSVOL files to gain control of domain controllers or propagate malware across the network.

Relying on a single domain controller for managing Active Directory services significantly increases the risk of a single point of failure. If a domain controller becomes inoperable, this practice could cause significant downtime and a lack of service availability.

By default Domain Controllers are owned by the Domain Administrators or Enterprise Administrators group. Allowing a non-standard user account ownership of a domain controller, gives that account the ability to modify its permissions, potentially enabling unauthorized access or privilege escalation, leading to a full domain compromise.

One or more enabled computer accounts have a password that has never been set (pwdLastSet is zero). These are pre-staged accounts created for a machine that has not yet joined the domain. Until the machine joins, the account carries a predictable default password derived from the account name, so any authenticated user who knows the name can take the account over and join a rogue machine or use the account for further attacks.

Backups of the Active Directory database are not updated or maintained according to best practices. Outdated backups can fail to capture recent changes in the environment, making them unreliable for recovery or rollback in the event of a failure or security incident.

One or more trust accounts have passwords that have not rotated for an extended period, instead of the roughly every 30 days default. Stale trust passwords can weaken the security of the trust relationship and increase the value of any previously captured trust credentials. Trusts should be reviewed for continued business need and configured to maintain healthy password rotation.

An account linked to a delegation cannot be resolved or does not exist. This situation may occur if the account has been deleted or is from another domain. Unknown accounts in delegations can pose a security risk, as it is unclear who has the delegated permissions, potentially leading to unauthorized access.

Weak LDAP encryption occurs when outdated and vulnerable SSL protocols, such as SSLv2 or SSLv3, are used to secure LDAP traffic. These protocols are considered weak and can be exploited by attackers to intercept and decrypt sensitive directory information, potentially leading to unauthorized access or data manipulation.

If AES is not enabled on a trust, Kerberos tickets will default to the weaker RC4 encryption or fail, potentially falling back to NTLM, which is less secure. Ensuring that Kerberos authentication between trusted domains is using AES encryption for trust relationships provides more secure authentication.

Organizational Units (OUs) in Active Directory that lack accidental deletion protection are vulnerable to unintentional deletion. This could lead to significant disruptions and data loss, as the deleting OUs can remove key objects and resources in the domain. Accidental deletion protection is a safeguard that prevents the deletion of OUs unless this protection is intentionally removed.

The modification of the default OU location in Active Directory occurs when default organizational units (OUs) like CN=Computers or CN=Users are changed, potentially causing unexpected behavior in scripts, tooling, security audits, or policies that rely on these standard locations. This change can disrupt automated processes and pose a security risk if not properly controlled or documented.

Domain Controllers are considered inactive if they have not authenticated or changed their passwords within the past 30 days, which is a default. Attackers can exploit inactive Domain Controllers to reset passwords or reintroduce unwanted changes into Active Directory, potentially leading to a domain compromise.

Trusts between domains use a shared secret that is regularly updated. If this update does not occur, it indicates that the remote domain may no longer be active, or the trust is no longer functioning correctly.

The Recycle Bin within Active Directory allows for restoration and extends traceability in the event objects need to be recovered.

Computer accounts rotate passwords every 30 days as per the Microsoft default. Threat actors could alter the password changing frequency for persistence into the environment.

An unsecured DNS zone configuration allows DNS records to be updated without authentication, exposing the domain to potential attacks. An attacker could exploit this to modify or add DNS records, enabling man-in-the-middle attacks or credential theft by redirecting traffic to malicious servers.

A certificate authority has the "EDITF_ATTRIBUTESUBJECTALTNAME2" flag set, which lets any requester add an arbitrary Subject Alternative Name to a certificate request regardless of the template. An attacker can enroll from a low-privileged template, place a privileged user's userPrincipalName in the SAN, and authenticate as that admin. Because the flag is CA-wide, it weakens every template the CA issues.

A certificate authority globally disables the SID security extension (the OID 1.3.6.1.4.1.311.25.2 appears in the CA's DisableExtensionList). With the extension disabled CA-wide, none of the certificates the CA issues carry the account SID binding, so certificate authentication falls back to weaker name-based mappings templates.

Offering misconfigured certificate templates could permit attackers to request certificates on behalf of other users, allowing them to impersonate high-privileged accounts without needing their credentials. This vulnerability arises when certificate templates have overly permissive configurations that enable users to request certificates with an alternate identity, effectively granting unauthorized access.

Passwords embedded within Group Policy Objects (GPOs) are accessible to resources connected to the domain. Although these passwords are encrypted, the encryption key is publicly disclosed on Microsoft's website. Malicious actors can easily decrypt the passwords and gain access.

If the Print Spooler service is enabled on a Domain Controller, attackers can exploit vulnerabilities in the service to extract domain controller credentials. This can lead to the compromise of the entire domain, allowing attackers to conduct privilege escalation or launch attacks like DCSync to retrieve all user password hashes.

Certificate templates with over-permissioned write settings allow low-level users to modify template properties that can make them vulnerable to various privilege escalation attacks. This misuse could allow an attacker to create a certificate for any user, effectively impersonating them within the network and gaining unauthorized access.

Permissive certificate templates in Active Directory Certificate Services (ADCS) can allow low-privileged users to request certificates with elevated permissions, potentially enabling them to impersonate high-privileged accounts, like domain administrators. This often occurs when templates are configured with the "Any Purpose" Extended Key Usage (EKU) or without any EKU at all.

One or more certificate templates carry an issuance policy linked to an Active Directory group (the policy OID has an msDS-OIDToGroupLink attribute) and are enrollable by low-privileged users. If the template is broadly enrollable, a user may receive a certificate that effectively grants access associated with the linked group. If the linked group is privileged, a low-privileged user who enrolls in the template effectively gains that group's privileges.

One or more certificate templates allow certificate-based authentication but omit the SID security extension by setting the CT_FLAG_NO_SECURITY_EXTENSION flag. Certificates issued from these templates do not include the account SID binding, so certificate authentication may fall back to weaker name-based mappings. If weak mapping is accepted, an attacker who can enroll in the template and manipulate mapped identity attributes may be able to obtain a certificate that authenticates as another account.

No applied Group Policy requires SMB signing for domain-joined computers or servers. Member machines do not require SMB signing by default, so without an enforcing policy an attackers may be able to relay SMB authentication and perform actions as the authenticating user, especially where the user has local administrative rights. This finding is based on effective Group Policy; individual machines may still be configured locally.

One or more Group Policy Objects grant a dangerous privilege (for example SeDebugPrivilege, SeBackupPrivilege, SeRestorePrivilege, SeTakeOwnershipPrivilege, or SeTcbPrivilege) to a broad principal such as Everyone, Authenticated Users, or Domain Users. These privileges can provide significant control over the affected systems. These assignments should be limited to narrowly scoped administrative accounts with a documented need.

SMB signing is not required on one or more domain controllers (the RequireSecuritySignature setting is zero). Without required SMB signing, an attacker who can intercept or coerce SMB authentication can relay it to the domain controller and act as the authenticating account. Domain controllers should require SMB signing to protect sensitive authentication and administrative traffic.

SMBv1 is a legacy protocol that lacks modern security features and is considered weak and susceptible to downgrade attacks. Allowing SMBv1 support on domain controllers introduces integrity issues on critical assets.

An unhardened Microsoft Exchange installation, whether active or legacy, can introduce privilege escalation vulnerabilities by altering domain permissions. Attackers can exploit these misconfigurations to modify permissions, enabling them to perform DCSync attacks, which can extract credential hashes and potentially lead to full domain compromise.

Group Policies that enable reversible password encryption compromises the security of stored passwords by allowing them to be decrypted into plaintext. Attackers can retrieve these passwords through attacks like DCSync, potentially leading to unauthorized access to accounts and sensitive resources within the domain.

The forest-wide dSHeuristics attribute is configured with one or more insecure values. This attribute can change important directory behaviors such as, anonymous LDAP access (character 7 = 2), enable List Object mode (character 3), or disable UPN/SPN uniqueness verification (character 21). Because the setting applies broadly, any non-default value should be carefully reviewed and documented.

LLMNR (Link-Local Multicast Name Resolution) is a network protocol that allows local name resolution when DNS is unavailable. Attackers can exploit LLMNR to perform man-in-the-middle attacks, redirect users to malicious servers, and capture credentials. Disabling LLMNR is a crucial step in enhancing network security.

When files distributed via Group Policy have weak access controls, unauthorized users may be able to modify them. Attackers can exploit this vulnerability to alter the files, potentially leading to code execution or the compromise of user accounts when the files are run.

Shorter passwords are more susceptible to brute-force or password spraying attacks. Enforcing a minimum password length of at least 8 characters, which is a Microsoft default, is a fundamental security measure to protect against unauthorized access.

A certificate authority grants powerful management permissions to non-standard or unnecessary principals. Users with Manage CA or Manage Certificates permissions can alter certificate authority behavior, approve requests, or otherwise influence certificate issuance. These rights should be treated as Tier 0 administrative privileges and limited to trusted PKI administrators.

Assigning Group Policy Objects (GPOs) to broad groups like "Everyone," "Authenticated Users," or "Domain Users" and granting access to privileged local groups, such as local administrators, can result in over-privileged access. This misconfiguration allows users with minimal permissions to perform actions typically reserved for administrators.

One or more Group Policy Objects grant edit or control permissions to non-standard principals. A user who can modify a GPO can change settings, scripts, or scheduled tasks that apply to systems and users within the GPO scope. GPO permissions should be reviewed carefully, especially for policies linked to domain controllers or broad organizational units.

Risky GPO login script permissions occur when low-privileged users, such as Authenticated Users or Everyone, have the ability to modify login scripts. This misconfiguration can allow attackers to insert or alter scripts that execute during user logins, potentially leading to remote code execution and persistence.

One or more schema version 1 certificate templates allow the enrollee to supply the subject and are enrollable by low-privileged users. Schema v1 templates let the requester add arbitrary application policies (extended key usages) to the request regardless of the template's configured EKUs. An attacker can request a certificate from such a template and inject a client-authentication or certificate-request-agent policy, then use it to authenticate or to enroll on behalf of others.

A certificate authority's RPC enrollment interface does not require packet encryption (the IF_ENFORCEENCRYPTICERTREQUEST flag is not set). An attacker who can relay NTLM authentication can relay a victim machine or user to the CA over the RPC certificate-request interface and obtain a certificate as that victim, similar to ESC8 but over RPC instead of web enrollment.

Unencrypted Certificate Enrollment occurs when the certificate enrollment interface is accessible over HTTP instead of HTTPS. This exposes sensitive data, including certificate requests, to potential interception by attackers.

One or more PKI objects grant a non-default principal dangerous control (full control, write, write-permissions, or take-ownership). The affected objects include certificate authority objects and the Public Key Services containers, including NTAuthCertificates and the Certification Authorities store. Control over these objects lets an attacker alter the PKI itself, for example by publishing a rogue CA certificate into NTAuthCertificates so that certificates it issues are trusted for domain authentication.

One or more privileged objects allow non-standard principals to modify the altSecurityIdentities attribute. This attribute can define explicit certificate mappings for account authentication. Unauthorized write access may allow an attacker to map a certificate they control to a privileged account and authenticate as that account.

One or more domain controllers do not enforce strong certificate mapping. Either Kerberos strong certificate binding is disabled (StrongCertificateBindingEnforcement = 0) or Schannel is configured for weak UPN-based certificate mapping (CertificateMappingMethods includes the 0x4 bit). When mapping is weak, a certificate is matched to an account by name rather than by the account SID, so an attacker who can obtain a certificate carrying a victim's name, or who can edit a name attribute, can authenticate as that victim.

The WebClient (WebDAV) service is running or configured to start on one or more domain controllers. This service is generally not required on domain controllers and can increase exposure to authentication coercion and relay scenarios. WebClient should be disabled on domain controllers unless a clear business requirement exists.

Outdated and insecure encryption algorithms, such as DES (Data Encryption Standard) and RC4, are still supported within the domain. These algorithms are vulnerable to cryptographic attacks, allowing attackers to exploit weaknesses in Kerberos authentication or intercept and decrypt sensitive data. Modern cryptographic standards should be used to prevent such vulnerabilities.

Hardened UNC paths are not enforced for SYSVOL and NETLOGON through Group Policy. Without these protections, clients may be more exposed to tampering or interception when retrieving Group Policy and logon script content from domain controllers. Hardened UNC path settings should require mutual authentication and integrity for these critical shares.

When LDAP signing is not enforced, attackers can intercept and manipulate unprotected LDAP traffic, potentially escalating privileges or harvesting credentials. Without signing, LDAP communications between clients and domain controllers lack integrity verification, making them vulnerable to man-in-the-middle (MitM) attacks. This weakness allows adversaries to modify authentication exchanges or inject malicious requests.

When WSUS certificate pinning is disabled, the integrity of WSUS updates can be compromised, even if HTTPS is used. Attackers or proxies could intercept WSUS traffic, sign responses with their own certificates, and potentially inject malicious updates. Certificate pinning ensures that only trusted certificates from the WSUS server are accepted, preventing such attacks.

When WSUS (Windows Server Update Services) is configured to allow user proxies, unprivileged users may route update traffic through their own proxy settings, potentially exposing update requests to interception or manipulation. While modern updates restrict this behavior by default, certain Group Policy settings, such as SetProxyBehaviorForUpdateDetection, can re-enable user proxy usage. This misconfiguration could allow attackers to redirect or tamper with update traffic, leading to security bypasses or the injection of malicious updates.

When WSUS is configured to use HTTP instead of HTTPS, update communications are vulnerable to interception and manipulation by attackers. Specialized toolsets exist that can exploit HTTP traffic to inject malicious updates, allowing attackers to compromise multiple systems across the network.

A WSUS server using weak SSL protocols such as SSLv2 or SSLv3 poses a security risk, as these outdated protocols are vulnerable to cryptographic attacks. Attackers can exploit these weaknesses to intercept and tamper with update communications between the WSUS server and client machines, potentially injecting malicious updates.

Custom AD Display Specifiers allow administrators to modify the interface and actions available in Active Directory administrative tools, like the right-click menus in AD Users and Computers. If improperly secured, attackers can manipulate the adminContextMenu attribute to introduce malicious scripts or commands, which can be executed with elevated privileges when clicked by an administrator. This presents a risk of unauthorized code execution within the domain.

One or more fine-grained password policies (Password Settings Objects) are not being applied because their msDS-PSOAppliesTo attribute is empty. As a result, the stronger password requirements defined in the policy do not take effect, and intended accounts may fall back to the default domain password policy.

Insufficient Domain Controller logging weakens the ability to detect, investigate, and respond to attacks on Active Directory. Without comprehensive logging, critical events, such as unauthorized access attempts or changes to privileged accounts, may go unnoticed, leaving the domain vulnerable to compromise. Furthermore, domain controller logs are essential for post-incident analysis, helping to assess the scope of a compromise and informing remediation efforts.

When net session enumeration is allowed, any authenticated user is able to enumerate network sessions on Windows systems, including Domain Controllers. This can expose critical information, such as where administrative accounts are logged in, which attackers can leverage to map the network and target credentials using tools like BloodHound.

Certificates should not use outdated or insufficiently strong encryption algorithms, such as RSA keys under 2048 bits. Certificates with weak encryption can be exploited by attackers, compromising the security of the systems that rely on them. RSA keys below 1024 bits are especially vulnerable.

The use of weak hashing algorithms, such as MD2, MD4, or MD5, exposes systems to security risks, as these outdated algorithms have vulnerabilities that allow attackers to generate hash collisions more easily than with brute-force methods. This compromises the integrity of the system, making it easier for attackers to impersonate or tamper with data.

Enabling PowerShell logging offers comprehensive insights into executed commands, the parameters used, and their execution context. This level of detail is critical for detecting malicious actions like security control bypasses, privilege escalations, and data exfiltration. Additionally, PowerShell logs are often essential for post-incident analysis, aiding in understanding the scope of a compromise and guiding appropriate remediation efforts.

A recognized synchronization account can change membership or exercise administrative control over a Tier 0 or otherwise privileged group. Relevant rights include WriteProperty on member, GenericWrite, GenericAll, WriteDACL, WriteOwner, and group creation or deletion within a privileged scope.

A recognized synchronization account can reset passwords or modify password-related attributes on Tier 0, AdminSDHolder-protected, or other privileged accounts. This may result from password writeback permissions being scoped too broadly or intentionally extended to protected accounts.

A recognized synchronization principal, or a principal that can control it, has a direct or indirect Active Directory permission path to a Tier 0 object. Paths may include password reset, group modification, ownership, DACL modification, delegation, object creation, or control of another intermediary principal.

The Password Replication Policy associated with AzureADKerberos permits one or more privileged or Tier 0 identities to use Microsoft Entra cloud Kerberos trust. Microsoft’s default policy blocks high-privilege accounts because relaxing it can create an attack path from Microsoft Entra ID to on-premises Active Directory.

The AzureADKerberos computer object is configured for unconstrained, constrained, or resource-based constrained Kerberos delegation. These settings are not expected for a standard Microsoft Entra cloud Kerberos trust deployment.

The AZUREADSSOACC$ computer account is configured for unconstrained or constrained Kerberos delegation. Resource-based constrained delegation is evaluated separately. Microsoft recommends disabling Kerberos delegation on this account.

A non-Tier 0 principal can control a recognized synchronization account through password reset, GenericAll, GenericWrite, WriteDACL, WriteOwner, or another sensitive object right.

A recognized Microsoft Entra synchronization account is directly or transitively privileged in Active Directory. The account is a member of a Tier 0 or built-in administrative group, or otherwise receives administrative authority through nested group membership.

Resource-based constrained delegation is configured on the AZUREADSSOACC$ computer account through msDS-AllowedToActOnBehalfOfOtherIdentity. Microsoft Entra seamless single sign-on does not require this configuration.

A stale password for the AzureAD SSO account (AZUREADSSOACC) poses a significant security risk, as this account is critical for converting Kerberos tickets into SAML tokens for Azure AD single sign-on. If the password is not rotated regularly, attackers could extract it and use it to impersonate users, potentially compromising the entire Azure AD environment.

A recognized synchronization account has privileged group membership or broad Active Directory rights that can affect objects beyond its expected synchronization scope. This check evaluates group membership and effective permissions visible in Active Directory, including Full Control, GenericWrite, WriteDACL, WriteOwner, password reset, group membership modification, and object creation or deletion rights.

A recognized synchronization account has directory replication rights on a domain naming context. These rights can be expected when Password Hash Synchronization is used, but Active Directory alone cannot confirm whether that feature is currently enabled. The finding identifies the DCSync-capable account and its scope for validation.

A recognized synchronization account has elevated permissions over AdminSDHolder or one or more AdminSDHolder-protected objects. These permissions may allow password resets, group changes, ACL modification, ownership changes, or other control of protected administrative identities.

A principal outside the approved Tier 0 boundary can control the AzureADKerberos computer object or associated Kerberos trust objects used by Microsoft Entra cloud Kerberos trust. Risky rights include password reset, GenericAll, GenericWrite, WriteDACL, WriteOwner, delegation modification, and changes to password replication policy.

A principal outside the approved Tier 0 administrative boundary can control AZUREADSSOACC$. Risky rights include password reset, GenericAll, GenericWrite, WriteDACL, WriteOwner, SPN modification, delegation modification, and writes to Kerberos encryption settings.

A recognized synchronization account can participate in Kerberos delegation because it is not protected from delegation or has unconstrained, constrained, or resource-based constrained delegation configured.

The owner of AZUREADSSOACC$ is not an approved Tier 0 or built-in system principal. An object owner can typically modify the object’s permissions, even when no explicit administrative ACE is present.

A disabled recognized synchronization account still has privileged group membership, replication rights, password reset rights, group modification rights, or other sensitive permissions in Active Directory.

The AZUREADSSOACC$ computer account is not marked as sensitive and cannot be delegated. This protection reduces the chance that credentials or authentication context associated with the account can be forwarded through Kerberos delegation.

The AZUREADSSOACC$ computer account used by Microsoft Entra seamless single sign-on permits RC4 or DES Kerberos encryption. Microsoft recommends moving this account to AES-based encryption and rotating its Kerberos decryption key as part of the change.

One or more enabled accounts match known Microsoft Entra synchronization account patterns but appear stale or no longer required. This check uses on-premises indicators such as account status, password age, logon activity, naming patterns, group membership, and retained directory permissions. Because the active connector configuration is not available from Active Directory alone, the finding identifies a likely orphan that requires ownership validation.

Multiple enabled accounts match recognized Microsoft Entra synchronization account patterns. Multiple accounts can be valid for separate connectors, forests, staging designs, or Cloud Sync agents, so the finding identifies an inventory condition that requires ownership validation rather than proving misconfiguration.

More than one active-directory computer object matches the AZUREADSSOACC$ name or recognized Microsoft Entra Seamless SSO account pattern within the evaluated forest. One account per synchronized forest is expected, so duplicates may indicate an incomplete migration, abandoned configuration, or naming collision.

A recognized synchronization account has a stale password. Password age alone does not prove the account is unused or insecure, and some Microsoft Entra Connect account types are managed differently. The finding is intended to trigger ownership and lifecycle review.

AZUREADSSOACC$ has service principal names that are not expected for the organization’s Microsoft Entra Seamless SSO deployment. Unexpected SPNs can redirect Kerberos service authentication or indicate that the account is being used for an unrelated service.