| Author |
Message |
Steve Riley [MSFT]
Guest
|
 Posted:
Sun Dec 12, 2004 12:21 pm Post subject:
My 30-second AD design |
|
|
The "Allow/deny log on" thread reminded me of something I've been mentioning
at seminars on occasion, based on work I've done with various customers.
Seems that too many organizations embark upon inordinately long and tedious
AD designs, alas often consultant-generated! I've heard of *design* projects
that last over two years. Then one week after the first DC gets built the
next version of Windows appears!
So here's what I've used a number of times:
1. Forests and domains should mirror geography. Both of
these (with the notable exception of southern California)
are difficult to move.
2. Organizational units should mirror your administrative
model: roles of machines and humans.
3. Security/distribution groups should mirror your
organizational chart.
It's simple, it's elegant, and it gets the politics out of the design. In
every case I've used it, it's worked. If you're planning a new design, or
looking to replace the one you've got, try this.
Steve Riley
steriley@microsoft.com |
|
| Back to top |
|
 |
Herb Martin
Guest
|
| Posted:
Sun Dec 12, 2004 10:34 pm Post subject:
Re: My 30-second AD design |
|
|
"Steve Riley [MSFT]" <steriley@microsoft.com> wrote in message
news:#pNaZLB4EHA.824@TK2MSFTNGP11.phx.gbl...
| Quote: | The "Allow/deny log on" thread reminded me of something I've been
mentioning
at seminars on occasion, based on work I've done with various customers.
Seems that too many organizations embark upon inordinately long and
tedious
AD designs, alas often consultant-generated! I've heard of *design*
projects
that last over two years. Then one week after the first DC gets built the
next version of Windows appears!
|
Up to here we agree.
| Quote: | So here's what I've used a number of times:
1. Forests and domains should mirror geography. Both of
these (with the notable exception of southern California)
are difficult to move.
|
Forests and domains are overused as design elements. Only
larger companies or those with specific needs really need to
have more than one or two of either -- even then "larger" is
pretty big.
SITES were invented so that geography would not automatically
be a reason for adding domains.
While you are right -- at times, this is not a good primary
design PRINCIPLE.
Forests are largely about autonomy and the intention NOT
to share resources, OR about the need for different Schemas
(which is rare in real life).
Domains may help you to solve "political" problems as well.
| Quote: | 2. Organizational units should mirror your administrative
model: roles of machines and humans.
|
Yes, and more explicitly should follow your:
1) Plans for Delegating of control
2) Assignment of Group Policy
(need to control users and assign Software.)
| Quote: | 3. Security/distribution groups should mirror your
organizational chart.
|
As a first cut perhaps, but the KEY point to groups is
using Global Groups to represent lists of users who should
have access to the same objects even if those people cross
organizational boundaries -- e.g., projects, teams, job
function -- and to use Local Groups to represent "sets of
Resources" that should be controlled as a set.
Universal groups can be used for both scalability and to
combine other functional groups from multiple domains
within the organization.
| Quote: | It's simple, it's elegant, and it gets the politics out of the design. In
every case I've used it, it's worked. If you're planning a new design, or
looking to replace the one you've got, try this.
|
Simple is good.
"As simple as possible, and no simpler." -- A. Einstein |
|
| Back to top |
|
|
Steve Riley [MSFT]
Guest
|
| Posted:
Mon Dec 13, 2004 9:02 am Post subject:
Re: My 30-second AD design |
|
|
Slightly different philosophies. One difference you and I have is this:
| Quote: | Forests and domains are overused as design elements. Only
larger companies or those with specific needs really need to
have more than one or two of either -- even then "larger" is
pretty big.
|
I deal almost exclusively with big companies. Thsoe who followed our old
advice (yes, we were wrong back then) to use only one forest with one domain
are now seriously regretting it. Alas, in many multinational organizations,
there are real reasons why multiple domains and forests make sense. I am a
big fan of multiple forests, given that the forest is the real security
boundary and in the customers I routinely work with there are real security
differences across geographies.
| Quote: | SITES were invented so that geography would not automatically
be a reason for adding domains.
|
My customers use sites more as a replication control function than a
directory design attribute.
| Quote: | but the KEY point to groups is
using Global Groups to represent lists of users who should
have access to the same objects even if those people cross
organizational boundaries
|
Good clarification; it's implicit in my thinking but I like that you
specifically call it out.
Steve Riley
steriley@microsoft.com
"Herb Martin" <news@LearnQuick.com> wrote in message
news:efgY$mG4EHA.2288@TK2MSFTNGP11.phx.gbl...
| Quote: | "Steve Riley [MSFT]" <steriley@microsoft.com> wrote in message
news:#pNaZLB4EHA.824@TK2MSFTNGP11.phx.gbl...
The "Allow/deny log on" thread reminded me of something I've been
mentioning
at seminars on occasion, based on work I've done with various customers.
Seems that too many organizations embark upon inordinately long and
tedious
AD designs, alas often consultant-generated! I've heard of *design*
projects
that last over two years. Then one week after the first DC gets built the
next version of Windows appears!
Up to here we agree.
So here's what I've used a number of times:
1. Forests and domains should mirror geography. Both of
these (with the notable exception of southern California)
are difficult to move.
Forests and domains are overused as design elements. Only
larger companies or those with specific needs really need to
have more than one or two of either -- even then "larger" is
pretty big.
SITES were invented so that geography would not automatically
be a reason for adding domains.
While you are right -- at times, this is not a good primary
design PRINCIPLE.
Forests are largely about autonomy and the intention NOT
to share resources, OR about the need for different Schemas
(which is rare in real life).
Domains may help you to solve "political" problems as well.
2. Organizational units should mirror your administrative
model: roles of machines and humans.
Yes, and more explicitly should follow your:
1) Plans for Delegating of control
2) Assignment of Group Policy
(need to control users and assign Software.)
3. Security/distribution groups should mirror your
organizational chart.
As a first cut perhaps, but the KEY point to groups is
using Global Groups to represent lists of users who should
have access to the same objects even if those people cross
organizational boundaries -- e.g., projects, teams, job
function -- and to use Local Groups to represent "sets of
Resources" that should be controlled as a set.
Universal groups can be used for both scalability and to
combine other functional groups from multiple domains
within the organization.
It's simple, it's elegant, and it gets the politics out of the design. In
every case I've used it, it's worked. If you're planning a new design, or
looking to replace the one you've got, try this.
Simple is good.
"As simple as possible, and no simpler." -- A. Einstein
|
|
|
| Back to top |
|
|
Jeff Cochran
Guest
|
| Posted:
Mon Dec 13, 2004 6:06 pm Post subject:
Re: My 30-second AD design |
|
|
On Sat, 11 Dec 2004 22:21:42 -0800, "Steve Riley [MSFT]"
<steriley@microsoft.com> wrote:
| Quote: | The "Allow/deny log on" thread reminded me of something I've been mentioning
at seminars on occasion, based on work I've done with various customers.
Seems that too many organizations embark upon inordinately long and tedious
AD designs, alas often consultant-generated! I've heard of *design* projects
that last over two years. Then one week after the first DC gets built the
next version of Windows appears!
So here's what I've used a number of times:
1. Forests and domains should mirror geography. Both of
these (with the notable exception of southern California)
are difficult to move.
2. Organizational units should mirror your administrative
model: roles of machines and humans.
3. Security/distribution groups should mirror your
organizational chart.
It's simple, it's elegant, and it gets the politics out of the design. In
every case I've used it, it's worked. If you're planning a new design, or
looking to replace the one you've got, try this.
|
But it may not be appropriate. :)
Consider an organization with two distinctly separate divisions.
That's exactly what forests and domains are designed for, autonomy.
Both those divisions happening to be in Cleveland shouldn't put them
in a single forest/domain.
The problem with organizational charts is that work often doesn't flow
in terms of organizational charting. Many organizations will use
project teams that break across an organizational chart, but need
identical management and security concerns. Worse yet, many
organizations will rearrange these teams as projects mature or
complete, further muddying the water.
Your design approach makes sense and works, when appropriate to the
organization. It may fit 80% or more of the organizations out there
(okay, not really, since 90% of organizations have no need of a second
forest, or often even a domain, they just aren't big enough). But a
sensible, well thought out design will win hands down every time.
Besides, most of us work in the real world, where politics *do* play a
role in organizing our lives.
Jeff |
|
| Back to top |
|
|
Herb Martin
Guest
|
| Posted:
Mon Dec 13, 2004 9:21 pm Post subject:
Re: My 30-second AD design |
|
|
"Steve Riley [MSFT]" <steriley@microsoft.com> wrote in message
news:e4$dmAM4EHA.2404@TK2MSFTNGP14.phx.gbl...
| Quote: | Slightly different philosophies. One difference you and I have is this:
Forests and domains are overused as design elements. Only
larger companies or those with specific needs really need to
have more than one or two of either -- even then "larger" is
pretty big.
I deal almost exclusively with big companies. Thsoe who followed our old
advice (yes, we were wrong back then) to use only one forest with one
domain
are now seriously regretting it.
|
This is part of the problem with oversimplifaction;
people use the suggestion as in the wrong context
and then blame you for what made sense in the
proper context.
| Quote: | Alas, in many multinational organizations,
there are real reasons why multiple domains and forests make sense.
|
This gets to the heart of the Autonomy, and the political
reasons for domains and forests. Even the geopolitical
reasons.
The infamous "Germany has an UNWRITTENT LAW that
requires a German company to be managed by either local
people within German or ONLY by the wholly owning
parent company." comes to mind.
| Quote: | I am a
big fan of multiple forests, given that the forest is the real security
boundary and in the customers I routinely work with there are real
security
differences across geographies.
|
Yes, autonomy, different schemas or political issues are
the reason for this.
| Quote: | SITES were invented so that geography would not automatically
be a reason for adding domains.
My customers use sites more as a replication control function than a
directory design attribute.
|
Exactly.
| Quote: | but the KEY point to groups is
using Global Groups to represent lists of users who should
have access to the same objects even if those people cross
organizational boundaries
Good clarification; it's implicit in my thinking but I like that you
specifically call it out.
|
Thanks.
After years, I have finally hit on a way to explain Groups
consistently and completely in on 5-10 minutes without
leaving out the reasons for all of the features (e.g., containment
different types, etc.) |
|
| Back to top |
|
|
Steve Clark [MSFT]
Guest
|
| Posted:
Tue Dec 14, 2004 3:19 am Post subject:
Re: My 30-second AD design |
|
|
Sites are about controlling replication traffic and as a higher-order policy
application object.
"Herb Martin" <news@LearnQuick.com> wrote in message
news:efgY$mG4EHA.2288@TK2MSFTNGP11.phx.gbl...
| Quote: | "Steve Riley [MSFT]" <steriley@microsoft.com> wrote in message
news:#pNaZLB4EHA.824@TK2MSFTNGP11.phx.gbl...
The "Allow/deny log on" thread reminded me of something I've been
mentioning
at seminars on occasion, based on work I've done with various customers.
Seems that too many organizations embark upon inordinately long and
tedious
AD designs, alas often consultant-generated! I've heard of *design*
projects
that last over two years. Then one week after the first DC gets built the
next version of Windows appears!
Up to here we agree.
So here's what I've used a number of times:
1. Forests and domains should mirror geography. Both of
these (with the notable exception of southern California)
are difficult to move.
Forests and domains are overused as design elements. Only
larger companies or those with specific needs really need to
have more than one or two of either -- even then "larger" is
pretty big.
SITES were invented so that geography would not automatically
be a reason for adding domains.
While you are right -- at times, this is not a good primary
design PRINCIPLE.
Forests are largely about autonomy and the intention NOT
to share resources, OR about the need for different Schemas
(which is rare in real life).
Domains may help you to solve "political" problems as well.
2. Organizational units should mirror your administrative
model: roles of machines and humans.
Yes, and more explicitly should follow your:
1) Plans for Delegating of control
2) Assignment of Group Policy
(need to control users and assign Software.)
3. Security/distribution groups should mirror your
organizational chart.
As a first cut perhaps, but the KEY point to groups is
using Global Groups to represent lists of users who should
have access to the same objects even if those people cross
organizational boundaries -- e.g., projects, teams, job
function -- and to use Local Groups to represent "sets of
Resources" that should be controlled as a set.
Universal groups can be used for both scalability and to
combine other functional groups from multiple domains
within the organization.
It's simple, it's elegant, and it gets the politics out of the design. In
every case I've used it, it's worked. If you're planning a new design, or
looking to replace the one you've got, try this.
Simple is good.
"As simple as possible, and no simpler." -- A. Einstein
|
|
|
| Back to top |
|
|
Joe Richards [MVP]
Guest
|
| Posted:
Tue Dec 14, 2004 5:07 am Post subject:
Re: My 30-second AD design |
|
|
Good try Steve, I understand where you are coming from for sure. My experience
is Enterprise as well (I think of small companies of 100k seats globally
distributed).
Much of the time is eaten up not in the basics of the design, but in political
details and in-fighting required to get agreement from everyone on the design of
AD plus the operational support model that will be used. Almost never is the NT4
support model correct for a large compay deploying AD. Coming to mind would be
items like DNS (Windows or UNIX, delegated or ??), organizational control versus
centralization goals of a company (many companies are actually changing support
models while deploying AD), directory collapse decisions as larger companies
tend to already have existing x.500 mainframe or LDAP directories or more likely
both. Then of course you have the Application considerations such as Exchange
which if you don't take into account up front will most certainly decimate your
design later when you feel like dealing with it.
One company I was an admin for we collapsed some 500-700 or so NT4 domains into
an 11 domain global forest of 250k users and about 400 distributed DCs. It
wasn't so bad as we started with five main account domains already that the NT4
resource domains were sucking off of. We added an empty root and some app
domains to it for data center applications. The design was simple (geographic
but that is what we had before for the NT4 account domains) but the agreement
from thousands of admins around the world took a while because we went from
thousands of domain admins in NT4 domains to three (yes the number 3) domain
admins across the entire world for the whole forest.
To your specific points.
1. I don't necessarily agree forests should be geographic, but am behind the
domain being geographic with some special cases such as global application
domains. They don't house normal users but application specific resources. Say
you have a web portal app that is datacenter-centric but distributed across NA,
SA, EU, AP. Instead of spreading the ids/groups/servers across those domains,
you have one domain for all of that that sits in those datacenters.
2. I can agree with this one but keep in mind humans and computer resources
don't necessarily have to be in the same OUs. I.E. You have a centralized
(hopefully provisioned) human management with a decentralized computer management.
3. I don't like this one. I like resource based grouping. Sure you can have
higher level groups that are role or org chart based that you nest in if you
want but closest to the resource and ACLing the resource should be resource
groups. At the org mentioned above we specifically and purposely used DLGs for
this as well and users were added directly to the groups. This meant that
whomever managed the resource had intimate and direct control of who had access
to that resource.
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net
Steve Riley [MSFT] wrote:
| Quote: | The "Allow/deny log on" thread reminded me of something I've been mentioning
at seminars on occasion, based on work I've done with various customers.
Seems that too many organizations embark upon inordinately long and tedious
AD designs, alas often consultant-generated! I've heard of *design* projects
that last over two years. Then one week after the first DC gets built the
next version of Windows appears!
So here's what I've used a number of times:
1. Forests and domains should mirror geography. Both of
these (with the notable exception of southern California)
are difficult to move.
2. Organizational units should mirror your administrative
model: roles of machines and humans.
3. Security/distribution groups should mirror your
organizational chart.
It's simple, it's elegant, and it gets the politics out of the design. In
every case I've used it, it's worked. If you're planning a new design, or
looking to replace the one you've got, try this.
Steve Riley
steriley@microsoft.com
|
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in