Group Scope Question

[Corey Arndt]

This may sound basic but I need to ask anyway before I get AD implemented.
I am not quite sure what I should set my 'Group Scope' to..Domain Local or
Global.
I have 2 sites linked via a slow connection that are similar and are in a
single domain. I plan on having a Domain Controller in each site to control
security and replicate files from the remote site to the main site.
Licenses will be shared between the sites.
I plan on having different groups for each site that are similar (QA_Site1,
QA_Site2, Engineers_Site1, Engineers_Site2, etc).
Should these groups be Domain Local or Global?
Anys suggestions?
I appreciate any help you can give.
Thank You

 

[Steven L Umbach]

You can use either as long as your domain is in Native Mode. Keep in mind
that domain local groups can only be used within the domain. If you ever
think you may configure a trust between domains or have a child domains you
will need to use global groups to give users access to resources in another
trusted domain. Domain local groups are best used in access control lists
similar in the way you use local groups on a computer and they generally
contain global groups in a domain. In other words add users to global groups
and then add global groups to local/domain local groups. So you may end up
using both. Universal groups are good for nesting global groups into. ---
Steve

 

[Joe Richards [MVP]]

I agree with Steve in that if you are in native mode, you can use either domain
local or global.

Unlike Steve, possibly, I prefer the domain local in a multidomain environment.
I prefer to put groups as close to resources as possible though and am not a big
fan of role based ACLing; instead preferring resource based ACLing. Then you
place the users into the domain local groups directly. The person who manages
that group then has better control over the folks accessing the resource. If you
do the global into local nesting, the power of who can manage a resource may
accidently be usurped from the person who should be managing that access.

For instance, say you have a GG from Dom1 and a DLG from Dom2. The DLG controls
access to a file share. Barb controls the access to the file share and has the
ability to manage Dom2\DLG. Someone tells her to do the old User into Global,
Global into Local strategy. She does it, not realizing fully that she doesn't
control the membership of GG but it looks good right now. Someone else who
controls GG later adds someone else for the other purpose GG has which is to
grant access to something else. This person also now has access to the resource
granted to DLG and Barb knows nothing about it...

joe

 

[Roger Abell]

Hey Joe, I couldn't pass it up . . .

I agree with Steve in that if you are in native mode, you can use either domain
local or global.

Unlike Steve, possibly, I prefer the domain local in a multidomain environment.
I prefer to put groups as close to resources as possible though and am not a big
fan of role based ACLing; instead preferring resource based ACLing.

These are not mutually exclusive but are IMO best only when used together

Then you
place the users into the domain local groups directly. The person who manages
that group then has better control over the folks accessing the resource. If you
do the global into local nesting, the power of who can manage a resource may
accidently be usurped from the person who should be managing that access.

That is a different case than the poster's question.
Of course one can nest DLGs in DLGs.

For instance, say you have a GG from Dom1 and a DLG from Dom2. The DLG controls
access to a file share. Barb controls the access to the file share and has the
ability to manage Dom2\DLG. Someone tells her to do the old User into Global,
Global into Local strategy. She does it, not realizing fully that she doesn't
control the membership of GG but it looks good right now. Someone else who
controls GG later adds someone else for the other purpose GG has which is to
grant access to something else. This person also now has access to the resource
granted to DLG and Barb knows nothing about it...

I would argue that
1. the so-called role GG is not correctly understood and
applied here.
If it were there would be no using it for "other purpose"
that should not be a conjoined resource access/right of
those role members. This is an administrative failing,
not a failing inherent in only the role/resource adm model.
2. if control over access to a resource is to be delegated
then that delegatee should have control over all means
of membership the resource access granting group.
When this is not to be so, then it should be due to some
mandated accesses which are supposed to be outside of
the control of that delegatee. If such mandated access is
abused/misused, this is not a failing of the delegatee,
nor is it a failing of the resource/role model usage but
would likely have happened with a different administrative
control model as well.

Also, your scenario has exampled for the poster an appropriate
use of GGs, to cross domain boundaries. I also agree that for an
entirely single domain forest, or for use solely within a single
domain (and especially when one intentionally wants to force
that intradomain limitation) then DLGs can be used. There are
a few scattered references in Group Policy docs of the need to
use GGs but I have always been left uncertain of the reasoning
when the GPOs of solely intradomain, and I have not experience
the "issues" GG usage is said to avoid, again when GPO use is
constrained within a domain of multi-domain forest. There is also
fact that the size of a user token can accommodate more groups if
GGs are used instead of DLGs, but it is a rather high limit for
most deployments no matter which is used.