RBAC: A Practical Guide

• Permission cloning: copying access from “someone similar” causes slow, invisible privilege creep.
• Too many global admins: broad roles become the default because they’re “easier.”
• Shared accounts: no accountability and no clean offboarding path.
• No lifecycle process: joiners/movers/leavers aren’t standardized, so access accumulates.
• No reviews: if access isn’t reviewed, it will drift away from least privilege.

1. Inventory access: list privileged roles, key apps, shared mailboxes, sensitive file shares, and external guests.
2. Define a role model: base roles (all employees) + department roles + app-specific roles.
3. Assign via groups: avoid one-off assignments where possible so changes are auditable and repeatable.
4. Separate privileged access: admins use privileged accounts for admin actions; daily work stays standard-user.
5. Just-in-time admin where possible: make privileged roles eligible and time-bound instead of always-on.

AGDLP is an acronym for a group nesting pattern that's been around for decades. It sounds bureaucratic, but it solves a real problem: how do you manage permissions without creating a tangled mess that nobody understands six months later?

What AGDLP means

• A — Accounts: Individual user accounts (people).
• G — Global Groups: Groups that represent roles or job functions (e.g., "Sales Team," "Finance").
• DL — Domain Local Groups: Groups that represent access to specific resources (e.g., "Finance-Folder-ReadWrite").
• P — Permissions: The actual permissions on the resource (folder, app, mailbox).

The pattern: Put accounts into role groups. Put role groups into resource groups. Assign permissions to resource groups.

Why this matters for SMB teams

Small and mid-size businesses often skip this structure because it feels like overkill. "We only have 50 people — why do we need all these groups?" Here's why:

• Onboarding becomes simple: Add someone to "Sales Team" and they automatically get access to everything sales needs. No hunting for permissions.
• Offboarding becomes reliable: Remove them from "Sales Team" and all their sales access disappears. No orphaned permissions hiding in folder ACLs.
• Access reviews become possible: You can look at group membership instead of auditing 47 different folder permissions.
• Changes don't break things: If Sales needs access to a new resource, you add the "Sales Team" group to it. You don't touch individual users.

What happens without it

Without structure, you get what most small businesses have:

• Permissions assigned directly to users on folders, apps, and mailboxes.
• Nobody knows who has access to what without clicking through every resource.
• New hires get "cloned" from someone else — inheriting permissions that don't make sense.
• Departed employees leave behind orphaned access that nobody finds until an audit (or an incident).
• "Can you give me access to X?" becomes a daily IT ticket.

A real example

Let's say you have a Finance folder on SharePoint that only the finance team should access.

Without AGDLP:

• You add Alice, Bob, and Carol directly to the folder with "Edit" permissions.
• Bob leaves. You forget to remove him from the folder (or aren’t aware he still had access).
• New hire Dana joins Finance. You add her to the folder. Months later, Dana moves to Marketing but keeps her Finance access because nobody remembers to remove it.

With AGDLP:

• You create a role group: "GRP-Finance" (Alice, Bob, Carol are members).
• You create a resource group: "DL-Finance-Folder-Edit" and add "GRP-Finance" to it.
• You assign "Edit" permissions on the folder to "DL-Finance-Folder-Edit."
• Bob leaves: you remove him from "GRP-Finance." Done. All his finance access is gone.
• Dana joins Finance: you add her to "GRP-Finance." She gets everything finance needs.
• Dana moves to Marketing: you remove her from "GRP-Finance" and add her to "GRP-Marketing." Clean.

Simplified for smaller orgs

You don't need to follow AGDLP religiously. For a 30-person company, you might skip the "Domain Local" layer and just use:

• Role groups: "Sales," "Finance," "Operations," "Leadership"
• Permissions: Assign those groups directly to resources

The key principle is the same: never assign permissions to individual users if you can avoid it. Use groups. Name them clearly. Document what they're for.

• Quarterly access reviews: privileged roles, sensitive groups, external guest access.
• Offboarding checks: verify disabled accounts, removed role memberships, revoked sessions/tokens.
• Audit trails: keep logs of role assignments and approvals to support investigations and vendor questionnaires.

• Identity governance: access reviews, entitlement workflows, privileged role management (varies by identity provider)
• Microsoft environments: Entra ID roles, PIM, access reviews
• Other IdPs: Okta and similar platforms provide role/group-driven access patterns