Re: My 30-second AD design

From: Steve Riley [MSFT] (steriley_at_microsoft.com)
Date: 12/13/04

  • Next message: Jan: "Routing and Remote Access"
    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
    >
    >


  • Next message: Jan: "Routing and Remote Access"

    Relevant Pages

    • Re: My 30-second AD design
      ... Forests and domains are overused as design elements. ... Resources" that should be controlled as a set. ... combine other functional groups from multiple domains ...
      (microsoft.public.windows.server.security)
    • Re: Information or websites on designing an Enterprise-size tree
      ... WAN lines with the multi-domain design. ... MS web site. ... We need to design and setup a tree for 60 K users ... One starts with the number of Forests and Domains, ...
      (microsoft.public.windows.server.active_directory)
    • Re: BBC - Police release train protesters
      ... sinks is under our control, ... USAmericans tell us about their great forests, but anybody, or almost ... with the crooked politicians, but as well with the crooked companies ...
      (uk.railway)
    • Re: AD Design Gurus
      ... Architecture and detail AD technical design. ... Forests for apparent political reasons. ... deployment cost, difficult resource sharing, complex GAL integration, etc. ...
      (microsoft.public.windows.server.active_directory)
    • Re: My 30-second AD design
      ... Forests and domains should mirror geography. ... >It's simple, it's elegant, and it gets the politics out of the design. ... That's exactly what forests and domains are designed for, ... project teams that break across an organizational chart, ...
      (microsoft.public.windows.server.security)