Active Directory has been the backbone of on-premises Windows environments for more than two decades. That longevity is part of what makes it a persistent security problem. AD configurations set during a 2009 domain build are still running in 2026. Service accounts created for applications that no longer exist are still active and often over-privileged. Password policies configured before the concept of password spraying was well-understood remain in effect. Group memberships accumulated through years of “just add them to Domain Admins for now” decisions have never been audited.
The misconfigurations in this article are not hypothetical. They are the findings that appear consistently in AD security assessments across regulated SMB environments — healthcare practices, defense subcontractors, financial services firms — regardless of how well-managed the environment appears on the surface. Many of the organizations where these findings show up have managed IT support. The problem is not that nobody is paying attention. It is that AD security assessment is not the same as AD administration, and most managed services engagements cover the latter without ever touching the former.
This article covers what to look for, why each finding matters in terms of business risk and compliance, and how to frame the findings for clients who are not security practitioners.
Category 1: Privileged Account Exposure
Domain Admins is the highest-privilege group in an Active Directory domain. Members of Domain Admins have unrestricted access to every system in the domain — they can read any file, access any user’s mailbox, extract credentials from domain controllers, and disable any security control. In most regulated SMB environments, this group has more members than it should, and those members have more regular daily-use access than the security model intends.
Over-populated Domain Admins. The consistent finding: organizations that have grown over years tend to have accumulated Domain Admin memberships that made sense at the time they were added and were never removed. A technician who needed domain admin access for a server migration three years ago is still a Domain Admin. A service account for a backup product that supports domain admin elevation was never scoped down. A vendor account added during a deployment is still active. None of these are malicious decisions — they are the natural result of adding without auditing.
The remediation principle for Domain Admins is straightforward: the group should contain only the minimum number of accounts needed for domain-level administration, those accounts should not be used for daily work tasks, and every member should have a documented business justification that is reviewed at least quarterly. Two to four accounts in most SMB environments is the right order of magnitude. Ten or more is consistently a finding.
Accounts with non-expiring passwords in privileged groups. Service accounts and historical user accounts configured with “Password never expires” are a durable finding in almost every domain. For service accounts with functional dependencies, this is often a legitimate operational constraint — changing the password breaks the service and requires coordinated maintenance. The security problem is not the non-expiring password itself but the combination of a non-expiring password, a high-privilege account, and no monitoring of that account’s activity. An account whose password has not changed in six years and who is a member of Domain Admins is a significant exposure if that credential was ever compromised in a breach that went undetected.
Admin accounts used for daily computing tasks. In smaller environments, it is common for the domain administrator to perform their daily work — email, browsing, document creation — using their administrative account rather than a separate standard user account. This means administrative credentials are in use for hours every day, exposed to phishing, web-based drive-by attacks, and credential capture in ways that a properly scoped admin account used only for administrative tasks would not be.
Category 2: Password Policy and Credential Weaknesses
Default domain password policies in Active Directory were designed for an era before password spraying was a primary attack technique. The NIST guidance on password policy has evolved significantly since most of these defaults were set, and many environments have not caught up.
Weak or legacy default domain password policies. Many SMB environments still run with the Windows Server default password policy: eight-character minimum, complexity enabled, 42-day expiration. NIST SP 800-63B guidance — which both CMMC and HIPAA assessors reference — has moved significantly away from mandatory rotation and toward length-based requirements, breach-based checking, and elimination of complexity requirements in favor of passphrases. An environment still running the 2003-era defaults is not aligned with current NIST guidance, which is a compliance gap for clients under CMMC or HIPAA.
Kerberoastable service accounts. Service accounts configured with Service Principal Names and weak or non-rotated passwords are targets for Kerberoasting — an attack technique where an authenticated domain user requests Kerberos service tickets and attempts to crack them offline. The attack requires no special privileges to initiate and leaves minimal traces in default logging configurations. The finding is common because service accounts with SPNs are routinely created without managed passwords or Group Managed Service Accounts, and password rotation for service accounts is painful enough that it often does not happen at all.
The remediation approach is to migrate service accounts to Group Managed Service Accounts where the service supports it — gMSAs handle password rotation automatically at a configured interval without requiring manual coordination. For services that cannot use gMSAs, a documented password rotation schedule with PSA tickets is better than no rotation at all.
Accounts with passwords that match known-compromised credential databases. Password auditing against breach databases is one of the most operationally useful assessments for regulated clients and one of the least commonly performed. An account whose password matches a credential from a known breach dataset — even if the breach was from a completely unrelated service — is an active risk: password reuse across personal and corporate accounts is consistent across user populations regardless of how many security awareness trainings have been delivered. For clients under CMMC or HIPAA, a documented process for detecting and remediating compromised credentials is both a security control and a compliance evidence item.
Category 3: Stale and Unmanaged Objects
Active Directory accumulates objects over time. User accounts for employees who left. Computer accounts for systems that were decommissioned. Groups that were created for a project and are now empty or redundant. Organizational Units that have not been touched in years. None of these are inherently dangerous in isolation, but they represent unmonitored attack surface and compliance evidence gaps.
Stale user accounts. An enabled user account in Active Directory for a former employee is not merely a housekeeping issue. It is an active credential that can be used to authenticate to domain resources if the password is known or guessable. For healthcare clients, a former employee’s active AD account with access to systems that touch ePHI is a HIPAA violation waiting to be discovered. For CMMC-obligated clients, stale accounts that could access CUI systems are a direct control gap under Access Control practice AC.L2-3.1.1, which requires organizations to limit system access to authorized users. A former employee is not an authorized user. The account should be disabled immediately on separation and deleted after a defined retention period.
Stale computer accounts. Computer accounts for systems that have been decommissioned or replaced remain in the domain and in whatever groups they were members of at decommission. If a computer account is in a group that grants access to shares, databases, or services, removing the physical machine from the network does not revoke those group memberships. A computer account that has not authenticated to the domain in 90 days is a reliable indicator of a stale object. The standard assessment threshold is 90 days of no sign-in; anything beyond that should be disabled and reviewed before deletion.
Dormant service accounts with broad permissions. Service accounts are created for specific applications and often granted permissions that made sense for the application’s deployment at the time. When the application is retired, upgraded, or replaced, the service account persists — sometimes for years — with its original permissions intact. These accounts are attractive targets because they typically have non-expiring passwords, are not monitored for interactive logon attempts, and often hold permissions to file shares, databases, or network services that go well beyond what any active application would require.
Category 4: Delegation and Trust Misconfigurations
Kerberos delegation settings and domain trust relationships are among the most technically complex areas of Active Directory security and among the most frequently overlooked in MSP-managed environments. They are also among the most consequential when misconfigured, because misconfigured delegation can allow a compromised service account to impersonate any user in the domain — including Domain Admins.
Unconstrained Kerberos delegation. Unconstrained delegation allows a service account to impersonate any user who authenticates to the service — storing the user’s Kerberos ticket in memory in a form that can be reused to access any resource in the domain on that user’s behalf. This was a necessary feature for certain application architectures in older Windows deployments, but it should be limited to service accounts where no constrained alternative exists, and those accounts should be in Tier 0 (domain controller equivalent) protection scope. In practice, unconstrained delegation is frequently found on service accounts for applications that have not needed it for years, or that were configured with unconstrained delegation because it was easier than configuring constrained delegation correctly.
Accounts sensitive to delegation not protected. Highly privileged accounts — Domain Admins, Enterprise Admins, account operators — should be flagged as “Account is sensitive and cannot be delegated” in Active Directory. This prevents their Kerberos tickets from being delegated through unconstrained or constrained delegation scenarios. It is a single checkbox per account in Active Directory Users and Computers, and it is consistently not checked for privileged accounts in environments that have not had an AD security review.
Misconfigured or legacy domain trusts. Domain trusts that were set up for specific business purposes and never reviewed accumulate SID history, transitivity, and authentication scope that may not reflect the current organizational relationship. A forest trust established for an acquisition that was subsequently divested may still be active. A domain trust configured for a development environment may allow authentication across the trust boundary in ways that the production environment was not designed to support.
Category 5: Attack Path Exposure
Individual misconfigurations are concerning in isolation. Attack paths are concerning in a different way — they represent chains of individually modest misconfigurations that, when combined, allow a threat actor to escalate from a low-privilege starting position to domain-level control. Attack path analysis is the assessment discipline that identifies these chains before an attacker does.
The most common attack paths in SMB Active Directory environments follow predictable patterns: a standard user account that is a local administrator on a workstation where a privileged user has recently logged in; a service account with write permissions on a group policy object that applies to domain controllers; a helpdesk account that has password reset permissions on accounts in privileged groups. Each link in the chain looks manageable in isolation. The chain, end to end, represents a path from a phishing victim’s account to domain compromise.
The practical implication for MSPs is that AD security assessment cannot be limited to reviewing each misconfiguration category in isolation. A finding that appears low-risk by itself may be the critical link in an attack path that reaches a domain controller. Identifying those paths requires either attack path analysis tooling or enough AD expertise to trace the permission relationships manually — neither of which is typically part of a standard managed services scope.
Multi-step attack path analysis — which maps how an attacker could chain together multiple lower-level findings to reach domain-level control — is one of the most operationally useful outputs an AD security assessment can produce for a client conversation. It translates a list of technical findings into a narrative about actual risk: not “you have seventeen accounts with non-expiring passwords” but “if a user in accounting is phished, an attacker can reach your domain controller in three steps using existing configuration weaknesses.” That is a risk story that drives remediation decisions.
→ The SentinelBaseline Platform includes AD security assessment at weekly cadence in the Baseline+ tier and daily cadence in Supreme, with daily multi-step attack path analysis and monthly AD password auditing against breach databases at the Supreme tier.
How to Turn Technical AD Findings Into a Client-Readable Risk Story
The gap between a technically accurate AD security assessment and a client conversation that results in remediation is the translation layer. Most clients cannot evaluate whether “twelve accounts have Kerberoastable SPNs with passwords older than two years” is a serious problem or a minor configuration item. What they can evaluate is whether the consequence of that finding is business-relevant.
The translation framework that works consistently has three components: the finding stated plainly, the path from that finding to business impact, and the remediation framed in practical terms.
For privileged account findings: “Fourteen accounts have full administrative access to every system in your domain. Six of those accounts belong to people who left the company more than a year ago. If any of those accounts is used by someone with the former employee’s credentials — whether from a data breach, a shared password, or a guessed password — they would have complete control of your entire network infrastructure. Removing those accounts is a half-day of work and closes a significant exposure.”
For password policy findings: “Your password policy requires passwords to be changed every 42 days, but it allows eight-character passwords that meet a complexity requirement. In practice, most users respond to frequent rotation by using predictable patterns — ‘Spring2024!’ becomes ‘Summer2024!’ becomes ‘Fall2024!’ — which automated password-guessing tools are specifically designed to anticipate. We recommend moving to a longer-minimum passphrase requirement with breach-based checking instead of calendar-based rotation. This is more secure and less annoying for users.”
For attack path findings: “If any user in your accounting department clicks a phishing link and their computer is compromised, an attacker could reach your domain controller — the system that controls access to everything on your network — in three steps using configuration weaknesses that already exist. We have mapped those steps and identified the specific changes that would break that path. None of them require new technology; they require three configuration changes that we can make in a scheduled maintenance window.”
The principle across all three: state the finding in concrete terms, connect it to a business consequence the client can visualize, and frame the remediation as something specific and achievable. The goal of the client conversation is not to demonstrate technical depth — it is to get the remediation on the calendar. Platform tooling that generates one-click PSA tickets from findings, with AI-assisted prioritization of what to address first, shortens the path from “here is what we found” to “here is what we are going to fix and when.” The remediation delivery stays with your team; the revenue from that remediation work is billed against your standard rate.
→ Why Sentinel covers the workflow model in detail — one-click PSA ticket generation, MSP-owned remediation, and how the platform identifies and prioritizes findings without auto-patching, preserving the billable remediation relationship with your client.
AD Security Assessment Checklist for MSPs
Use this before an onsite review, a new client onboarding, or a quarterly security check-in. Each item should have a clear owner and a documented status — not “we will look at this” but “here is the current state and here is what needs to change.”
Privileged accounts and groups
- Domain Admins membership reviewed — count justified, no stale or service account members
- Enterprise Admins and Schema Admins groups contain only expected accounts (typically empty except during specific tasks)
- All privileged accounts are flagged as “Account is sensitive and cannot be delegated”
- No privileged accounts used for daily computing tasks — admin accounts are separate from standard user accounts
- Built-in Administrator account is renamed, disabled, or has a complex non-guessable password and is monitored for logon activity
Password policy and credential hygiene
- Default domain password policy meets current NIST SP 800-63B baseline (minimum 12 characters, breach-checking preferred over calendar rotation)
- Fine-grained password policies applied to privileged accounts with stricter requirements
- Service accounts with SPNs use Group Managed Service Accounts or have a documented rotation schedule
- AD password audit run against known breach credential databases in the past six months
- Accounts with “Password never expires” reviewed — each has a documented business justification
Stale and unmanaged objects
- User accounts with no logon in the past 90 days reviewed — disabled or documented as intentional
- Computer accounts with no logon in the past 90 days reviewed — disabled or deleted
- Service accounts associated with decommissioned applications identified and disabled
- Empty or redundant security groups reviewed and removed where no longer needed
- Off-boarding process documented — AD account disable and group membership removal on employee separation
Delegation and trust configuration
- Unconstrained Kerberos delegation is not enabled on any accounts other than domain controllers
- Constrained delegation accounts reviewed — delegation scope is limited to required services
- All active domain trusts are documented with a business justification and reviewed in the past year
- SID filtering enabled on external and forest trusts where applicable
Audit logging and monitoring
- Domain controller audit policy logs account logon, account management, logon/logoff, privilege use, and policy change events
- Security event logs forwarded to a SIEM or retained beyond the default 20MB/overwrite threshold
- Alerts configured for Domain Admin logons outside of expected maintenance windows
- Failed logon attempts monitored for patterns consistent with password spraying
If you want to see how the platform’s AD security assessment, password auditing, and attack path analysis integrate with your PSA and remediation workflow — and how to structure this as a recurring, billable service for your on-prem client base — book a 30-minute demo.
Frequently Asked Questions
How often should an Active Directory security assessment be conducted?
At minimum, quarterly — aligned to the QBR cycle so findings drive client conversations rather than sitting in a report. For clients with higher risk profiles or more dynamic environments (frequent staff changes, active M&A, complex service account inventories), monthly or weekly automated AD assessment is more appropriate. The distinction between a one-time assessment and ongoing assessment matters for compliance: CMMC AU practices require continuous monitoring, not point-in-time snapshots. A quarterly manual review combined with weekly automated AD security assessment covers both the structured review cadence and the drift detection in between.
What permissions does an MSP need to run an AD security assessment?
Reading most of the configuration areas in this article requires Domain Users access or a read-only security reader role — you do not need Domain Admin to assess most AD security settings. LDAP queries against the domain controller return the object attributes needed for stale account analysis, delegation configuration, group membership, and password policy settings. Attack path analysis requires permission to enumerate the same attributes. Remediation actions — modifying group memberships, changing delegation settings, disabling accounts — require appropriate write permissions and should follow your change management process with client awareness. Assessment and remediation are separate activities with different permission requirements.
How does on-premises AD assessment relate to Entra ID security review for hybrid environments?
Most regulated SMBs running on-premises Active Directory also have Microsoft 365 and Entra ID, making them hybrid environments where the on-premises domain synchronizes to the cloud tenant via Entra Connect. In hybrid environments, misconfigurations in on-premises AD can propagate to Entra ID — a stale on-premises account with a synchronized cloud identity retains cloud access even if the on-premises account is not directly used. Password hash synchronization means that a compromised on-premises credential may also compromise the cloud identity. The two assessments are complementary, not redundant — on-premises AD assessment and Entra ID security review should both run on a regular cadence for hybrid clients, not alternate with each other.
What compliance frameworks require Active Directory controls to be reviewed?
CMMC Level 2 has the most direct mapping — Access Control (AC), Identification and Authentication (IA), and Audit and Accountability (AU) practices all have specific requirements that on-premises AD controls satisfy or fail to satisfy. The privileged account review maps to AC.L2-3.1.5 (least privilege), stale account removal maps to AC.L2-3.1.1 (authorized users only), and password auditing maps to IA.L2-3.5.7 and 3.5.8. HIPAA maps through the Access Control (§164.312(a)) and Audit Controls (§164.312(b)) Technical Safeguards. NIST CSF 2.0 maps through the Govern and Protect function categories. SOC 2 maps through the Logical Access Controls criteria (CC6.1 through CC6.7). In every case, the AD assessment findings are directly relevant compliance evidence, not optional housekeeping.
Can clients fix these issues without taking systems offline?
Most of the remediation actions in this article do not require downtime. Removing accounts from Domain Admins, disabling stale accounts, flagging privileged accounts as sensitive to delegation, updating password policies — these are configuration changes that take effect without service interruption. The exceptions are changes that affect running services: modifying a service account password or transitioning to a gMSA requires coordination with the dependent service and typically a brief restart of that service. Attack path remediation that involves Group Policy Object changes or Kerberos delegation modifications should be tested in a change window, though they do not typically require domain-wide downtime. The path from assessment to remediation is shorter than most clients expect — which is part of what makes the client conversation about findings easier to have when you can follow it immediately with a realistic timeline.