AGLP Group Model
Jim Watts
model. I understand the principals and reason behind then AGLP idea, but
can't quite get the types of groups, specifically the 'Local' bit.
As i understand it, User accounts should be placed into a global group. This
global group should then be placed into a local group, and permissions
should be assigned to this local group. The question is, is this a LOCAL
group or a DOMAIN LOCAL group?
The DOMAIN LOCAL group would obviously be stored in the domain, and could be
used to assign permissions to resources on any server within the same
domain. However, a LOCAL group would reside only on the member server on
which it was created and so could grant permissions only to resources on
that server. To keep things simple, a single group should only be used to
grant permissions to a single resource and so there appears to be no
adavantage to either. However, i can see an advantage in that a local
administrator would only need rights to their own server to CREATE the local
group, where as they would need rights to the Directory (or at least OU) to
create a domain local group. Does anybody have opinions on this, or can
somebody point me to a Microsoft discussion on LOCAL as opposed to DOMAIN
local groups.
Secondly, Q231273 seems to break the AGLP 'rule' as it says that permissions
should not be granted for a DOMAIN group to a resource that is stored in the
directory. This is because of the scope of the group, and while i understand
the reasons i'm not sure what consitutes a directory object. A GPO obviously
is, but is an Exchange2000 folder or mailbox as these are present in the
domain? With this in mind, does anybody actually use AGLP or does everybody
just nest global groups?
All thoughts appreciated, especially on the Local versus Domain Local
question,
Jim
--
Jim Watts,
Directory and e-Business Development
Southampton University Computing Services
Email: J.W...@Soton.ac.uk
Phone: +44 (0)23 8059 2280
Ace Fekay [MVP]
"Jim Watts" <J.W...@Soton.ac.uk> wrote in message
news:eAXdi0heCHA.1596@tkmsftngp10...
> A hopefully simple question concerning the account, group and permissions
> model. I understand the principals and reason behind then AGLP idea, but
> can't quite get the types of groups, specifically the 'Local' bit.
This is not so simple of a question. Read on Jim and you'll see what I
mean...
>
> As i understand it, User accounts should be placed into a global group.
This
> global group should then be placed into a local group, and permissions
> should be assigned to this local group. The question is, is this a LOCAL
> group or a DOMAIN LOCAL group?
With AD they are now called Domain Local Groups.
>
> The DOMAIN LOCAL group would obviously be stored in the domain, and could
be
> used to assign permissions to resources on any server within the same
> domain. However, a LOCAL group would reside only on the member server on
> which it was created and so could grant permissions only to resources on
> that server. To keep things simple, a single group should only be used to
> grant permissions to a single resource and so there appears to be no
> adavantage to either. However, i can see an advantage in that a local
> administrator would only need rights to their own server to CREATE the
local
> group, where as they would need rights to the Directory (or at least OU)
to
> create a domain local group. Does anybody have opinions on this, or can
> somebody point me to a Microsoft discussion on LOCAL as opposed to DOMAIN
> local groups.
>
Actually the real difference is that a Local Group is on a local machine and
is not a Domain Security Principal. THe Local group is only good for Rights
(as opposed to permissions) to perform certain tasks. Take for instance, a
sales department user (just a Domain User) brings his/her own laptop to work
running W2k Pro. The admin joins his laptop to the domain. Then he sees his
clock is slightly off or he tries to install software, he finds he cannot.
That is because once joined to the domain, the Domain Users group gets
automatically added to the Local Users group on the laptop. To allow what he
needs to install/change the time, etc, the administrator of th edomain has
to log into the domain to add that sales user's account to the Local
Administrator (or even Power User if not the owner of the laptop) so that
user can now perform those tasks. The domain admin was able to do this
because automatically when joined, the Domain Administrators group from the
domain is added to the Local Adminstrators group so therefor has full
control on the laptop when he/she logs in.
Keep in mind the differences between Rights and Permissions. A Right is the
ability to perform system tasks, install software on a machine,
backup/restore folders, log on locally, etc, etc. They are more or less like
a "Written Rule", (You can go to Adminstrative Tools, Local Security Policy
and see what I mean). A Permission gives the ability to access a share, a
folder (NTFS permissions) and/or use a printer. This extends to AD as well.
The permissions in AD dictate what users can view, manipulate or even change
the permissions on AD objects, such as a user account, Site object, computer
account, etc.
So you can give a Local Groups (domain or local machine) Rights, such as
change a clock and other system tasks that you cannot to a Domain Global
Group. But you can add the Global Group to the Local Group and it will pick
up those Rights that were given to the Local Group.
> Secondly, Q231273 seems to break the AGLP 'rule' as it says that
permissions
> should not be granted for a DOMAIN group to a resource that is stored in
the
> directory. This is because of the scope of the group, and while i
understand
> the reasons i'm not sure what consitutes a directory object. A GPO
obviously
> is, but is an Exchange2000 folder or mailbox as these are present in the
> domain? With this in mind, does anybody actually use AGLP or does
everybody
> just nest global groups?
I wouldn't say "break" the AGLP rule. The AGLP rule, IMO, is designed for
resource access (files, folders, printers) and not Active Directory objects.
A directory object consitutes a user object, group object, Site object,
computer acccount in the domain, anything in AD pretty much. The reason that
it says that you shouldn't use Domain Local groups because they are "local"
to that specific domain only. They cannot be distinguished to what they
refer to in other domains because they don't traverse a trust.
I use this example in class. Consider your home. You are the owner. Your
home is your Domain. You are the Domain Admin. Being Domain Admin (in this
example) you have certain Rights to perform certain tasks at home, such as
the use of the bathroom, kitchen, if you decide to build something, the TV,
etc. And they are all sepcific rights. Consider it that those rights are for
your household only (your Domain only). Now your neighbor has his/her set of
local rights to their home as well. When they stop over, do they have those
rights in your own home? No they do not. Their rights are specific to their
own home and cannot be traversed across that trust. However, you can give
your neighbor rights to your domain by "allowing" them (in essence adding
him/her -which they can be viewed as security principals [users] and this
can also be a group - their family) to your own Domain local group) so they
can excercise those rights, such as the invitation to "help yourself to a
beer out of the fridge", or go ahead and use the bathroom. etc. In essence,
you just gave him/her that specific right. Also think about it, you invited
him/her into your Domain. You also just gave them the right to Log on
Locally. You can also look at the friendship with your neighbor as a trust.
You are trusting him/her. The neighbor is the the trusted party. If reverse,
then you can go into their home too.
For AD obects, it doesn't work that way since they are not an accessible
resource (like a printer, etc). Those objects are like furniture in your
home (Domain). If you have given yourself that right to use the furniture,
manipulate the furniture, etc, that is specific to your home only. Those
rights (written rules) for your home with your furniture don't mean anything
and cannot be "evaluated" by your neighbor. But when he/she comes over,
since they are the actual security principal user account) and not a
"written rule". In reverse they have their own written rules and they don't
mean anything to you, unless you're a nosy, obnoxious and ignorant/arrogant
neighbor. LOL
>
> All thoughts appreciated, especially on the Local versus Domain Local
> question,
>
> Jim
> --
> Jim Watts,
> Directory and e-Business Development
> Southampton University Computing Services
> Email: J.W...@Soton.ac.uk
>
> Phone: +44 (0)23 8059 2280
>
>
Jim,
I hope all this helped out, especially my anology. Many of my students laugh
at it, but you know what, they all now understand the differences.
--
Ace
Please direct all replies to the newsgroup so all can benefit.
Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
--
Ace Fekay [MVP]
> Jim
> --
> Jim Watts,
> Directory and e-Business Development
> Southampton University Computing Services
> Email: J.W...@Soton.ac.uk
>
> Phone: +44 (0)23 8059 2280
>
>
P.S. Jim, just to add, the AGLP rule was based on NT4. It is now:
Mixed mode: AGDLP
Native Mode: AGGUDLP
David Adner
things you said... If you're being literal, then I have to disagree.
If you're referring to best practices, then I understand.
"Ace Fekay [MVP]" wrote:
>
> Actually the real difference is that a Local Group is on a local machine and
> is not a Domain Security Principal. THe Local group is only good for Rights
> (as opposed to permissions) to perform certain tasks. Take for instance, a
I may be misunderstanding you here, since Local Groups can be used to
assign permissions on a server. Unless you're talking about assigning
permissions to AD objects?
> So you can give a Local Groups (domain or local machine) Rights, such as
> change a clock and other system tasks that you cannot to a Domain Global
> Group. But you can add the Global Group to the Local Group and it will pick
> up those Rights that were given to the Local Group.
Here's another confusing statement. You can grant Global Groups
specific User Rights. It's not typically the recommended method, but
it's possible. So if you're only talking best practices, I understand,
but you didn't really clarify that.
Ace Fekay [MVP]
"David Adner" <david...@yahoo.com> wrote in message
news:3DB7427C...@yahoo.com...
> Don't want to get too deep into this, but I was wondering about a couple
> things you said... If you're being literal, then I have to disagree.
> If you're referring to best practices, then I understand.
Actually it was based on best practice and the way the system was meant to
be used. But not everyone follows it.
>
> "Ace Fekay [MVP]" wrote:
> >
> > Actually the real difference is that a Local Group is on a local machine
and
> > is not a Domain Security Principal. THe Local group is only good for
Rights
> > (as opposed to permissions) to perform certain tasks. Take for instance,
a
>
> I may be misunderstanding you here, since Local Groups can be used to
> assign permissions on a server. Unless you're talking about assigning
> permissions to AD objects?
Well, the article mentions not to use Domain Local Groups to assign
permissions for AD objects because they cannot be enumerated or evaluated in
other domains in a multi domain tree or forest for that matter, since they
are specific to and "local" only to that domain. I am not saying that you
cannot use Local Groups to assign permissions on a server. Best practice to
reserver them for Rights assignments.
Also, you can look at it that Local Groups (not a DLG) are actually a Local
security principal of the local machine, and not a "domain"security
principal. You can give it permissions, just best practice (according to the
MS rules by their designers) not to.
>
> > So you can give a Local Groups (domain or local machine) Rights, such as
> > change a clock and other system tasks that you cannot to a Domain Global
> > Group. But you can add the Global Group to the Local Group and it will
pick
> > up those Rights that were given to the Local Group.
>
> Here's another confusing statement. You can grant Global Groups
> specific User Rights. It's not typically the recommended method, but
> it's possible. So if you're only talking best practices, I understand,
> but you didn't really clarify that.
Yes, I should have clarified this. These are best practices based on the way
MS designed the way the operating system and it's features were meant to be
used. But more so to be able to keep track of it (documentation and
following these AGGUDLP rules) and so someone else can follow it if they
walked in after the Admin left (a prerfect scenario? - one would want
that!).
I try to teach that this is best practice, but not everyone follows it. It
is easier to document this in a larger environment if one follows these
rules then just assigning Rights to specific Domain accounts. You can go
into the Local Security Settings, User Rights and assign Domain Global
groups, but is not best practice, hence the AGGUDLP. There are some default
exceptions, like the IUSR account getting the Log on Locally Right.
I hope I didn't forget anyting and that I wasn't too confusing and this
clears it all up.