Active Directory

DNS COMPONENTS:

The DNS consists of three components. The first is a "Name Space" that establishes the syntactical rules for creating and structuring legal DNS names. The second is a "Globally Distributed Database" implemented on a network of "Name Servers". The third is "Resolver" software, which understands how to formulate a DNS query and is built into practically every Internet-capable application.

(A) Name Space:

The DNS "Name Space" is the familiar inverted tree hierarchy with a null node named "" at the top. The child nodes of the root node are the Top Level Domains (TLDs)-.com, .net, .org, .gov, .mil-and the country code TLDs, including .jp, .uk, .us, .ca, and so forth. Node names, known as labels, can be as many as 63 characters long, with upper- and lower-case alphabetical letters, numerals, and the hyphen symbol constituting the complete list of legal characters. Labels cannot begin with a hyphen. Upper- and lower-case letters are treated equivalently. A label can appear in multiple places within the name space, but no two nodes with the same label can have the same parent node: A node name must be unique among its siblings.

(B) Name Servers:

The second key component of the DNS is a globally connected network of "name servers". Each zone has a primary or master name server, which is the authoritative source for the zone's resource records. The primary name server is the only server that can be updated by means of local administrative activity. Secondary or slave name servers hold replicated copies of the primary server's data in order to provide redundancy and reduce the primary server's workload.

Furthermore, name servers generally cache data they have looked up, which can greatly speed up subsequent queries for the same data. Name servers also have a built-in agent mechanism that knows where to ask for data it lacks. If a name server can't find a domain within its zone, it sends the query a step closer to the root, which will resend it yet a step closer if it can't find the domain itself. The process repeats until it reaches a TLD, which ensures that the entire depth of the name space will be queried if necessary.

The combination of all the DNS name servers and the architecture of the system creates a remarkable database. There are more than 32 million domain names in the popular TLDs for which the whois utility works. Nominum, whose chief scientist, Paul Mockapetris, invented DNS, claims that there are more than 100 million domain names stored and that the system can easily handle 24,000 queries per second. The database is distributed-no single computer contains all the data. Nevertheless, data is maintained locally even though it's distributed globally, and any device connected to the IP network can perform lookups. The update serial number mechanism in each zone ensures a form of loose coherency on the network-if a record is out of date, the querier knows to check a more authoritative name server.

(C) Resolver:

The third component of the DNS is the "resolver". The resolver is a piece of software that's implemented in the IP stack of every destination point, or "host" in IETF-speak. When a host is configured, manually or through DHCP, it's assigned at least one default name server along with its IP address and subnet mask. This name server is the first place that the host looks in order to resolve a domain name into an IP address. If the domain name is in the local zone, the default name server can handle the request. Otherwise, the default name server queries one of the root servers. The root server responds with a list of name servers that contain data for the TLD of the query. This response is known as a referral. The name server now queries the TLD name server and receives a list of name servers for the second-level domain name. The process repeats until the local name server receives the address for the domain name. The local server then caches the record and returns the address or other DNS data to the original querier.newdiv

The Domain Name System (DNS) is basically a large database which resides on various computers and it contains the names and IP addresses of various hosts on the internet and various domains. The Domain Name System is used to provide information to the Domain Name Service to use when queries are made. The service is the act of querying the database, and the system is the data structure and data itself. The Domain Name System is similar to a file system in Unix or DOS starting with a root. Branches attach to the root to create a huge set of paths. Each branch in the DNS is called a label. Each label can be 63 characters long, but most are less. Each text word between the dots can be 63 characters in length, with the total domain name (all the labels) limited to 255 bytes in overall length. The domain name system database is divided into sections called zones. The name servers in their respective zones are responsible for answering queries for their zones. A zone is a subtree of DNS and is administered separately. There are multiple name servers for a zone. There is usually one primary nameserver and one or more secondary name servers. A name server may be authoritative for more than one zone.

DNS names are assigned through the Internet Registries by the Internet Assigned Number Authority (IANA). The domain name is a name assigned to an internet domain. For example, mycollege.edu represents the domain name of an educational institution. The names microsoft.com and 3Com.com represent the domain names at those commercial companies. Naming hosts within the domain is up to individuals administer their domain.

Access to the Domain name database is through a resolver which may be a program or part of an operating system that resides on users workstations. In Unix the resolver is accessed by using the library functions "gethostbyname" and "gethostbyaddr". The resolver will send requests to the name servers to return information requested by the user. The requesting computer tries to connect to the name server using its IP address rather than the name.

Let's say that your organization would like to look at Active Directory and wants to use an external namespace for your design. However, your environment currently uses multiple DNS namespaces and needs to integrate them into the same design. Contrary to popular misconception, integration of these namespaces into a single AD forest can be done through the use of multiple trees that exist in one forest. One of the most misunderstood characteristics of Active Directory is the difference between a contiguous forest and a contiguous DNS namespace. Many people do not realize that multiple DNS namespaces can be integrated into a single Active Directory forest as separate trees in the forest. For example, Figure 5.6 shows how Microsoft could theoretically organize several Active Directory domains that share the same forest but reside in different DNS namespaces.

Figure 5.6 Sample Active Directory forest with multiple unique trees within the same forest.

Only one domain in this design is the forest root, in this case microsoft.com, and only this domain controls access to the forest schema. All other domains, including subdomains of microsoft.comand the other domains that occupy different DNS structures, are members of the same forest. All trust relationships between the domains are transitive, and trusts flow from one domain to another.

If your organization currently operates multiple units under separate DNS namespaces, one option may be to consider a design such as this one. It is important to understand, however, that simply using multiple DNS namespaces does not automatically qualify you as a candidate for this domain design. For example, you could own five separate DNS namespaces and instead decide to create an Active Directory structure based on a new namespace that is contiguous throughout your organization. Consolidating your Active Directory under this single domain could simplify the logical structure of your environment while keeping your DNS namespaces separate from Active Directory.

If your organization makes extensive use of its separate namespaces, you may want to consider a design like this. Each domain tree in the forest can then maintain a certain degree of autonomy, both perceived and real. Often, this type of design will seek to satisfy even the most paranoid of branch office administrators who demand complete control over their entire IT structure.

To gain a greater understanding of the times an organization might use this particular design model, let's look at the following AD structure. City A is a local county governmental organization with a loose-knit network of semi-independent city offices such as the police and fire departments that are spread out around the city. Each department currently uses a DNS namespace for name resolution to all hosts and user accounts local to itself, which provides different e-mail addresses for users located in the fire department, police department, and other branches. The following namespaces are used within the city's infrastructure:

• citya.org

• firedeptcitya.org

• policeofcitya.org

• cityalibrary.org

The decision was made to merge the existing network environments into a single Active Directory forest that will accommodate the existing departmental namespaces but maintain a common schema and forest root. To accomplish this, Active Directory was established with citya.org as the namespace for the root domain. The additional domains were added to the forest as separate trees but with a shared schema, as shown in Figure 5.7.

Figure 5.7 Single Active Directory forest with separate directory trees for departments.

The individual departments were able to maintain control over their individual security and are disallowed from making changes in domains outside their control. The common forest schema and global catalog helped to increase collaboration between the varying organizations and allow for a certain amount of central administration.

NTLM, a Windows network authentication protocol, is a challenge/response system that allows a client to prove its identity without sending a password to the server. The Windows domain controller challenges the client to perform a complex mathematical calculation on the user's domain password and send this encrypted password to the domain controller. The domain controller then uses the same calculation to decrypt the password. If the decoded password matches the password obtained from the Security Account Manager (SAM) database, then the client is authenticated and may log into the network and access network resources.

NTLM is an abbreviation for Windows NT LAN Manager; it offers improved security over the now-obsolete LAN Manager protocol. The Indiana University network is configured to use only the latest version of this protocol: NTLMv2. This version provides increased security over NTLMv1.

A Real Time Communication (RTC) application may specify RTCAU_NTLM in the tag to indicate the client will accept NTLM authentication challenges.

Some of the information above comes from the Microsoft Development Network library.(Link)