Centralization sums up my primary reason for implementing Active Directory. The Active Directory structure makes it possible for you to achieve truly centralized management of users, regardless of how big your client’s network has become. If you’ve worked with Windows NT before, you know that in Windows NT a domain is a completely independent entity. While it’s possible to create a trust relationship between domains that exist on a common network, the domains are never truly integrated with each other because there is no higher authority that manages the domains. The situation is different with Active Directory. Whereas the domain level was the highest level of abstraction in Windows NT, the highest level of abstraction in Windows 2000 and 2003 Server is the forest, which is basically a collection of domains.
Microsoft chose to call this unit a forest because you can place domains into the forest, and you can place entire trees of domains into it. A domain tree consists of a parent, child, grandchildren, and great grandchildren domains. You can have as many layers of subdomains within a domain tree as is necessary to achieve the desired organizational structure. The Active Directory domain structure is handy to have whether your client’s network is big or small.
As you may recall, in Windows NT, each domain had its own Administrator account and its own Domain Admin group that was responsible for managing that domain. In Windows 2000 and 2003 Server, the domain Administrator account and the Domain Admin group still exist and can be used the same way that you were used to using them in Windows NT. There is also an Enterprise Admin group. Members of this group can manage any object within the entire Active Directory, regardless of what domain it exists within.
Managing trust relationships
The first time that someone tried explaining the concept of parent and child domains, forests, and trees to me, my head was spinning. All I could think about was that managing trust relationships for an organization that made use of all of these structures must be a real chore. However, managing trust relationships in Windows 2000 and 2003 Server is much easier than in Windows NT because there are essentially no trusts to manage. Within a forest, every domain trusts every other domain automatically. The only time you’d really have to worry about managing trust relationships would be if you had a relationship between domains residing within different forests.
The only time that you would likely have to set up an interforest relationship would be if you needed to set up a trust relationship with a domain in another company’s network. These enhanced management capabilities make Windows 2000 and 2003 Server more scalable than Windows NT. This is especially true for larger organizations. Windows NT has a limit of about 40,000 objects within a domain. Windows 2000 Server expands this limit to over 10 million objects. I have not yet seen the object limit figures for Windows 2003 Server, but I’m sure that it’s possible to have over 10 million objects.
Organizational units improve scalability
Another way that Active Directory improves scalability in large organizations is through the use of organizational units (OUs). An OU is basically a collection of users and computers. The idea is that if you have a large domain, you can organize the domain into OUs. For example, suppose that your client’s company used one large domain that spanned the entire corporation. Normally, this would mean that the administrative team would be responsible for managing the entire domain and all of the objects within it. Now imagine that your client’s company has a really large finance department and that the finance department’s secretary is good with computers. You could create an OU named FINANCE and move all of the user accounts and computer objects for the finance department into this OU.
After doing so, you could delegate the authority to reset passwords for this OU to the finance secretary. When someone in finance needed a password reset, they wouldn’t have to contact the help desk; they could just ask the secretary. This would give the department faster turnaround on password resets and free the help desk from some of the administrative burden. When you delegate authority to an OU, the person that you’re delegating control to only has the permissions that you allow and only for that OU.
Therefore, the secretary in finance wouldn’t be able to reset passwords for the rest of the company. The secretary also would not be able to perform any other administrative tasks within the OU, unless, of course, you delegated additional permissions. If you like the idea of delegating authority, you’ll be happy to know that you can also delegate authority to create, delete, or manage user accounts or groups within the OU.
Multimaster replication and sites
Another cool benefit of an Active Directory environment is the concept of sites and multimaster replication. In Windows NT, when you make a change to the SAM, the change is applied directly to the PDC and is later replicated to each BDC. In an Active Directory multimaster replication environment, each domain controller contains a copy of Active Directory, not just the information for a single domain. Therefore, when a change is made to Active Directory, the change is applied to whatever domain controller is the closest, and is then replicated to the remaining domain controllers. This prevents a designated PDC from being overburdened. You can really see the benefits of multimaster replication when you consider how sites work. Sites are a logical Active Directory structure completely independent from domains.
The idea is that if part of a domain is connected by a slow link, you may designate each side of the link as a separate site. Each site has its own domain controller. Therefore, when someone within a site needs to make an Active Directory update, the updates are applied to the domain controller within the site. The changes are collected and then replicated to the domain controller on the other side of the site link at preset intervals. This domain controller is known as a bridgehead server. It’s the bridgehead server’s job to intercept the updates and replicate them to the remaining domain controllers. Sites can be a little complicated to understand, but the basic idea is that they greatly decrease the amount of traffic that must flow across your slow or high-cost network links.