An Overview of the Active Directory Design Process

Goals and Gathering Information

The first thing to do is ask yourself why you are about to install Active Directory. You will need to research the various features and evaluate exactly how some of these features will benefit your business in some way. You may be looking to simplify your current Windows NT4 domain structure, or looking for a way to provide a single sign on solution, or possibly looking to secure and lock down your computers by using group policy. Whatever your reasons make sure you keep your business goals in mind when deciding whether and how to deploy the various components of Active Directory

Before you start on the actual design it is a good idea to collect as much information and documentation together as possible. Existing network diagrams including subnet information, routing, Domain Name System (DNS) documentation, details about LAN and WAN links and speeds, number of users and computers per location, departmental information and details of the current administrative model are good examples of pieces of existing documentation or knowledge. Add to that any changes you wish to make through the use of new Active Directory features and you should have good idea of what you have already got and where you want to go

Forest Design

To start the ball rolling you need to decide how many forests you want. To keep things simple, which is generally what you want, always assume you are going to have just the one forest. This configuration is the easiest to manage for most situations and there needs to be good justification for more than one

There are a few reasons why you might want/have to have more than one forest. Being part of a forest means you have to trust all administrators of that forest. If you need to create two or more distinct security zones within Active Directory you will need to create a separate forest for each zone. These zones may be physically separated by a firewall in addition to the fact that there is limited or no trust between the forests. Typical examples of this occur if one department needs exclusive control of its own network resources and data. This cannot truly be achieved in a single forest design due to the power of the domain administrator and enterprise administrator accounts. You may need to create a one way forest trust in this example where the lower security forest trusts the higher security forest but not the reverse. This allows the higher security department to access the general network resources of rest of the company. If the rest of the company needs access to some parts of the secure forest then a trust the other way can be established, but this should be carefully controlled using a method called selective authentication

Another reason for having two forests may be due to a merging of two companies, which both have their own Active Directories and want to maintain their own exclusive management of their respective infrastructures. A two way forest trust can allow limited or full access to and from each of the forests. Also a free add-on from the Microsoft website called the Identity Integration Feature Pack for Microsoft Windows Active Directory can help you synchronise objects, properties and Exchange global address lists (GALs) between the forests

Domain Design

As with the forest, always assume you are going to have the simplest design which is the single domain model. You should justify having a more complex multi domain structure with well thought out reasons

If a subsidiary or department wants autonomy over their IT infrastructure then you need to analyse exactly what IT administration requirements they have. Most IT tasks can be delegated using organisation units but certain administrative roles will require the creation of an additional domain. If you wish to delegate the ability to create, manage, backup and restore some domain controllers but not all, you will need to create another domain. In addition the domain owner of the new domain has the ability to create and manage external trusts to NT4 or Windows 2000 domains or even Kerberos realm trusts.

A single domain can only have one password, account lockout policy and Kerberos policy, all of which are set in a domain level Group Policy Object and affect all domain controllers for the domain. If you require different account settings such as these for different parts of the company then you will need additional domains to support this.

If a multi domain forest is required, some companies plan for a model known as the empty forest root domain model. In this design the forest root domain remains largely empty and untouched and various child domains are created for the subsidiaries of the company. The enterprise administrators group is in the forest root and the membership of this group needs to be carefully controlled. However, even with this model it is possible for a malicious domain administrator (from any forest domain) or someone with physical access to any domain controller to impersonate the enterprise administrator or damage the entire forest. It is therefore not always worth the effort and cost in creating a separate forest root domain and a simpler design may be in order. Whatever you decide, all domains must effectively trust all other domains and administrators. The gains of a consolidated single Active Directory usually outweigh the risk of an attack

Once you have decided upon how many domains you need you should choose an appropriate DNS name each domain. The two best approaches are to choose a different name from your current internet DNS name or to choose a subdomain of your internet DNS name. An example of the former is microsoft.local and an example of the latter is corp.microsoft.com where corp is the top level of Active Directory. It is possible to choose exactly the same name as your current internet DNS name but this can create confusion, having two sets of DNS servers (one internal and one external) with different but identically named domains. It can also mean that internal machines may have difficulty connecting to your company’s external web site unless you configure certain internet records in your internal namespace

Sites and Domain Controller Placement

A site object represents a well connected part of your network and your site design usually reflects the number of locations you have. You do not need a site object for a location that has no domain controller or server that hosts a site aware application, such as a Distributed File System (DFS) server. Any subnets from these locations should be added to the nearest site object instead. Plan to create a subnet object for each IP subnet on the network that contains Windows hosts and allocate each subnet to the appropriate site.

Once you have planned for your sites then you need to decide how you will link them together. The site links between the sites should closely match structure your physical WAN links. They can be point to point or multi point, whichever best matches the WAN link type. You should assign a cost to each link that is inversely proportional to the available link speed. For example, a 1MB WAN link that is 50% utilised during the day could be given a cost of 5000, whereas a 1MB WAN link that is only 10% utilized could have a cost of 1000. The actual numbers don’t matter to much as long the best links have the lowest costs which will be important should a domain controller need to select which site it replicates with if it needs to choose between two or more. Also decide how often you want to replicate over each site link. This can be as often as 15 minutes and as little as once a week. You can also plan to schedule the replication so it cannot occur at certain peak traffic times during the day.

You need to decide if you will place a domain controller in each site or not. Place a domain controller in a site if there are many users in the site who need to log on and you don’t wish to add this logon traffic to the WAN link that connects to another office which does have a domain controller. Active Directory aware application servers such as Exchange or DFS work much better with a domain controller local to them. If you do not place a domain controller in a site and the WAN link goes down then users will not be able to log on and therefore access any network resources. They will be able to access local workstation resources only through the use of cached credentials

You also need to decide which sites hold global catalog servers. If you have a single domain then all domain controllers should also be global catalog servers as this adds no extra traffic. In a multi-domain environment having all domain controllers set as global catalog servers may well introduce too much traffic to some of the slower WAN links and sites. If you place a global catalog in a site then you will have to accept there will be more traffic to that site and on the WAN link. Global catalogs are contacted at logon time to enumerate universal group membership and so if you don’t place a global catalog server in a site and the link goes down, users cannot log on even if a local domain controller is present. An alternative feature called universal group caching can be enabled on the site to allow log on without contacting a global catalog. A final option is to disable the requirement to check a global catalog server on the domain controller via a registry key, but this effectively removes the ability to use universal groups for account in that site

Decide which domain controllers will hold the various single master operations roles. The two forest wide roles should generally be left on a single central domain controller and the three domain wide roles should be placed together on one central server in each domain. The infrastructure master role is not compatible with a global catalog server so the servers which hold the roles should not be also be global catalog servers. Nominate additional servers to which you will transfer or seize the roles should the first server fail

Organisational Units (OU’s) and Delegation of Permissions

Again, as with the other parts of the design keep your organisational unit plan nice and simple. Firstly, if you don’t need any organisational units then don’t have any. Organisational units perform two main jobs – they allow for easy delegation of administrative permissions and they allow for logical assignment of group policies. If you don’t have these needs then you don’t really need them. Basically, if at the end of the design process you have unused organisational units (as far as delegation and group policy is concerned) then reconsider if you need them

Design the top level OU’s based upon the administrative requirements of your organisation. For example, if you need to delegate the ability to manage the sales department to a local sales administrator then create an OU for sales and assign a sales admin group permissions to this OU. Most designs usually have location based OU’s at the top levels as locations are relatively static, and departmental OU’s beneath these in the hierarchy, however if this is overly complicated for your requirements or isn’t ideal for your administrative needs then you can pretty much plan the OU’s whichever way works best

As far as delegation is concerned is generally better to delegate object permissions to a regional or departmental OU than delegating certain tasks such as resetting of passwords as these are more complex to troubleshoot. However if you keep good documentation and plan well then task based delegation can be very powerful. An example of an object level assignment is the sales admin mentioned before, who has full control permissions to the sales OU. An example of a task based assignment is a helpdesk role that is assigned the reset password permission and various user management permissions at the domain level

At this point you may also want to detail your object naming convention for users, groups, computers, printers and possibly a number of other object types

Group Policy

Group policy has many settings that can be configured and it is not expected that companies will use anywhere near all of these, so you need to decide which settings you wish to apply and to which users and computers. The two main types of settings are the security settings which are mainly computer settings and also registry settings which cover things such as setting the wallpaper, removing desktop features and controlling the general workings of group policy itself

Based upon your business needs decide which policy settings you wish to apply. Try and keep the number of Group Policy Objects (GPO’s) you need to create to a minimum by grouping multiple settings into each GPO. This will speed up the boot process and log on process. You can use the Group Policy Management Console (GPMC), which is a free tool on the Microsoft website, to help plan and model GPO’s in a test environment to try out different combinations of settings

You can assign a GPO to a site to affect every account in that site and you can assign a GPO to the domain to affect every account in the domain. As I mentioned before, the security account polices such as the password policies have to be assigned at the domain to affect domain log on

You plan your lower level OU’s with GPO’s in mind. The easiest way to deploy a GPO to a collection of users or computers is to ensure those accounts are in an OU (plan to create one if you need to) and then link the GPO to the OU. This will affect all the accounts in that OU and in all child OU’s nested beneath. You should use this default inheritance of  GPO’s to your advantage and plan to nest OU’s in OU’s if it helps you reduce the amount GPO’s you need to create. For example, if you need to apply a GPO to three departments then you could create a parent OU to hold the three departmental OU’s and link the GPO to the parent

There are a few advanced GPO features that you can use to control the application of group policy. An enforced GPO cannot be overridden lower down the hierarchy and could be used for certain company wide polices. A block on an OU can prevent GPO’s from above (except for enforced GPO’s which get through). A security filter can prevent the GPO running for a group of users or computers so for example you could prevent certain polices from affecting the domain administrators group. A WMI filter can aim a GPO so it only affects machines based upon their hardware capabilities, so for example computers with greater than 500Mb of disk space or if they have a certain build number. Document all of these options well if you plan to use any of them

You may wish to plan to delegate the ability to create, link or edit GPO’s. You can delegate the ability to create GPO’s in a domain and you can delegate the ability to link GPO’s to specific OU’s. Once you have created a GPO you can also delegate the ability to edit that GPO without giving the ability to edit any others. For example you could create a software assignment GPO and delegate the ability to add and remove software packages into it to a local site technician

Summary

All these guidelines I have suggested are designed to keep things a simple as possible. I would always begin with a starting plan of a single forest, single domain, single site, no OU model, and only introduce extra elements if required by the business needs. Any other approach is certainly open for use though it has to be technically justified otherwise you may be simply making the design more complex for no added advantage

Comments

• Anonymous
  January 01, 2003
  Gordon has been really busy recently.  In the last few weeks he's become an MVP in his favourite...