In part 1 of this series, we introduced the Active Directory (AD) service, arguably the most important feature in the Windows 2000 server. We discussed the AD domain model and explained a number of basic AD terms and concepts.
You can get up to speed on AD basics by checking out the first article in this series:
In this second installment, we’ll take a look at resource name resolution, object rights, tree replication, and limitations.
Resource name resolution
To exchange all the data between servers, AD must know how to address the AD servers. Active Directory uses Domain Name Services (DNS) for this address resolution. DNS uses Internet Protocol (IP), and that means if you are not using Transmission Control Protocol/IP (TCP/IP) on your network, you will not be able to use Active Directory.
Also, if you are currently using TCP/IP on your network and you are using Dynamic Host Configuration Protocol (DHCP), you will have to implement Dynamic DNS (DDNS). Unfortunately, DDNS is so new that you can’t use existing DNS server software, including the NT 4.0 DNS server, to support it.
At the time of this writing, DDNS had a few other problems. First, while DDNS can store the information about the location of the resource, it has no way of telling whether the resource is actually active. The DDNS server provides the name and location of the service to your client. The client then must check all the locations to make sure that the resources are available.
Active Directory cannot use Windows Internet Naming Service (WINS) for address resolution. But AD can share information with any application or directory that uses Lightweight Directory Access Protocol (LDAP) or Hypertext Transfer Protocol (HTTP).
If you’d like to learn more about enterprise migration to Windows 2000, download our free Windows 2000 WhitePaper , which aims to bring you up to speed on what you can expect with Microsoft’s forthcoming OS.
Active Directory represents network resources in the form of objects. Objects that can have rights to access other objects are called security principals. In AD, the only security principals you have are user or group objects.
To understand the effect of this, assume you wanted to allow all the people in your branch office to access a printer. In an Active Directory environment, you’d have to grant rights to each user or create a BranchOffice group and assign rights to the group.
AD uses Access Control Lists (ACLs) to control the rights objects have. ACLs control who can do what with an object and what an object can do.
Active Directory uses static inheritance to allow rights to flow from one object to another. When you assign rights to higher container objects, the rights can flow down, but not without your help. You must go to the subordinate object and validate the rights granted to the superior object.
Active Directory’s static inheritance may cause performance problems on your network. Because each object must update its ACL list to accept the rights you grant, more traffic flows over the network in a multi-server environment.
For example, if you make one update to an object controlling 100 objects in an AD environment, each object’s ACL lists must update. These 100 object updates must then replicate to each server DC (domain controller) in the AD tree. If you have many servers or have your tree divided across WAN links, this can take quite a lot of your network’s bandwidth.
Active Directory limits the ability to grant rights to users beyond an administrative scope. Administrative scopes can go down only to the individual OU (organizational unit) level. This means that you can grant a user administrative rights only over an organizational unit, not an individual object.
Unfortunately, in an Active Directory environment, administrative rights can’t flow across domain boundaries using trust relationships. When you grant administrative rights at the top of the AD tree, the rights may not flow to the bottom of the tree if you have multiple domains in your tree. You must grant the administrative rights at each domain.
Tree partitioning and replication
As you add more servers, your network directory becomes more complex and more key to the smooth operation of your network. Fortunately, Active Directory allows you to break your directories down into manageable units called partitions. You can then spread the information in your directory trees among servers on your network by replicating the partitions.
AD doesn’t first use time stamps for detecting updates. Instead, it uses Update Sequence Numbers (USNs). Any time you make a change to an object, Active Directory gives it a USN.
The servers check each other on a regular basis and compare the USNs of their objects. If a server finds that a neighbor has a USN for an object higher than its own, it copies the change to its replica of the database and increments its USN to match.
If, for some reason, two servers have identical USN updates for the same object, AD checks the time stamps of the update. After finding the USN with the latest time stamp, it makes the update.
AD allows you to create replicas only at the domain level. If you have servers spread across WAN links, you’ll need to create domains at each site and trust relationships between them. If you don’t, you may create a situation where replications take place over slow WAN links, saturating your WAN with needless traffic.
Currently, Microsoft has no plans to support client operating systems for any platform other than Microsoft-based operating systems. Even in that universe, you’re limited. Microsoft recommends that you upgrade Windows NT Workstation clients to Windows 2000 when it ships. Microsoft will ship software for Windows 9x clients to allow them to see Active Directory servers. If you’re running other Microsoft operating systems, such as MS-DOS or Windows 3.x, you’re out of luck. You’re also out of luck if your clients run a non-Microsoft operating system such as the Mac OS, Linux, or OS/2.
If you’d like to share your opinion, please post a comment below.