Networking Basics: Part 5 – Domain Controllers

What domain controllers are and how they fit into your network infrastructure.

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.

As you can see, a domain controller performs a very important role within a Windows network. In the next part of this article series, I will talk more about domain controllers and about the Active Directory.