BACK

Planning and Design stuff

Planning and Design objectives:

• Scalable to easily accommodate future growth
• Increase project success
• Decrease project cost

DNS namespaces:

• DNS domains are not the same as Microsoft domains; however as AD is built on DNS, the Microsoft domain trees can exactly parallel DNS domains.
• The Internet DNS namespace is the publicly and globally accessible one
• The AD DNS namespace is the one resolved by pointing to AD DNS servers for DNS
• See the DNS page elsewhere on this site, especially for root domain, root hints, DNS forwarding
• The four AD DNS namespace choices:
  • Same - AD namespace registered in public DNS with delegations from public DNS to publicly accessible AD DNS servers. All domains and hosts in AD can be potentially be resolved from the public Internet - hosts may or may not be accessible from the outside due to NAT and firewalls. This is unlikely to be used due to lack of security.
  • Same with Split DNS - Like "same" above but two separate DNS systems server the same namespace in parallel. One is available from the outside and only contains some host, ones that are meant to be public - this DNS may be manually populated, may or may not be AD DNS. The other DNS is AD DNS. This system is complex to maintain and some name resolution of public resources from within AD may be difficult.
  • Different - Once public namespace, a separate private one. The private one may be publicly registered but not publicly used - this is done to avoid a namespace overlap. The private one could also use a .local or .priv AD TLD - AD DNS would host a "." root domain. This system is potentially confusing to users. DNS namespace overlaps are a potential issue too.
  • AD a subset of Internet DNS - Sort of a combination or "same" and "different" above... The AD private namespace is a sub-zone of a the public DNS namespace, but there is no delegation going down from public parent to private child, and no DNS queries from the outside come into AD DNS. Internal DNS names are a little longer, and there may be some slight complications on accessing internal AD resources from the outside.

One or more forests?

• A forest is a true security boundary - choose multiple forests to has security boundary separations
• A forest has a single schema - choose multiple forests to have more than one schema
• See The Forest section of this site

One or more domains?

• A domain is a replication boundary, you can choose multiple domains to control replication traffic. The choice of replication traffic control by domain is NOT based on geography or WAN links, but based on diverse and separate domain based object access needs. In other words limit by domain what objects are replicated so that only objects more needed are available.
• GPO based account policy is by domain only. Anything in the account policies node of the GPO is applicable at a domain level only. This is not at all clear in the GUI and often a AD newbie source of frustration. The account policies node contains things like password length, account lockout settings, etc.. If different groups of uses have different account policies needs this could be a reason to use multiple domains.
• The domain is an administrative boundary. Multiple domains can be used to handle multiple administrative organizations within a forest.

Forest root domain design issues / questions:

• See the Forest Root section of this site
• A forest may have a empty root domain or dedicated root domain, such as "DS" or "AD".
• Plan the domain structure with care. The forest root is not moveable or transferable or deleteable. It is cumbersome to rename the root domain. It is non-trivial to rename any domain.
• All trees in the forest have a trust relationship with the forest root domain, so inter-tree DNS (and replication ?) traffic flows through the forest root. This is the central tree root trust. One needs to be aware of placing the forest root domain DCs centrally / accessible networkwise.
• The empty forest root is a best security practice (at least in larger organizations), as domain admins (DAs) in the forest root can self privilege elevate to enterprise admins (EAs), and this model basically gives a whole domain just to the EAs to avoid this and thus keeps all the child domains on equal security boundary terms. EA's are in the forest root domain by default; the empty root security model gives a whole domain to EAs.

OU design (and also forest and domain design): ALL OU'S EXISTANCE MUST BE JUSTIFIED BY EITHER A DELEGATION OF ADMINISTRATION OR FOR AN APPLICATION OF GPO(S) - more on OUs here

Domain Controllers (DCs):

• Domain has a real-world and best practice minimum of two DCs. (Technically only one DC is required.)

• If n is the number of DC needed to handle load, a large Site should have at least n + 1 DCs
• A DC in a site enables users in the site to continue to function even without WAN connectivity out of the Site
• A DC in a site in turn requires and increases WAN bandwidth needs due to replication
• DC placement is a domain by domain decision

Global Catalogs (GCs):

• See GC section
• Weigh forest-wide query speed against replication bandwidth use
• For fault tolerance >= 2 GCs per Site
• GC placement is a forest wide decision

Group Policy

Sites:

• See Sites section
• See DC section, above, on this page
• See GC section, above, on this page
• ???

TCP/IP Addressing Planning:

• Physical layout
• Number of sites · Number of hosts per site
• Bandwidth requirements
• Utilization estimates
• Broadcast domain segmentation

Trusts ???

delegation of rights and authority ???

Data Owners vs. Service Owners:

• One powerful feature of AD and improvement over a workgroup and NT and even from 2000 to 2003 is the greater ability to segregate and delineate and delegate. There need no longer be a god administrator who can and does do everything
• Services are AD itself, DNS, the network, physical servers, authentication, etc.
• Service owners are generally IT
• Data is content. User's attributes, files on the file servers
• Data owners are defined by business functionality needs and goals and are prob not IT
• Ex: Service owners can maintain service availability, and data owners can populate security groups and disable that recently fired employee

Microsoft frameworks:

• MSF - Microsoft Solutions Framework - software development oriented
• MOF - Microsoft Operations Framework - IT oriented
• Life cycle process:
  • envision
  • plan
  • develop
  • stablize
  • deploy
  • repeat

Stake-holders - key players in the organization who's buy-in and support are needed for a successful project

Overall general AD design philosophy: "It depends."

BACK