Essential Active Directory Checks Before Launching Any Penetration Test

Internal penetration tests are easily compromised in the first minutes. Spotting a familiar technique and launching a tool without context can produce log noise, affect services, or yield results that cannot be explained to the client. With Active Directory this problem is especially visible because the domain links users, servers, authentication, and access rights. The approach of “check first, understand later” rarely produces good outcomes.

Before any active testing, a sufficient picture of the environment must be assembled. The goal is not a perfect map but enough understanding to know what is being examined, which risk is being validated, and what may change after an action.

Defining scope and rules of engagement

The phrase “test Active Directory” conveys almost nothing by itself. The scope must clarify whether one or multiple domains are included, whether domain controllers may be contacted, whether scanning is permitted, which service accounts must remain untouched, and who on the client side must be notified of critical findings on the day of discovery.

A working document should record allowed network segments, prohibited actions, escalation paths for critical findings, and the method for logging results. This prevents on-the-fly decisions about touching a particular service or testing a chosen hypothesis.

Inventory before exploitation

After boundaries are agreed, the composition of the assessment area must be determined: how many domains are reachable, where the domain controllers reside, which servers rely on domain authentication, and whether separate segments or trust relationships exist. The resulting map helps separate important objects from background noise. Ordinary user accounts, service accounts, and domain administrators may appear similar in an export, yet the consequences of compromising each are very different.

During inventory, objects that warrant closer attention become visible. A service account cannot be assessed by name alone; its purpose, Service Principal Name settings, rights, and connected systems must be understood before any test begins.

Account roles and Kerberos pre-authentication

Technical objects in Active Directory must be classified by purpose: user accounts, service accounts, privileged accounts, and integration accounts. Accounts with Kerberos pre-authentication disabled should be identified because they are susceptible to AS-REP Roasting. The same disciplined approach applies to NTLM traffic and relay opportunities.

Kerberos ticket-granting mechanisms, DACL permissions, and delegation rights must be examined together. An error in object permissions can form the first link in a privilege-escalation chain even when the account is not a member of an obvious administrative group.

Certificate services and network context

AD CS infrastructure is frequently overlooked until late in an assessment. Testers need to identify who manages certificate templates, how certificates are issued, and which rights are tied to the issuance process. The same sequence applies: configuration first, then hypothesis, then safe validation.

Finally, the engagement format must be aligned with the client. A standard internal pentest seeks to confirm vulnerabilities, while a Red Team exercise also measures detection speed and log visibility. Every action must be logged with timestamp, target object, account used, hypothesis tested, and result obtained so that findings remain reproducible and rollback procedures can be verified.