Re: My 30-second AD design
From: Steve Riley [MSFT] (steriley_at_microsoft.com)
Date: 12/13/04
- Previous message: Steven L Umbach: "Re: Block HTTP remote access"
- In reply to: Herb Martin: "Re: My 30-second AD design"
- Next in thread: Herb Martin: "Re: My 30-second AD design"
- Reply: Herb Martin: "Re: My 30-second AD design"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 12 Dec 2004 19:02:12 -0800
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. 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.
> 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.
> 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...
> "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
>
>
- Previous message: Steven L Umbach: "Re: Block HTTP remote access"
- In reply to: Herb Martin: "Re: My 30-second AD design"
- Next in thread: Herb Martin: "Re: My 30-second AD design"
- Reply: Herb Martin: "Re: My 30-second AD design"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|