This section provides information about the security features of Windows NT.
The most fundamental security issue in a computer network is posed by the question: Which computers can a given user access? For both local and remote users, the answer to this question is governed primarily by the domain structure of Windows NT.
Administrators assign each Windows NT–based computer, whether a server or desktop computer, to a single Windows NT domain. (This is usually permanent, but it can change.) Each domain has a Windows NT Domain Controller that serves as a repository for security information, most notably a set of domain-wide user accounts and group definitions. A user’s account holds a logon name, password, capabilities, and other information, such as the user’s real name. Each account in a domain can locally log on to and remotely access each computer in the domain, although there are other controls that can restrict access on an account-by-account basis.
If the administrators agree, one domain can trust another. When this happens, accounts in the second domain have the same access to computers as accounts in the first domain. In setting up the trust, the first administrator is in effect saying, “Your users may access the computers in my domain” (although there are many limitations on that access). Usernames across a multidomain network must be unique only within a domain and are implicitly prefixed by their domain name, such as SALES\JJones, where SALES is the domain and JJones the user. Trust is one-way. In the current example, accounts from the first domain cannot access the computers in the second domain. However, two domains can trust each other, and a domain can trust, and be trusted by, more than one other domain.
There are many popular practices for structuring domain trust relationships (domain models) and some are based on criteria other than security, for example, network browsers group computers and their shared resources by domain. In all cases, however, the fundamental security of domains is based on the same question: Which computers can a given user access?
There are two features that further allow administrators to control access to computers. User rights are special capabilities that administrators assign to accounts that can use a given computer. Most rights are used internally by Windows NT, and the default assignments seldom change. However, two rights are noteworthy: the right to log on locally and the right to log on remotely. These allow each computer to tightly limit each kind of logon. Further, each account has an optional list of workstations to which its user can locally log on.
When you locally log on to a Windows NT–based computer, your logon session runs under the name you present along with your password at logon. When you attempt to access a remote computer (for example, connecting to one of its shared directories or printers, or performing remote administration), the remote computer transparently authenticates you and establishes a remote session for your activities there. If the domain structure allows, the remote account is the same as your local one. Otherwise, you sometimes can specify a name and password of an account that is allowed on the remote computer. But under no circumstances can you establish a remote session without being authenticated–that is, without demonstrating you know the name and password of an account that is legal on the remote computer. And without a remote session your programs can obtain no significant services.
After you have been logged on to the remote computer, remote server applications can assume the identity of your user account through a simple process called impersonation. When they do so, they are running under your permissions and capabilities, and their actions are appropriately constrained by controls in the remote environment, for example, ACLs on the remote file systems. This is our first and perhaps best example of how the Windows NT environment implements single-logon and propagates it to server applications. A server in this scenario need know nothing about authentication or accounts. It simply impersonates its client user (whose name it may not even choose to discover), and the Windows NT environment restricts the program’s actions accordingly. The BackOffice family of products and other Microsoft applications universally use this fundamental security model, and Microsoft strongly encourages all BackOffice-compatible applications to do so as well.
Under single-logon, you log on only once, so that logon should be quite strong. For this purpose, Windows NT uses a technique called trusted path, which is typically found only in highly secure operating systems. The trusted path prevents what is commonly called the spoofing scheme, in which a malicious program already running on a computer presents what appears to be a legitimate logon window in order to capture a user’s password. Under the trusted path approach, users of Windows NT are trained always to call up the logon window by pressing the CTRL+ALT+DEL keys simultaneously. When they do, Windows NT reliably displays its Security Window, which allows them to safely enter the password. (You also use the trusted path approach to change your password and log off, which prevents similar spoofs.) Windows NT also includes a variety of password controls, including the ability to lock an account when its password appears to be under attack.
There are two important enabling technologies that can strengthen Windows NT logon and password management: PASSFILT and GINA. PASSFILT lets an administrator install a trusted program that is called every time a user changes a password. The program receives the new password and can ensure that it meets certain strength criteria such as length and the use of randomly chosen characters. Microsoft includes an optional PASSFILT module in Windows NT that enforces an example password policy. This addresses the time-honored but still troublesome problem posed by users who choose nonsecure passwords. GINA is a replaceable program that is part of the Windows NT local logon system. Although not for the novice, vendors can supply alternative GINA modules that strengthen the logon process. Prime examples include support for smart card authentication (see “Enabling Technologies” later in this chapter) and biometric authentication (devices such as fingerprint or retinal scanners).
All objects in the Windows NT environment can have an Access Control List (ACL). An ACL defines a set of users and groups, and the kind of access each has on the object. The most visible and important ACLs are those that protect all elements in the Windows NT native file system format (NTFS) and the Windows NT registry. These house all software that enforces Windows NT security, and ACLs are therefore important in protecting the system’s integrity. (Windows NT sometimes uses encryption for additional protection, for example, its user accounts and other key security data.)
Users have full control of ACLs on the files, directories, and other objects they create, and use simple window interfaces to manage them. They also can specify the ACL to be given by default to all newly created objects in the directories they manage.
ACLs protect other objects, such as file shares and printers, and most of the BackOffice applications extend the ACL model to data they manage. It is often necessary for an application to have a customized ACL format for the objects it manages. In both cases the purpose and intent are the same.
Windows NT uses a simple administrative hierarchy. Full administrators, members of the local Administrators group on each computer, have complete power over that computer. Windows NT Server includes several operator roles each of limited power, for example, account operators who manage user accounts and server operators who look after day-to-day server operations. Windows NT administration is based simply on membership in certain groups so you can devise network-wide administrative roles flexibly. For example, you can include domain administrators from the local domain (or remote domains) to the administrators who control your LAN workstations. You also can create a group for accounts that administer only user workstations and not the more critical network servers.
Windows NT and its applications can record an extensive set of system events in the security log. You can define an audit policy that designates which of six categories the system records (logons and logoffs, user and group management, and so on). You also can attach auditing information (which looks much like an ACL) to any Windows NT object (this is typically done for NTFS files, NTFS directories, and Registry keys). An object’s category determines when the system audits access to the object-based on the user and group, and the success or failure of the operation. You can even stipulate that the system shut down if the audit trail exceeds the allowed storage.
Microsoft provides extensive software libraries that allow trustable programs to insert their own custom audit records into the audit trail. The libraries also give audit tools easy, high-level access to the security log.
Remote Access Service (RAS) allows remote users to dial in to a Windows NT RAS server and use the resources of its network as if directly connected. In its simplest mode, users logging on to Windows NT remotely simply check a small box on their logon window that automatically establishes the RAS connection and authenticates the session. RAS uses the Windows NT standard single-logon technique, and users can log on under their office account. Overall, working from the road is identical to working from one’s office, and it is secure.
Administrators designate which accounts can use RAS. They also can set up RAS to automatically “call back” a specific number for each account. This ensures that a user’s remote access comes only from a specific phone number. RAS uses the Windows NT standard “challenge/response” logon, which prevents passwords from passing over the communication link. RAS clients and servers can require that all communication be encrypted, currently by the 40-bit or 128-bit RC4 cipher. You also can limit remote access to the resources of the RAS server itself (as opposed to its networks).
Microsoft’s Virtual Private Networking technology uses the industry-supported Point-to-Point Tunneling Protocol (PPTP) to extend the use of RAS to the Internet. Instead of dialing directly into the RAS server using a telephone line, the remote RAS client dials a local Internet service provider and establishes an Internet link to the provider’s PPTP RAS server. This virtual private network allows a remote user to securely access a central network over the nonsecure Internet.
Not all networks are prone to attack, and Windows NT does not impose performance penalties by applying cryptographic techniques to all network traffic. Instead, its philosophy is to support specific applications that must cryptographically protect data in transit across a network. However, it does use some common-sense and basic cryptographic techniques in its standard, underlying protocols.
Local logon requests are encrypted when they pass between the workstation and its domain controller. This helps ensure that passwords are not exposed and that interlopers cannot interfere with the primary authentication process. The remote (or secondary) authentication we discussed uses the NTLM challenge/response protocol to ensure that passwords never appear on the network unencrypted.
Windows NT uses the Microsoft SMB protocol for file and printer sharing and many for other remote services. SMB also applies integrity protection to this protocol. The protection does not encrypt data, but it does prevent a broad range of attacks that seek to modify the data while in transit or to impersonate the client’s identity.
Windows NT is one of the few commercial operating systems that has successfully completed the U.S. Government C2 evaluation process, as well as the FC2/E3 evaluation under its companion European criteria, Information Technology Security Evaluation Criteria (ITSEC). This is important for two reasons. First, it ensures that the base operating system has certain important security features. Second, and more importantly, it provides an opinion about the system’s security from an independent, trained, experienced, and unbiased team of government security analysts. This team has had the full cooperation of Microsoft developers and core software architects, as well as access to source code and internal design documents. The team, which meets regularly with the developers and architects to gauge Microsoft expertise, commitment, and thoroughness with regard to security, concentrates on fundamental security architecture and is guided by what is commonly called the “Orange Book” (Trusted Computer Systems Evaluation Criteria).
The C2 evaluation process is therefore not a detailed search for security bugs, but rather an opinion that the overall security architecture is sound. For more information, see www.microsoft.com/ntserver/info/default.asp.
Future releases of the Windows operating system may bring many new security features, for example:
To ease domain administration in larger sites, a future version of Windows may allow administrators to group domains so that each domain implicitly trusts every other domain in the group, and that accounts in a domain can be used in all other domains in the same group.
Invisible to most users, Kerberos offers a variety of expanded authentication capabilities. For example, it allows servers to pass client user identities for use by other servers in a multitier client/server arrangement and allows mutual client/server authentication. It also allows users of the Windows operating system to securely access remote services other than Windows NT services that use this popular technology. Future versions of the Windows operating system may also authenticate users using public keys and certificate technology, including SSL. This facilitates authentication from sources other than Windows operating systems sources and eliminates some of the disadvantages of traditional passwords.
The Active Directory is logically a single, network-based storage hierarchy based on X.500 standards (and, of course, protected by ACLs, which have some interesting new properties of their own). When upgrading from Windows NT 4.0 to Windows 2000 or later, many security parameters may migrate to the Active Directory from their current location in the Windows NT Registry, including all user accounts. This significantly enhances central security administration. Administrators also can delegate detailed operations to lesser administrative users who must perform specific functions; for example, letting a help desk attendant assign a new password to a user without otherwise changing the user’s privileges. Because these privileges are based on the ACLs that protect the Active Directory elements, managers can devise custom administrative hierarchies that fit their own particular needs.
Future versions of the Windows operating system may allow users automatically to encrypt information stored in the native NTFS file system format in much the same way they can automatically compress files today. It has provisions for data recovery that allow trusted administrators to recover data if users forget their own encryption keys or leave the company. This is a welcome and essential feature for people who use laptops or removable hard drives.