5

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?

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:

enter image description here
Source

| improve this answer | |
  • So thanks for the long explaination, but the very first paragraph is the most important for me. In a single forest/domain, it does not matter? What about "if your company merges with or buys another company", or more importantly, you had 15 company related, every of those company had a domain (x.y.z.com) in the same forest, have now merged and now your target is to bring back everyone in the top level domain (y.z.com). – burgergold Dec 6 '17 at 11:07
  • Similar scenario but 13 of the 15 are in the same forest, 2 of them are not but have trust with it. Also in both case, there is pretty much no user story where we are required to provide access on something part of those domain except the top level one – burgergold Dec 6 '17 at 11:09
  • @burgergold, I don't understand what you are trying to ask. Basically, it's entirely a question of scope (table). You want to be as restrictive as possible, but keep the possibility to collaborate on ressource with members of different domains of forests. – Daniel Dec 6 '17 at 11:18
  • Also, it's not about being required to grant access. Implementing IGLDA is not about the current state, it's about staying flexible and compatible when entering a different state, like going from a 10 people small company with a single domai and forest, to a 300 people company with four domains in three forests because they acquired three other companies. Also, IGDLA is not about domain names. That is a completely different question. – Daniel Dec 6 '17 at 11:21
  • In our state, it can't really happen. We are public and not private. We already merged the whole place into one. Our target is to get ride of every domain except one. In the mean time, applying the agldp is synonym of doing the work 15 time and increasing objects in domains we want to remove. See the point? – burgergold Dec 6 '17 at 11:26
0

The benefit is that it prevents someone making the permission group 'LocalAdmin_server1' a member of a role group 'JobRole1' etc. hence: use Domain Local for permissions, use Global for Roles. Scope is your friend.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.