Windows NT Security

v1, 6 Mar 1998

Jamie Lewis, Steve Morse

Network Services / Security Services / Archive

Microsoft

Market Impact

NT Server and NT Workstation compete in four different markets. NT Workstation is Microsoft's future in the shrink-wrapped client operating system market, for example, while NT Server has largely created the mainstream market for general-purpose, shrink-wrapped server operating systems, competing with Unix and NetWare. More specifically, NT Server competes with Unix both as an enterprise application platform and as an Internet platform. In all four arenas, security is a baseline requirement for NT's success.

While security is an important issue for client operating systems, the primary focus in the marketplace has been on server security. In this respect, NT's primary competition has come from Unix. To be sure, security has always been an important issue for NetWare and NetWare has a large installed base, but it has a second-tier position as an enterprise application and Internet platform. It's clear that the battle for dominance of enterprise application and Internet/intranet servers is between NT and Unix. Security is obviously an important factor in that battle, and several Unix vendors have attempted to use security as a competitive weapon against Microsoft.

As is the case with NT, security is an intrinsic part of Unix. Unix also has the advantage of long field experience, many hard knocks, proven scalability, and considerable maturity. It's also fair to say that when compared to earlier versions of NT, Unix's maturity showed in both the battle-hardened code and the experience of the Unix vendors in dealing with security issues as they arose. As we've already said, however, Microsoft has in large part turned the security issue around, addressing both the technological and organizational issues that were of legitimate concern to customers and developers.

Another often-claimed security advantage for Unix is the potential availability of source code. Having the source code, the argument goes, allows independent developers to objectively assess the true security of the operating system and even make their own fixes and improvements. While the source code for several noncommercial versions of Unix is freely available, the fact remains that the most important commercial vendors of Unix--Sun, IBM, and Hewlett-Packard--don't release their source code. By contrast, Microsoft does license the source code for independent analysis and review, and currently over 30 universities and a few national labs hold such licenses. So on the basis of this issue, NT has the advantage over Unix.

Beyond these basic security considerations, larger market dynamics are at work that affect the competition between Unix and NT. For one, the Unix market is fragmented and the multiple versions of Unix are not all completely compatible. While Unix security is good in general, security testing for Unix has thus become strongly version-dependent.

In addition, the vendors of the leading Unix implementations generally tie their operating systems to their hardware marketing agendas. Together, Sun Microsystems, IBM, and Hewlett-Packard represent the major suppliers of Unix for enterprise customers, and each vendor's version of Unix is tied closely to its own hardware platform. This dependency compounds the version fragmentation problem, limiting the size of the Unix market. The small size of the Unix market--when compared to the Windows market--limits the overall appeal of Unix to independent software developers. The resulting damper on available Unix applications again compounds the problem, limiting the overall appeal of Unix platforms to customers.

Consequently, NT has made significant gains over Unix, on both the client and server. Microsoft is a master at shipping large volumes of shrink-wrapped software, and in the last year, NT has begun to have a significant impact on the Unix market. On the client, for example, IDC recently reported that NT Workstation shipments outnumbered all Unix workstation shipments combined. And on the server, NT is clearly out-shipping Unix by large volumes. While Unix vendors may use security as a scare tactic, then, it is not an issue that will impede NT's progress in the market. The current version of NT, with appropriate service packs applied, is a secure operating system. And given Microsoft's efforts to improve its own internal response policies and procedures, Unix vendors cannot rely on security as a saving grace.

Where both NT and Unix are weak--and where NetWare clearly has the advantage--is in the directory arena. The limitations of NT 4.0's domain-based directory are well known, and these limitations have their implications for enterprise security. For one thing, it is difficult to define and deploy an enterprise-wide security policy using NT's current set of tools. While Domain User Manager, Server Manager, Access Control List Editor, and Event Monitor can do the job in a narrow technical sense, attempting to manage security policy on the scale of a large enterprise with these tools is problematical.

Unix also has lagged in terms of true enterprise directories. While the Internet-standard Domain Naming Service (DNS) and products like Sun's Network Information Service and Sun DS offer some help, these products don't have the capabilities of Novell Directory Service (NDS). As the Lightweight Directory Access Protocol (LDAP) becomes more prevalent, Unix platforms will have better directory support, but this evolution is still in the early stages and LDAP-based policy management is still in its infancy. (See the Network Strategy Report "LDAP version 3: The Maturing of the Internet Directory Standard.")

By contrast, NDS does offer some basic enterprise-wide security policy management in conjunction with the file system's access controls and with BorderManager (see the Network Strategy Report "Novell BorderManager"). Administrators can define access rights for users or groups for an entire directory tree or for a subsection (organizational unit) within the tree, and can define user access rights to Internet hosts. NT simply doesn't have the overall access management capabilities of NDS. Novell has only recently begun to exploit NDS effectively, however, and as we've covered in previous documents, NT's application server capabilities continue to make it a strong competitor to NetWare.

As we've said, Microsoft proposes to remedy its directory shortcomings in at least two stages. First, the company will release Security Configuration Editor. Second, NT 5.0's Active Directory will provide directory hierarchies--and corresponding security policy management--similar to those of NDS. However, it's unlikely that NT 5.0 will ship this year away. And even after it ships, there will be a period of at least a year while major customers evaluate it, wait for service packs, and begin their transitions. It's also likely that many customers will wait until after they've implemented their Y2K fixes and weathered the roll over before they undertake significant upgrades to their enterprise infrastructure, which could further delay NT 5.0 and Active Directory implementation. Therefore, Novell will continue to have a window of opportunity with NetWare and NDS into the year 2000. Since NetWare still trails in the application server category, however, Novell's best strategy is to use tactics like NDS for NT to integrate NT application servers with NDS, allowing customers to use NDS as the security repository for those and other servers on the network.

Microsoft understands the challenges it faces and is working hard to maintain solid security in NT 4.0. It's clear the company will not let security problems stop NT. Microsoft has already demonstrated that it can move rapidly to handle security problems when they arise in the field. To be sure, it takes time to properly test the security aspects of software, but with Microsoft's resources and determination, it won't take long to bring NT to the same level of maturity as Unix. While directory and policy-based management issues will continue to be a factor in NT's market position, security will not of itself limit NT's market growth.

Recommendations

As we've said in multiple documents, customers must approach network security in the context of established security policies. A company must first assess the true value of its information resources before it can decide intelligently how much it is willing to spend in terms of money, time, and difficulty on security measures.

In general, customers can assume that NT is a secure operating system. Its native authentication mechanism ensures that only authorized users can log in, and its access controls ensure that only authorized users gain access to system resources. In considering NT as a general-purpose client and server operating system, as an enterprise application platform, or as an Internet platform, customers don't have to worry about the adequacy of its security.

But customers must always pay close attention to their deployments, making sure they employ good security hygiene and create good corporate policies. There is no single solution for achieving security, and just assuming you're secure because products provide good security is dangerous. It helps to have solid operating system architecture, firewalls, locked server rooms, and vigilant auditing as well as other security measures, and all of these solutions work together. For example, while SP3 addressed many NT security issues, Microsoft has had to apply hot fixes subsequent to SP3 to address specific problems. It's not unreasonable to expect future problems as well. Thus, it is still prudent to protect a sensitive NT server with a packet-filtering firewall. Finally, any security measure requires thoughtful deployment. For example, network security also involves human resource policies, background checks for privileged employees, educating employees on good security policy, and enforcing corporate security policies.

Much of the criticism of NT's security stems from the compromises entailed when it must use the older LAN Manager form of user authentication in order to accommodate Windows clients, namely Windows 3.1, Windows for Workgroups, and Windows 95. Microsoft acknowledges that security is less rigorous under these conditions, because it developed the LAN Manager authentication protocol many years ago. However, as we've been saying, customers who place the highest importance on security should seriously consider using only NT Workstation clients.

Older Windows clients may be necessary on an exceptional basis to accommodate legacy hardware and applications. Customers can optionally deploy such computers with extra security measures, including point-to-point data encryption if need be. But if corporate security policy deems that security is paramount and justifies the investment, customers should also seriously consider upgrading older applications and replacing older hardware so that they can deploy only NT Workstation.

Another important point is that implementation details can make or break security, even in the most "bullet-proof" operating system. While NT encrypts the authentication exchange for the login process, a potential intruder who intercepts this exchange stands a much better chance of guessing a poorly chosen password--one that is all-alphabetic (such as a relative's name) or all-numeric (such as an old phone number)--than a password that is a mixture of alphabetics, numerics, and punctuation. Certain file system directories (like Repair) can contain valuable information for an intruder; these shouldn't be readable by anyone but properly authenticated administrators.

Managers should always place servers in locked, secure rooms. Even without a valid user name or password, intruders who have full physical access to a server can often read NT's entire file system by booting to another operating system and using widely available utilities. Privileged users--such as Domain Administrators--should never leave a workstation they've logged in to unattended; at a minimum, the screen saver should have password protection. In other words, treat the network like any other valuable business asset.

In addition, NT 4.0's Service Pack 3 demonstrates the importance of keeping up with software upgrades and monitoring the advisories issued by any operating system vendor. As we've said, Microsoft is determined to make sure that NT remains secure and, as part of that effort, publishes hot fixes, workarounds, and other security-related information on its NT security Web page. Customers should consult this page regularly. Microsoft also sends proactive advisories to its Premier support customers.

Moreover, for large-scale deployment, customers should remember that NT still doesn't have a directory that can scale upward, and this shortcoming has a real effect on deploying and managing enterprise security policy. Without a true enterprise directory that serves as a repository for security policy, administrators must establish and monitor security on a piecemeal basis. The difficulty of doing so is inimical to good overall security.

NT's multiple domain models attempt to compensate for this shortcoming, but they have limitations just the same. For example, NT domains, even using the single and multiple master domain models, don't have any provision for multi-level hierarchies in which administrative responsibility and authority can be delegated to a demarcated part of the organization. In addition, while NT can log a plethora of security events in the Event Log of each server, gathering, collating, and interpreting these logged events from a collection of servers is at best a formidable task, and at worst a practical impossibility.

Microsoft acknowledges these limitations, and customers can expect to see new solutions coming out in the next year or so. The Security Configuration Editor is due out later this year as part of the Windows NT 4.0 Service Pack 4. Security Configuration Editor should help customers create, deploy, and monitor security policies through standard templates. There are also third-parties that can help customers manage various aspects of network and system security, such as Enterprise Administrator from Mission Critical Software, Enterprise Security Manager from Axent, Enterprise Management System from Bindview, Internet scanner from Internet Security Systems (ISS), Kane Security Analyst from IDI, and Entrax from Centrax Corporation. Enterprise customers should seriously consider acquiring and utilizing these administration tools.

In addition, Microsoft will be including a much more capable directory product--Active Directory--with NT 5.0 when it ships. Active Directory will allow customers much more flexibility, which will greatly facilitate security policy management but which will also place new planning responsibilities on those customers who seek to take full advantage of Active Directory. Experience has already shown that planning a new directory deployment, especially when it includes the delegation of security responsibilities, is a time-consuming process, one that entails not only technical considerations but also organizational dynamics. Customers should therefore begin planning now for how they will subdivide and delegate security responsibility and authority under NT 5.0 and Active Directory.

The bottom line is that NT Server and Workstation form a good foundation for building network security. While present shortcomings in NT's directory place constraints on scalability and manageability, NT's architecture is sound and Microsoft has been diligent in dealing with security problems and maturing the operating system at a rapid pace. Just the same, customers can never be complacent about security and must understand that no network deployment is truly secure without careful thought about the implementation details. And customers can't stand still; they must plan with future threats and future capabilities in mind. In particular, customers should be getting ready for NT 5.0 now.

NT Security Architecture

NT security is the result of the cooperative efforts of several system components. These include the Logon Process, the Local Security Authority, the Security Account Manager (SAM), and the Security Reference Monitor, as shown in Figure 1. Together these components comprise the security subsystem, and all of the components run as user-mode processes, except for the Security Reference Monitor, which is part of the kernel.

Figure 1: Windows NT Security Components

The Logon Process authenticates users seeking access to NT domains and workstations by validating user names and passwords either locally or remotely through a domain controller (we discuss the details of the logging in later in this report). An essential aspect of the Logon Process is the so-called Trusted Path, which refers to the means by which the system solicits a user name and password. In NT, Control-Alt-Delete, which Microsoft calls the secure attention sequence (SAS), always presents the user with a dialog box asking for user name and password, constituting a "trusted path" for user authentication. There are other ways a user can initiate the login process, as described later in this report, but the Trusted Path is the way a user can be sure of getting a bona fide login screen. The Trusted path also prevents Trojan horse programs from masquerading as a login dialog box.

The Local Security Authority is the central control point of NT's security subsystem. It generates Security Access Tokens (described below) for logged-in users and manages the local computer's security policy. The Local Security Authority also logs the audit messages generated by the Security Reference Monitor and is responsible for maintaining trust relationships.

The SAM is the database holding the user directory. The SAM resides in the registry of the workstation for local logins and in the registry of the domain controllers for domain logins. (During normal operations, NT Server will also cache the SAM in memory to increase the performance of security operations.) The user and group entries in this directory contain the user and group names, Security Identifiers (described below), and encrypted local passwords. The SAM is part of the NT Registry and is not accessible to ordinary users. From an operating system point of view, only system processes, such as the Logon Process and the Local Security Authority, can access the SAM. These processes make the SAM accessible via administrative programs to authorized managers, including local and network administrators.

The Security Reference Monitor carries out the actual checking to determine whether a user has the requisite permissions to access a system object, such as a file or printer, by comparing the access controls on an object to the authorization information in the user's access token. The Security Reference Monitor also generates audit messages in accordance with audit policy, which the Local Security Authority defines. (We describe security auditing in more detail later in this report).

User Login Process

All users must authenticate themselves to NT, whether they want to use the local computer running NT Workstation or access the networked resources under the aegis of an NT domain. Without such an authentication, users can't use any computer under NT control (although it may be possible to gain limited access to a local computer by booting up DOS).

NT authentication begins when the user invokes the Trusted Path in one of several ways to display a login dialog box. The user can press the Control-Alt-Delete key combination or pull down the Start menu and select Shut Down, which gives the user the option to log out the current user and then log in as a new user. Users who have installed Active Desktop with Internet Explorer 4.0 can also choose logout directly from the Start menu. Regardless of how the user invokes the Trusted Path, the next step is to provide a valid user name and password to the Local Security Authority. The Local Security Authority then invokes one or more local authentication packages, which, if they exist, may be custom-written and need not be the one bundled with NT.

The local authentication package determines if the user name and the cryptographic hash of the password match the entry in the SAM, and if so, returns the Security Identifier, or SID, for that user. NT stores the SID in the SAM. The SAM does not hold the passwords themselves, but instead a 32-byte cryptographic hash of the passwords. Users who are not administrators cannot view the contents of the SAM. The only access right to the SAM that ordinary users have is to update their own passwords based on proof of knowledge of the old password. Administrators set up password policy and users control their passwords through NT's Domain User Manager tool.

If the user name isn't in the local SAM--that is, this is a domain user--or there is no local authentication package, the Local Security Authority can forward the user name and password to a network-based authentication package, such as that provided by an NT domain controller. When authenticating users in a client/server relationship, NT employs a challenge-response protocol known as Windows NT Challenge/Response. The protocol uses the following process for users logging in to network domains:

• The user types in his or her user name and password on the client computer.
• The client computer computes the cryptographic hash of the password and discards the actual password from its memory.
• The client computer sends the cleartext user name to the domain controller.
• The domain controller creates a random 16-byte number, called a nonce or challenge, and sends it to the client.
• The client encrypts the nonce with the user's password hash and returns the result to the domain controller.
• The domain controller retrieves the user's password hash from its domain SAM, uses the hash to encrypt the nonce it just created, and compares the result with the value returned from the client.
• If the two calculations agree, the domain controller considers the user authenticated.

The NT Challenge/Response authentication process allows the client to prove to the domain controller that it "knows" the user password without actually sending the password. Likewise, the domain controller doesn't store the user password itself, but only a hash of it.

LM Authentication

NT also supports an alternate form of user authentication, so-called LAN Manager authentication or LM authentication, for backward compatibility with earlier versions of Windows (Windows 3.1, Windows for Workgroups, and Windows 95). It is similar in overall operation to the NT authentication method but differs in implementation specifics.

• The authenticating server converts the user's password to all uppercase before hashing and storing it (in addition to the unmodified NT version of the password).
• The user's workstation converts the password submitted by the user to all uppercase.
• The workstation pads the user's password, which may be up to 14 characters long, with extra nulls (all zeroes) to make up 21 bytes.
• The software then divides the 21 bytes into three 7-byte groups, and converts each of them into a 64-bit encryption key.
• The security system then encrypts the nonce three times, once by each of the newly created encryption keys and returns it to the server.
• The server performs the same action on the locally stored password, using the all-uppercase LAN Manager version and compares the result with the values returned from the workstation.

Which form of authentication applies depends on the workstation's operating system. The NT Server that authenticates domain users may choose to accept this latter form of authentication, or may allow only NT authentication, as determined by the administrator. The latter case would preclude user authentication from computers using earlier forms of Windows.

The Security Identifier

In order to identify every user and group unambiguously, NT generates a Security Identifier (SID) for every user and group defined within the domain. The operating system uses these Security Identifiers, not user or group names, to determine the access privileges of users and groups. When an administrator creates a new user or group, the operating system generates a long number. This number is will be unique within the domain because the server bases it on the name of the computer, the current system time on that computer, and the current thread's user-mode execution time.

The uniqueness is important for proper security auditing because a Security Identifier identifies a user or group created at a specific time and place and given specific access privileges by a specific administrator. If an administrator deleted the user or group from the domain, and then re-created it with the same name and password, the new user or group object would receive a new Security Identifier. And it wouldn't have any of the access privileges of old user or group name. The administrator would have to explicitly grant new access privileges to this user or group.

Once a user has successfully logged in to an NT domain or an NT workstation, the Local Security Authority generates a Security Access Token for the login session. This Security Access Token contains the user's Security Identifier, plus the Security Identifier of every group to which the user belongs, and is the vehicle for determining the user's right to access system objects.

Security Context

A security context is the operating environment defined by the set of rights and privileges granted to a user. This security context defines what the user can and cannot access or invoke and is vital for overall security because the user will call on applications or system services that often have considerably more privileges than the user.

When a user calls upon a program or service to perform work, that program or service must operate within the security confines imposed on the subject. In order to do so, the program or service uses a technique called impersonation to assume the security attributes of each calling user. The program or service may be operating on behalf of many users concurrently, and when it does so, it keeps track of the security context of each of them. For example, several users may ask a system service to open a particular file. Most of these users aren't administrators and therefore have read-only access, while administrators have both read and write access. The system service impersonates each of these users when accessing the resource, giving him or her only those access rights defined in the security policy.

Access Control

Every object under NT's purview has an Access Control List that determines which users or groups can access that object, and the specific actions on that object the operating system will allow. NT management utilities and documentation refer to these access controls as permissions. Examples of controlled objects are file system subdirectories, files, and printers. Examples of permitted actions are reading, executing, writing, and deleting for subdirectories and files; and submitting or removing print jobs from the queue for printers.

In addition, these objects may or may not be containers. Container objects, such as subdirectories, hold other objects, such as files and subsidiary directories, and the held objects inherit the security attributes of the container objects. Thus, for example, NT allows the administrator to restrict a subdirectory and all the files and subdirectories within it to read-only access for a given group of users. However, file object security applies only for the NT File System (NTFS), not for the older MS-DOS and Windows File Access Table (FAT) file system. NT also supports FAT-based file systems, but can only apply security attributes to drive shares, not to individual files or directories.

The Access Control Lists themselves contain three types of Access Control Entries: AccessDenied, AccessAllowed, and SystemAudit. Each Access Control Entry is actually a Security Identifier of a user or group, along with an associated access mask. The AccessDenied Access Control Entry denotes that the Security Identifier cannot access the object with specific rights defined in the access mask. The AccessAllowed Access Control Entry gives the Security Identifier the specific access rights. The SystemAudit Access Control Entry defines which security events will be logged (more on auditing later in this report). An object may have any number of Access Control Entries of each of these types.

When a user requests access to a controlled object, NT's Security Reference Monitor checks the Security Identifiers in the user's Security Access Token against the Access Control Entries in the object's Access Control List. It starts with any AccessDenied Access Control Entries and then checks for any AccessAllowed Entries. If any of the Security Access Token Security Identifiers match any of the AccessDenied entries, the system immediately denies the user any access to the object. It then stops checking the Access Control Entries, although the user may also have full access to the object through an AccessAllowed entry.

For example, if the administrator gives the group Everyone the No Access permission to a share, then even Domain Administrators can't access the share, even if they are listed on an AccessAllowed entry. All users, including all Domain Administrators, are members of the group Everyone, and the administrator has denied access to the group. Thus, the AccessDenied entry overrides any and all AccessAllowed entries. (However, the share owner still has the right to change permissions and thereby remove this AccessDenied entry.)

If the user's Security Access Token hasn't encountered a matching AccessDenied entry, then the Security Reference Monitor checks as many of the AccessAllowed entries as necessary to assemble all the access rights the user (or more usually the application invoked by the user) has requested. In requesting access to an object, the user declares which specific rights he or she needs. Each AccessAllowed entry, through its included rights mask, may grant one or more of these requested rights. Once the Security Reference Monitor finds enough AccessAllowed entries to grant the user all the specific rights he or she requested, the user gains access to the object. If the Security Reference Monitor exhausts the list of AccessAllowed entries without finding one of the Security Access Token's Security Identifiers or without finding all the requested rights, the user doesn't get any access to the object. It's all or nothing.

For example, user Fillmore, who is a member of the Everyone and Presidents groups, asks to open a file with read, write, and delete privileges. In checking the file's Access Control List, the Security Reference Monitor finds an AccessAllowed Access Control Entry with Fillmore's Security Identifier and with read and write in its access mask. It finds another AccessAllowed entry with the Presidents group Security Identifier and with read and delete in the access mask. Since Fillmore has both Security Identifiers in his login Security Access Token, and since the two Access Control Entries combined provided all the access rights Fillmore asked for, he gets access to the file. If Fillmore hadn't been a member of the Presidents group, he wouldn't have obtained any access.

Administrators (and users with proper authority) can set and change Access Control Lists through the Permissions option in the Properties dialog box associated with each object displayed in NT Explorer. Users and applications can also change permissions though command line tools, and applications can alter permissions programmatically.

User Rights

In addition to access privileges granted or withheld through an object's Access Control List, certain users may have additional rights that pertain to the system or domain as a whole, as opposed to specific objects under NT's control. Examples of user rights are: shutting down the system, changing the system time, backing up files and directories, restoring files and directories (separate from the backup right), adding workstations to the domain, taking ownership of files and directories, accessing the computer from the network, and loading and unloading device drivers.

User rights can supersede object Access Control Lists that would otherwise deny access to an object. For example, a user with the right to back up files and directories can read all files and directories even though some of them may have Access Control Lists denying this user read access. The right to back up files and directories can apply on the local workstation level or to the entire domain.

Administrators can grant or deny user rights through the Domain User Manager tool.

Remote Access

As telecommuting increases, users must be able to access NT servers and domains from remote locations, and do so securely. Remote users may connect directly through dial-up modems and ISDN adapters over telephone company facilities, or indirectly through an Internet service provider (ISP) and the Internet. Either way, NT must be able to authenticate that user reliably and then exchange data with that user with integrity and privacy.

As we explained in the earlier discussion of the login process, NT logins don't involve the exchange of cleartext passwords or any other cryptographic secret over private or public networking facilities. The use of nonces and encrypted responses help prevent casual interception and replay of the authentication process.

However, once NT authenticates a user, there still remains the problem of communicating securely between the server or servers and the remote client across public facilities. Remote Access Service (RAS) offers a configurable option for encrypting data exchanges between the RAS server and the remote client using Point-to-Point Tunneling Protocol (PPTP). Since it is an option, users and network administrators can, by invoking the Network applet on NT's Control Panel, choose between cleartext and encrypted sessions.

Designed for users that connect through ISPs, Microsoft developed PPTP in cooperation with 3Com/U.S. Robotics, Ascend Communications, Copper Mountain Networks, and ECI Telematics. Microsoft has submitted its specification to the Internet Engineering Task Force (IETF) as an Internet Draft. The protocol uses a hashed version of the user's password to set up session keys and establishes a secure tunnel for IP, IPX, and NetBEUI connections across the Internet. For more information about PPTP, see the Network Strategy Report "NT Server 4.0."

Auditing

NT can keep an audit trail of security-related events. As shown in Figure 2, these events can include either the successful or unsuccessful attempts (or both) to invoke selected actions. These actions include: logging on and off, file and object access, invocation of user rights, user and group management, changes to security policy, system shutdown and restarts, and process tracking (which basically records when user and application processes start and stop). The administrator establishes the audit policy by checking any or all of these actions for success and/or failure. In addition, an application running under NT can define its own auditable events. Applications can define these events in the Registry at installation time.

Figure 2: Audit Policy Dialog Box

In the case of auditing NTFS file or directory access, the administrator can further refine the audit policy by selecting the files or directories that NT should monitor. In doing so, the administrator also specifies which users or groups are subject to auditing and which actions on their part (read, write, delete, execute, change permissions, or take ownership) will generate an audit message. The administrator can request an audit message if attempts to perform these actions are successful, unsuccessful, or both.

When the system logs a security event, it includes two indicators in the log entry: a primary ID, which identifies the actual process that generated the event; and an impersonation ID, which denotes the user on behalf of which the process was acting. In the case of an access violation or attempted violation, the administrator can more easily determine who was behind it and what application he or she was using. Many audit log messages also contain a handle ID that helps correlate a group of actions on the same object over a period of time. For example, when a user opens and then closes a file, the audit events carry the same handle ID, enabling the administrator to determine how long the user had the file open.

Multiple Domains

The security model described above presupposes the existence of a single domain within which the SAM on the domain primary and backup controllers holds the security information about all of the domain's users and groups. Workstations and servers within the domain need consult only the single SAM to authenticate users, obtain a Security Access Token, and thereby determine access rights.

However, scaling, political, and geographical considerations often require the use of multiple domains, thus raising the possibility that users authenticated by one domain will need access to objects in a different domain. In such cases, one domain must be in a position to trust another or users will need to authenticate themselves to multiple domains. For example, if user BFranklin logged in to the Philadelphia domain, but needs a file in the Washington domain, one of two things must happen. Either BFranklin must have an additional account in the Washington domain and log into that domain separately, or else the Washington domain must trust the Philadelphia domain to securely authenticate and vouch for BFranklin.

While it's theoretically possible to establish an account for a user in each domain for which that user needs to access resources, it is bad administrative and security practice. For one thing, it multiplies the administrative duties, creating needless extra work and allowing extra opportunities for errors. More important, however, having multiple accounts interferes with proper oversight of the user's privileges and undermines accountability. Because the user has a different Security Identifier for each domain account, it is more difficult to audit the user's actions. And if the user leaves the organization, finding and removing each of his or her domain accounts can be a less than reliable process.

A sounder approach is to establish trust relationships among domains, thereby allowing the administrator to define user accounts once only. The following sections describe the nature and mechanics of inter-domain trust and describe some multiple-domain models.

Inter-Domain Trust

One NT domain is said to trust another when the former, called the trusting domain, relies on the latter, the trusted domain, to authenticate the users who will access the trusting domain's resources. For example, a user logs into the trusted domain and then opens a file in the trusting domain without logging into the latter. The trusted domain provides the trusting domain with the user's Security Access Token, which the latter uses to determine if the user has the requisite permissions in the file's Access Control List.

Establishing a trust relationship between two domains requires the active participation of the administrators of both domains. The process typically begins with the trusted domain, where the administrator enters the name of the trusting domain and a password. Then the trusting domain's administrator can set up the other side of the relationship, entering the trusted domain's name and the same password. This password serves to provide both domains with a shared secret. Both domains use the password to encrypt communications between them.

Trust relationships between domains are strictly one-way and point-to-point. In other words, the fact that domain B trusts domain A does not mean that A trusts B. The administrators of both domains would have to set up the latter relationship separately if they need two-way trust. In addition, the trust relationship between one domain and another ends with the trusted domain and isn't transitive to other domains. For example, assume domain A trusts B and B trusts C. Under these circumstances, A does not trust C, although B is a common point. For A to trust C, the administrators of A and C must set up a separate trust relationship.

Multiple Domain Models

While an enterprise is free to create any trust relationships it desires among its domains, there are some well-established models for organizing these domains. These are the single domain, master domain, multiple master domains, and complete trust models, and the choices among them depend on the organization's size and division of responsibilities, as we explain later in this section. We include the single domain model--which entails no trust relationships at all--for the sake of presenting a complete comparison of options. We originally discussed these models in the Network Strategy Report "NT Server 4.0."

The single domain model, as shown in Figure 3, deploys one domain, the administrative domain, which is solely for the purpose of holding user accounts and authenticating users. All other domains, known as resource domains, actually contain the working network resources, such as file systems, printers, and application services. The resource domains trust the administrative domain, since the latter authenticates the users logging in and generates their session Security Access Tokens. (The arrows in Figure 3 point from the trusting resource domains to the trusted domain.) There is no need for the administrative domain to trust any of the resource domains, or for the resource domains to trust one another.

Figure 3: Single-Master Domain Model

The primary advantage of the single domain model is that administrators need to define user accounts only once. Users need to log in only to the single domain and the company can centralize user account management. Moreover, the responsibility for managing users and groups is separate from resource management, allowing for some delegation and decentralization of responsibility. Such an arrangement also makes it easy to assign access rights by granting these rights to a domain group and then adding users to the group, instead of granting rights to each individual user. And the number of individual trust relationships to manage is equal to the number of resource domains and therefore relatively small.

While Microsoft says that a single NT domain can't handle more than about 40,000 users, in reality, customers find that domains often can't handle far fewer than 40,000 users, making it necessary to deploy multiple administrative domains. Organizations that need to establish multiple domains can use the multiple master domain model, as shown in Figure 4. Like the single master domain model, this model segregates administrative domains from resource domains, the latter trusting the former. The model differs in that the administrative domains may or may not trust one another. For example, the human resource domain may hold confidential employee information (i.e., a local resource in an administrative domain) and will therefore not trust other administrative domains, even though these domains may trust the human resource domain.

Figure 4: Multiple Master Domain Model

Like the single master domain, the multiple master domain model requires users to have only a single domain account and to log in only once. User administration is relatively centralized and generally remains separate from resource management. As before, administrators grant rights to users by assigning users to groups that have the required access privileges. However, the multiple domain model is more complex and can have considerably more individual trust relationships to set up and manage than the single domain model.

In some organizations, political constraints may make it impossible to segregate user administration from resource management. One or more domains may need to handle their own user and group accounts as well as their network resources. In addition, the users in one domain may need access to resources in several other domains. In these circumstances, the complete trust model, as shown in Figure 5, may be necessary. In this model, each domain sets up a trust relationship directly with every other domain; the trust relationship may be one- or two-way, depending on the access needed.

Figure 5: Complete Trust Model

Enterprise customers should avoid the complete trust model because it is a compromise. On the plus side, it can accommodate decentralized administration and support models, and it does establish user accounts within the domain that holds most of the resources that users need. On the down side, it is difficult to manage, doesn't scale well, and can adversely affect performance. The complete trust model entails a larger number of trust relationships than the other models, since each domain may need trust relationships in both directions with every other domain. Therefore, the number of trust relationships grows with the square of the number of domains. For example, five domains require 20 trust relationships, while ten domains require 90. It is therefore best for small networks with a limited number of servers.

The table in Figure 6 summarizes Microsoft's recommendations for which domain model is best suited to certain organizational characteristics:

Figure 6: Microsoft's Domain Model Recommendations

The upshot of these recommendations is that with the domain-oriented directory of NT 4.0, customers must trade off scalability and manageability. Larger organizations with more users and locations will require many more trust relationships. Companies that need to decentralize control of accounts and resources will also find that they may sacrifice manageability because of the number of trust relationships involved.

Security Services for Applications

Because NT is an application platform, it gives applications access to a full range of security services through two application program interfaces: the Cryptographic Application Programming Interface (CryptoAPI) and Security Services Provider Interface (SSPI).

CryptoAPI provides a standardized way to invoke such security services as certificate generation, digital signatures, and data encryption and decryption regardless of the provider. Microsoft shipped the latest version of CryptoAPI (version 2) in July 1997, and it's available for NT 4.0. So-called Cryptographic Service Providers (CSPs) provide security services, operating through a separately defined interface, the Service Provider Interface (SPI). Separating the API and SPI allows applications to make use of different service implementations without any modifications. For example, an application can invoke Digital Encryption Standard (DES) data encryption through CryptoAPI and obtain the services of either a software encryption module or a hardware accelerator. (We describe several CSP products later in this report.)

While applications can use CryptoAPI to invoke detailed security services, these applications can also use the SSPI, a higher-level interface, to invoke more generalized security services without getting involved in the mechanics of such services. For example, an application can ask SSPI to create a signature without having to specify the individual steps of generating, encrypting, and packaging message hashes, as would be necessary with CryptoAPI. But like CryptoAPI, SSPI shields the calling application from the implementation details of the provider. Figure 7 shows the relationship between SSPI and CryptoAPI.

Figure 7: SSPI and CryptoAPI

Note that SSPI is for establishing secure network connections and supports single sign-on by using default user credentials. Most BackOffice applications use SSPI for basic user authentication. It offers data integrity services, including both the generation and verification of digital signatures, but it doesn't include data encryption or decryption services. Applications that need data confidentiality must invoke such services through CryptoAPI, which provides core cryptography services for key management, signatures, and encryption. (For more detailed information about SSPI and CryptoAPI, see the Network Strategy Overview "Interoperable Authentication.") SSPI, like CryptoAPI 2.0, is available with version 4.0 of NT.

Potential Vulnerabilities

NT has undergone a maturing process, and part of that process has been the hard practical realities of intruders. Like any complex software system, NT Server and NT Workstation have a history of bugs that intruders have been able to exploit. While Microsoft has been able to fix most of the problems, there is never such a thing as a 100 percent assurance that security is totally airtight. It's therefore useful to have an understanding of the nature of these attacks in order to be prepared for any contingency. More important, knowledge of NT vulnerabilities, even if Microsoft has fixed them, helps increase awareness of how vital implementation details are in assuring security.

Denial-of-Service Attacks

The easiest way to inflict damage on a system host is to exploit known structural weaknesses or bugs in the operating system or TCP/IP stack to cause the host to stop functioning in some important way. The intruder doesn't obtain any direct control or valuable data, and thus denial-of-service attacks are more akin to vandalism.

All network operating systems are potentially vulnerable to denial-of-service attacks and NT has had problems in the past. NT 3.51 and earlier versions contained several bugs that vandals could exploit to cause it to stop working, and even early versions of NT 4.0 were vulnerable.

Prior to NT 4.0 Service Pack 3, an intruder could crash NT Server by starting a TCP session and then, before exchanging any data, sending a packet with the Out of Band (OOB) flag set, a special condition that NT's TCP stack simply wasn't expecting. In addition, NT's DNS server was vulnerable to deliberately submitted responses for which it hadn't issued a query. NT's FTP server was also vulnerable to the deliberately erroneous command "GET ../.." and Internet Information Server 1.0 was vulnerable to a URL in the form of http://hostname.com/../../. Connecting via Telnet to port 135 on an NT host and sending any text would start consuming 99 percent of the host's CPU time, thereby making the host unusable.

All of the denial-of-service attacks mentioned above were fixed by Service Pack 3, which underscores the importance of installing these Service Packs on a timely basis. This is especially true for servers exposed directly to the Internet. Because installing Service Packs can be a tricky and time-consuming proposition, customers should also consider availing themselves of basic firewall protection until they can install the Service Pack. For example, a simple packet filter can effectively thwart the port 135 Telnet attack.

Another important lesson from the history of denial-of-service attacks is that they are relatively easy to mount and new ones may easily arise at any time. All of the OS developers, including Microsoft, do their best to anticipate these attacks, but customers will serve themselves best if they assume that something new might slip through. The best general defenses against denial-of-service attacks are properly implemented firewalls and ongoing vigilance. For more information on firewall protection, see the Network Strategy Report "Firewall Architecture and Implementation."

Password Issues

Passwords remain a necessary evil in any security arrangement and NT is no exception. NT offers a password mechanism that is in theory extremely hard to break. But users and administrators often make life relatively easy for intruders by choosing easy-to-guess passwords. They also leave passwords, even in encrypted form, in places where intruders can get at them. Mixing NT Challenge/Response authentication with LM authentication in order to accommodate older Windows clients can also make life easier for intruders.

NT passwords can be up to 14 characters long, are case-sensitive, and can include a wide variety of extended characters. As we discussed earlier, NT creates a hash of the password and stores that hash as part of the user's security information in the SAM. NT uses the case-sensitive version of the password for user authentication involving only NT workstations and servers. But it can also maintain backward compatibility with the older LAN Manager authentication process used by Windows 3.1, Windows for Workstation, and Windows 95 clients. To support older Windows clients, NT Server converts the password to all caps, and then creates a cryptographic hash of it. NT Server then stores this "LAN Manager version" of the password in the SAM along with the NT version of the password, thereby making the password easier to guess.

In previous versions of NT, intruders could use the so-called "red button" attack to gain access to the SAM. By sending a null session over TCP/IP to the server, an intruder program could cause NT Server to dump a list of user names from the SAM, and perform SID to name lookups, gaining information that could help them crack accounts. Microsoft addressed this problem in SP3 for NT 4.0, which prevents the attack outright.

An additional weakness in NT's password storage--in both the NT and LAN Manager versions--is that it doesn't use a random salt value when it hashes and stores a user's password, unlike Unix and NetWare. A salt value is a randomly chosen number that a security service can append to each password encrypted on a given server. It helps thwart intruders by causing the same password to take on a different hashed value in different places, making precomputed dictionary attacks much more difficult. Dictionary attack programs must hash each candidate word from scratch with the current salt value. Because hashed passwords in NT are unsalted, intruders have the luxury of using a precomputed dictionary. If each possible dictionary word already has a corresponding hash stored with it, programs can perform dictionary checks of the SAM much faster and easier.

In general, intruders can't access the hashed passwords in the SAM from remote computers unless they already have administrator privileges. Even administrators can't directly access the hashed passwords stored in the SAM. There is often a backup copy of the SAM in the Repair subdirectory of the NT installation, however, and administrators who have improperly configured their systems can make that copy available to everyone to read and copy. Using a tool like L0phtCrack 1.5, which anyone can download from L0pht's Web site, it's easy to mount a combination dictionary and brute force attack on these hashed passwords. We tried it with a slow Pentium workstation and found that L0phtCrack could guess a password consisting of four numerics ("2909") in about 2 minutes. For an 11-character non-dictionary all-alphabetic password ("Stolichnaya"), using both upper and lower case, L0phtCrack required about 2 days of continuous running in order to guess it.

Passwords containing a combination of letters, numbers, and punctuation take much longer to guess. If L0phtCrack has to cope with passwords containing such combinations, the search described above would take six years on the average instead of two days. While passwords containing numbers and punctuation are harder for users to remember and type, they are clearly much more secure than all-alphabetic passwords.

With Service Pack 2 for NT 4.0, Microsoft began providing an optional dynamic link library (DLL) that enforces strong passwords. (Service packs are cumulative, so all subsequent service packs include the functions of previous service packs.) When administrators enable this feature on domain controllers, users must choose a password at least six characters long and containing at least three out of four character types: upper-case letters, lower-case letters, numbers, and punctuation.

The point of this demonstration is that while NT security is very good from an architectural and design point of view, it is easy to undermine if administrators and users are careless. Easy access to backup copies of the SAM and the use of simple passwords make an intruder's task vastly easier, once again emphasizing the need for good security practice and hygiene with an organization.

Man-in-the-Middle Attacks

Intruders who can intercept communications between NT workstations and servers are potentially in the position to discover information. Even worse, they can attempt to compromise user accounts by capturing and then using the authentication exchange to recover the password. As we explained earlier, NT does not use cleartext passwords and thwarts replay attacks by using a random nonce, and as a rule, NT isn't vulnerable to man-in-the-middle attacks.

However, intruders could learn user passwords in some special circumstances. Pure NT authentication--that is, authentication between only NT workstations and servers--uses case-sensitive passwords, making brute-force attacks difficult. However, when NT Server must accommodate Windows 3.1, Windows for Workgroups, and Windows 95 clients, it also deploys LAN Manager authentication as we explained earlier. In such cases, NT accepts passwords without regard to case, reducing the number of dictionary and brute-force possibilities an intruder must try.

Moreover, the specific encryption technique used for LAN Manager authentication makes guessing such passwords even easier, especially if the password is 7 or fewer characters in length. Therefore, Windows 3.1, Windows for Workgroups, and Windows 95 users who must authenticate across public communication facilities like the Internet run an increased risk of having their accounts compromised.

Microsoft acknowledges the shortcomings of LAN Manager authentication and has specific advice for its customers. First, the company tells customers that the strongest possible security is possible only in all-NT environment. Customers who place a high premium on security should install only NT Server and NT Workstation. We made that same observation in the Network Strategy Report "Windows NT Workstation and Windows 95." In an all-NT network, customers can disable LAN Manager authentication on both servers and clients, thereby preventing intruders from using this loophole.

Trojan Horses

Because of the NT file system's tight access control, Trojan horse attacks have generally been unsuccessful. Trojan horse attacks attempt to deceive users with phony login dialog boxes that can capture account and password information on behalf of an intruder. As we explained earlier, NT's primary form of defense against this kind of Trojan horse attack is the so-called Trusted Path. The operating system captures the unique key sequence Control-Alt-Delete ahead of anyone else and presents a legitimate login screen. Intruder-supplied Trojan horse programs can't activate in place of the authentic login screen.

However, the Trojan horse problem does arise if the intruder can cause a user's workstation to boot up DOS instead of NT. In such cases, it's possible for a Trojan horse program to simulate NT's login appearance and capture the user's account name and password. As we explained above, the best overall defense against such contingencies is to maintain an all-NT environment, precluding user workstations from using any other OS.

Microsoft's Security Measures

Microsoft fully understands how important security is in NT's marketing and is aware of the success of past attacks on NT. Therefore, the company has taken a new and proactive attitude toward security, as evidenced by its services and products. For example, Microsoft started both the Security Problem Response Team and Microsoft's internal tiger team. The products include not only a comprehensive set of fixes in NT 4.0's Service Pack 3 but also the forthcoming Security Configuration Editor in Service Pack 4. And a host of new security enhancements is coming in NT 5.0. Microsoft has also been active in encouraging third-party developers to create supplementary security support products for NT.

Security Problem Response Team

Microsoft has established the Security Information Response Team to respond to field reports of security problems in all its products, including NT. The team works to create workarounds and fixes for these problems, and depending on the severity of the problem, provides rapid dissemination of the solution to customers.

Customers can report security problems to Microsoft in several ways. Microsoft prefers that customers report security issues by emailing them to secure@microsoft.com (customers can encrypt reports mailed to this address), reporting them to their Premier support representative, or reporting them to the Microsoft field sales force. In addition, Microsoft monitors and participates in two mail lists: ntbugtraq@listserv.ntbugtraq.com and bugtraq@netspace.org. Microsoft also obtains input from the Computer Emergency Response Team (CERT) at Carnegie Mellon University.

The response team monitors these input sources on a 7x24 basis. When a report of a security problem arrives, the product support staff immediately evaluates it. First they determine whether the problem arose because of an implementation problem (for example, the customer is using an older version of the software) and then reproduces the reported behavior. The product support staff may also get back to the reporting customer if they need more information about the problem.

The team refers security problems that pass this initial screening to the responsible developers in the appropriate product area. Those developers then try to find a workaround that affected customers can implement immediately. If this isn't possible, they then attempt to generate a hot fix to the software in question. In either case, the team posts the short-term solution on Microsoft's security Web page and sends an alert to Premier customers. Microsoft says that if it needs to create a hot fix, it tries to do so within 24 to 72 hours, although it can't guarantee these specific response times because testing the fix may sometimes be difficult. In some cases, Microsoft also coordinates with CERT in responding to a vulnerability.

The product team involved may also include a fix for the problem in the product's next service pack. Microsoft's policy is to generate a hot fix for security problems that endanger the customer's operation or data, and company officials say they are conservative in deciding on the urgency of hot fixes. In borderline cases, they will choose to issue a hot fix rather than wait for a service pack. Microsoft rolls all hot fixes into the next scheduled service pack to ensure consistency.

Security Configuration Editor

NT as a whole includes a number of separate security-oriented tools, such as Domain User Manager, Server Manager, and Access Control List Editor. However, configuring and analyzing security on an enterprise-wide basis is a complex task. The fact that customers must resort to a series of utilities makes security administration less reliable and predictable than it should be. Moreover, NT 4.0 has only Event Viewer for analyzing security policy on a server-by-server basis, and it isn't adequate for enterprise needs.

To handle these problems, the Security Configuration Editor--which Microsoft says will be available later this year with NT 4.0 Service Pack 4--will be able to configure and analyze security on a system wide basis. Security Configuration Editor will be a snap-in component of Microsoft Management Console. It will provide a simplified user interface for defining and installing security templates system-wide and for analyzing system security settings against established templates. In this sense, Security Configuration Editor will supplement the individual security-oriented tools such as Domain User Manager. Security Configuration Editor will give enterprise administrators a mechanism for applying consistent security policy across the enterprise, while allowing local administrators the option of fine-tuning local policy. For example, it may be corporate policy to prohibit Printer Operators from also serving as Backup Operators, but still allow specific exceptions in individual departments.

Security Configuration Editor will also use established security templates to audit established security policies across the enterprise and build a database from the results. Central administrators will be able to quickly spot occurrences where local policy diverges from central guidelines, and then either modify the local policy in question or revise the template to conform with established practice.

Security Configuration Editor templates will define security in six basic areas: system security policy, user accounts, rights and privileges, directory security, file system security, registry security, and system services.

System security policy covers such issues as password policy, permitted user login times, overall object security, and audit policy. User account policy defines who can belong to certain privileged groups (for example, Backup Operators) and which other privileged groups they may belong to. Rights and privileges management determines which users have special rights, such as changing the system time or accessing the system from the network. Directory security creates overall security descriptors for part or all of the NT Directory; security defined for high-level nodes in the directory tree are inherited by lower-level objects. File system and registry security define similar overall policies for each domain's file system and registry, respectively. System services define both generic and specific security properties (for example, startup settings) for each critical system service (for example, the Common Internet File System).

NT 5.0 Security

While NT 4.0 is generally secure, its lack of an enterprise directory service makes it hard to administer. In order to correct these problems and better position NT as an operating system that can safely handle intranet and extranet security problems, Microsoft will introduce several new security improvements in NT 5.0. Since NT 5.0 is still unreleased and these features are still under construction, we provide only an abbreviated description of these planned enhancements. In general, they apply to both NT Server and NT Workstation.

Active Directory's Role

Active Directory will represent a major advance over NT 4.0's simple domain model, since the domains within Active Directory will be able to form a multi-level tree structure. Customers will be able to establish two-way transitive trust relationships among these domains. Lower-level domains trust all the higher-level domains within the hierarchical tree. This arrangement will make trust relationships easier to manage and will make possible the delegation of administrative authority from higher to lower levels within the tree.

Active Directory will bear on security in two ways. First, Active Directory will be the repository for security policy information for the enterprise. For example, Active Directory will be able to store domain-wide password restrictions and system access privileges. Second, Active Directory will incorporate the object-based security model, controlling each user or group's right to read or update objects within the directory. The directory will therefore be able to hold such important items as encrypted passwords and user certificates with the assurance that only authorized users will be able to read or change them.

Multiple Security Protocols

Using the SSPI, NT 5.0 will be able to employ multiple security protocols, as Figure 8 shows. The primary mechanism for authenticating users will be Kerberos Version 5, which has the advantage of authenticating not only the client but also the server. Kerberos also has the ability to delegate authorization to the servers. Because Kerberos provides a standard authentication protocol, NT clients will be able to authenticate to Unix-based Kerberos servers, while Unix clients will be able to authenticate to NT-based servers.

We should note, however, that Kerberos is an authentication protocol, not an authorization protocol, and that authorization is essential for full interoperability. Today, Kerberos has an extension for authorization information, and NT implementation of Kerberos will use this authorization field for transporting NT SID information. (SID information is necessary ensure proper access control, as we discussed earlier.) The extension is not part of the standard however, and so there isn't a standard way of formatting the authorization field. Microsoft says it will publish a specification detailing how NT 5 uses the authorization field, but customers should understand that full interoperability between Kerberos implementations is not a given. Once a Unix Kerberos server authenticates a user, for example, he or she may not be able to access resources if the Kerberos server doesn't support Microsoft's authorization extension.

(For more information on how Kerberos works, see the Network Strategy Report "Cryptographic Systems.") Kerberos servers will authenticate users both within and across domains.

Figure 8: Multiple Authentication Services

In addition to Kerberos, NT 5.0 will also support the NT 4.0 authentication, Distributed Password Authentication (DPA), and Transport Layer Security (TLS). NT 4.0 authentication provides backward compatibility for workstations and servers running older versions of NT, and will allow NT 5.0 domains to establish one-way, point-to-point, non-transitive trust relationships with NT 4.0 (and earlier) domains. In addition, NT 5.0 servers will continue to support LAN Manager-style authentication for Windows 3.1, Windows for Workgroups, and Windows 95 clients for those who require backward compatibility and who are willing to accept the security weaknesses entailed.

Distributed Password Authentication is a shared-secret authentication protocol used by large Internet membership organizations such as MSN and CompuServe, and is part of the Microsoft Commercial Internet System (MCIS). The protocol allows users to log in once to an Internet membership organization and connect to multiple sites without re-authenticating themselves.

TLS is an Internet standard version of Secure Socket Layer version 3 (SSL3), a protocol that uses public key certificates and establishes secure sessions between Web browsers and servers. A TLS secure channel to an NT 5.0 server will use certificates issued by trusted certificate authorities and won't require an online authentication server.

Integration of Public Key Certificates

NT 5.0 will be able to authenticate users who present X.509 version 3 certificates instead of a user name and password. Once the server validates the certificate and establishes its connection with a known and trusted certificate authority, Active Directory will map the certificate to a domain user account. Multiple certificates will be able to share the same account. The domain account will then determine, through its group membership, the user's access rights to system resources. For example, a company wishing to grant certain access rights to individuals employed by a business partner can do so by mapping their certificates to a single domain account created for that specific purpose. It isn't necessary to create user accounts for each outside individual.

NT 5.0 and Internet Information Server 4.0 will also include the Microsoft Certificate Server for issuing and managing X.509 certificates. The server will be able to receive requests over such transports as HyperText Transport Protocol (HTTP), remote procedure call (RPC), and email, and check the request against custom-made policies. The server will also allow administrators to update and publish certificate revocation lists (CRLs).

Encrypting File System

Another new security feature in NT 5.0 will be the Encrypting File System (EFS), which will be part of the NT File System (NTFS). EFS will allow users the option of encrypting individual files or entire directories, including the files in contained subdirectories.

EFS will use public key technology to manage the encryption and decryption of files. Each encrypted file will have its own bulk encryption key (EFS will use Data Encryption Standard), which EFS will then encrypt with the public half of the owning user's public key pair and store with the encrypted file. The user will retain the private half in a secure place (for example, a smart card) and retrieve it to decrypt the file.

EFS will also provide for data recovery by keeping a copy of the session key with an authorized agent (usually the administrator). A separate data recovery agent--this could be an administrator or other privileged user--will also have a separate public key pair. Administrators can keep this key pair securely locked away, except when needed to perform recovery of the data in a file. EFS will use the public half to encrypt the file's bulk encryption key and store that separately encrypted version of the key with the file, along with the key encrypted with the owner's public key. If the owning user should, for example, leave the company or lose his or her private key, the data recovery agent will be able to decrypt the file.

EFS will be completely transparent to the user and will close many of the loopholes commonly found in file systems. Still, administrators must pay careful attention when implementing such products instead of assuming that they do all of the work. For example, once a user designates a file as encrypted, EFS can't enforce that attribute on any temporary files derived from the original file. Applications often fail to clean up their temporary files, which become a good resource for intruders looking for confidential information. Thus, administrators should be sure to configure applications to store temporary files in a specific directory, and then to specify that the operating system should encrypt the contents of that directory.

EFS will also provide much better protection of unattended computers and stolen laptops. DOS and Unix tools are available that can allow intruders to bypass NTFS security, giving them access to file contents by booting a different operating system. With EFS, these contents can be encrypted and therefore unusable. Many notebook computers are targets of theft not for their hardware but for the potentially valuable data they contain. Again, with EFS, this incentive will be gone.

Third-Party Solutions

Although NT 5.0 promises to solve many of the security management problems that characterize NT 4.0, the new version of the OS isn't likely to ship until late this year at the earliest. Consequently, a number of independent hardware and software vendors have created products that supplement the security features in NT or that function as cryptographic service providers (CSPs) for the Crypto Applications Programming Interface (CryptoAPI).

One such vendor is Centrax Corporation, whose Entrax product provides a mechanism for comprehensive security detection and response. Entrax supports the distribution of security policies to servers and workstations throughout the enterprise and collects security-related information from each of them to monitor activity and audit policies. This is functionally similar to NT 5.0's Security Configuration Editor, but available now for NT 4.0. Entrax can report such things as the servers, workstations, and domains accessed by a particular user; the identity of all users accessing a specific object on a target computer; a list of logins and logouts; and the top ten suspicious users, as determined by policy standards and user activity. The product can respond in a progressive fashion by increasing the level of security monitoring, disabling the account, stopping the user's processes, and logging the user off.

The Kane Security Monitor from Intrusion Detection, Inc. examines the collected event logs to identify any unusual and potentially threatening activity on the network and can automatically alert administrators. The Kane Security Analyst, on the other hand, provides an overall assessment of an NT installation, examining password strength, access control, user account restrictions, system monitoring, data integrity and data confidentiality.

Enterprise Administrator from Mission Critical Software enhances NT security by creating a true hierarchy of administrative control zones, or territories. Each territory can be under the control of a local administrator whose authority is confined to specific servers. (For more information, see the Network Strategy Report "Enterprise Administrator.")

Cryptographic Service Provider products for CryptoAPI are available from Frontier Technologies, which sells the e-Lock family of products for supporting encryption, digital signatures, and public key infrastructure. Trusted Information Systems will soon be shipping the TIS RecoverKey CSP for the emergency recovery of lost secret keys. Atalla produces the Atalla Trustmaster CSP, a PCI adapter card that accelerates bulk encryption and decryption and the generation and verification of digital signatures. SPYRUS has released its EES LYNKS Privacy Card to support Authenticode technology and other RSA-based applications.

Other ISVs providing NT security products include Axent, Bindview, and Internet Security Systems (ISS).

Comparisons

NT Server and Workstation are both more secure than their antecedents, Windows 3.1, Windows 95, and Windows for Workgroups; there is broad consensus on this point. However, the comparisons of NT with Unix and NetWare are somewhat more controversial, with vocal proponents supporting each of these operating environments. In this section, we review some of the salient differences among the security implementations of these operating systems.

Windows 95 and Windows for Workgroups

NT employs user-level security, as we discussed earlier in this document. Under user-level security, NT allows or denies access to the resource on a user-by-user basis (or collectively in a group of users). Users gain access by authenticating themselves through a name and password.

By contrast, simpler Windows products such as Windows for Workgroups and Windows 95 use share-level security to control access to shared resources, such as a subdirectory. Share-level security means that the share itself can have one or two passwords, and any user who knows these passwords can access the share. One password can determine who has full control of the share, while a second password can grant read-only access. Both passwords are optional.

While share-level security provides nominal protection, the quality of that protection is greatly inferior to user-level security. For one thing, multiple users share knowledge of a secret, which makes unauthorized dissemination of that secret virtually impossible to control. In contrast, user-level security entails passwords unique to each person. In addition, share-level security offers no possibility of effective auditing because it is impossible to know who accessed the shared resource. With user-level security, each person requesting access--even through group membership--must present his or her personal credentials.

Unix

The Unix operating system--in all of its variants--is similar to NT in that its architecture includes security considerations. Unix security is on a par with NT's, although Unix security is somewhat simpler and less granular than that of NT. Unix has something of an advantage from having been in existence longer than NT and therefore having had more field-testing. However, Microsoft has been diligent in correcting NT's security vulnerabilities and the resulting rapid maturation of NT has made its security as good as that of Unix. (Microsoft also argues that it has sold many more copies of Windows NT than competing vendors have sold of Unix. Thus, Microsoft says, NT has a much larger number of "system hours," which is multiplying the number of users times amount of time they've used the product, than the leading Unix implementation.)

Unix authentication entails verifying a user's ID and password against account information stored in Unix's file system. Like NT, Unix stores passwords in encrypted form, allowing for both plaintext and encrypted password login processes, depending on the implementation. But it's worth pointing out that many Internet protocol servers for Unix, such as Web servers and mail servers, use basic authentication--clear-text passwords. While SSL can protect such implementations from man-in-the-middle attacks, many companies don't use SSL on corporate intranets because of the performance hit it entails. Instead, they use basic authentication. Because Microsoft has integrated them with NT, Internet Explorer and IIS can use LM authentication, which is at least better than clear text. Other Web servers and clients don't support it, however, so customers have to choose between better security and interoperability.

Unlike NT, Unix employs salt values as part of the encrypted password. As we explained earlier, a salt value is a random number appended to each password encrypted on a given server. Since the salt value changes from server to server, it's impossible to tell if multiple accounts on different servers have the same password--as many users have. Also, having a different salt value on each hashed password prevents intruders from making use of precomputed dictionaries for breaking passwords.

The objects in the Unix file system--folders and files--have three specific access rights associated with them: execute, read, and write. The ability to read also implies the ability to list (in the case of a folder) and the ability to write implies the right to delete. In contrast, NT's Access Control Lists can separately grant or withhold specific access rights. Unix grants or denies these rights to three categories of user: the object's owner, members of the object's group, and the world. For example, suppose user GCleveland creates a file (and is therefore the file's owner) and places it in the group called "Cabinet." GCleveland can retain the execute, read, and write privileges, but grant only the read privilege to the Cabinet and no privileges at all to everyone else (the world in Unix terms).

A file object can belong to only one group but users can belong to multiple groups. Thus Unix is similar to NT in that the administrator grants file object privileges to users by including those users in the appropriate group. Unlike NT, it isn't possible to create multiple groups, each of which has a separate set of access rights to the file (aside from the single exception of world privileges). In this sense, Unix has less granular access rights controls than NT.

Overall, then, Unix security is on a par with NT. Unix has been in use longer than NT, but it also has the disadvantage of having split into a number of dissimilar versions. The leading vendors of Unix--namely Sun, IBM, and Hewlett-Packard--often tie their Unix implementations to their hardware marketing agendas. NT, by contrast, exists only in the versions Microsoft creates. Beyond these considerations, Unix and NT have similar internal architectures, relying on preemptively dispatched threads and protected address spaces. Both operating systems provide reliable platforms for mission-critical applications.

NetWare 4.x

As a network operating system providing basic file and print services, NetWare provides security comparable to NT's. Like Unix, NetWare 4.0 and Novell Directory Service (NDS) store user passwords hashed with a salt value, which is the user's 32-bit user ID. Unlike NT and Unix, NetWare employs public key cryptography to fully authenticate the user to servers under NDS control and to maintain data integrity during login sessions. The password serves as an encryption key to protect the user's private key.

A user logs in to NDS by proving to NDS that he or she knows the password through encrypted challenge-response exchange, at which point NDS securely conveys the user's private key to the user's workstation. Instead of using this permanent private key for data signatures, the workstation uses it to compute a temporary Gillou-Quisquater (GQ) key, which has two advantages. First, it's faster to use for signatures and second it's valid for only a defined period of time, thus limiting the amount of damage that rogue workstation software could do if it got possession of the key. The workstation doesn't store either the user password or the private key.

Once the user logs in and his or her workstation generates a session GQ key, the workstation and the servers under NDS can mutually authenticate themselves through their public keys. They also safeguard the integrity of much of the data exchanged between them by digitally signing the first 52 bytes of each packet.

Like NT, NetWare maintains Access Control Lists for the network objects (files, directories, printers, servers, etc.) under its control. Each of these Access Control Lists can grant or deny a variety of access rights either to individual users or to various groups. However, NetWare's security differs from NT's in that NDS supports multiple hierarchical levels from the tree root down through organizational units (including subsidiary organizational units) and multiple servers, each containing directories, files, printers, and other network resources. NDS allows the administrator to define security privileges at any of the levels, while NT 4.0's directory structure supports only domains at the top level and servers within each domain. (We discussed NT 5.0's more advanced distributed security earlier in this report.)

However, as an application server, NetWare isn't quite as bulletproof as NT or Unix, since its design emphasizes performance and not application integrity. From the point of view of server-based applications, Novell designed NetWare for speed, not application and kernel protection, and this design choice had its effect on NetWare's overall security. Thus, NetWare doesn't use separate address spaces, preemptively dispatched processes and threads, or the protection features of the processor's hardware. In theory, any rogue application running on the server can invade and compromise the operating system kernel, a contingency that is not a serious problem with NT or Unix.

To be sure, denial-of-service and Trojan horse attacks are no more prevalent with NetWare than they are with NT or Unix. However, as we noted, NetWare doesn't have the same kind of bulletproof kernel as the other operating systems, so it's slightly easier for would-be intruders to exploit any weakness in NetWare server-based applications. On the other hand, NetWare has an advantage with NDS, allowing enterprise customers to more easily deploy and manage security policy. This advantage is temporary until Microsoft ships Active Directory with NT 5.0.

Conclusion

While Windows NT includes robust security features, NT Server has come under a number of attacks, the success of which has been due primarily to bugs in the operating system, not fundamental architectural flaws. Microsoft's past response to security problems was less than ideal as well. But Microsoft made an impressive turnaround over the last year, implementing measures that have established NT as a secure operating system and improved the company's standing. Remaining issues include NT Server's support for the less-secure LAN Manager authentication protocol and the lack of a fully functional directory that provides a common foundation for all security functions. While NT can stand some improvement, Microsoft has taken its responsibility for security seriously, and is fielding a secure product with NT 4.0 and the appropriate service packs.