Active Directory Agdlp
Active directory agdlp is a role model that nests user accounts into global and domain local groups. You place accounts in global groups, nest those in domain local groups, and assign permissions. Many IT teams skip this structure and grant rights straight to single users. Direct grants make audits hard and leave broad rights open across servers and databases. Over time, staff change jobs and keep old group rights they no longer need. How active directory agdlp works in practice The acronym s
Active Directory: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Active directory agdlp is a role model that nests user accounts into global and domain local groups. You place accounts in global groups, nest those in domain local groups, and assign permissions. Many IT teams skip this structure and grant rights straight to single users. Direct grants make audits hard and leave broad rights open across servers and databases. Over time, staff change jobs and keep old group rights they no longer need.
How active directory agdlp works in practice
The acronym stands for accounts, global groups, domain local groups, and permissions. Each layer has a clear job in your directory design. First, you create user or computer accounts for every person and service. Next, you group those accounts by job role inside a global group. For example, all backend engineers join a single global group in their home domain. Then, you create a domain local group tied to a specific target resource. That resource might be a file share, a database server, or an internal app. You place the global group inside the domain local group. Last, you grant read or write permissions only to that domain local group. This split keeps job roles separate from resource rules. When a new engineer joins the team, you add them to one global group. They get all needed resource permissions right away without touching target servers. When they leave the team, you remove them from that single global group.
How to set up groups without permission sprawl
Good group design starts with clear naming rules for every layer. Name global groups after the team or job function, such as finance analysts or site admins. Name domain local groups after the target resource and the access level, such as payroll read. Never grant resource permissions straight to a global group or a single user account. Keep each domain local group tied to one task or one server role. If your company runs multiple domains in a forest, you can add universal groups. In that model, global groups sit inside universal groups before joining domain local groups. Review group memberships every quarter to catch stale accounts. Remove old test groups that no longer point to active servers. Keep admin accounts in separate global groups from daily user accounts. This separation stops daily accounts from holding high server rights by mistake.
What native directory groups solve and what they miss
Native directory nesting makes user onboarding and offboarding clean and fast. It stops admins from editing access control lists on every single server. Auditors can check who holds rights to a server by reading two group lists. Still, active directory agdlp only decides who can log in and open a session. Once a user logs into a database or server, directory groups stop checking actions. A domain local group can let an engineer log into a production database. It cannot stop that engineer from running a drop table command during that session. It also cannot rewrite sensitive fields like emails, phone numbers, or card numbers in query results. Directory groups grant standing access that stays active twenty-four hours a day. If an attacker steals an account password, they inherit every group permission right away. Teams still need a way to check individual commands and queries in flight.
Active Directory: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
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
What is the difference between AGDLP and AGUDLP?
AGDLP works best inside a single domain or a small two-domain setup. AGUDLP adds universal groups in the middle to link roles across many domains in a forest.
Why should you not assign permissions straight to global groups?
Assigning permissions to global groups ties job roles straight to server rules. If you move servers across domains later, you must rebuild your access lists from scratch.
Does active directory agdlp control what users do inside a database session?
No, directory groups only check identity when the user first logs in. They do not inspect SQL queries, block dangerous commands, or mask card numbers in results.