If you would like to read the other parts in this article series please go to:
- Networking Basics: Part 1 – Networking Hardware
- Networking Basics: Part 2 – Routers
- Networking Basics: Part 3 – DNS Servers
- Networking Basics: Part 4 – Workstations and Servers
- Networking Basics: Part 5 – Domain Controllers
- Networking Basics: Part 7 – Introduction to FSMO Roles
- Networking Basics: Part 8 – FSMO Roles continued
- Networking Basics: Part 9 – Active Directory Information
- Networking Basics: Part 10 – Distinguished Names
- Networking Basics, Part 11: The Active Directory Users and Computers Console
- Networking Basics: Part 12 – User Account Management
- Networking Basics: Part 13 – Creating Groups
- Networking Basics: Part 14 – Security Groups
- Networking Basics: Part 15 – Universal Groups & Group Nesting
- Networking Basics: Part 16 – The Windows Operating System’s Role in Networking
- Networking Basics: Part 17 – The OSI Model
- Networking Basics: Part 18 – Sharing Resources
- Networking Basics: Part 19 – Share Level Permissions
In the previous article in this series, I introduced you to the concept of domains and domain controllers. In this article, I want to continue the discussion by talking about the anatomy of a Windows domain.
As I explained in Part 5 of this article series, domains are not something new. Microsoft originally introduced them in Windows NT Server. Originally, domains were completely self contained. A single domain often housed all of the user accounts for an entire company, and the domain’s administrator had complete control over the domain and anything in it.
Occasionally though, having a single domain just wasn’t practical. For example, if a company had offices in several different cities, then each office might have its own domain. Another common scenario is when one company buys another company. In such situations, it is not at all uncommon for both companies to already have domains.
In situations like these, it is sometimes necessary for users from one domain to access resources located in another domain. Microsoft created trusts as a way of facilitating such access. The best way that I can think of to describe trusts is to compare them to the way that security works at an airport.
In the Untied States, passengers are required to show their drivers license to airport security staff before boarding a domestic flight. Suppose for a moment that I were going to fly somewhere. The security staff at the airport does not know who I am, and they certainly don’t trust me. They do however trust the state of South Carolina. They assume that the state of South Carolina has exercised due diligence in verifying my identity before issuing me a drivers license. Therefore, I can show them a South Carolina drivers license and they will let me on the plane, even though they don’t necessarily trust me as an individual.
Domain trusts work the same way. Suppose that I am a domain administrator and my domain contains resources that users in another domain need to access. If I am not an administrator in the foreign domain then I have no control over who is given user accounts in that domain. If I trust the administrator of that domain not to do anything stupid, then I can establish a trust so that my domain trusts members of the other domain. In a situation like this, my domain would be referred to as the trusting domain, and the foreign domain would be known as the trusted domain.
In the previous article, I mentioned that domain controllers provide authentication, not authorization. This holds true even when trust relationships are involved. Simply choosing to trust a foreign domain does not give the users in that domain rights to access any of the resources in your domain. You must still assign permissions just as you would for users in your own domain.
At the beginning of this article, I mentioned that in Windows NT a domain was a completely self contained environment, and that trusts were created as a way of allowing users in one domain to access resources in another domain. These concepts still hold partially true today, but the domain model changed dramatically when Microsoft created the Active Directory. As you may recall, the Active Directory was first introduced in Windows 2000, but is still in use today in Windows Server 2003 and the soon to be released Longhorn Server.
One of the primary differences between Windows NT style domains and Active Directory domains is that domains are no longer completely isolated from each other. In Windows NT, there was really no organizational structure for domains. Each domain was completely independent of any other domain. In an Active Directory environment, the primary organizational structure is known as a forest. A forest can contain multiple domain trees.
The best way that I can think of to compare a domain tree is to compare it to a family tree. A family tree consists of great grandparents, grandparents, parents, children, etc. Each member of a family tree has some relation to the members above and below them. A domain tree works in a similar manner, and you can tell a domain’s position within a tree just by looking at its name.
Active Directory domains use DNS style names, similar to the names used by Web sites. In Part 3 of this article series, I explained how DNS servers resolve URLs for Web browsers. The same technique is used internally in an Active Directory environment. Think about it for a moment. DNS stands for Domain Name Server. In fact, a DNS server is a required component for any Active Directory deployment.
To see how domain naming works, let’s take a look at how my own network is set up. My network’s primary domain is named production.com. I don’t actually own the production.com Internet domain name, but it doesn’t matter because this domain is private and is only accessible from inside my network.
The production.com domain is considered to be a top level domain. If this were an Internet domain, it would not be a top level domain, because .com would be a top level domain and production.com would be a child domain of the .com domain. In spite of this minor difference, the same basic principle holds true. I could easily create a child domain by creating another domain name that encompasses production.com. For example, sales.production.com would be considered to be a child domain of the production.com domain. You can even create grandchild domains. An example of a grandchild domain of production.com would be widgets.sales.production.com. As you can see, you can easily tell a domain’s position within a domain tree just by looking at the number of periods in the domain’s name.
Earlier I mentioned that an Active Directory forest can contain domain trees. You are not limited to creating a single domain tree. In fact, my own network uses two domain trees; production.com and test.com. The test.com domain contains all of the servers that I monkey around with while experimenting with the various techniques that I write articles about. The production.com domain contains the servers that I actually use to run my business. This domain contains my mail server and some file servers.
The point is that having the ability to create multiple domain trees allows you to segregate your network in a way that makes the most sense from a management prospective. For example, suppose that a company has offices in five different cities. The company could easily create an Active Directory forest that contains five different domain trees; one for each city. There would most likely be a different administrator in each city, and that administrator would be free to create child domains off of their domain tree on an as needed basis.
The beauty of this type of structure is that all of these domains fall within a common forest. This means that while administrative control over individual domains or domain trees might be delegated to an administrator in another city, the forest administrator ultimately maintains control over all of the domains in the forest. Furthermore, trust relationships are greatly simplified because every domain in the forest automatically trusts every other domain in the forest. It is still possible to establish trusts with external forests or domains.
Conclusion
In this article, I have talked about the organizational structure used in creating Active Directory domains. In the next part of this article series, I will talk about how network communications work in an Active Directory environment.
If you would like to read the other parts in this article series please go to:
- Networking Basics: Part 1 – Networking Hardware
- Networking Basics: Part 2 – Routers
- Networking Basics: Part 3 – DNS Servers
- Networking Basics: Part 4 – Workstations and Servers
- Networking Basics: Part 5 – Domain Controllers
- Networking Basics: Part 7 – Introduction to FSMO Roles
- Networking Basics: Part 8 – FSMO Roles continued
- Networking Basics: Part 9 – Active Directory Information
- Networking Basics: Part 10 – Distinguished Names
- Networking Basics, Part 11: The Active Directory Users and Computers Console
- Networking Basics: Part 12 – User Account Management
- Networking Basics: Part 13 – Creating Groups
- Networking Basics: Part 14 – Security Groups
- Networking Basics: Part 15 – Universal Groups & Group Nesting
- Networking Basics: Part 16 – The Windows Operating System’s Role in Networking
- Networking Basics: Part 17 – The OSI Model
- Networking Basics: Part 18 – Sharing Resources
- Networking Basics: Part 19 – Share Level Permissions
This article is very useful for the networking basics.
Thank you so much for provide this information and knowledge about it.
I am glad that you like it.