Domain Access Control
You set up domain access control by linking user identities to central directory groups. Those groups then get specific rules for each server, app, or database. Most teams start by building broad roles for whole departments like engineering or support. Over time, these broad roles give too many people full read and write power. When an engineer only needs to check one bug, wide permissions create big risks. How native domain access control works A central directory acts as the main source of
Cross-Domain SSO: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up domain access control by linking user identities to central directory groups. Those groups then get specific rules for each server, app, or database. Most teams start by building broad roles for whole departments like engineering or support. Over time, these broad roles give too many people full read and write power. When an engineer only needs to check one bug, wide permissions create big risks.
How native domain access control works
A central directory acts as the main source of truth for your team. Admins create user accounts and put them into groups based on job titles. Each server or database trusts the central directory to check who logs in. When a user tries to log in, the directory checks their password and group.
After login, the target system reads the group name and maps it to a role. That local role holds the actual rules for what the user can do. For example, a database role might allow reading tables in one schema. Another role might allow writing data or changing table structures across the whole host.
Teams also use domain rules to restrict which machines a user can reach. Network rules and directory policies work together to block unknown devices at login. This setup keeps user management in one place instead of on fifty separate servers. When someone leaves the team, you disable one directory account to block all logins.
What native directory rules solve and what they miss
Native directory rules are great at deciding who can log into a host. They stop strangers from reaching your internal systems and cut down password sprawl. Auditors like them because they show a clear list of user groups and roles. For basic login checks, a directory setup does its job very well.
Still, a directory check ends the moment the user logs into the session. The directory cannot see the actual queries or commands that run after login. If a role allows table reads, the user can read every row and column by default. That means query results can return raw emails, phone numbers, and card numbers.
Cross-Domain SSO: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static domain groups also struggle when an engineer needs temporary power for a fix. Admins often add the user to a high power group and forget to remove them. Soon, half the team has permanent admin rights on production databases and servers. Native domain tools also fail to keep a single log of every command run.
Ways to tighten rules beyond basic group roles
To reduce risk, start by breaking big department groups into smaller task roles. Create separate roles for read tasks, schema changes, and server admin work. Review your directory groups every month to clear out old permissions that lingered. Never let shared admin accounts sit open for daily engineering work.
You also need controls that work inside the active session, not just at login. A good setup checks each command or query right before it runs on the host. It can pause risky commands and ask a peer to approve them in chat. It can also mask sensitive fields by rewriting matched fields in query results.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the main goal of domain access control?
It lets admins manage user logins and group rules from one central directory. This stops teams from making separate user accounts on every single server or database.
Why are directory groups not enough for database security?
Directory groups only check who can log in and which broad role they get. They do not inspect live queries or rewrite sensitive fields like card numbers in results.
How often should teams review their domain roles?
Teams should check group memberships every month and remove extra write permissions right away. For high risk systems, require approval per task instead of granting permanent admin roles.