NTFS Permissions Architecture - Best Practices?

[Jim Garrison]

I need to come up with an architecture for organizing file
access permissions in an A/D environment. From what I've
read, I gather that the best way to do this is to define
Domain Local Groups to define logical roles and assign
DLGs the rights to the disk resources at the NTFS ACL level.
Then, I put the users in Global Groups and make the Global
Groups members of the appropriate Domain Local Groups to
complete the linkage between users and resource rights.

First of all, is this considered the "best practice" for
designing a permission architecture?

Next, what about machine-local groups? In an A/D environment
should these be ignored, or should I extend the indirection
to use them also (although I can't see any immediate benefit)?
In other words, should I define access rights in terms of
machine-local groups, make Domain Local Groups members of
the machine-local groups, and then make Global Groups
members of the DLGs? If yes, what are the benefits of
a 3-level architecture such as this?

I case it's important, this is for an organization with
only one domain and only one A/D tree.

Pointers to relevant documentation/whitepapers would also
be appreciated.

TIA

 

[Herb Martin]

I need to come up with an architecture for organizing file
access permissions in an A/D environment. From what I've
read, I gather that the best way to do this is to define
Domain Local Groups to define logical roles and assign
DLGs the rights to the disk resources at the NTFS ACL level.

Yes, (if you are in Native more or better you can use true
"Domain Local Groups" which are NOT quite the same as
those groups in Mixed/Int modes which are merely Local
but "on the domain".)

You should THINK of Local groups (machines or domains)
as being for a "Collection of Resources" rather than for a
group of people (directly).

So that anyone or any group (better) added to the local group
is given permission on that "set of resources".

Then, I put the users in Global Groups and make the Global
Groups members of the appropriate Domain Local Groups to
complete the linkage between users and resource rights.

Yes. You should THINK of Global Groups as being primarily
a "bunch of people or other groups" (group of people but I was
trying to avoid the word group for clarity.)

If you are in Native+ mode you can also nest Users in a Global
which can be added to another Global which is eventually put
into Local group(s) for access to resource sets.

First of all, is this considered the "best practice" for
designing a permission architecture?

Yes. But notice this is NOT a 'permission architecture' but
rather a Group architecture. The Permission Architecture
comes next which is relatively easy if you have designed the
groups (for different sets of people and different sets of
resources) well.

Global (and Universal) Groups are "re-usuable" so that
you might put "Atlanta Engineers" (GG) into BOTH
"Engineer Resources" (Local) and into "Atlanta Resources"
(L) etc....

Universals are mostly for scaling in large (giant) domains
but also allow members (generally Global groups) to be
from multiple domains while Global groups only accept
members from the same domain where they are themselves
created.

Next, what about machine-local groups? In an A/D environment
should these be ignored,

Mostly (if you are in Native mode).

Unfortunately in Mixed mode (and NT) domains the Local groups
on the domain were only for DC usage -- you still had to grant
resource access by putting the Globals of the domain into the
Locals of the computers (mostly non-DC servers.)

But there are reasons why you might wish to still use the Locals
of the machine, especially for either the default groups or for
purely local access (one machine only.)

or should I extend the indirection
to use them also (although I can't see any immediate benefit)?

Making someone an "admin" of their own machine or the server
for which they are responsible is usually done with the local
Administrators group and there are similar exceptions for such.

In other words, should I define access rights in terms of
machine-local groups, make Domain Local Groups members of
the machine-local groups, and then make Global Groups
members of the DLGs?

No, use Domain Locals for "access to sets of resources" whenever
that choice is viable, but use the machine locals when you need
to accomplish that specific goal.

If yes, what are the benefits of
a 3-level architecture such as this?

Easier management. The person (or the thought involved)
in changing a Global group can be different from the strategy
of adding those Locals to the resource permissions.

"department level" admins can handle the Global Membership;
Resource server admins can handle the Local membership
and setting the permissions.

Even if it's the 'same people' it makes thinking about it and
getting it right easier.

Also don't overlook that idea (above) of RE-USING a group
in different places. If you add the users directly to the Local
groups and then want that same set of people to have access
to something else (even in another domain) you have to start
all over.

With the Global == Users and Local == Set of Resources it
is much more scalable and managable for large domains.

If you have 7 users you can do anything you want, but if you
have 70,000 you had better think it through and follow the
guidelines. Even 7,000 or perhaps 700 is difficult to manage
well if you don't use the guidelines.

The entire set of RULES about group behavior was designed
to encourage (but not quite force) you to follow those guidelines.

I case it's important, this is for an organization with
only one domain and only one A/D tree.

Not quite as critical but you should still use at least one level
of Globals for Users and one level of Locals (domain or computer)
for "access to a set of resources.".

Pointers to relevant documentation/whitepapers would also
be appreciated.

The above it likely more explicit and more clear than anything
else you will find written.

If you have questions, just ask -- groups should be simple, but
very explicitly understood.

 

[Joe Richards [MVP]]

I will give a shorter and diverging opinion Herb.

First, is the nesting strategy "best practice". No. It is one of many
models you can use. All of them are fine, it just depends on what your
goals are for the structure of the groups and your management.

In general, you use this type of group nesting in situations where you
are trying to lay a role based permissioning over a resource based
permissioning. You need to keep in mind that this can be troublesome in
a multidomain environment as you will need multiple global groups (one
for every domain) to place in the domain local or local groups. In
addition to that, if different people manage those global groups than
manage the local group then whomever manages the local group has
effectively lose control over the membership once they add one of those
global groups.

Other issues I see with using global/universal groups and nesting or
role based security is that the roles tend to not be very granular so
people start getting access to things they don't need access to simply
because they are in a group that has that access due to the role they
hold. The more nesting you do the more involved trying to figure out who
has access to what. And also with a global or universal group, trying to
figure out where all a group has access rights can be difficult to
ascertain with such wide (forest) scope.

One other serious issue that people are starting to wrestly with more
and more is an issue with being in too many groups which is aggravated
by the group nesting schemes. Do a search on the MSKB for kerberos cert
and token bloat issues related to group memberships. I think unless MSFT
comes up with something unique in this space, you will start seeing
people moving back to machine local groups on members so that the token
bloat can be brought under control.

As a general rule I like using domain local or local groups period. It
is a model that has worked very well for me for 10 years of managing
large enterprise environments.

Since you have a single domain, you can actually use Universal, global,
or DLG groups as they would all have the same range of influence.


joe


--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

 

[Roger Abell [MVP]]

I will add a couple observations, as although I have points
both in agreement with, and divergent from, both Joe and
Herb, I also see a couple of points not yet mentioned.

First, you ask, are (member) local groups redundant,
obviated, when in a domain environment, and so can
just be replaced with domain locals.

For this, yes often defining a member local is just an
extra level without good effect. However, there are
cases where, even when one can establish that there
will never be any need for a machine local account to
echo the permissions granted (membership in the machine
local), there are still effects mandating the use of member
locals. The most prominent that comes to mind is SQL2k
Server when using Windows accounts. Here, if you
grant to a domain group and that group is renamed the
grant in SQL is broken. But if you use machine locals
at least you are insulated from the side effect that may not
be apparent to those that might rename the domain group,
and hopefully those that could rename the member local
on the SQL server would have a higher awareness of the
group's use and rename impacts.
There are others examples, and you need to take these
into account.

I believe Joe touched on token bloat, a direct result from
nesting. This is worse for locals than for globals, as locals
each take significantly larger space.

But now globals have visibility/use beyond the domain of
definition, and hence present the possibility for unintended
(unexpected/unknown) uses. This is a factor in longer
term managability of the selected control architecture (i.e.
group design being a big part thereof).

OK, so you should have seen a global vs local tension there.

Herb advised
<quote>
You should THINK of Local groups (machines or domains)
as being for a "Collection of Resources" rather than for a
group of people (directly)
</quote>
which is something with which I (partially) fully agree.
However, I say "(partially)" because Herb stopped short
from saying to use globals for a group of people. To use
locals for collections of resources that are enabled for
access as a grouping is IMO quite correct. Collecting
people into groups, which are then used to populate the
resource groups, is IMO also correct - but you need to
think about that "tension" when selecting global/local here.
Also, you need to keep Joe's warning about token bloat
in mind when considering this resource/role model.

Now, my own take on one thing that was not yet fully
highlighted is that you, perhaps above all other considerations,
should design for the long term. Name groups for there uses
(which means know the uses before they are defined) and have
a process that holds these to only those uses (or renames them
to there extended, evolved usage). There is close to nothing
worse than a many year old tangle of groups, the actual use of
which is an unknown, the blieved use of which may or may not
match reality, etc.. Once things have degraded to that point
(which can be quite soon in there is no game-plan from the start)
then even when groups exist appropriate for a new usage there
start to appear (redundant) new groups for the new uses just
because no one has the ability to anticipate future side-effects
that might come from group reuse. Hence the population of
groups explodes over time, the token bloat can state to show
up but from a new cause (group explosion rather than nesting
design); and the tangle just continues to tighten.
Get a well thought out naming convention, and define a process
to make sure that it is used as designed - always.

I guess by now you may have guessed that group architecture
(or rather shortfalls therein) is one of my pet annoyances.

Roger

 

[Roger Abell [MVP]]

I will add a couple observations, as although I have points
both in agreement with, and divergent from, both Joe and
Herb, I also see a couple of points not yet mentioned.

First, you ask, are (member) local groups redundant,
obviated, when in a domain environment, and so can
just be replaced with domain locals.

For this, yes often defining a member local is just an
extra level without good effect. However, there are
cases where, even when one can establish that there
will never be any need for a machine local account to
echo the permissions granted (membership in the machine
local), there are still effects mandating the use of member
locals. The most prominent that comes to mind is SQL2k
Server when using Windows accounts. Here, if you
grant to a domain group and that group is renamed the
grant in SQL is broken. But if you use machine locals
at least you are insulated from the side effect that may not
be apparent to those that might rename the domain group,
and hopefully those that could rename the member local
on the SQL server would have a higher awareness of the
group's use and rename impacts.
There are others examples, and you need to take these
into account.

I believe Joe touched on token bloat, a direct result from
nesting. This is worse for locals than for globals, as locals
each take significantly larger space.

But now globals have visibility/use beyond the domain of
definition, and hence present the possibility for unintended
(unexpected/unknown) uses. This is a factor in longer
term managability of the selected control architecture (i.e.
group design being a big part thereof).

OK, so you should have seen a global vs local tension there.

Herb advised
<quote>
You should THINK of Local groups (machines or domains)
as being for a "Collection of Resources" rather than for a
group of people (directly)
</quote>
which is something with which I (partially) fully agree.
However, I say "(partially)" because Herb stopped short
from saying to use globals for a group of people. To use
locals for collections of resources that are enabled for
access as a grouping is IMO quite correct. Collecting
people into groups, which are then used to populate the
resource groups, is IMO also correct - but you need to
think about that "tension" when selecting global/local here.
Also, you need to keep Joe's warning about token bloat
in mind when considering this resource/role model.

Now, my own take on one thing that was not yet fully
highlighted is that you, perhaps above all other considerations,
should design for the long term. Name groups for there uses
(which means know the uses before they are defined) and have
a process that holds these to only those uses (or renames them
to there extended, evolved usage). There is close to nothing
worse than a many year old tangle of groups, the actual use of
which is an unknown, the blieved use of which may or may not
match reality, etc.. Once things have degraded to that point
(which can be quite soon in there is no game-plan from the start)
then even when groups exist appropriate for a new usage there
start to appear (redundant) new groups for the new uses just
because no one has the ability to anticipate future side-effects
that might come from group reuse. Hence the population of
groups explodes over time, the token bloat can state to show
up but from a new cause (group explosion rather than nesting
design); and the tangle just continues to tighten.
Get a well thought out naming convention, and define a process
to make sure that it is used as designed - always.

I guess by now you may have guessed that group architecture
(or rather shortfalls therein) is one of my pet annoyances.

Roger

 

[Jim Garrison]

I will add a couple observations, as although I have points
both in agreement with, and divergent from, both Joe and
Herb, I also see a couple of points not yet mentioned.

First, you ask, are (member) local groups redundant,
obviated, when in a domain environment, and so can
just be replaced with domain locals.

[snip]

Thanks for all the good info.

There is close to nothing
worse than a many year old tangle of groups, the actual use of
which is an unknown, the blieved use of which may or may not
match reality, etc..

This is exactly the situation I'm facing, so I was hoping
to learn enough to design the "best" architecture.

It sure sounds like there's a need for a good book about
permissions architecture, going over all these points
and more. Obviously, the right architecture will depend
a lot on the organization size, security granularity needed,
and expected growth. I'd certainly buy such a book, and
I'm sure there are a lot of frustrated Windows sysadmins
out there who would also Since NTFS has been with us
for quite a while, I'm surprised this isn't already in
O'Reilly's catalog...

 

[Roger Abell [MVP]]

I will add a couple observations, as although I have points
both in agreement with, and divergent from, both Joe and
Herb, I also see a couple of points not yet mentioned.

First, you ask, are (member) local groups redundant,
obviated, when in a domain environment, and so can
just be replaced with domain locals.

[snip]

Thanks for all the good info.

There is close to nothing
worse than a many year old tangle of groups, the actual use of
which is an unknown, the believed use of which may or may not
match reality, etc..

This is exactly the situation I'm facing, so I was hoping
to learn enough to design the "best" architecture.

It sure sounds like there's a need for a good book about
permissions architecture, going over all these points
and more. Obviously, the right architecture will depend
a lot on the organization size, security granularity needed,
and expected growth. I'd certainly buy such a book, and
I'm sure there are a lot of frustrated Windows sysadmins
out there who would also Since NTFS has been with us
for quite a while, I'm surprised this isn't already in
O'Reilly's catalog...

Hi Jim,

I believe you are absolutely right. And, I have in past spoken
with a couple of publishers, and found them "tentatively" interested
in such a work that touches on design issues from a long-term view.
What I have however discovered is that it is a very, very hard topic
to present with meaning/understanding but also with the flexibility
that an analyst needs to bring aftesh to each specific organization
and its specific culture and preexisting architectural commitments.
It would be all too easy to present an example, or few, that take
things to a detail level for so many hypothetical contexts, but that
would be a disservice when it is the agility to balance the tradeoffs
and invent appropriate solutions that one really needs.

Roger