The RODC Deployment Sequence includes: 1. Provisioning a physical server for the DMZ. 2. Installing Windows Server with the AD DS role. 3. Configuring it as a Read-Only Domain Controller. 4. Defining the Password Replication Policy. ### Configure Read-Only Domain Controller replication settings The RODC maintains its non-writable database by acting as a pull-only client to a writable Bridgehead server in the secure core. Using the Directory Replication Service Remote Protocol (MS-DRSR) over RPC, the RODC initiates requests for updates rather than the core pushing them.  This pull-based mechanism ensures that the identity bridge remains a consumer of data, never a source of truth that could corrupt the primary forest. ### Configure one-way firewall rules for LDAP ports Network traffic must be restricted to unidirectional flows originating from the corporate domain controller toward the RODC. Using LDAPS (Lightweight Directory Access Protocol over SSL) prevents cleartext credential interception. Relying on standard LDAP over port 389 exposes the environment to man-in-the-middle attacks. Forcing port 636 ensures all identity data is encrypted in transit. The firewall must drop any packets originating from the RODC toward the core. This configuration effectively kills the return path for data exfiltration via directory protocols.The blast radius of a local breach is limited by this architectural choice.
### Verifying the local cache for air-gapped authentication Successful deployment requires verifying that the RODC has prepopulated the local cache. A failure to do so will result in authentication timeouts when the AI environment loses its heartbeat to the core.  The RODC will attempt to contact a writeable controller for every login request if the "msDS-RevealOnDemandGroup" attribute is misconfigured. This request will fail against the one-way firewall rule. Testing this involves pre-populating the cache for authorized users via the Active Directory Users and Computers console. You'll then disconnect the upstream link to simulate a total air-gap. Finally, an administrator attempts a login to the AI interface to confirm the local database can resolve the identity. ## Step 2: Automate identity syncing with Activepieces self-hosted ### Deploying automation in isolated network environments Activepieces reaches into the local directory to synchronize identity metadata across 734+ integrations without requiring a persistent outbound connection to a third-party cloud. Deploying this automation engine as a self-hosted Docker container within the air-gapped subnet prevents the "service-reachability failure" that occurs when a workflow tool attempts to phone home for updates. Every credential Activepieces touches can be routed to your own secret manager instead of a vendor database, ensuring that no third party ever holds the keys to your air-gapped infrastructure. You can configure a self-hosted instance against an external secret manager and inspect the Activepieces database yourself to verify the credentials are not there, a capability listed alongside audit logs and SCIM in the enterprise governance set. This ensures your credentials are never ours to hold, providing a level of security that cloud-only tools cannot match. By hosting the execution engine locally, you'll maintain a verifiable audit log of every permission change, which satisfies the requirement for internal oversight of automated administrative actions. ### Sync Active Directory groups to AI permissions Constructing a flow within Activepieces requires defining a specific "source of truth" for user roles. This prevents the "permission drift" that happens when manual overrides are applied directly to the AI database.  The flow acts as a one-way gate: it queries the Active Directory LDAP interface for group memberships and maps those strings to internal roles within the AI environment. The Activepieces flow builder allows administrators to select specific metadata fields through a Data Selector. This ensures that only necessary identifiers are passed to the AI agent. The "Variables" tab in the selector interface lists the specific environmental constants, such as production API keys or database strings, that the flow is authorized to use. Once these variables are mapped to the code steps, the system can automatically transform a "Senior Researcher" AD tag into a "Read/Write" permission level in the vector store. ### Testing the trigger: Mapping a new AD user to an AI agent role Testing the trigger confirms that a new entry in the Active Directory results in an immediate permission set within the AI cluster. This avoids the "access lag" that forces users to wait for manual provisioning. When a new user is added to a specific AD Organizational Unit, Activepieces detects the change and executes the pre-defined mapping logic. A user never inherits more authority than their AD group specifies. If the test fails, the error is logged within the isolated network. ## Operational maintenance for air-gapped identity bridges Maintaining an identity bridge requires a shift from automated cloud synchronization to manual, high-assurance verification cycles to prevent credential drift. ### Rotate service account credentials in air-gapped networks Service account rotation in an isolated environment must be performed through a dual-custody manual update. This prevents the "silent lockout" that occurs when the bridge loses its connection to the identity provider. Because the air-gapped AI cluster can't reach out to a Domain Controller to verify a password change, a mismatch between the two environments results in immediate service suspension. ### Auditing logs when the SIEM is outside the gap Log aggregation for an air-gapped bridge requires a dedicated, internal log-forwarding node. A standard Security Information and Event Management (SIEM) tool can't pull data across the physical disconnect. To mitigate this, you'll need to configure the bridge to export encrypted, append-only audit trails to a physical write-once media or a dedicated unidirectional diode. This provides the external SIEM with the telemetry needed to trigger alerts without creating an inbound path for attackers. ### The 'Sneakernet' fallback for emergency identity updates Emergency identity revocation requires a documented "Sneakernet" protocol to ensure that terminated users lose access to the AI environment even when the automated bridge fails. A compliant fallback process involves: 1. Generating a cryptographically signed "Revocation List" from the primary Active Directory. 2. Transferring the list via a scanned, single-use USB drive or an optical disc to the air-gapped gateway. 3. Manually importing the list to the local identity store to force an immediate session termination for all flagged accounts. ## Frequently asked questions about air-gapped AD integration ### Can I use Azure AD (Entra ID) for a completely air-gapped system? Microsoft Entra ID requires a persistent connection to the public internet to validate tokens and refresh its global certificate authority. This means it can't function as the primary identity source for a physically isolated network. Attempting to force this connection creates a **"cloud-tethered" vulnerability**. The air gap is structurally compromised by the required outbound traffic to Microsoft’s endpoints. You'll need to deploy an on-premises instance of Active Directory Domain Services to meet compliance with strict isolation standards. This localized deployment ensures that authentication traffic never leaves the physical perimeter, which prevents external credential harvesting even if the internal AI environment is compromised. ### How does latency change when using a Read-Only Domain Controller? Deploying a Read-Only Domain Controller (RODC) introduces a "credential chaining" delay for any user who hasn't previously logged into that specific site. The RODC is a specific server role that holds a non-writable copy of the directory database. Because the RODC doesn't store passwords by default, it must forward the initial authentication request to a writable Domain Controller across the bridge. This results in a noticeable lag during the first login of a session. This latency is the trade-off for a reduced attack surface. Since the RODC cannot push changes back to the main corporate forest, a breach within the AI environment can't be used to modify administrative permissions or create "shadow" accounts in the primary business network. ### What happens to AI sessions if the directory sync fails? Active AI sessions will typically persist until their current Kerberos ticket or OAuth token expires if the one-way synchronization bridge fails. At that point the system will deny further access because it can't verify the user's current standing. This creates a "stale permission" failure mode where a terminated employee might retain access to sensitive models for several hours until their local token hits its hard timeout. To mitigate this, auditors require a manual revocation protocol that can be executed directly within the air-gapped environment. High-risk access can be severed even when the automated identity bridge is offline. ## Related reading - [Air-Gapped AI Deployment: How to Run Mistral (2026)](https://www.activepieces.com/blog/air-gapped-ai-deployment-how-to-run-mistral-2026) ## References - [SANS Institute](https://isc.sans.edu/diary/7468)The firewall must drop any packets originating from the RODC toward the core.