DMZ Domain Controller
A dmz domain controller is a server in a perimeter network that checks user logins. You set it up to handle external requests while keeping internal directory servers safe. Many teams place a read-only server or a separate forest in the perimeter zone. If perimeter roles are too broad, a breach in the perimeter can reach internal systems. How a dmz domain controller works in practice Perimeter apps often need to check user identities before granting entry. Opening direct network paths from th
Cross-Domain SSO: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A dmz domain controller is a server in a perimeter network that checks user logins. You set it up to handle external requests while keeping internal directory servers safe. Many teams place a read-only server or a separate forest in the perimeter zone. If perimeter roles are too broad, a breach in the perimeter can reach internal systems.
How a dmz domain controller works in practice
Perimeter apps often need to check user identities before granting entry. Opening direct network paths from the perimeter to the core network creates high risk. To avoid this, teams deploy a dmz domain controller inside the screened subnet. This server holds user and group data needed by external apps.
Two common design patterns exist for this setup. The first pattern uses a read-only server that pulls updates from the internal directory. It cannot write changes back to the core network. Even if an attacker takes over the perimeter server, they cannot alter internal accounts. Admins also restrict which password hashes copy out to the perimeter server.
The second pattern builds a separate forest in the perimeter zone. A one-way trust allows perimeter servers to trust internal users without reversing the flow. Internal systems never trust accounts created inside the perimeter network. Firewall rules between the zones stay strict and allow only required sync traffic. Both patterns limit how much directory data sits exposed at the network edge.
What perimeter directories solve and what they miss
A perimeter directory solves the problem of checking who can log in at the edge. It stops external traffic from reaching core identity servers directly. It also limits the number of credentials stored in the perimeter zone. These controls help teams pass network audits and shrink the initial blast radius.
Still, directory servers only check identity at the moment a user logs in. Once the login succeeds, the directory steps out of the path. It cannot see or control what an engineer or app does inside the session. A user with valid perimeter roles can still run risky commands on target hosts.
Cross-Domain SSO: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Perimeter directories also cannot inspect database queries or filter sensitive output in flight. If an app queries a database, raw emails or card numbers return unchanged. Native directory logs record the login event, not the actions taken afterward. Teams still need runtime controls that inspect every command and query after login.
Steps to harden perimeter directory setups
Start by removing all write permissions on directory servers in the perimeter zone. Replicate only the specific user accounts that need to log into edge apps. Never sync high-level admin accounts to any server outside the core network. Block all outbound connections initiated from the perimeter back toward internal subnets.
Next, review firewall rules between the internal network and the perimeter subnet. Allow traffic only between specific IP addresses and required directory ports. Rotate local admin credentials on perimeter hosts on a strict schedule. Finally, pair your directory setup with tools that check commands and queries at runtime.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Should I place a writable directory server in the perimeter network?
No, placing a writable server in the perimeter puts your core network at risk. If attackers breach a writable server, they can push malicious changes to internal systems. Use a read-only server or an isolated forest instead.
How does a one-way forest trust protect internal servers?
A one-way trust lets perimeter apps check internal user logins without trusting perimeter accounts. Accounts compromised in the perimeter cannot log into resources inside the core network. This keeps lateral movement blocked at the firewall boundary.
Does a dmz domain controller log commands run during a session?
No, a directory server only logs the initial login check and ticket requests. It does not track shell commands or database queries run after login completes. You need runtime session inspection to log and control active commands.