Agdlp Process
You set up the agdlp process by placing user accounts into global role groups. Next, you nest those global groups inside domain local groups that hold resource permissions. Teams use this model in directory systems to keep role rules neat and clean. When admins grant rights to single users instead, group lists grow messy fast. Broad roles also let staff read or change more data than their job needs. How the agdlp process works step by step The agdlp process stands for Accounts, Global groups,
Process: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up the agdlp process by placing user accounts into global role groups. Next, you nest those global groups inside domain local groups that hold resource permissions. Teams use this model in directory systems to keep role rules neat and clean. When admins grant rights to single users instead, group lists grow messy fast. Broad roles also let staff read or change more data than their job needs.
How the agdlp process works step by step
The agdlp process stands for Accounts, Global groups, Domain Local groups, and Permissions. Each letter shows one clear step in the chain of user rights. First, you create an account for each person or service on your team. You never attach file or database permissions straight to these single user accounts.
Second, you build global groups that match job roles across the whole company. For example, you might make one global group for backend engineers. You put the right user accounts inside that global group based on job duties.
Third, you create domain local groups tied to one specific system or resource. One domain local group might stand for read rights on a finance database. Another domain local group might stand for write rights on a shared folder.
Fourth, you put the global job group inside the domain local resource group. Last, you attach the actual read or write permissions to the domain local group. When a developer joins the team, you add their account to the global group. They get all needed resource permissions right away without touching single server rules.
Managing group nesting across multiple domains
Large companies often run more than one directory domain across regions or business units. The agdlp process handles this scale by splitting job identity from local resource rules. Global groups live in the same domain as the user accounts they hold. Domain local groups live in the domain where the target server or database sits.
Process: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
When a user in one domain needs a file in another, nesting bridges them. Admins add the outside global group into the local resource group. If the company adds a third domain later, admins might add universal groups. Even then, the core logic stays the same across every single team. Job groups hold people, and resource groups hold permissions.
What directory group nesting solves and where it stops
This group model solves major pain points for system admins and security auditors. Without nested groups, admins must edit access lists on dozens of servers by hand. When someone changes jobs, old permissions often stay behind by mistake. With nested groups, moving a user between two global groups updates everything at once. Auditors can also check who holds rights by reading a few group lists.
Still, directory groups only decide who can log in and open a resource. Once a user logs into a database or server, directory checks stop working. The directory cannot see which SQL queries or shell commands the user runs next. A user in an approved group can still run a bad delete command. Directory groups also cannot rewrite sensitive fields like emails or card numbers in results. To control live queries and hide sensitive data, teams need runtime checks beyond groups.
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 inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
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 approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What does each letter in AGDLP mean?
A stands for Accounts, G stands for Global groups, and DL means Domain Local. P stands for the Permissions that you attach to the domain local group.
Why should you avoid giving permissions straight to user accounts?
Direct permissions force admins to update many servers by hand when staff change roles. This manual work leads to leftover access rights and long audit reviews.
Does the agdlp process control what queries a user runs inside a database?
No, directory groups only control the initial login or high-level role assignment. They do not inspect live commands or mask phone numbers and national IDs.