Design your Active Directory tree with security in mind

Successfully designing an Active Directory (AD) tree is no small feat. AD has many different components and concepts that can easily confuse and intimidate a new Windows 2000 administrator. When designing your tree, you must consider business needs, site locations, administrative overhead and, most importantly, security. In this Daily Drill Down, I’ll show you how to design an AD tree that takes into account all of these needs—especially security.

Why use Active Directory?

The main benefit of using AD is that you can centralize the management of your entire Windows network. AD is designed to support millions of objects within the database. With AD, you canget rid of your legacy resource domains, which will allow you to reclaim the hardware required to keep these domains active while also eliminating the administrative headaches.

You can use AD to create increased policy-based desktop security and software distribution with the tools included with Windows 2000 server. AD allows you to delegate administrative control to personnel for simplified tasks, such as DHCP and the addition of new systems to the network. You can also search for printers and other shared resources, which simplifies installation and increases usefulness to the client user.

AD integrates with other programs and features that add security and manageability. Group policies can make the management of your users and resources easier by providing policy-based administration. Exchange 2000 adds a layer of messaging to your AD setup. With the ability to add MSN Messenger and e-mail information, Exchange 2000 adds to the schema of AD.

Although not originally included with the AD install, integrated public key infrastructure (PKI) services available from third parties allow you to use public cryptography keys for securing your infrastructure. AD is based on Kerberos, an open standard for using authentication and encryption. Adding PKI services to AD gives you that extra bit of data security.

By using AD as the core of your network management system, you’ll have the ability to scale the system, while still keeping your security concerns manageable. If you need to add further security to AD beyond what Microsoft ships with Windows 2000, Microsoft also recommends some third-party management applications that add more granular features to AD. You can find out more about these third-party applications at Microsoft’s Active Directory Deployment and Administration Web site.

AD provides a granular security model so you can dish out rights only to the people who need them. The best way to set up a secure AD is to evaluate your existing policies and create a plan to alter them based on the new AD abilities.

Start with forest planning
Creating a detailed plan for your forest schema before you begin building an AD tree will save you from having to reorganize your AD users and resources later. A forest is the top of the chain when it comes to administrative control. In total, AD consists of a schema, configuration information, a global catalog, and trusts with domains in the forest.

Your schema contains the information and attributes about everything stored in the forest. The schema is a template for which information is stored in the database. A schema in an AD installation is replicated to every domain controller in your forest.

Configuration objects are like the cells in an Excel spreadsheet. The configuration containers have data defining the infrastructure, such as domains, sites, and site links. Just like the schema, the configuration containers are also replicated throughout your network to all the domain controllers.

Because networks contain a lot of information, you don’t want queries to each database/domain controller every time someone searches for a printer. This is where the global catalog comes in. The global catalog keeps a scaled-down version of the AD information that is most often searched. This increases the speed of the system, especially if you have slow links throughout your organization. Every domain controller that is running the global catalog in the forest, regardless of the domain to which it belongs, has an exact copy of the current global catalog.

The AD database is very scalable—well into the millions of objects. Because of this scalability, there is no technical reason for you not to use a single forest. Some organizations choose to separate their forests for administrative reasons. One of the first steps in AD design is to choose which of the three acceptable models of AD you want to use:

• Single forest design: This is the most simple of the three models. All directory objects are in a single AD database and have one root domain. With one forest, your administrative costs are lower than with multiple databases. Microsoft recommends you use the single forest design if at all possible.
• Subscription forest design: This is a blend of the single and multiple forest design concepts. This design is sometimes used when an organization is phasing AD into multiple units within the same business. If some business units have already started adopting AD, they can begin creating their forest and then integrate it into the main corporate forest later. Then, in the exterior forests, the administrators can manage security and shared information in their own forest without being concerned with what is going on in the main forest.
• Multiple forest design: This model is best used when the business units have their own administrators and must manage their systems and security away from the rest of the organization. This the most complex configuration, and your administrative overhead is the greatest because you need to administer each forest independently and apply security and policies on each subsystem.

If AD already exists in your organization, you have the choice of participating in the existing structure or going it alone and creating your own forest. If you have your own forest, you gain the ability to control your data in the way that your unit requires, and you aren’t limited to the greater control of a system-wide administrator. However, if you have a single administrative group, a shared forest with domains gives you the same controls.

When you use a single forest to share all your domains, managing the entire network becomes much easier. Any schema changes you make become global, affecting all domains in the forest. Configuration and security changes will affect all resources in your organization. You’ll have one global catalog for all of your users, and you won’t have to troubleshoot any issues with the systems taking affinity to another catalog. And, best of all, security trust relationships will be automatic between the domains that are in your forest.

There is only one technical reason that may limit your ability to have a single forest. If you’ve deployed a network address translation (NAT) firewall between your domain controllers, and you can’t use a VPN to connect the two sites, you must have independent forests that have trusts set up.

The problems of working with multiple forests
When you have more than one forest in the same organization, a couple of caveats can give you headaches as an administrator. Not the least of these is the fact that having multiple AD forests will greatly increase your administrative overhead and cost.

One of the key things you lose when you use multiple forests is the automatic trust relationship between servers. Domains and servers within a single forest inherently trust one another. If you want to access resources in another forest, you must manually create the trust between the two forests. Beyond trust issues, some of the other complications created by multiple forests include the following:

• Kerberos authentication will not occur between the two forests. Each forest contains its own Kerberos encryption key for the root domain, which can’t be passed between forests.
• Client systems can belong to only one forest at a time.
• Multiple forests dictate multiple global catalogs, which increases complexity and the chance of failure.
• You have to use additional applications to replicate the information across the forest boundary.

In short, to maximize security and minimize network administrative overhead, create a single forest.

Logical domain design
Within a forest, you create domains to prevent data from replicating to every point in the network, and to segment users and resources into logical groups. This allows easier administration and reduces the replication bandwidth needed for data transfer. You also gain scalability by segmenting your network into smaller slices, allowing the network to grow to an almost unlimited size.

A domain is also used for authentication of your users and the resources that they require, groups they are organized into, and computers that are allowed to log into the network. Within the domain, you can assign policies to users, groups, and even computers, and standardize the system configurations across your organization. This helps reduce the cost of managing your workstations. You can also assign some additional policies to users, such as passwords and logon policies.

Domains can also serve as a repository of information about resources, such as printers, SQL servers, and mail servers. This gives users the ability to search for resources with a simple search entry instead of having to browse through the network, thereby reducing the calls for help to add printers and other resources.

The first domain in your forest is assigned the role of the root domain. All other domains in the forest will be built upon this root domain to define the AD hierarchy. Two groups are contained in the root domain: the Enterprise Administrators and the Schema Administrators. These groups will give access to a select few superadministrators to manage your entire forest and all the domains that are contained therein.

It’s best to keep other users out of this root domain and create all of your objects in a subdomain. By having a dedicated domain, you have fewer administrators with the ability to make forest-wide changes. Since the root domain can never be changed, you can move subdomains around without affecting the root. So if a unit or your business changes its name, you don’t have to set up an entirely new forest. You just change the domain instead.

Domain name services
With AD comes a new way to search and find resources. Domain name services (DNS), adopted from the Internet DNS, replace NetBIOS names via Windows Internet Name Service (WINS). DNS is a highly scalable design that's the backbone service mapping names to IP addresses.

For security reasons, I recommend having an internal, private DNS server for use with your Active Directory. If the DNS server is compromised or becomes unavailable, the entire AD system and your network will come to a complete stop. After setting up AD, there will be a new option within the DNS control panel that activates DNS integration with AD and stores DNS objects in the AD schema. You should always have more than one DNS server, as well as a domain server for each domain. Having multiple DNS servers prevents interruptions of service in case one DNS server fails.

Organizational units in Active Directory
Organizational units (OUs) are containers within the domain that contain users, groups, computers, and other OUs. This allows you to nest OUs for management purposes.

With OUs, a department can manage its own resources within the domain. This delegation allows for distributed management of the network resources, which reduces administrative costs for the overall network. This lets the forest and domain administrators manage the directory service, while delegating smaller tasks to regional personnel.

With the OU structure, you set up delegation of administrative tasks. Place the users, systems, and other objects in an OU, and then delegate that OU to the user or other OU that you want to manage that group. Doing so will help reduce the number of administrators with high-level access, and it will provide the right amount of control to the users who need to manage a smaller number of people without full administrative control.

OUs also allow you to set up effective group policies that can help you secure your entire network. You can apply policies to an OU, thereby managing logon, password, and Kerberos policies. Group policies cannot be applied to the default Users And Computers container. Although it may appear to be an OU, it’s not.

Controlling replication with site topology
Domains allow you to control which AD data is replicated to which locations. For remote sites, you don’t want your entire directory going off-site. This is where your site topology is helpful. You can define your sites and what domains are replicated to other sites for authentication or disaster recovery purposes. Doing so can reduce the amount of network connectivity that is needed at each domain site.

Only the beginning
Defining policies, setting up domains, and creating your forests are sizable tasks. Once you get started, you’ll see that this project will take weeks to plan—if you do it correctly—but only about 30 minutes to set up. When you take time in advance to include security as a part of your AD design, you’ll end up with a more secure and easily administered network.