| Previous | Table of Contents | Next |
The simplistic SMB protocol was always seen as rather insecure and feature poor. This led Microsoft to adopt a new security model, called the domain security model. This model relies on one or more servers that share a common database of usernames and passwords.
I can see you raising your eyebrows. You’re thinking, “Shared? Isn’t that really insecure?” Unless you’re a military installation, domain security is probably okay. Microsoft uses reasonable enough encryption technologies that casual folks can’t get past it; the upside here is that if one server is down, other folks can still log into the network. What’s more, because the domain model shares usernames and passwords among several servers, you avoid administrative hassle when adding users to the network.
Each NT domain must have an NT server that acts as the primary domain controller, and it may have one or several backup domain controllers that act to help out with authentication services while the PDC is up and take over completely if the PDC goes down.
An NT domain is not a directory service as I defined it in Hour 1 (we’ll talk more about directory services in Hour 13, “NetWare Networking Basics”). It’s not really scalable enough to be a directory, and it doesn’t carry anything more than usernames, passwords, security groups, and basic information on who a user is. Microsoft has promised a real directory (called Active Directory) in NT 5.0. I’m sure it will be wonderful, but you won’t catch me installing it on a production network until it’s been in the field a good 6 to 12 months.
Workstation Wrestling
If you’re using an NT workstation, note that networking to an NT server is slightly different than networking for users of Windows 9x. Part of the domain security model is the concept of a secure workstation; each NT workstation must be registered with the domain using a valid set of supervisory credentials before it’s allowed to participate in file- and print-sharing. Windows 9x machines aren’t considered to be securable machines, so they don’t have to register.
| SIDs and You
When you install NT, the installation process generates a unique security identification number (SID). It’s considered to be a reasonably secure declaration of the identity of the workstation, because it’s randomly generated and has billions of possible values. In NT Workstation, this SID is used as a starting point for generating unique identification numbers for users, groups, and so on that reside on the workstation. In NT Server, this SID is considered to be more than the SID for just that machine; it’s the domain SID and is used to generate object numbers for the entire domain. When you create an NT Workstation computer account, the domain controller generates a workstation identification number based on the domain SID. The domain controller establishes a secure encrypted channel with the workstation, based on a shared password. If you change the computer name, your computer will no longer be considered the same computer that was added to the domain database, and it will not be able to access the domain. You’ll have to delete the computer from the domain database using the Server Manager tool and then read it. This doesn’t hurt anything, but it does create extra work for you. SID issues exist when using drive duplication to install Windows NT in a standardized manner—your SID should never be the same on two NT workstations. See Hour 16 for more details. |
Part of the concept behind a secure NT workstation is the idea that you cannot access a given workstation until you’ve identified yourself. On the downside, this can prevent you from accessing even the workstation if the network is down. For example, say you can’t get to your NT server because the router that connects you to it is down. If you can’t authenticate at all, you’re locked out of the workstation and can’t do local work. (You cannot simply bypass the login prompt the way you can on a Windows 95 machine; you must log in.) Fortunately, because a copy of the last-used domain information is stored (cached) on your hard drive, you can authenticate to the workstation anyway.
I’ve only seen “roaming” users have problems with this—that is, users who use more than one workstation. I’ve seen a user change her password on the domain one day and then go to another location where there’s a network problem and be unable to get into the workstation. The problem? She had changed her password the previous day, and the second workstation hadn’t found out about it yet. The solution? She used her old password, and it worked just fine.
Many manufacturers ship Windows NT with no administrator password. If you can’t get into your workstation because you can’t communicate with the domain, you can always try logging into the local machine with the username Administrator and no password. This works more often than you’d think. So much for secure workstations!
| Previous | Table of Contents | Next |