Why A-G-DL-P?

[Mandy]

I'm having a discussion with the Linux guy in my department and we were
taking about permissioning on group shares.

I'd like to know why, in Microsoft, one should apply permissions to domain
local groups instead of just going to the global groups? I know that the
permissioning works regaurdless but why use domain local groups?

I'd especially love any reference articles on the subject.

Thanks,

[Greg Williams]

Mandy,

Domain local groups, among other things, are used particularly to set
persmissions over an external trust:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/31915de7-ff58-4f26-a8ec-450ffca75912.mspx

See part:
When a trust is established between a domain in a particular forest and a
domain outside of that forest, security principals from the external domain
can access resources in the internal domain. Active Directory creates a
foreign security principal object in the internal domain to represent each
security principal from the trusted external domain. These foreign security
principals can become members of domain local groups in the internal domain.
Domain local groups can have members from domains outside of the forest.

Also....found this excerpt located here that better explains it in english
:)
http://www.experts-exchange.com/Networking/Microsoft_Network/Q_21595190.html

A good example is if you have an accounting share and there are many
different global groups that need access to this share. Rather than adding
many different global groups to give the same access (lets say Read
permissions) to this share you can create one Domain Local group named "DL
Accounting Read" and put all of the global groups that need read access to
the share within this group. This allows for setting permissions for
multiple groups though one easily managed group on the permissions and
security tab of the share. This helps because you can then avoid the
situation of where a user is a member of more than one global group and one
of those global groups permissions are configured incorrectly you have to go
through each one to figure out which. Overall it makes management much
easier. Although this is a best practice, if you have a small enough
environment that will not be expanding quickly you can manage permissions
through Global Groups just as effectively. But if your environment is
mid-size to large you will definately want to put in the extra time
initially as using A-G-DL-P will make your life much easier.

I hope this helps, there are also many support articles in Microsofts
Knowledge Base that will cover this as well.

[Joe Richards [MVP]]

Like darn near anything how you do it depends and the big dependency is how you
want things. I have never liked AGLP or UGLy or any of the other cute names for
it. But then I have always worked very large enterprise environments so I could
be missing some salient point for small businesses. But I don't think so.

Basically the idea is that you add users to global groups, global groups to
local or domain local groups, and you apply permissions to those. The idea is
that you group your permissions along LGs or DLGs and you group people,
preferably by roles into Globals.

In a single domain forest it is unnecessary because any group scope will work.
You could use just globals and apply perms to them, ditto domain local and
universals.

In a multidomain forest, if you use globals, you will use need to use multiple
globals because users from domain A can not be a group in Domain B, this pretty
much means if you want (and you should want) to minimize group memberships, you
should use domain local or universal groups.

I like domain local groups as the answer. You apply the permissions to the
domain local groups and whomever controls the resource controls the group so
directly controls the membership of that group and hence access to the resource.
If you go with nesting globals into DLGS, someone else might control one of the
nested groups and people could get access that you had no clue about until you
eventually audit it all.

The point that use of domain locals falls down is on permissioning certain parts
of AD in multidomain forests. If you grant some permission the config for
example, the permission will only be applicable if you hit a DC of the domain
the DLG exists in. If you deny access to anything in any naming context
including the config with a DLG, if that person or people in that group access a
GC (or DC for config) that is a DC for a domain the DLG doesn't exist in, the
deny will not be applied.

And to confuse it all, if you have disabled the GC requirement for
authentication because you can't deploy GCs everywhere or you really dislike
global group caching for various reasons then Universal groups has similar
limitations as domain local groups because you aren't guarantee to get them in
your token.

So with all of that, you look at your environment, determine how YOU want to
manage it and go with it. The beauty is that you have lots of choices, you
aren't forced into specific things.

The only time I would look at UGLy seriously is in the case of combining Role
based groups with resource based groups.

Could you permission directly to role based global groups. Sure but you will
almost certainly be adding more ACEs to your ACLs than you actually need which
is worse than having people in a lot of groups.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Post by Mandy
I'm having a discussion with the Linux guy in my department and we were
taking about permissioning on group shares.
I'd like to know why, in Microsoft, one should apply permissions to domain
local groups instead of just going to the global groups? I know that the
permissioning works regaurdless but why use domain local groups?
I'd especially love any reference articles on the subject.
Thanks,