Once you’ve gotten the first four things done, then your job’s finished, in a sense—people can now read and write files on that file server, view pages on that Web server, print to that shared printer, set up meetings with you over your scheduling server, and so on. I mean, hey, networking’s all about sharing, so just open the doors and let ’em in!
As you’ve probably realized, there’s a missing piece here: security. While there’s a lot to security, it basically boils down to two things: authentication and permissions.
◆ First, you want to be able to identify who’s entering your network. That’s authentication.
◆ Second, once you know for sure who you’re talking to—once you’ve authenticated—then you must be able to look up somewhere what that person is allowed to do, his permissions. For example, a network logon could figuratively go something like, “Okay, now I know you’re Jack…but I’ve been told to deny Jack access to everything.” Merely being authenticated doesn’t mean that you get access!
Authentication
The first part of security is called authentication, and you usually accomplish it through usernames and passwords, although as time goes on you’ll eventually use the more science-fiction means of authentication: One day, the computer may recognize you by your fingerprint, face, voice, retina blood vessel pattern, or some other item that’s distinctly you. The geek term for those authentication approaches is biometric.
For now, however, it’s user accounts and passwords that identify users. I realize that nearly every- one who’s reading this book has undergone an authentication at some point—you’ve logged in to a network some time. It all sounds simple, doesn’t it? And yet user accounts and passwords present special problems.
Storing Authentication Information
First, you’ll need some kind of program that lets administrators create user accounts and store them in a file. In their simplest form, user accounts consist of a database of usernames and passwords. That’s no big deal—it’s a very simply structured database, and there are tons of database programs out there—but don’t forget that you need to encrypt that information. Otherwise, there’s the possi- bility that someone could come along and steal the database file, take it home, and perhaps crack it for your user’s passwords.
Just such a thing happened to NT 4. NT stored user information in a file named SAM. If you leave me in the same room as your server, then I can copy that SAM onto a floppy and take it off-site to analyze it. Wasn’t it encrypted? Well, yes, but sometimes encryption isn’t enough—a group of hackers figured out how to crack SAM’s encryption. With just a bit of work, anyone could extract passwords from an NT SAM. (Which is a good reason to keep your servers behind lock and key, so that it’s harder for someone to steal your account files.) Windows 2000- and 2003-based domains (a term I’ll define soon) use a more sophisticated encryption scheme on its user account/password file (which is named NTDS.DIT, not SAM), but unfortunately even that file can be cracked with some determination. Again, let me stress that this is only a danger if you let someone physically sit down at the servers that do logons, a set of servers called domain controllers, so don’t worry that 2003 isn’t secure. Any security person can tell you that you should never give the bad guys physical access to your important servers—lock ’em up!
28 CHAPTER 2 THE BASICS: NETWORKING SOFTWARE, SERVERS, AND SECURITY
The tool that lets administrators create, modify, or delete user accounts is called Active Directory Users and Computers. Active Directory refers to Windows 2000 and 2003’s system for storing user- names and passwords. It’s called a directory because directory is the current network lingo for “database of user accounts.” Personally, I think it’s kind of confusing—in my mind, directory conjures up visions of drive letters, like C:\DOS—but it’s the current argot, so it’s worth knowing. And, in case you’re wondering, the “Active” part is just Microsoft marketing; don’t look for any deep meaning there. (It’s not like Novell makes a product called Comatose Directory or Lethargic Directory.) Authenticating without Compromising Security
So you’ve got a server somewhere that contains the list of usernames and passwords. Those are only good if someone can use her username and password to be authenticated and get access to things on the network. So you need some way for a user sitting at her workstation computer to be recognized by that server. You’re already familiar with this recognition process: we call it logging on.
Suppose I’m sitting at my Windows XP workstation and I want to get to some files on a file server named files-r-us.bigfirm.biz. Before files-r-us will give me access, I’ve got to submit myself for authentication—I’ve got to log on. One of the many programs that comes with every version of NT since version 3.1 is called winlogon.exe, and it’s the program that pops up when you first turn your workstation on, asking you to punch in your username, password, and domain. (Again, I’ll explain what a domain is in a minute.)
So imagine that I’m trying to access some data on files-r-us. Files-r-us responds by asking my workstation, “What’s his name and password?” Now I’ve got a problem.
You see, what I’d like to do is to just say over the network line, “This is Mark and his password is ‘swordfish.’” Then files-r-us can just look in its directory file of usernames and passwords and see if it has a user named Mark with a password of “swordfish.” If so, then it lets me in. If not, it doesn’t. Simple, eh?
Well, there’s one flaw here—the part where my workstation passes “swordfish” over the network. A class of programs called “sniffers” can record and display any data that passes over a network wire. So passing passwords around on an unencrypted Ethernet cable isn’t a great idea. That means you’ve got another challenge: how to prove to a server across the network from you that you’ve got Mark’s password without actually showing that password to the server.
Over time, networks have come up with different answers, but Active Directories, whether based on Windows 2000 or 2003, use an old authentication method called Kerberos which some folks at MIT first invented in the mid ’80s. It replaces an older method employed by NT 3.x and 4 called NTLM, which was short for NT LAN Manager, a reference to one of NT’s predecessors. What follows is an extremely simplified version of how Kerberos works. (It’s actually a wildly simplified description, but it’ll help you understand the more complete explanation that you’ll see in the next section.)
Let’s return to files-r-us. I try to access its data, so files-r-us needs to first log me in. It does that by saying, “I’ll tell you how to access my data,” and sends me some instructions on how to get to its data. But the data is encrypted—with my password! In other words, anyone could claim to be me, and files-r-us would happily send these vital instructions-for-connection. But only I can decrypt those instructions, so only I can benefit from them. So files-r-us ensured that only someone with my password could gain access, without sending my password over the wire.
WHAT’S THE POINT OF NETWORKS AND NETWORKING? 29
Centralizing and Sharing User Account Information: Domains
But my simple example about trying to access one file server is, well, a bit too simple. Most com- panies will end up with more than one server, and in fact it’s not unusual to end up with dozens or hundreds of servers. And that leads to the following problem. Recall that I said a page or so back that if you’re going to employ user accounts, then you’ll need a file to store them in. But what if you have more than one server? What if in addition to the server named files-r-us.bigfirm.biz, I’ve also got a mail server named postoffice.bigfirm.biz and a Web server named www.bigfirm.biz? I might want to log in to any one of those three, so they all have to be able to accomplish logons. But now let’s examine what that actually means in terms of keeping track of user accounts. Should each server contain a complete copy of NTDS.DIT, the file containing the names and passwords for users?
That might work, but it’d be a pain, for several reasons. First, NTDS.DIT can get pretty big, and I’d end up burning up a lot of disk space copying it to every server in my enterprise. Second, if servers are connected by low-speed WAN links, the process of copying the changes to NTDS.DIT to all of the servers on my network (a process called directory replication) would take up a lot of time and network band- width. Third, do I really want to have to create a network “storm” of file copying amongst the servers every time someone just changes his password? And finally, what about the issue of securing the NTDS.DIT file in the first place? If I copy NTDS.DIT to every single server in the enterprise, there are bound to be a few that are out in the open, not physically secured. It’d be easy for an intruder to copy the NTDS.DIT from a poorly secured computer and spirit it off-site, to crack it at leisure.
The better idea that we’ve used in networks for years is to put the user directory, the NTDS.DIT, not on every single server, but instead on a relatively small subset of the servers. Those NTDS.DIT-holding servers then serve in the role of logon server, doing the job of authenticating for the other servers. In Microsoft parlance, a logon server is more commonly called a domain controller. So, to return to the example of accessing data on files-r-us, imagine that files-r-us is not a domain controller and doesn’t contain a copy of NTDS.DIT, and that another computer, vault.bigfirm.biz, is a domain controller and contains a copy of NTDS.DIT. In this newer arrangement, I don’t directly log into files-r-us but instead enlist the aid of vault.bigfirm.biz in order to authenticate with files-r-us.
In a purely Active Directory network (which can only include Windows 2000, XP, and 2003 sys- tems), vault.bigfirm.biz would help me log in to files-r-us with Kerberos. In order to understand how Kerberos works, you first need to understand that under Kerberos, not only do the users have pass- words, the server programs do also. Thus, the file server program running on files-r-us has its own password. So both the user and the server each have passwords—remember that.
When I tell my workstation to try to get some data from files-r-us, my workstation sees that it’ll need to get me logged in to files-r-us. It does that by asking the domain controller, vault, to give me something called a “ticket” to the file server service on files-r-us. The domain controller responds by handing my workstation an encrypted piece of data, which is the Kerberos ticket.
The ticket can be decrypted with my password, making its contents a mystery to anyone but me (or my workstation, which obviously knows my password). My workstation decrypts the ticket, which contains two things. First, it contains a message saying “your special one-time-only password for accessing the file server at files-r-us is ‘opensesame.’” Second, it contains another encrypted message—but this one’s not encrypted with my password, so I can’t decrypt it! But my workstation knows to send it to the file server, which decrypts it successfully, as the file server has its own passwords. Once the file server receives and decrypts the part of the Kerberos ticket that I sent it, the file server
30 CHAPTER 2 THE BASICS: NETWORKING SOFTWARE, SERVERS, AND SECURITY
sees that that ticket piece says something like, “The special one-time-only password for communi- cating with Mark is ‘opensesame.’ And by the way, you should have gotten this message from Mark sometime between 10:45 A.M. and 10:50 A.M. from his IP address, which should be 117.39.82.3.”
Once the file server gets its half of the Kerberos ticket, it knows a few things:
◆ The user claiming to be Mark who wants access to the file server is indeed Mark.
◆ Any messages from that now-authenticated person named Mark should have originated from IP address 117.39.82.3.
◆ If Mark and the file server really want to maintain a secure connection, they could even encrypt their communications using this shared—but secret—password, opensesame.
Security Roles and Definitions: Domains, Domain Controllers, and Member Servers Armed with this information, I can define a few Microsoft networking terms.
Domain You just saw an example where one machine (vault) let me log in to another machine (files-r-us). I haven’t mentioned this yet, but before I could get anywhere I needed to log in to the computer at my desk, my workstation—and when I first tried to log in to my workstation, it was once again vault.bigfirm.biz that authenticated me. Clearly, then, my workstation and files-r-us “trust” vault.bigfirm.biz in some fashion.
The collection of machines that share the same list of user accounts, the same NTDS.DIT, is a domain. Or, to put it a bit more specifically: several computers hold a copy of NTDS.DIT and are willing to act as “logon servers” (domain controllers) with that NTDS.DIT. The collection of machines that are willing to accept logons from those domain controllers (in Microsoft terms, who “trust” those domain controllers) and the domain controllers themselves are collectively called a domain. So my workstation, vault, and files-r-us are all part of the same domain.
Domain Controller A server, such as vault.bigfirm.biz, that contains a copy of the user account/password data, and that therefore can let users log in to servers, is a domain controller. Domain controllers exist to centralize the user account/password information so that you needn’t put the NTDS.DIT on every server.
Member Server A machine that is running NT 3.x, 4.0, 2000, or Server 2003 but not acting as a domain controller will not contain a copy of NTDS.DIT and therefore can’t authenticate domain members. Such a machine is called a member server.
Permissions and Access Control Lists (ACLs)
Once a server has determined that I am indeed me, does that mean that I’ll get access to the server’s information? Not necessarily. Authentication just identifies me. The next step in security is access control, also known as (depending on what network operating system you are using) rights, permissions, or privileges.
Ever since its earliest versions, NT (which includes Windows Server 2003) has had a very flexible system of file and directory permissions. As you’ll see later in this book, you can exert very fine-grained control, such as specifying that Mary can read or write to a given file, that Bill can only read it, and that June cannot access the file at all. Don’t get the idea, however, that permissions
WHAT’S THE POINT OF NETWORKS AND NETWORKING? 31
refer only to files. There are permissions to do things like create, modify, and destroy user accounts, and even permissions to create domains in the first place. The flexibility of these permissions is one of Microsoft networking’s great strengths.
Just about everything in the Microsoft networking world has security on it. Want to read a file? You need the permissions to read it. Want to shut down the program that provides the Web server? You need the permissions to shut it down. Want to create a new user account on your network? You need the permissions to create a new user.
These permissions are stored as a list. In the case of the file, the operating system sets aside a little space for every file that it creates, and keeps the permissions in that space. A set of permissions for a file, then, might look like
◆ A user named June can do anything that she wants to the file.
◆ Another user, Joe, can only read it.
◆ Any user in a group named Cube-dwellers can read or modify the file, but not delete it.
◆ The operating system can do anything that it wants to the file.
In Microsoft networking-speak, that list is called an access control list or, inevitably, ACL. Each of the four entries are called access control entries or ACEs. You will learn in this book that lots of things have ACLs, and adjusting those ACLs is how you configure security in your network. Access to Earlier Security Systems
The last challenge that Windows 2000 and 2003’s security designers faced was the so-called “legacy” support—ensuring that they could interact with the security systems built into Windows for Workgroups, Windows 9x, NT 3.x, and 4. I’ve described in very broad strokes how Kerberos works, but Windows and NT didn’t use anything like that and in fact couldn’t do Kerberos logons; Kerberos first appeared in the Microsoft networking world in February 2000, with the introduction of Windows 2000. Microsoft knew that you wouldn’t be very happy if they required you to throw away all of your old Windows 9x and NT systems before you could implement Active Directory, so Windows 2000, XP, and Server 2003 know a variety of logon methods—NTLM 1.2 for Windows 9x and NTLM 2.0 for NT 3.x and 4—in addition to Kerberos.