[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1005
  • Last Modified:

Active directory security groups

Active directory security groups

I know that it's best practice to give permissions to resources using the Domain Local groups.
But I need to understand the reasons that I might still ignoring.

1- DLG can have users and groups from other domains but the resources in the domain where the DLG is created.
 Comments:  since GG can have users and groups from the same domain and can give permissions to resources in the domain where the GG exists or to other domains. why would we use the DLG.
2-Universal group can have members from all other domains and can give permissions to resources in all other domains. what would be the problem using the UG instead of DLG or GG.?

Thanks
0
jskfan
Asked:
jskfan
  • 3
  • 2
  • 2
  • +1
3 Solutions
 
KCTSCommented:
You can use universal groups - but there is very little point unless you have multiple domains and users from one domain commonly need access to resources in other domains.

One word of caution though, do not add users diretly to universal groups. Add the users to global groups and then add the global groups to the universal group. The reasoning behind this is that the universal group membership has to be replcated to all DCs in the forest that are global catalog servers and long lists of univeral group members means makes this very inefficient. Its much better just to replicate the fact that a global group is a member of the univeral group, rather than list all the users.
0
 
PberSolutions ArchitectCommented:
There is no right answer to this.  It all boils down to preference and the policies your company has, how big your company is as well.

M$ recommends that because it has some good points.  It's called AGLP

If I have a share or a web site that I want permissioned I can permission it will all three groups type or even just use Server Local Groups as well and just place users in there.  All will work fine, so why do the AGLP thing?

Remember...
Global Groups can only have members of one domain.  
Domain Locals can contain groups/users from any trusted domain.
Universals are just like Domain Locals, but at a forest level.

So if I permission a resource using global groups, I will have to go to that object and permission it for each global group that needs access.  If you only have a few groups not an issue, but when you have a large enterprise benefits can be seen by permissioning using AGLP.  

Let say I want to permission 6 groups based on user departments with mixture of Read Only (RO) and a Read Write (RW) access to a resource.  I could use just 6 Global Groups and permission each group to that resource as needed and be done.  You would probably want to name those groups to reflect the resource that it is permission against, just to keep track of things.  But they are department type groups so you would probably want to name them after the department.  So you compromise and make it a combo of the two.  So it called something like: Dept_Server_share_RO.  Now let say you have a another resource with slightly different requirements, you could use the same groups, but they are named after a different resource.  So now you could decide to name that GG more generic.  If you have a big company, you could end up with many groups or the same groups permissioned all over the place and you forget where they are permissioned.  It can also be difficult because you might not want to make the GG name generic, so you create new ones for each resource and how do you keep the groups in sync, since they are department based and each group should have the same members.  Also each new GG you create, the user will need to logoff/logon to gain that group in their token.

Now lets look at the same example with AGLP.

Same 6 groups, just named after the Department.  I have a resource that needs RO and RW access.  I create a DLG or a UG and name it after the resource and permission the resource appropriately.  i.e.  Server_Share_RO, Server_Share_RW.  Now I just add the GG to the DLG/UG.  In this case I have 8 groups as the previous only had 6.  Now I want to do this same thing on another resource, so I create two more DLG/UG named after the resource, but now I just add the same GG to them.  And so on and so on.  You will end up with more groups, but you know where each DLG/UG is permissioned because you named them after the resource and access as well as you don't need to go the end resource to permission once you've done it once with the two DLG/UG.  You only need to manipulate groups at a domain level which is must faster.

So you potentially don't have to keep groups in sync, you know where your groups are permissioned, users don't have to logoff/Logon to gain access as well as you gain the speed of not having to permission the end resource just updating groups.

If you look at this from a security perspective it better too.  If I need to revoke access to a resource right now, I can just remove a user from the GG and you should be good right?  No exactly, the user will still have that GG in their token until they logoff, so I could go to the resource and then pull the group from the permissions, might be tough if you don't know where it is permissioned..  If I did the same thing with AGLP, I can remove the group from the DLG/UG and their access is gone.  Also with AGLP, your user group membership will be potentially lower as hopefully you will have less GGs.

Once again there is no right answer for this.  As you can see, the same thing can be done several ways.
0
 
Netman66Commented:
Try giving access to a Trusted Domain group by adding it to your domain group.  It has to be a DLG or you won't even see the Trusted domain to pick from.

IE: try adding the Domain Admins group from a Trusted domain to any group other than a DLG in the trusting domain.

UG's will work, but everything needs to be Native mode and the traffic from UG replication can be significant if that's all you're using.

0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
jskfanAuthor Commented:
Netman66:

That's good point, but never tried to add a group from a trusted domain and see what you are talking about.

AS of replication caused by UG, don't you think is the same as the replication caused by DLG, since both can have groups from different domains??
0
 
PberSolutions ArchitectCommented:
This issue that Netman66 brings up with UG and replcation is the fact that UG are Forest Wide.  DLG and domain wide.  So if you have 10 domains in a forest and you update a UG, it replication to all domain controllers in the forest.  A change to a DLG will only replicate to the DC's within that domain.

See this:
http://technet2.microsoft.com/windowsserver/en/library/8ac658b0-199c-47df-ac2b-ef9cb56fa7f01033.mspx?mfr=true
http://www.samspublishing.com/articles/article.asp?p=31748&seqNum=7&rl=1
0
 
Netman66Commented:
Sorry to come back late, but what Pber explains is what I was referring to.

It's not a huge deal for a couple of domains and a couple of locations, but quickly gets out of hand after that.

0
 
jskfanAuthor Commented:
DLG  or UG can have groups and user from all domains in the forest. so what would be the difference in replication?
0
 
PberSolutions ArchitectCommented:
Both can have groups from all trusted domain.  It's just that UG are replicated to all DC's in the forest, while DLG only exist in that one domain so they only replicate to the DC's in that one domain, not all the DC's in the forest.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 3
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now