Audit Active Directory in Air-Gapped Environments

How to Audit Active Directory in an Air-Gapped Environment Without False Confidence

If you need to know how to audit Active Directory in an air-gapped environment, start with a scoping question, not a tooling question. Many teams say "air-gapped" when they actually mean "no direct Internet access," "logically isolated," or "tightly segmented." That distinction matters because your audit method, your evidence chain, and your acceptable controls change with the actual connectivity model.

CISA's implementation guidance for BOD 23-01 makes the boundary explicit: many environments that are described as air-gapped are only logically isolated, and any system that is directly connected to the operating environment, or connected to another system that is connected to that environment, is not treated as physically air-gapped for that guidance. For an Active Directory audit, that is a useful operational rule: do not assume isolation just because a network has no direct web browsing path.

This article uses practical audit terms rather than claiming a universal vendor taxonomy:

Isolation model	Practical meaning for an AD audit	Audit consequence
No Internet	The environment has no direct outbound Internet access, but local internal routing still exists.	A local audit is straightforward, but cloud-managed workflows may not be usable.
Logically isolated	Access is restricted through gateways, jump hosts, brokers, or controlled transfer paths.	Scoping and evidence transfer matter as much as the audit itself.
Segmented	The environment is routable but constrained by firewalls, VLANs, or ACLs.	Treat it as connected for privilege and protocol risk.
Physically air-gapped	No network path exists to the Internet or to the broader operating environment.	Collection, review, and export all need a fully local workflow.

The point is not semantics. The point is to avoid false confidence. An isolated AD forest can still have privilege drift, unsafe delegation, weak protocol settings, stale privileged accounts, writable GPO paths, exposed certificate templates, or weak audit policy. If the directory changes, it still needs to be measured.

Why Isolation Does Not Remove AD Risk

Isolation reduces some external attack paths, but it does not remove identity risk inside the boundary you still have to defend. Active Directory continues to hold privileged groups, Kerberos settings, trust relationships, delegation, ACLs, Group Policy, and often certificate services. Those control planes remain security-critical even if the environment never touches a public SaaS service.

That is why an isolated environment still needs the same core review discipline described in How to Audit Active Directory Security: Practical Checklist for Internal Teams. Privileged groups still accumulate exceptions, old service accounts still survive migrations, and directory permissions still drift between one cleanup and the next. If you already run periodic reviews, the same lesson from Recurring AD Audit Workflow: Why Annual Audits Drift and How Continuous Posture Monitoring Works applies even more strongly in isolated networks: a one-time cleanup does not stay correct on its own.

ANSSI's 2023 guidance for administering systems that rely on Active Directory is useful here because it does not treat AD as a static directory. It treats it as an administration plane that must be compartmentalized, monitored, and governed with discipline. In practice, that means an air-gapped or isolated AD should still be assessed as a live control plane, not as a legacy island that is somehow safer because it is harder to reach from the Internet.

What You Can Audit Without Internet Access

A well-scoped offline review can cover most of the control surface that actually matters in an AD environment:

Identity and privilege structure: privileged groups, nested groups, delegated rights, DCSync-capable principals, stale administrators, service accounts, and ownership anomalies.
Directory security settings: LDAP signing, channel binding, NTLM exposure, SMB signing, SMBv1, cached logons, Kerberos policy, LAPS deployment, and trust configuration.
Group Policy and SYSVOL integrity: GPO links, security filtering, permission inheritance, password exposure in SYSVOL, and hardened UNC path settings.
Change visibility: whether the audit policy, event forwarding design, and log retention model are actually sufficient to detect critical AD changes locally.
AD CS, if present: CA role exposure, certificate template risk, enrollment surfaces, and strong certificate binding issues.

This is why offline AD auditing is not only possible; it is often more grounded than teams expect. Microsoft documents that AD data is accessible through directory protocols and that Group Policy is split between directory metadata and file-based content in SYSVOL. That means a serious offline audit is not limited to screenshots or point-in-time administrator interviews. It can collect evidence directly from the directory and its associated file shares.

Data Sources to Collect Locally

The most reliable offline audit uses multiple local data sources because no single source answers every question.

Data source	What it tells you	Why it matters offline
LDAP or LDAPS	Users, groups, computers, ACL-relevant attributes, delegation settings, trusts, password and Kerberos policy, certificate template metadata	Core inventory and misconfiguration analysis come from the directory itself.
SYSVOL over SMB	GPO files, scripts, policy settings, preference artifacts, replication consistency clues	GPO security cannot be reviewed correctly from LDAP alone.
Security event logs	Directory changes, audit policy changes, object access, privileged logons, group membership changes	You need local evidence for drift and post-remediation validation.
WEF/WEC topology, if used	Whether events are actually centralized inside the isolated boundary	Local collection design matters when there is no cloud SIEM path.
CA and certificate logs, if AD CS exists	Enrollment, template activity, issuance events, and role exposure	Certificate abuse remains relevant inside isolated Windows estates.
Snapshot metadata	Audit date, DC scope, excluded domains, unreachable hosts, permissions used	Without this, reruns are difficult to compare and findings are hard to defend.

Two details are easy to miss.

First, Microsoft's Group Policy documentation matters because every GPO has both directory data and a file system component in SYSVOL. If you only query LDAP, you miss part of the policy surface. That is one reason offline audits frequently understate risk around scripts, preference files, or policy path integrity.

Second, use LDAPS rather than assuming plain LDAP is acceptable because the environment is internal. The current EtcSec collector documentation is explicit on this point in standalone mode: ldaps:// is the supported and recommended path for AD collection, while unencrypted LDAP is not the supported baseline for production use.

Building a Safe Offline Audit Workflow

A defensible offline workflow is mostly about repeatability.

1. Define the exact trust boundary

Record whether the environment is physically air-gapped, logically isolated, or simply disconnected from the public Internet. If data export is possible through a jump host, broker, or manual transfer process, write that down. The audit report should explain the connectivity model because the review assumptions depend on it.

2. Collect from a trusted local host

Run the audit engine from a host inside the same trust boundary as the directory you are reviewing. Avoid ad hoc administrator laptops. Use a dedicated review host when possible, and keep the collector configuration and output under change control.

3. Collect directory and SYSVOL evidence together

Do not split identity review from GPO review. In isolated AD, some of the most operationally dangerous drift lives in the relationship between directory objects and file-backed policy content. That is why articles like NTLM Relay Attacks: Hijacking Authentication in AD and SMB Signing Disabled: Why It Still Enables NTLM Relay still matter in "offline" estates: the underlying protocol and file-path exposure is local, not Internet-dependent.

4. Preserve a comparable snapshot

Store the audit date, the set of domain controllers reached, whether all expected domains were included, and whether AD CS or trusts were in scope. A report without collection context is hard to compare later. If you want remediations to hold, you need a clean before-and-after baseline rather than a single exported PDF with no collection metadata.

5. Re-measure after cleanup

Once findings are fixed, rerun the same scope and compare the same evidence classes. That is the only reliable way to prove that privilege drift, protocol hardening, or policy cleanup really held after the change window.

Event Logging and Detection in Isolated AD

Offline does not mean invisible. It means your visibility has to be designed locally.

Microsoft's Windows Event Forwarding guidance is useful here because it states what WEF actually does and what it does not do. WEF can forward events from sources to a collector, but it is passive with respect to event generation. It does not enable the right audit subcategories for you, and it does not resize logs for you. If the domain controllers are not logging the right events, a local Windows Event Collector will simply centralize incomplete evidence faster.

That is why advanced audit policy configuration has to be part of the review itself. Microsoft also recommends planning and pilot validation before broad deployment because the real questions are event volume, operational usefulness, and whether teams can understand the events they are collecting.

For an isolated AD review, start with a narrow local detection baseline:

Goal	Local evidence to verify
Audit policy integrity	Audit policy changes such as Event ID 4719 and proof that critical subcategories are enabled on DCs
Directory change visibility	Directory Service Changes coverage, including Event ID 5136 where appropriate
Sensitive object access	Object access auditing such as Event ID 4662 where it is intentionally configured for high-value objects
Privileged change tracking	Group membership changes, admin account use, and privileged logon patterns
Centralization inside the boundary	WEF/WEC subscriptions, local collector health, retention, and export procedure

These are not single-event detections. They are evidence classes you correlate with your inventory and your expected baseline. If your policy says no one should gain DCSync-equivalent rights and no privileged group should change outside a controlled window, your logs need to support that assertion locally.

If you need a deeper event-by-event map, Active Directory Monitoring: Security Event IDs That Matter goes much deeper on the Windows security logging side.

Findings to Prioritize in Air-Gapped AD

An isolated environment should not change your priority order much. It should change your collection method.

Privilege drift and stale admin paths

Start with the same questions raised in Privileged Access Drift Active Directory: How Admin Rights Creep Back After Audits and Stale Privileged Accounts: Hidden Risk in Active Directory: who is effectively privileged today, how did they get that access, and would that still be approved if reviewed now?

That includes:

direct and nested membership in privileged groups
DCSync-capable accounts
delegated rights that grant GenericAll, WriteDACL, WriteOwner, or equivalent escalation paths
AdminSDHolder-related drift
disabled or dormant accounts that still retain privileged group membership

Protocol hardening and relay surface

Next, prioritize protocol settings that remain dangerous even inside isolated networks:

LDAP signing and channel binding
SMB signing
SMBv1 exposure
NTLM settings and unnecessary fallback
weak certificate mapping or unsafe certificate issuance if AD CS exists

Offline environments often keep legacy settings longer because change windows are more difficult and interoperability testing is slower. That does not make the exposure less real.

Local administrator password hygiene

Shared local administrator passwords are still a lateral movement problem in isolated Windows estates. Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter remains relevant here because the risk is local credential reuse across systems, not Internet connectivity.

Kerberos, service accounts, and delegation

Service accounts, old SPNs, constrained or unconstrained delegation, and weak encryption posture also remain high-value checks in isolated AD. If the environment contains legacy line-of-business servers, the probability of old service account patterns is often higher, not lower.

Remediation and Validation Without Cloud Dependency

Remediation in an air-gapped AD should be staged the same way as any other high-risk Windows identity change: correct the dangerous condition, rerun the same evidence collection, and prove the result inside the same boundary.

⚠️ Warning: Do not treat exportable reports as proof by themselves. A report is only defensible if the underlying collection scope, collection rights, and rerun method are stable enough to compare over time.

A practical sequence looks like this:

Remove or reduce the highest-risk privilege paths first: stale privileged accounts, unsafe ACLs, unnecessary DCSync rights, unsafe delegation, and weak protocol settings.
Re-check GPO and SYSVOL integrity after every protocol or policy hardening change, especially if you touched SMB, hardened UNC paths, or administrative templates.
Validate that local audit policy still covers the changes you care about, and that your WEF/WEC design still captures them where applicable.
Re-run the same audit scope and compare before-and-after findings rather than trusting manual spot checks.
Record what is still intentionally accepted because of operational constraints, especially in legacy isolated environments where compatibility work takes longer.

That final point matters. In isolated environments, exceptions are often rationalized as temporary. If you do not document them with owners and review dates, they become permanent architecture.

How EtcSec Supports Air-Gapped AD Audits

For this use case, the important product boundary is simple: EtcSec's standalone collector mode does not require a SaaS dependency. The local documentation describes a standalone server mode where the collector runs inside your environment and communicates with Active Directory locally, including LDAP or LDAPS for directory data and SMB access to SYSVOL for Group Policy review.

That matters in isolated environments because the audit can stay inside the same trust boundary as the directory under review. For an AD-only assessment, you can keep the scope local rather than assuming outbound access to cloud services.

When the environment is ready for posture measurement, the most useful EtcSec checks in this context are the ones that prove local control health, not generic Internet exposure. Examples include LDAP_SIGNING_DISABLED, SMB_SIGNING_DISABLED, LAPS_NOT_DEPLOYED, DCSYNC_CAPABLE, ACL_GENERICALL, KERBEROASTING_RISK, and ADMIN_SD_HOLDER_MODIFIED.

The key point is not that an air-gapped AD needs a different standard of review. It is that the collection and validation workflow must be able to operate locally, be rerun locally, and be compared locally.

Dedicated administration paths and privileged workstation hygiene
LDAP signing, channel binding, and SMB signing enforcement
Windows LAPS deployment and local admin password rotation
Privileged access review and removal of stale admin paths
WEF/WEC design plus validated advanced audit policy on DCs
GPO and SYSVOL integrity review
AD CS review where certificate services exist
Recurring remeasurement instead of one-time cleanup

How to Audit Active Directory in an Air-Gapped Environment

How to Audit Active Directory in an Air-Gapped Environment Without False Confidence

Why Isolation Does Not Remove AD Risk

What You Can Audit Without Internet Access

Data Sources to Collect Locally