For this exam, you are asked to be a network architect. The process of learning how to design an efficient and effective Active Directory follows the same pattern as learning a foreign language. Consider someone asking you a question in a foreign language. When you are just learning a new language, you have to translate, think in your native language, and translate again to respond. When you become fluent, you begin to think in the foreign language. With practice, you will become a much more efficient conversationalist, and eventually you’ll talk as fast as a native speaker.
As far as being a network architect goes, the proper use of concepts like Organizational Units and permissions inheritance should become as familiar to you as the placement of windows and walls are to a traditional architect. Once you’ve reached that point, you’ll be able to look beyond the complexities of what makes up an Active Directory and directly translate physical locations, departments, and job duties into trees, Organizational Units, and domain local groups.
You’ll need a solid understanding of the objects in the domain structure and how they relate to and interact with each other. The topics covered on the Windows 2000 MCSE tests overlap much more than they did on the older exams. Microsoft has interwoven the Networking Essentials, DNS, Active Directory, and Security topics throughout all of the exams. Although Active Directory and Security have their own tests, you’ll need to know how Organizational Units, permissions inheritance, and Group Policies work for almost all of the exams, including this one.
Domain controllers authenticate users and perform many other administrative functions that keep AD running smoothly. If at all possible, you should try to include one domain controller for each replication site where interactive logins occur. Funneling all the login traffic for a network into a small number of remote computers significantly decreases overall network performance and user satisfaction.
Domain controllers tend to use more expensive hardware than typical workstations. If cost is an issue and you are limited in the number of domain controllers, don’t skimp on the connectivity speed between domain controllers. If you are using an Ethernet network, try to have 100 Mbit connections between domain controllers and, if possible, across the entire network.
The first domain controller in an Active Directory network usually hosts the different operations master roles. There are a few different types of operations masters, and they aren’t all used or manually modified very often. You can usually just allow the first domain controller to retain the operations master’s functions.
Global catalog servers keep track of just about everything to do with objects and replicate that information on a regular basis. This means that global catalog servers need a lot of bandwidth. You have to strike a balance between the number of global catalog servers and the amount of available bandwidth you have supporting them.
The more global catalog servers you have, the faster the response for each request, assuming there is enough bandwidth to run at full capacity with room to spare for periodic fluctuations in network traffic.
Although it’s possible to have multiple domains sharing a single Active Directory, most of the time a well-designed single domain with multiple subdomains is an easier and more efficient solution to create and maintain. Active Directory can encompass multiple domains, sites, and forests. This can become very complex, so if you’re given a choice between single or multiple domains, always choose single unless there is a compelling reason to do otherwise. In a few cases, a multiple domain strategy is the best solution:
- Remote locations
If remote locations have low bandwidth connections between them, the frequent replication traffic generated in a single domain setup may be enough to overwhelm the connection. The cost of maintaining faster interconnection lines may outweigh the benefits of a single domain, especially if each location has qualified network administrators already on staff.
- Limited partnerships
If two essentially separate organizations want to keep their own administrative controls in place, a multiple domain setup would keep domain Administrator accounts separate. This is especially important if companies are keeping secrets from one another.
- Policy separation
If one company has a more stringent password policy, it may be necessary for the security of one company and the convenience of another to keep the policies separate. The only way to do that is with separate domains. For example, suppose a defense contractor requires passwords of at least 10 random characters changed every 48 hours without reusing the same password. The less sensitive areas of the company may not want such a strict policy.
Domains within an Active Directory are automatically arranged in a hierarchical tree structure. The first domain in a tree is called a root tree . Every domain tree has a single root tree. Root trees and their child domains can be linked into a forest of domain trees. All trees in the forest have two-way transitive trust relationships, which means all user accounts in a forest can potentially access all resources in all domains in the forest.
The domain that will act as the root tree is created first. Most of the time, the root domain contains many of the resources and structures that will be used throughout all the child domains. You can name the root domain with the company name and create child domains for each department within a company. Sometimes, a company will want to further separate the branches of a tree from a common root domain without resorting to creating a multiple tree domain. This is made possible by creating an empty root domain .
Suppose two companies merge and they want to have the benefits of automatic two-way trusts and a single domain tree while still maintaining a bit of separation between each domain. If the departmental structure of the companies is quite different, it might be easier not to have a common Organizational Unit structure.
If the first domain in a tree is left relatively empty, the child domains will be starting with a nearly clean organizational slate. This is a good way of organizing a company with one name and many separate divisions. In a smaller company, the same principle applies to a single domain’s Organizational Unit structure. Each parent OU can be separated from the other’s while still being connected with a hierarchical tree structure.
You probably won’t want to create a multiple forest structure for a single organization, regardless of how many divisions they have. Because they only allow for specific one-way trusts between two domains, linking the forests can be an administrative nightmare. In a few specific cases, a multiple forest may be your best option:
If two forests need to set up a limited relationship between a small number of domains, but otherwise remain autonomous, having a few one-way trusts is an acceptable way to share information.
If two large and complex forests already exist and companies are merging, the pragmatic approach may be to just link the domains that need to be linked on a case-by-case basis as the merger goes through. You should document each other’s network for a potential full merger in the future.
Many businesses have a central ownership, but have separate names to describe each division. It is especially important to maintain name identification throughout the company if you choose to use the same domains for internal and external use. You can maintain brand identity through separate names while maintaining all the benefits of a single forest structure by naming each domain root for each separate division.
A multiple-tree forest is far easier to manage than a multiple forest. All trust relationships are two-way and are configured automatically. Replication among domains is easy to accomplish by the strategic division of replication sites that can encompass just about any well connected area of the forest, regardless of domain.
An Organizational Unit (OU) is a group of related objects that share access permissions. They are used similarly to the way groups were used in Windows NT, except that OUs can contain just about any type of object, not only user accounts.
Organizational Units provide a logical way to group and collectively manage such network resources as user accounts, files, folders, and printers. Usually, the OU matches a real-life department or team within a company. There are many benefits to dividing up the Active Directory into OUs.
The most obvious benefit is the ability to quickly map a company’s departmental structure to permissions-based groups, where all the objects that need to perform job functions can be administered together as a unit.
The other benefit is the ability to easily delegate authority. You can assign administrator-like privileges to the manager of the web design department for all the scanners, printers, and web directories used by the department without giving that manager an Administrator account for the whole network.
By repeating this process, you can allow departmental managers to have day-to-day control over their work environment without any undue security risks. This will free more time for you to manage, monitor, and maintain the network as a whole without micromanaging every department.
The best part is that, when a new resource or employee is added or removed, you can simply drag and drop that resource in or out of the OU. What you’ll do is create a domain for the company, create subdomains where appropriate, and divide the remaining resources into OUs based on departmental divisions.
This is the easiest component to remember. Any individual network resource in the Active Directory is considered an object. User accounts, files, folders, printers, and Organizational Units are all objects.
Objects have properties that describe what they are and permissions to control who has access to them. Objects can generally be moved around the Active Directory by dragging and dropping them in the Microsoft Management Console (MMC). The definitions of all objects are stored in the schema, which is covered in more detail later in this chapter as well as in other sections of the book.
It’s a lot easier to manage security for a group of similar users rather than to assign permissions to each individual user account. Windows 2000 has three types of security groups detailed in Table 23-3.
Table 23-3. Security Groups
|
Group |
Description |
|---|---|
|
Used to grant permissions within only the local domain. May contain user accounts and global groups from any trusted domain. Permissions granted are valid only within the local domain, regardless of where the account or group originated. | |
|
Used to grant permissions across the entire forest. May contain only global groups and user accounts. Replicates only the group name between domains, not the group membership list, so replication traffic is less than with universal groups. | |
|
Used to grant permissions across the entire forest. Usually contains other groups, rather than individual user accounts. Can contain any type of group. Must replicate to all domains in the forest, so frequent changes to group membership can generate significant network traffic. |
All of the groups can contain other groups. Putting one group inside another is called nesting. Nesting is an efficient way to manage permissions for a large number of users while limiting the number of groups you have to directly manage on a regular basis. You can take the following approach to help organize groups:
Start by adding user accounts to global groups by department or job function.
If more than one department needs access to the same resources, nest the departmental global groups into a larger global group. Try to minimize the total number of independent global groups by nesting as many as possible. Keeping track of permissions will be easier with fewer separate groups.
If you can see a need for universal groups, add the global groups to universal groups; otherwise, simply add the global groups to the appropriate domain local groups to lessen replication traffic, as compared to just using universal groups to distribute permissions across the forest.
Once all the user accounts are grouped as efficiently as possible, start granting the needed permissions and test to make sure everyone can access what they are supposed to and nothing else.
After everything is running smoothly, you can delegate control of departmental group membership to each department head. Changes at the departmental level automatically replicate up through the group structure, and you should have a nearly self-sufficient group structure.
The ability to share information securely and conveniently is important to almost all businesses. Windows 2000’s trust scheme will make it a bit easier to manage than the cumbersome NT trust scheme. You’ll still need to map out which domains need to trust which and whether or not those domains are within the same forest. There are two main types of trust relationships in Windows 2000, transitive and external. There is also a third type, called a shortcut trust , which I’ll discuss later.
Transitive trusts are by far the most common type of trusts you’ll run into. They are automatically created between parent and child domains within a tree structure and between domain roots. This means that every domain within a forest automatically has a two-way trust relationship with every other domain in the forest. This is why it is so important that permissions be assigned properly, especially if certain domains in the forest need tight security.
Sometimes domains in different forests need to trust each other. This type of relationship is not automatic. There are a couple of rules you’ll need to know about external trusts in order to determine if they meet a company’s goals:
External trusts are one-way only. If you need a two-way external trust, you have to create two separate one-way trusts between domains in different forests.
External trusts only connect two domains in different forests. The transitive trust relationships that each domain shares within its own forest are not shared by the remote domain. The rest of the domains in each forest are isolated from the remote computer.
The Active Directory uses a totally different method of authentication than Windows NT. Windows 2000 uses the Kerberos model of authentication, which involves the use of keys. The Kerberos model is discussed throughout the book and in detail in the security chapter.
Only Windows 2000 networks running in native mode can take full advantage of all the trust relationships described in this section. When attempting to make a trust relationship with a remote Windows 2000 domain, be sure to check to see if their network is in mixed mode or native mode.
All child domains have a transitive trust with their parent domains, but domains may be in different trees with several transitive trusts separating them from each other. This can cause more authentication overhead than is necessary. Active Directory allows you to specifically create a two-way transitive trust between two domains within the forest without having to rely on the series of two-way transitive trusts that automatically link them via the tree structure.
When you are designing a Group Policy, you’ll have to figure out what the company’s priorities are. You’ll need to weigh several options: security vs. convenience, control vs. flexibility, and up-front effort vs. recurring effort. As a consultant, you might run into a client who wants security, convenience, flexibility, and control with maximum up-front effort (yours) and minimal recurring effort (theirs). This is not possible with Group Policies.
The main sticking points are security and flexibility. If you want to restrict access to objects on the network, the people who have permission must make the changes themselves. This is more secure, but it diminishes convenience. Consider this situation:
Your supervisor calls to tell you her son has broken his arm and she’s on the way to the hospital. You’ll have to give her sales presentation to the assembled crowd in twenty minutes. You try to open sales.ppt and get “Permission Denied.” No problem, just call the Network Administration department to change permissions. The last you checked, there were three network administrators, but when you call them you find out that one is on vacation, one’s out on an emergency hardware installation 45 miles away, and the third one quit yesterday.
The alternative extreme can result in having a disgruntled employee modify the sales presentation to include just about anything. Your job is to explain this and convince the company to balance the needs of security and convenience by allowing you to implement a responsible Group Policy structure.
It’s almost always easier to apply permissions to groups of similar users, rather than to each individual user on a case-by-case basis. Windows 2000 gives you many different types of groups to choose from. Groups are smaller divisions than Organizational Units and only contain user accounts, whereas OUs can contain all kinds of objects. No matter which groups you use, the reasons for the policies will remain the same. Getting to know what the policies can do will help you determine which groups to use. Group Policies are applied through the use of a Group Policy Object (GPO) containing the rules that make up the policy.
Group Policies can be used to define which programs are to be installed on which computers. This can be done by department, with web development getting Photoshop and Flash, sales getting Outlook and Excel, and technical support getting Quake. Actually, the Group Policy can be used to make sure technical support doesn’t install unauthorized programs, which brings us to another of GPO’s benefits: security.
Group Policies can allow certain users to log in to any workstation and have access to only their authorized applications, regardless of whether the unauthorized application is installed on the workstation that they are locally logged in to. GPOs can also restrict physical and remote access to sensitive computers, such as domain controllers.
If you’ve created the OU structure to match the company’s real-world departmental structure, assigning permissions by OU is a convenient way to provide access to those who need it and deny access to everyone else. Also, if you arrange to have the employee transfer process include a notification to the network administrator, employees can be moved in and out of OUs faster than they can clean out their cubicle.
If you want to create a Group Policy that applies to the whole domain or multiple domains, it’s better to apply the policy on the domain level rather than the site level. This is more work initially, because Group Policies only apply to the local domain. You’ll have to apply the same policy to each domain separately. This should help avoid accidental policy application.
Overall, I think the best approach is to apply no Group Policies at the site level, general policies at the domain level, and specific policies at the OU level. This hierarchical approach has less risk and gives you more granular control over policies. The up-front investment in time usually pays off later.
Members of a security group can be prevented from inheriting a GPO, even it if applies to their entire domain. This is especially useful for users with elevated privileges who need to retain access to secure objects.
In addition to blocking GPOs with security groups, you can also block GPOs at the OU level. Normally, Group Policies are automatically inherited from any parent OU. You can set an OU to block policy inheritance, but it only works if the parent OU doesn’t have a No Override setting. You’re better off just taking the time to plan Group Policies thoroughly, rather than worrying about whether or not they will apply and what the exceptions are.
Everything in Active Directory is an object that has an access list of permissions. Efficiently assigning these permissions can save you and the users a lot of grief in the day-to-day operations of the network. There are a few different strategies for designing a delegation scheme.
You need to transfer, or delegate, the authority to access objects throughout the Active Directory. These objects can number into the hundreds of thousands in moderate sized businesses. Properly grouping and then assigning permissions by group is essential. How you divide the groups depends on the type of organization and the type of objects you’re dealing with.
The first step to creating a solid delegation plan is to create an inventory of the type and number of objects you have. Every object must be owned by somebody who will be responsible for its safekeeping. If you find an object that is improperly owned, a member of the Domain Administrators group can take ownership and temporarily or permanently assign ownership to themselves or another user.
You can delegate permissions by object or by task. A task might be backing up files or clearing a print spool. Task-based delegation is generally more difficult and time consuming, so it is used much less frequently than object-based delegation.
Objects automatically inherit permissions from their containers further up the AD structure. Sometimes, it is necessary to prevent this from happening. Be very careful if you block permissions inheritance, because if you forget you did it, making a change to the parent object will no longer be passed on down the line to the blocked object. Be sure to document every case of blocked inheritance.
If you have experience with the Domain Name System (DNS) used on the Internet, you’ll have no problem designing a DNS naming scheme for your Active Directory. The first thing you’ll have to decide is whether or not you’ll be using the same domain name for the internally (company) and externally (Internet) accessible network resources.
One of the simplest and most effect ways to organize a hierarchical naming scheme like DNS is to mirror the actual geographic and departmental hierarchy of the company. You have to take into account whether or not the business wants to use the same domain name for internal and Internet addressing. Table 23-4 shows an example of DNS Naming Scheme.
Table 23-4. DNS Naming Scheme
|
Company Breakdown |
DNS Name Used |
|---|---|
|
Parent company name: O’Reilly & Associates |
oreilly.com |
|
Geographic locations: Sebastopol, Cambridge |
sebastopol.oreilly.com cambridge.oreilly.com |
|
Sebastopol’s Departments: editorial, production, and marketing |
editorial.sebastopol.oreilly.com production.sebastopol.oreilly.com marketing.sebastopol.oreilly.com |
The DNS naming system is from left to right, specific to general. A final example would be if the marketing office in Sebastopol had a server named zookeeper. In that case, that server’s DNS address would be zookeeper.marketing.sebastopol.oreilly.com. Every unique DNS name has to have a unique Internet Protocol (IP) address.
You’ll notice that the parent company name is part of all the subdomain names. You can create as many subdomains as you’d like. However, you cannot change the original parent domain name. The name is called the forest root domain.
Because the forest root domain name cannot be changed, if the company is going to merge or otherwise change names in the near future, you may want to consider registering the new name and using it internally, especially if it’s going to be a hyphenated name. When the merger is finalized, the new domain name can be made public.
If you choose to use the same domain name both internally and externally, you’ll probably want to set up a firewall . A firewall can separate DNS zones from one another. You may put network resources in any zone you’d like and make any zone either public (accessible from the Internet) or private (accessible only from within your local network).
If the company wants the least amount of risk, you should suggest that they use separate domain names for internal and external use. It’s conceivable that a resource could be accidentally (or intentionally) put in the wrong DNS zone or otherwise made accessible to the outside world. Not only is the use of separate internal and external domain names a bit more secure, it makes it easy to determine which resources are public just by the domain name.
The schema is a database that contains a listing of all the types of objects and their properties. The schema determines which properties are both necessary and optional for each object. A faulty schema modification can have a disastrous and unexpected impact across the entire AD. If you’re not absolutely sure of all the possible consequences a particular schema modification can cause, don’t even consider doing it.
Some AD aware programs will modify the schema to include new functionality. New types of objects with different access permissions may be needed as technology changes. The ability to modify AD’s schema is mostly for future compatibility. Most installations will never have to be modified directly. You should still understand how the schema works, because applications you install may be modifying it for you.
The attribute-schema objects define the rules and structure of an attribute of an object. A folder is an object that needs many different attributes to describe it in its entirety. Each attribute, such as its name, will need rules to define it and make sure it behaves in a similar way to all other folders. Can a folder have the same name as another folder in the same location? How long can that name be? These attributes can be combined into a group called a class .
An object usually has multiple attributes. Because each attribute is defined in a separate attribute-schema object, these objects have to be unified to create an encompassing definition of the familiar object, such as a file, folder, or user account. The collection of attribute-schema objects that define a common object (like a folder) is called a class-schema object.
A class-schema object can require certain attribute-schema objects and allow others if needed. For example, a file has to have a name, but not necessarily an application-mapped file extension.
Class-schema objects also determine the structural hierarchy attributes of an object. You can put a file in a folder or a folder in a folder, but you can’t put a folder in a file.
There are two ways the schema can be modified: by using the Active Directory Schema snap-in for the Microsoft Management Console (MMC) or through the installation of an application that modifies the schema automatically. Objects in the schema have a unique identification number called an object identifier . There is a worldwide hierarchical numbering scheme that is similar to the IP address system used on the Internet. The International Organization for Standardization (ISO), an international standards body, maintains this hierarchy and can assign numbers for use in the schema.
The are a few potentially negative side effects of modifying the schema that you should consider. Before you change the attributes of an object, check to make sure you won’t have conflicts with existing objects. Modifying the schema requires that all domain controllers replicate the change. This can cause a lot of traffic, so you may want to time it when network usage is low. Also, replication is not instantaneous throughout the domain, so inconsistencies can occur until the replication is completed.
A Windows 2000 network consists of peer-to-peer domain controllers. There is no longer an NT-style hierarchy of primary domain controllers and backup domain controllers. The Windows 2000 domain controllers need to exchange information among themselves on a regular basis. Unlike OUs, which are best designed to match the departmental makeup, replication sites have to be designed to physically link over a fast part of the network regardless of departmental boundaries.
Sites are the basic physical structures that allow the replication of data on the network. The strategy for creating an efficient replication environment is fairly straightforward: find the best available bandwidth between potential sites, look at bandwidth utilization on each subnet, and link sites accordingly. Your goal is to link sites so that they have the greatest bandwidth between them (see Table 23-5).
Table 23-5. Site Replication Strategy
|
Domain Controller Name |
Average Available Bandwidth to DCA |
Average Available Bandwidth to DCB |
Average Available Bandwidth to DCC |
|---|---|---|---|
|
DCA |
N/A |
7.8 Mbit |
5.2 Mbit |
|
DCB |
7.8 Mbit |
N/A |
6.1 Mbit |
|
DCC |
5.2 Mbit |
6.1 Mbit |
N/A |
By creating a table like Table 23-5, you can easily to see that you want to avoid the DCA to DCC connection of 5.2 Mbit and link DCA to DCB at 7.8 Mbit and DCB to DCC at 6.1 Mbit. Keep in mind that bandwidth usage can change very rapidly on a network, and you should consistently monitor network utilization.
Proper division of replication sites can help the overall performance of Active Directory. Many of the features of Active Directory that were not present in the NT directory structure require the efficient transfer of information throughout the entire network. Some of this traffic can be optimized by placing commonly needed resources within a site. A decrease in the number of sites, so that each site has access to the servers it needs to operate relatively autonomously, may outweigh the raw replication speed achieved by having smaller sites. Table 23-6 shows some examples of where site design can pay traffic dividends.
Table 23-6. Site-Level Traffic Optimization
Replication of data within a site is called intrasite replication. Replication between sites is called intersite replication. It is important that bandwidth between domain controllers be as high as possible, because they will be involved in both intersite and intrasite replication. You should always map out the physical location of all the domain controllers and the nearby hubs and switches that connect them. If possible, try to have 100 Mbit connections between all domain controllers and have at least one domain controller in each replication site.
The amount of time it takes to exchange replication data between domain controllers is called replication latency . Don’t confuse the amount of time it takes to complete a transfer, replication latency, with the total amount of bandwidth needed for the transfer, replication cost . Each replication session has a certain amount of setup and teardown traffic, in addition to the actual data transfer. If you configure the site replication to save changes in a batch and send them all at once, you’ll reduce the overall replication latency and lower the replication cost by transferring fewer setup and teardown packets.
Sites can be adjusted after they are created. Whenever there are changes to the network, you should re-evaluate your site borders to make sure you still have the most efficient replication setup. Adding a single computer to a site can significantly change the available bandwidth, which can have a cascading effect on the performance of seemingly unrelated parts of the network. Always perform a check on the current situation, called a baseline , so you’ll have something to compare the new numbers to after a change.
All the sites in Active Directory have to be able to share information. The way in which they replicate information is not random, you can choose which sites share a replication link and when they transfer data. You have to take into account employee shift schedules and sometimes differences in time zone when determining the most efficient timing of replication on large networks. The connection between two sites for the purpose of replicating data is referred to as a site link.
Most site links connect two locations, but each of those locations probably has a site link to somewhere else. Site links on fully routed IP networks are transitive, which means that, if site A is connected to site B and site B is connected to site C, then site A is effectively connected to site C via a site link bridge.
Because sites can span multiple domains and some domains have several domain controllers, you may want to specify which domain controller in a site will handle replication duties. The chosen domain controller is referred to as a bridgehead server. The domain controller that has the most unused bandwidth to another site is a good choice to be a bridgehead server.