Networking Basics: Part 2

So far in this article series, I have talked a lot about networking hardware and about the TCP/IP protocol. The networking hardware is used to establish a physical connection between devices, while the TCP/IP protocol is essentially the language that the various devices use to communicate with each other. In this article, I will continue the discussion by talking a little bit about the computers that are connected to a network.

Even if you are new to networking, you have no doubt heard terms such as server and workstation. These terms are generally used to refer to a computer’s role on the network rather than the computer’s hardware. For example, just because a computer is acting as a server, it doesn’t necessarily mean that it has to be running server hardware. It is possible to install a server operating system onto a PC, and have that PC act as a network server. Of course in most real life networks, servers are running specialized hardware to help them to be able to handle the heavy workload that servers are typically subjected to.

What might make the concept of network servers a little bit more confusing is that technically speaking a server is any computer that hosts resources over a network. This means that even a computer that’s running Windows XP could be considered to be a server if it is configured to share some kind of resource, such as files or a printer.

Computers on a network typically fall into one of three roles. Usually a computer is considered to be either a workstation (sometimes referred to as a client), server, or a peer.

Workstations are computers that use network resources, but that do not host resources of their own. For example, a computer that is running Windows XP would be considered a workstation so long as it is connected to a network and is not sharing files or printers.

Servers are computers that are dedicated to the task of hosting network resources. Typically, nobody is going to be sitting down at a server to do their work. Windows servers (that is, computers running Windows Server 2003, Windows 2000 Server, or Windows NT Server) have a user interface that is very similar to what you would find on a Windows workstation. It is possible that someone with an appropriate set of permissions could sit down at the server and run Microsoft Office or some other application. Even so, such behavior is strongly discouraged because it undermines the server’s security, decreases the server’s performance, and has the potential to affect the server’s stability.

The last type of computer that is commonly found on a network is a peer. A peer machine is a computer that acts as both a workstation and a server. Such machines typically run workstation operating systems (such as Windows XP), but are used to both access and host network resources.

In the past, peers were found primarily on very small networks. The idea was that if a small company lacks the resources to purchase true servers, then the workstations could be configured to perform double duty. For example, each user could make their own files accessible to every other user on the network. If a user happens to have a printer attached to their PC, they can also share the printer so that others on the network can print to it.

Peer networks have been traditionally discouraged in larger companies because of their inherent lack of security, and because they cannot be centrally managed. That’s why peer networks are primarily found in extremely small companies or in homes with multiple PCs. Windows Vista (the successor to Windows XP) is attempting to change that. Windows Vista will allow users on traditional client/server networks to form peer groups that will allow the users and those groups to share resources amongst themselves in a secure manner, without breaking their connection to network servers. This new feature is being marketed as a collaboration tool.

Earlier I mentioned that peer networks are discouraged in favor of client/server networks because they lack security and centralized manageability. However, just because a network is made up of workstations and servers, it doesn’t necessarily guarantee security and centralized management. Remember, a server is only a machine that is dedicated to the task of hosting resources over a network. Having said that, there are countless varieties of servers and some types of servers are dedicated to providing security and manageability.

For example, Windows servers fall into two primary categories; member servers and domain controllers. There is really nothing special about a member server. A member server is simply a computer that is connected to a network, and is running a Windows Server operating system. A member server might be used as a file repository (known as a file server), or to host one or more network printers (known as a print server). Member servers are also frequently used to host network applications. For example, Microsoft offers a product called Exchange Server 2003 that when installed on a member server, allows that member server to function as a mail server. The point is that a member server can be used for just about anything.

Domain controllers are much more specialized. A domain controller’s job is to provide security and manageability to the network. I am assuming that you’re probably familiar with the idea of logging on to a network by entering a username and password. On a Windows network, it is the domain controller that is responsible for keeping track of usernames and passwords.

The person who is responsible for managing the network is known as the network administrator. Whenever a user needs to gain access to resources on a Windows network, the administrator uses a utility provided by a domain controller to create a user account and password for the new user. When the new user (or any user for that matter) attempts to log onto the network, the users credentials (their username and password) are transmitted to the domain controller. The domain controller validates the user’s credentials by comparing them against the copy stored in the domain controller’s database. Assuming that the password that the user entered matches the password that the domain controller has on file, the user is granted access to the network. This process is called authentication.

On a Windows network, only the domain controllers perform authentication services. Of course users will probably need to access resources stored on member servers. This is not a problem because resources on member servers are protected by a set of permissions that are related to the security information stored on domain controllers.

For example, suppose that my user name was Brien. I enter my username and password, which is sent to a domain controller for authentication. When the domain controller authenticates me, it has not actually given me access to any resources. Instead, it validates that I am who I claim to be. When I go to access resources off of a member server, my computer presents a special access token to the member server that basically says that I have been authenticated by a domain controller. The member server does not trust me, but it does trust the domain controller. Therefore, since the domain controller has validated my identity, the member server accepts that I am who I claim to be and gives me access to any resources for which I have permission to access.

Domain Controllers

In the previous article in this series, I talked about the roles of various computers on a network. As you may recall, one of the roles that I talked a little bit about was that of a domain controller. In this article, I will talk more about what domain controllers are and how they fit into your network infrastructure.

One of the most important concepts in Windows networking is that of a domain. A domain is basically a collection of user accounts and computer accounts that are grouped together so that they can be centrally managed. It is the job of the domain controller to facilitate this central management of domain resources.

To see why this is important, consider that any workstation that’s running Windows XP contains a handful of built in user accounts. Windows XP even allows you to create additional user accounts on the workstation. Unless the workstation is functioning as a standalone system or is a part of a peer network, these workstation level user accounts (called local user accounts) are not used for controlling access to network resources. Instead, local user accounts are used to regulate access to the local computer. They act primarily as a mechanism which insures that administrators can perform workstation maintenance, without the end users having the ability to tamper with workstation settings.

The reason why local user accounts are not used to control access to resources outside of the workstation that they reside on is because doing so would create an extreme management burden. Think about it for a minute. Local user accounts reside on each individual workstation. This means that if local user accounts were a network’s primary security mechanism, then an administrator would have to physically travel to the computer containing an account any time a change is needed to be made to the account’s permissions. This might not be a big deal on smaller networks, but making security changes would be extremely cumbersome on larger networks or in situations in which a change is needed to be applied globally to all accounts.

Another reason why local user accounts are not used to control access to network resources is because they don’t travel with the user from one computer to another. For instance, if a user’s computer crashed, the user couldn’t just log on to another computer and work while their computer was being fixed, because the user’s account is specific to the computer that crashed. In order for the user to be able to do any work, a new account would have to be created on the computer that the user is now working with.

These are just a few of the reasons why using local user accounts to secure access to network resources is impractical. Even if you wanted to implement this type of security, Windows does not allow it. Local user accounts can only be used to secure local resources.

A domain solves these and other problems by centralizing user accounts (and other configuration and security related objects that I will talk about later in the series). This allows for easier administration, and allows users to log onto the network from any PC on the network (unless you restrict which machines a user can login from).

With the information that I have given you so far regarding domains, it may seem that the philosophy behind domains is that, since the resources which users need access to reside on a server, you should use server level user accounts to control access to those resources. In a way this idea is true, but there is a little more to it than that.

Back in the early 1990s I was working for a large insurance company that was running a network with servers running Novell NetWare. Windows networking hadn’t been invented yet, and Novell NetWare was the server operating system of choice at the time. At the time when I was hired, the company only had one network server, which contained all of the user accounts and all of the resources that the users needed access to. A few months later, someone decided that the users at the company needed to run a brand new application. Because of the size of the application and the volume of data that the application produced, the application was placed onto a dedicated server.

The version of Novell NetWare that the company was running at the time used the idea that I presented earlier in which resources residing on a server were protected by user accounts which also resided on that server. The problem with this architecture was that each server had its own, completely independent set of user accounts. When the new server was added to the network, users logged in using the normal method, but they had to enter another username and password to access resources on the new server.

At first things ran smoothly, but about a month after the new server was installed things started to get ugly. It became time for users to change their password. Users didn’t realize that they now had to change their password in two different places. This meant that passwords fell out of sync, and the help desk was flooded with calls related to password resets. As the company continued to grow and added more servers, the problem was further compounded.

Eventually, Novell released version 4.0 of NetWare. NetWare version 4 introduced a technology called the Directory Service. The idea was that users should not have a separate account for each server. Instead, a single user account could be used to authenticate users regardless of how many servers there were on the network.

The interesting thing about this little history lesson is that although domains are unique to Microsoft networks (Novell networks do not use domains), domains work on the same basic principle. In fact, when Windows 2000 was released, Microsoft included a feature which is still in use today called the Active Directory. The Active Directory is very similar to the directory service that Novell networks use.

So what does all of this have to do with domains? Well, on Windows servers running Windows 2000 Server, Windows Server 2003, or the forthcoming Longhorn Server, it is the domain controller’s job to run the Active Directory service. The Active Directory acts as a repository for directory objects. Among these objects are user accounts. As such, one of a domain controller’s primary jobs is to provide authentication services.

One very important concept to keep in mind is that domain controllers provide authentication, not authorization. What this means is that when a user logs on to a network, a domain controller validates the user’s username and password and essentially confirms that the user is who they claim to be. The domain controller does not however tell the user what resources they have rights to.

Resources on Windows networks are secured by access control lists (ACLs). An ACL is basically just a list that tells who has rights to what. When a user attempts to access a resource, they present their identity to the server containing the resource. That server makes sure that the user’s identity has been authenticated and then cross references the user’s identity with an ACL to see what it is that the user has rights to.

Windows Domain

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 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.