One shared folder, one permission given directly to one person - that is how access control quietly turns into archaeology. This page shows the group-first pattern that keeps permissions readable for years.
Open the security tab of a five-year-old shared folder in a typical office and you will find a museum: ex-employees, one-off exceptions, and names nobody recognises. Every entry was a quick favour once. The alternative is boring and total: the share trusts groups, and only groups. People join and leave groups as their jobs change, and the folder itself is never edited again. This page covers the pattern, the naming that makes it self-explaining, and the famous AGDLP model - graded honestly, because it is guidance, not law.
Two groups, two clear rights. When someone needs access, they join a group - the folder is never touched again.
Create the group when you create the resource, and name it so a stranger understands it: GRP-Accounts-Share-RW for read-write, GRP-Accounts-Share-RO for read-only. The workflow forever after is one step - Add-ADGroupMember -Identity "GRP-Accounts-Share-RW" -Members "rahul.sharma". Transfers and leavers become group edits, and "who can open the accounts share?" is answered by reading one group instead of one folder's security tab.
Only security groups can be given permissions; distribution groups are for email lists. Creating the wrong type is a classic beginner trap - the group exists, members are added, and access still fails because a distribution group cannot hold a right. Create resource groups as Security, Global scope for a single domain, and check the type before troubleshooting anything else.
The textbook model is AGDLP: Accounts go into Global groups, global groups go into Domain Local groups, and Permissions are given to the domain local group. It shines in multi-domain forests where the same team needs access in several domains. Honest grading for a single-domain office: the extra nesting layer often adds confusion faster than value, and one well-named global security group per resource is a perfectly respectable pattern. Use AGDLP where it solves a real problem; do not perform it as a ritual.
Putting the whole Accounts team group inside the Accounts share group is tidy and readable. Nesting becomes a problem when chains grow long and circular - a group inside a group inside the first group - and nobody can say who effectively has access. Keep nesting to one deliberate level, and review effective membership with Get-ADGroupMember -Identity "GRP-Accounts-Share-RW" -Recursive before any audit or incident review.
Groups only stay honest if someone looks at them. Once a quarter, export each resource group's members and ask the department head one question: does everyone on this list still need this? People who changed teams almost never get removed by default - removal only happens when a human reviews the list. That fifteen-minute review is the difference between group-based access as a system and group-based access as a slogan.
The full OU, user and group creation process - live on a real domain controller, step by step.
▶️ Watch Full VideoDo not rip anything out. Create the groups, add the same people to them, give the groups the same rights, verify access works, and only then remove the individual entries - one share at a time, during working hours, with the owner watching.
In a single domain, Global is simple and works everywhere in that domain. Domain Local is the textbook choice at the resource end in multi-domain setups (the P in AGDLP). Either works at office scale; consistency matters more than the debate.
Yes, a mail-enabled security group can receive mail and grant access. Many offices still keep the two jobs in separate groups so that leaving a mailing list never accidentally removes file access, or the reverse.