AGDLP: global vs local groups for job/role groups

I believe I do understand the what I've read of AGDLP. However, what I've read doesn't explain the advantage of using global groups for business role / job function or the disadvantage of using local group for them.

So lets say I've a single forest/domain, lets say with a functional level over 2008. A server member of this domain has a local administrator group. In this local administrator group, I assign 1 domain local group, lets name it LocalAdmin_server1 Now in this group, I want to add other groups, groups containing users of different job roles/team such as JobRole1, JobRole2, Team3 Why would having JobRole1, JobRole2, Team3 groups being global being a benefit or having them as a local group an issue?

Solution 1:

Short answer:
JobRole1 is a global group so admins from trusted domains/forests are able to grant users in JobRole1 access to ressources in their domain. It's a question of group scope. Check Using Group Nesting Strategy – AD Best Practices for Group Strategy for a list of groups and scopes.

Long answer:

So lets say I've a single forest/domain

For a single forest and domain, it does technically not matter whether you use domain local, global or universal groups. (You should also distinguish between domain local groups and local groups, as the latter only exist on a single machine.) It becomes important, with multiple domains or forest trusts. But if you implement AGDLP (now IGLDA), do it right from the start, otherwise it'be worth nothing, if your company merges with or buys another company.

So lets say I've a single forest/domain, ...

Let me propose a different example than yours. Hopefully, it becomes clearer. I use the new IGDLA terminology, which is short for "Identities, Global Groups, Domain Local Groups and Access". Ace Fekay wrote a great article about IGDLA.

• You have a file share (or ressource) "Sales".
• You have a user John. A user is also called an identity ([I]GDLA). Jon works in the sales department.
• John needs access (IGDL[A]) to the Sales folder share. You can also think of the "A" as a folder's ACL.

We could simply add user John to the Sales folder's ACL, but we don't do that. It's bad, but that is not the scope of this questions or answer.

The better solution is to create a group specifically to add it to the folder's ACL and then add the user to that group. IGDLA recommends to use a domain local group.

Why use domain local groups? (IG[DL]A)

Since the folder or file share exists only in one domain, and we create a group specifically for that folder, it makes sense to use a scope for the group that is as restrictive as possible.

Local groups are out of the question, because if you move the folder from fileserver1 to fileserver2, you would have to recreate the permissions from scratch. The very next option is to use a domain local group. You retain all the flexibility in terms of adding users and objects to it, even from other domains or even forests, but you can be sure that nobody can see this group outside your domain or forest. We name this group ACL_Sales_RW.

Okay, now you have a file share Sales and granted modify permissions to the domain local group ACL_Sales_RW. But you have multiple salespeople in your team and they need access to more than only the folder Sales. So you need an intermediary group.

Why use global groups? (I[G]DLA)

he intermediary group contains all salespeople users in your company, let's call it SalesTeam. You put user John into group SalesTeam, as well as all other salespeople in your company. You also place SalesTeam into ACL_Sales_RW to grant them read and write access to that file share.

You use the most restrictive scope for this group, too. Domain local groups do work. You can place user from your domain, the forest and also from other domains or forest in them. But domain local groups cannot be seen from trusted domains/forests. So if your sales people need access to a ressource in a trusted domain, they are out of luck. That is why you use global groups. They can be seen from outside your domain and if your sales people need access to a ressource in a trusted domain/forest, their sysadmin is able to simply add the SalesTeam group to their file share ACL.

If it still isn't clear, this image from Ace's blog may help you:

Source