The Windows 2000 Active Directory infrastructure is both an exciting and in depth technology. In order to decide how to implement Windows 2000 Active Directory, IT management and IT technical personnel should be familiar with the following concepts:

This document will hopefully provide ample information in order to support individuals in getting started in considering the use of Active Directory.

This document will be used to communicate the concepts regarding Active Directory. Within this document, we take an all-encompassing view of the Active Directory that includes not only the Active Directory itself, but also the related protocols and services that can be tightly integrated with Active Directory when implementing Windows 2000.

For the most part, active directory can be considered as the output of two major initiatives within Microsoft. The first would be to standardize the protocols that are used for communications within the Microsoft "domain" infrastructure to greater adhere to the IETF standards. The second would be to provide a centralized directory for managing the data that is accessed by these protocols.

The NT 4.0 domain infrastructure was developed at a time when the "Internet" protocols were not as prevalent as they are today. In fact, many of today’s more popular protocols, such as LDAP, were either in their infancy or non-existent when NT 4.0 was being developed. As a result, NT 4.0 makes use of several legacy and proprietary protocols in order manage domain communications. The following protocols are used prevalently within the NT 4.0 infrastructure (although some may be optional):

The above protocols are implemented in a proprietary manner within NT 4.0 and are known to have severe limitations with regards to scaling, management, and adherence to standards. Although Windows 2000 supports these legacy protocols for backwards compatibility, they are by no means required in a pure Windows 2000 network since Active Directory and it’s associated standard protocols provide similar functionality. In Windows 2000, the following additional protocols have enhanced and made mandatory:

Within the NT 4.0 infrastructure, many of the protocols were also associated with a certain database type. WINS, NTLM, etc. would access disparate, separately managed databases. Also, applications such Exchange Server would have their own directory database type and schema.

Windows 2000, on the other hand, uses the Active Directory database and schema for managing many different types of data. Information such as users, DNS zones, hosts, and Exchange directories can and in some cases must exist within the active directory, effectively negating the need to manage several different databases throughout the enterprise.

In summary, Windows 2000 active directory consists primarily of a type of database that must be accessed by specific type of protocols in order to manage and share information that is required within a distributed environment. Standard protocols such as LDAP, DNS, and Kerberos, which are more commonly used within the UNIX community, are used to access and store data within the Active Directory database. The protocols are also complimented with proprietary technology and protocol extensions that are specific to Windows 2000 Active Directory, these protocols are necessary when standards by international standards bodies have not yet been defined. It is also important to mention that Windows 2000 domain security boundaries cannot be implemented without an Active Directory infrastructure.

We discussed the prevalent protocols within Windows 2000 Active Directory in the previous section. Here we detail how these protocols are used by Windows 2000 in order to provide services.

The DNS is used within the Windows 2000 Infrastructure in order to achieve Name Resolution and Service Location on the Network

Name Resolution

DNS name and reverse resolution within Windows 2000 is similar to that of standard DNS services found on the Internet. The protocol is compatible with other DNS implementations such as BIND and its related resolver libraries.

The Windows 2000 implementation of DNS also supports secure dynamic updates to the DNS. This has been done in order to provide the same level of functionality that is available within the WINS infrastructure. Using this technology, a machine on the network can automatically have the DNS information for its hostname altered in, added to, or deleted from the DNS. DNS zone information can be stored in traditional human readable "zone files", however the benefits of Active Directory’s multi-master replication as well as other features make Active Directory enabled DNS a secure, powerful, and scalable name resolution system.

Finding Resources

Another crucial role of the DNS in Windows 2000 is for locating services on the network. This is achieved by storing this information in the DNS as a "SRV" record.

For example, a machine within the "flonetwork.com" domain may resolve the name of the local LDAP server (Domain Controller) by issuing a request of type "SRV" for "ldap.tcp.flonetwork.com". The DNS server would respond with the name of the Domain Controller. The local machine would then submit a request of type "A" for the host name that has been returned. The DNS server would then respond with the IP address of the host and at this point the local machine would then be able to use the LDAP protocol for accessing directory services on the network.

The LDAP protocol is used as the standard directory access protocol within Windows 2000 Active Directory. In fact, Active Directory is, for the most part, simply another implementation of LDAP. LDAP is typically used for accessing the following types of information within Windows 2000:

While it is not feasible to detail LDAP within this document, the following information is vital for understanding the use of LDAP within Windows 2000).

Because the LDAP standard is not very specific regarding how/what data is stored within a database, the Windows 2000 Active Directory also consists of several elements that are specific to its implementation. In particular, it is important to note that objects within the Active Directory are subdivided into the following database partitions by default:

The Kerberos protocol and its related services were developed at MIT and have been in use in the UNIX environment for several years. For the most part, Kerberos is used for authenticating users within a systems environment. The system provides a key granting mechanism. Once an authentication has taken place, this key or ‘ticket’ may be used to access other resources on the network without need for the user/service to authenticate again. It is important to note that, while the user/service does not have to authenticate several times in order to access different services, use of the ticket system will provide the user/service with access to only those resources which the user account has the privilege to access.

While Kerberos is used as a protocol for authenticating users (among other things) it is important to note that the actual information regarding the user accounts, and perhaps the very resource the account may accessing, reside within the Active Directory LDAP database. As you can see, Kerberos is tightly integrated with the Active Directory in order to manage distributed authentication. The ability to authenticate users from other domains (within the same forest) is enabled by Active Directory’s two way transitive trusts that are set-up automatically between domains. These trusts are a function of both the Kerberos and Active Directory components in Windows 2000.

The Active Directory infrastructure also makes use of several logical components. These include:

An Active Directory site defines a set of TCP/IP subnets in a location that houses any number of Active Directory Servers that are connected by a high speed network (10Mbps+). This information is crucial to the Active Directory in order to control how often data is replicated across the network. Replication of data from one site to another is done less often than within a single site.

In Windows 2000, the "Domain" concept is based on the DNS domain (such as "cybererasmo.com"). Management of each domain can be relegated to the administrators who manage the computers within the domain. Each domain has its own administrative boundaries and its own security policies that are managed by the domain administrator. A domain can span multiple geographical locations. A collection of domains that trust each other and which have a contiguous DNS namespace (e.g. "cybererasmo.com", "corp.cybererasmo.com") are considered to be domain "trees" in an Active Directory forest.

An OU is defined within the LDAP database. Organizational Units are used to contain objects such as user objects, computer objects, etc. Organizational Units can be used to organize objects in a manner that lends itself to delegation of management over these objects (people etc.). Also, group policy is applied via the OU policies (it is important to note that group policies can also be applied to sites and domains). These organizational units reside only within the domain that the OU is created in.

An Active Directory forest consists of one or more domains trees that do not necessarily have to share a contiguous namespace. For example, the domain trees for "flonetwork.com" and "mediasynergy.com" may co-exist in the same forest.

All domains within an Active Directory forest have two-way transitive trust relationships (a function of Kerberos) applied by default. This allows administrators of the different domains to access information regarding users and resources within a different domain for administrative purposes, such as automated login. It is important to note, however, that users within the domain cannot access resources in a different domain unless the administrator of the different domain has specifically granted access.

All domains within an Active Directory forest also share the same LDAP schema. Because the domains share the same schema, they can easily replicate data back and forth. Domains that reside in different forests, and hence which have different schemas, cannot easily replicate data to each other.

In order for machines on the network to gain access to the Active Directory and its related services, certain types of machines or services must exist on the network. These include:

DNS and Kerberos have been discussed in previous sections. Here we present important information regarding the Domain Controller, Global Catalog Server, and Domain Controller FSMO roles.

The Domain Controller is, in fact, an LDAP/Active Directory server. The server contains an LDAP database containing information about users, resources, domain relationships, etc. There may be several Domain Controllers throughout the enterprise.

The Domain Controllers support replication of the LDAP information. Furthermore, any Domain Controller can accept most updates to the LDAP database. This data is then replicated to other Domain Controllers. The rule of thumb regarding updates to the LDAP database is that the latest update is always considered the most "correct" update.

Workstations and Servers on the network must use the Active Directory Domain Controllers for accessing objects (such as: resource information, user information, etc.) if the legacy NetBIOS protocol is removed from the network.

Because using the LDAP database directly would not be efficient for finding enterprise wide resources every time a resource is required, the Global Catalog Server is configured to cache certain information from Domain Controllers. The GC also builds indexes for this data, in order to further improve response time for searches.

A Global Catalog is by default a Domain Controller, but contains specific additional information used for locating resources enterprise wide. In some sense in could be referred to as a ‘Super Domain Controller’.

Location and use of the GC is crucial in order to provide users/services with access to resource information as well as for logon validation and for providing lookup information for such applications as Exchange 2000.

Some special operations in Windows 2000 Active Directory require the use of a single master replication to control functions that cannot use multi master replication that domain controllers normally perform. There are five types of FSMO roles, but two types specifically control enterprise wide operations that concern the overall schema and configuration partitions. These two roles exist on only one domain controller in the entire enterprise and are strictly controlled for security reasons by a central administration team.

Based on the above characteristics, it is important to take the following into account when designing a rollout of Windows 2000 Active Directory:

The Windows 2000 Active Directory Implementation attempts to provide a centralized database for managing a distributed environment. Further more, standard protocols such as LDAP, DNS, and Kerberos are implemented in and around Active Directory in order to provide better support for industry standards within Windows 2000.

Windows 2000 Active Directory, by design, is much more secure, scaleable and manageable than the traditional NT distributed management services.

The Active Directory Infrastructure is also very in depth, in comparison to NT 4.0 management resources. As a result, when rolling out Windows 2000, management and technical personnel must decide:

Back to Home