Microsoft Windows NT 4.0 and Windows 98 Threat Mitigation Guide

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Chapter 4: Hardening Windows NT 4.0

Published: September 13, 2004 | Updated : March 30, 2006

Note: Welcome to the TechNet Archive. We've created this Archive area so that we can continue to make available older content that is still of interest to some of our users. This allows us to streamline the content offerings on the site and keep it focused on the newest, most relevant content.

On This Page

Introduction
Windows NT Host Security Design
Implementation
Testing the Solution
Summary

Introduction

Microsoft® Windows NT® version 4.0 lacks some of the enhanced security functionality that later versions of the Microsoft Windows® operating system have. Still, it has a number of extremely useful features and techniques that significantly increase the security of your systems. This chapter covers these topics in detail and explains how to use these features to harden your Windows NT 4.0 systems, whether they are workstations or servers.

These topics include information on how to:

• Install the initial operating system and patch baseline.

• Harden the boot sequence.

• Install the Directory Services Client add-in.

• Use system policies and the Security Configuration Manager.

• Choose the Windows NT LAN Manager (NTLM) authentication level.

• Define effective password policies.

• Use account and password lockouts.

• Harden the file system.

• Harden services.

• Perform other hardening measures.  

Windows NT Host Security Design

Hardening the Windows NT 4.0 operating system requires assessment and understanding of multiple topics.

Installing the Initial Operating System and Patch Baseline

The first critical step in hardening Windows NT-based systems is to install the latest set of security patches for the base operating system. Ideally you should have performed this step as part of your normal patch management process, as described in Chapter 6, “Patch Management.” This process should begin with a complete inventory to determine which computers are at which revision levels. You can use the Microsoft Baseline Security Analyzer (MBSA) or Microsoft Systems Management Server (SMS) to scan Windows NT 4.0 systems, either locally or remotely. After you complete the inventory, you should inspect inventory results to ensure that each Windows NT system has the necessary set of baseline updates installed. These updates should include:

• Service Pack 6a (SP6a) for Windows NT 4.0, which is the most recent service pack for Windows NT 4.0; it contains a complete and regression-tested set of fixes that are designed to be installed as a unit.

• The Post-Windows NT 4.0 Service Pack 6a Security Rollup Package (SRP). The SRP incorporates several patches that were released after the original SP6a release

• An up-to-date set of security patches. Microsoft has not released an integrated SRP or service pack for Windows NT 4.0 since the release of the SRP, but individual components such as portions of the operating system, Microsoft Internet Explorer, and add-on utilities such as the Routing and Remote Access Service (RRAS) and Internet Information Services (IIS) have been updated. You can obtain a current list of patches from Microsoft TechNet, or manually review the list of patches available through Windows Update.

• An updated version of Internet Explorer. Internet Explorer 6.0 Service Pack 1 (SP1) is the current version; it incorporates hundreds of security fixes and improvements released since the versions of Internet Explorer available with released versions of Windows NT. Depending on your environment, you may choose to download Internet Explorer directly from the Microsoft Web site, order it on a CD – ROM, or install it on multiple computers by using the Internet Explorer Administration Kit.  

Hardening the Boot Sequence

After the system has a correct and complete minimum patch set, you must next increase the degree of protection available to the system at boot time. This protection takes two forms: zeroing the boot menu timeout to make it more difficult for an attacker to boot into an alternate operating system, and using the built-in Syskey utility to encrypt information stored in the Security Account Manager (SAM) database.

Windows NT Server stores user account information, including a derivative of the user account password, in a secure portion of the registry protected by access control and an obfuscation function. The account information in the registry is accessible only by members of the Administrators group. Windows NT Server, like other operating systems, allows administrators access to all resources in the system. For installations that want enhanced security, strong encryption of account password derivative information provides an additional level of security to prevent administrators from intentionally or unintentionally accessing password derivatives by using registry programming interfaces. Syskey also protects SAM data from various kinds of offline attacks mounted by booting into an alternate operating system and accessing the SAM files.

Syskey generates a random encryption key that is used to encrypt the SAM data. After the SAM data has been encrypted, the key must be loaded at boot time and used to decrypt the in-memory copy of the SAM data. Syskey operates in three modes, as shown in Figure 4.1:

• In mode 1 (Store Startup Key Locally), the encryption key is super encrypted and stored on the local computer. At boot time, the key is decrypted and loaded, allowing the computer to be restarted without administrator intervention.

• In mode 2 (the Password Startup button and associated text fields), the encryption key is super encrypted with an administrator-specified pass phrase. At boot time, the administrator must type the pass phrase into the console to complete the boot. The system will not boot until the pass phrase is entered.

• In mode 3 (the Store Startup Key on Floppy Disk button), the random Syskey key is stored on a floppy disk, which must be inserted at a prompt during the boot cycle. This floppy disk must be stored and maintained securely.

  

  Figure 4.1 Syskey’s mode selection dialog box

Trey chose to implement Syskey protection on all of its computers running Windows NT. (Syskey is already enabled by default in Windows 2000, Microsoft Windows Server™ 2003, and Windows XP.). Most of Trey's servers, and all of its workstations, are set to use Syskey mode 1; Trey chose this mode for widespread use because it offers a reasonable balance of security and convenience. For high-value servers, Trey is using mode 2 even though it requires an administrator to visit the computer and enter the password each time it is rebooted. Because of the requirement to securely store and maintain a boot floppy disk for each protected computer, Trey elected not to use mode 3 on any of its systems.

Installing the Directory Services Client Add-In

Windows NT 4.0 systems can only fully participate in Windows NT domains; if there are Microsoft Active Directory® directory service domains, Windows 98 and Windows NT can natively participate in them only through the network basic input/output system (NetBIOS) interface. Windows 2000 and Windows Server 2003 provide NetBIOS compatibility by emulating a Windows NT primary domain controller (PDC). Even though Active Directory provides transitive two-ways trusts, Windows NT 4.0 systems can take advantage only of explicit one-way trusts, whether the system is using an Active Directory domain controller or a Windows NT BDC.

Instead of maintaining Windows NT-style domains, it is possible for computers running Windows NT and Windows 98 to participate in Active Directory domains by adding the Directory Service Client (DSClient) add-in. DSClient enables these systems to participate in Active Directory domains. With this software, these systems have use of many of the Active Directory features, such as the ability to use transitive trust relationships within the forest. Transitive trust relationships allow authorized users to access appropriate resources in any domain in the forest. The DSClient 2003 update runs on Windows NT 4.0 with SP6a and Internet Explorer 6 SP1; the DSClient version supplied with Windows 2000 also requires SP6, but can use Internet Explorer 4.01 or later. (Requirements for using the DSClient with Windows 98 are described in Chapter 5, “Hardening Microsoft Windows 98.”)

After it has been installed, DSClient does not provide support for all Active Directory features; in particular, it does not support Kerberos authentication, Group Policy application, or the use of service or user principal names (UPNs) for authentication. However, it does enable support for the following Active Directory features:

• Active Directory Service Interfaces (ADSI). ADSI provides a common programming API for Active Directory-aware scripts and programs. With ADSI, it is possible to script a large number of directory operations that would otherwise be unscriptable under Windows NT.

• Distributed file system (DFS) fault tolerance client. DFS fault-tolerant and fail-over file shares provide Active Directory-integrated, distributed file share resources.

• Active Directory Windows Address Book (WAB) property pages. User object pages, accessed through the Search menu, provide the capability for authorized users to update properties (such as addresses and phone numbers) on user objects.

• NTLM version 2 authentication. NTLM provides improved authentication features and gives the best level of authentication security other than Kerberos.

• Site awareness. Systems using the DSClient are aware of Active Directory sites and will use a domain controller in their local site, even for password change operations, if Domain Name System (DNS) is properly configured and sites are properly registered in Active Directory. See Microsoft Knowledge Base (KB) article 249841, “How Windows 98 Active Directory Client Extension uses Active Directory site information” at https://support.microsoft.com/?kbid=249841 for more details on how DSClient affects logon and password change behavior.

• Search for objects in Active Directory. Users can find printers and users in Active Directory from the Search menu.

• Reduced dependency on the PDC. Clients may connect to any domain controller in the domain for password changes.

Using System Policies and the Security Configuration Manager

System policies are a specific configuration management measure that Microsoft first made available with Windows 95 and Windows NT 4.0. By themselves, they do not increase the security of the system; they will, however, allow you to restrict access to specified resources in a way that enhances your other security measures, making it more likely that users will be unable to circumvent your policies and restrictions either through intent or ignorance. When these policies are properly designed and applied, they are a critical part of ensuring the integrity of your older systems. In fact, they are so useful that Microsoft expanded upon them for the Group Policy Object (GPO) functionality in Windows 2000 and later.

A system policy is a set of one or more restrictions that are applied to the HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE registry hives. When the user logs on to a computer, a successive series of policies are checked for and (if found) applied, based on the user name, global group memberships in the domain, and computer-specific policies. System policies are intended to be used in a Windows NT domain implementation and complement other domain-aware features such as user profiles.

It is important to understand the difference between system policies and user profiles. User profiles are the collection of user-specific configuration directories, files, shortcuts, and registry hives loaded under HKEY_CURRENT_USER (Ntuser.dat for Windows NT, User.dat for Windows 98); they control the appearance of the desktop, browser favorites and bookmarks, and other user-configurable options in both the operating system and any applications. Conversely, system policies are an extra set of registry entries that are applied to the computer after the active user profile has been located and loaded; they specify particular features of the operating system to which the current user should not have access.

Working with System Policies

Microsoft provides a detailed white paper, “Guide to Microsoft Windows NT 4.0 Profiles and Policies,” which explains user profiles and system policies, how they are used, and how they are used together. (See the “More Information” section for the white paper’s location).

System policies provide you with many controls over earlier versions of the desktop and user interface. If you are familiar with Group Policies in Windows 2000, you will be familiar with the basic capabilities of system policies. In general, though, they allow you to:

• Specify a banner or disclaimer that will be displayed before users are permitted to log on, such as one advising them of any applicable legal usage policies.

• Prevent the logon dialog box from displaying security-sensitive information such as the user name of the previous user or the shutdown button.

• Specify the behavior of logon scripts, cached roaming profiles, slow network detection, the Start banner, and Welcome Tips.

• Specify the location of various shared folders on the Start menu, including the Startup folder, allowing you to ensure that particular applications are always launched at logon.

• Restrict the appearance of the desktop: backgrounds, icons, colors, and available commands on the Start menu.

• Specify the behavior of various file system-related features, such as shell extensions, read-only file access time updates, and long file names.

• Restrict access to network resources, available drive letters, and the ability to map drives in the Windows Explorer. See KB article 156698, “Disabling Access to Network Resources Using System Policies” at https://support.microsoft.com/?kbid=156698 and KB article 220955, “Using System Policies to Hide Specific Drive Letters” at https://support.microsoft.com/?kbid=220955 for more information.

• Restrict the creation of hidden file shares.

• Specify and restrict printer, Simple Network Management Protocol (SNMP), and RRAS settings.

• Restrict the ability of the shell to launch particular executables.

• Restrict the ability to launch registry editors and the command prompt.  

System policies have many similarities to Group Policies, but there are a few limitations and differences that you need to keep in mind:

• System policies are not hierarchical. Given the flat nature of the Windows NT domain model, you do not have the same flexibility to define overlapping, complimentary system policies that you do with Group Policies under Active Directory. You can define policies for individual users, default users, groups, individual computers, and default computers. A subsequent section in this chapter describes the method used to apply them.

• System policies make their changes directly to the appropriate registry hive. They stay in force until something causes them to be changed, such as an alternate policy. Group Policies in Active Directory make their changes to a special part of the registry, which Windows then uses to override the normal registry entries. This system policy practice of making direct writes to the registry is known as “tattooing the registry” and means that system policies cannot make any assumptions about the state of any setting that is being managed.  

System policies are created by using the System Policy Editor (SPE) utility and administrative template files (.adm). These template files provide the SPE categories and subcategories, registry keys and values that control the specific settings, as well as any options, restrictions, and default values that may apply. You may create your own custom template files and add in specific registry settings that are not covered by the default templates supplied with the SPE.

After SPE is run and you create a group of settings that are then associated with a specific user, group, computer, or default user or computer, you will have a policy file named Ntconfig.pol. By default, computers running Windows NT are set to download appropriate policy files from the NETLOGON share on the domain controllers. Policy files should be placed in this share on the PDC; the contents of this share are then replicated to the BDCs via the Directory Replicator service. Computers running Windows NT can download all applicable policies from the domain controller they use for logon. These behaviors are the same whether the domain controllers are Windows NT or Windows 2000 or Windows Server 2003, because Windows 2000, Windows XP, and Windows Server 2003 clients will ignore policy files in the NETLOGON share in preference for the Active Directory-integrated GPOs.

System policies are loaded and applied on Windows NT in the following manner:

1. If a user-specific policy exists, it is loaded, the registry is modified, and the policy processing skips to step 4.

2. If the Default User policy exists, it is loaded and applied.

3. If Group Policies exist, they are loaded and applied in ascending order of priority as applicable. If a Group Policy conflicts with the Default User policy, it will take precedence unless the Group Policy setting is to “ignore.”

4. If a computer-specific policy exists, it is loaded, the registry is modified, and the policy processing skips to step 6.

5. If a Default Computer policy exists, it is loaded, and the registry is modified.

6. The policy application is complete.  

By default, Windows NT is set to download and apply system policies. This behavior is described in KB article 168231, “System Policies Are Not Applied in Windows NT” at https://support.microsoft.com/?kbid=168231, and is controlled by the following registry value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Control\Update\UpdateMode (REG_DWORD)

• A value of 0 disables the application of system policies.

• The default value of 1 enables Automatic mode. Windows will look for the Ntconfig.pol system policy file on the authenticating domain controller as described previously.

• A value of 2 enables Manual mode. Windows will look at the NetworkPath (REG_SZ) value (in the same key) and attempt to find the policy file located there.  

It is important to verify the proper functioning of system policies. KB article 154120, “Debugging User Profiles and System Policies in Windows NT 4.0” at https://support.microsoft.com/?kbid=154120 describes the process of replacing userenv.dll with the check build version, allowing you to create a log file that you can use to debug policy application. This procedure is good on all versions and service pack levels of Windows NT 4.0, including Terminal Server edition.

Even though the default system policy behavior depends on a functional Windows NT domain infrastructure, computers running Windows 2000, stand-alone computers running Windows NT, and users in the local account database can still benefit from system policies. KB article 168579, “How to Set Up Locally-Based System Policies” at https://support.microsoft.com/?kbid=168579 gives specific directions for two methods of configuring a Windows NT system so that it can provide system policies for users in the local account database. If you are using computers running Windows 2000, Windows XP, or Windows Server 2003 on a Windows NT domain, KB article 274478, “Group Policies for Windows 2000 Professional Clients in Windows NT 4.0 Domain or Workgroups” at https://support.microsoft.com/?kbid=274478 gives the process necessary to allow Windows 2000-compatible policies to be distributed by Windows NT domain controllers.

Planning Considerations for System Policy Deployment

Keep in mind these potential system policy complications as you develop and deploy your policies, in order to ensure the best level of security:

• Because of various bugs in the system policy implementations in Windows NT 4.0, you must have at least SP3 to ensure that all of the important patches related to system policies have been applied to your systems. Generally, this is not a problem unless you have specific requirements for supported applications, because other security requirements virtually demand that you have all your Windows NT systems on SP6a.

• System policies require up to two logons and logoffs in order to ensure that system policies are being located, downloaded, and applied.

• Because policies do not automatically remove themselves from a computer, you should create a group-specific policy for your administrator accounts. This policy should be set to remove, at a minimum, the restrictions necessary for your administrators to re-grant themselves access to those features they may need; a common Administrator Group Policy is to simply restore all restricted features.

• Carefully read the individual settings in your policies and be sure that you are correctly parsing any potential double negatives. Some settings will require you to enable them in order to turn off the specified behavior.

• You should double-check the location of your system policy files. They should be in your NETLOGON share, the location of which varies according to whether the primary domain controller is running Windows NT 4.0 or Windows 2000 or Windows Server 2003.

• It is important to ensure that your Directory Replication service is working correctly and that the contents of the NETLOGON share on the PDC are getting properly copied to all the BDCs.

• You should ensure that the modification time of your policy files is updated every time you modify and deploy a new policy. Some clients with older service packs will cache the policy files, and they use the modification time as their indicator to refresh the file. Better yet, ensure that all of your computers running Windows NT are on at least SP3, and preferably on SP6a.

• If you have a mix of Windows NT 4.0 and Windows 2000 or Windows Server 2003 domain controllers, it is possible to establish a replication process to bridge between Windows NT’s Directory Replication service and Windows 2000’s File Replication Service. You can achieve this by using the Lbridge.cmd tool available in the Windows 2000 Server Resource Kit.

• Windows NT 4.0 Terminal Server Edition poses an interesting set of complications for the use of system policies. See KB article 192794, “How to apply System Policy settings to Terminal Server” at https://support.microsoft.com/?kbid=192794 for more information.  

It is worth repeating that system policies are not an adequate substitute for proper application of registry and file system access control lists (ACLs), nor will they allow you to skimp on other system hardening measures. As an example, consider the system with a system policy that restricts the user to only running the Microsoft Office application binaries. The user could make use of the standard Office File menu to create new folders, copy executables such as cmd.exe or either of the registry editors to writeable locations, and rename them to executable names permitted by the system policy – thus circumventing the policy.

There are specific areas of weakness that you need to consider when deploying system policies in order to supplement them with other security measures:

• Any restricted executables in system policies should be specified by full path names and should not rely on the default search path.

• You should consider restricting the use of the Tools and Views menus in Windows Explorer. These menus contain many options that can be used to overcome policy restrictions.

• Registry files (.reg) can normally be executed even if access to RegEdt32 and RegEdit has been removed, because the default file name extension association is still in place.

• No user-writeable directories, such as their temporary directory and profile directory, should ever be part of the default search path.

• The World security ID (SID) in the registry has more access than it should. You should strongly consider restricting it to only the Query/Enumerate/Read permissions; however, this may break older applications and require extensive testing to determine the specific permissions that you must apply in order to retain functionality.

• All executables in system directories should be carefully scrutinized. Even if you remove the Execute permission from them, if a user has Read, he or she can copy them into a writeable location and attempt to run them from there.  

Security Configuration Manager

Security Configuration Manager (SCM) was originally designed for Windows 2000, but Microsoft made it accessible to Windows NT 4.0 SP4 and later. SCM is available on the SP6a CD-ROM or by download from the Microsoft FTP site. The chief tool in SCM is the Security Configuration Editor (SCE), which you use to create and manage security templates and system policies.

You can use the SCE to perform several useful tasks. For example, with it you can:

• Build security templates that specify auditing, user rights, and security settings for computers running Windows NT.

• Apply templates automatically to one or more computers in a domain.

• Scan one or many computers to assess their levels of compliance with a particular template.  

By default, installing SCE adds a set of templates in the %winnt%\security\templates folder. Each template is intended for a particular security environment and computer type:

The basic templates (Basic*4.inf) apply a standard level of security to target computers, including a six-week password age limit and a basic set of registry key, file system, and user rights permissions.

The compatible templates (Comp*4.inf) apply stronger security than the basic templates. However, security settings that can interfere with older clients or applications remain turned off; the goal of this template set is to raise security without introducing application compatibility problems.

The high security templates (HiSec*.inf) apply some additional security policies, including increasing the minimum password length to eight characters from seven and using a more restrictive set of file system and registry permissions. These templates can cause problems with older applications that depend on file system or registry permissions or user rights assignments.

The secure templates (Secur*.inf) are the most protected standard templates, but they enable features — including Server Message Block (SMB) signing—that will limit interoperability between secured computers and Windows 95/98 clients that are not similarly configured.

Table 4.1: Predefined Templates That Ship with the Windows NT SCE Toolset

If you want	To secure	Use
Basic security	Primary / backup domain controllers	BasicDC4.inf
	Member servers	BasicSv4.inf
	Workstations	BasicWk4.inf
Improved security with good application compatibility	Primary / backup domain controllers	CompDC4.inf
	Member servers	CompDC4.inf
	Workstations	CompWS4.inf
High security with reduced application compatibility	Member server or domain controller	HiSecDC4.inf
	Workstation	HiSecWS4.inf
High security with reduced Windows 98 connectivity	Member server or domain controller	SecurDC4.inf

Because the SCM was originally designed for Windows 2000, it provides a familiar interface for those administrators who use Group Policies. This familiar interface includes updating the integrated Windows NT ACL editor to the same ACL editor used on Windows 2000. This action has important consequences on ACL behavior throughout the entire system, because SCM requires the Windows 2000 ACL inheritance model, which applies inherited ACLs dynamically. Rather than copying access control entries (ACEs) from the parent object onto the child object, the new subsystem references the Allow Inheritable Permissions policy to see if it is enabled. The updated inheritance system will be used by the normal ACL editors in the Windows Explorer as well as through the policies applied by the SCM. However, it will not be directly accessed by the Registry Editor (regedt32.exe), so policies applied by SCM that change ACLs in the registry can create ACLs that cannot be manipulated by the Registry Editor. Further information about the new ACL editor system and its consequences, including directions for disabling it (which in turn disables SCM), can be found in KB article 195509, “Installing Security Configuration Manager from SP4 Changes Windows NT 4.0 ACL Editor” at https://support.microsoft.com/?kbid=195509.

The SCM lets you configure the following areas:

• Account Policies, which includes password and account lockout policy options.

• Local Policies, which includes audit, user rights assignment, and security policy options.

• Event Log policies.

• Restricted Groups, which provides the ability to lock down the membership of designated groups.

• System Services, which provides options to configure various services and transports.

• Registry permissions.

• File System permissions.  

The SCM GUI provides a listing of the various policies that have been defined and that are stored in the %winnt%\security\templates folder. The graphical user interface (GUI) lets you define, edit, and maintain multiple policies suitable for the different older systems you maintain, as well as analyze the system and compare its compliance with a selected policy template.

The primary difference between SCM and Active Directory policies is that Windows NT does not provide an automated way of deploying policy templates throughout a related group of computers, so you still must provide some way of distributing configuration templates to the appropriate computers. Distribution will require either manual intervention or some sort of scripting, combined with some mechanism to ensure that policies are automatically applied on a regular basis.

Use SCM to assist in making and deploying the following basic account policy changes on all systems:

• Rename the Guest account (in addition to disabling it) by using the SCM (via the Local Policies | Security Options | Change Guest account name to setting). Even though it is disabled, ensure that it has an extremely strong password. Regularly audit to ensure that it is not included in any groups other than Domain Guests, which should have no other members.

• Rename the Administrator account to something that is not obvious (using the Local Policies | Security Options | Change Administrator account name to setting), then create a decoy account named Administrator with no privileges or permissions. Treat this decoy account as you did the Guest account by setting a strong password for it and disabling it. Do not make the common mistake of labeling this account as a decoy in the comments; this will defeat the purpose of the account. You also need to regularly audit to ensure that the decoy account is not added to any groups; be sure to watch out for authentication attempts against this account. Although this measure does not prevent attackers inside the network from using the well-known SID to find the real name of the administrator account, it does slow down sloppy attackers and attempts from external networks, giving you advanced warning of hostile intentions.

• Prohibit the enumeration of account names and file shares for anonymous users (the null session). By default, Windows permits a remote system to connect with no credentials and list this information. This technique is a common route of attack. Use the Disallow enumeration of account names and shares by anonymous setting in the Security Policies object of the Local Policies node.

Choosing the NTLM Authentication Level

Windows NT 4.0 clients earlier than SP4 use NTLMv1 authentication, which has been proven to have design flaws that make it vulnerable to interception and decryption by attackers. NTLM authentication was designed as a successor to the even weaker LAN Manager (LM) authentication protocol, which requires the storage of all password information in a weaker hash known as the LM hash (which the subsequent section describes in more detail). The LM hash is easily cracked and broken, leading to compromise of the password.

LM, NTLM, and NTLMv2 are used to authenticate such operations as:

• Joining a domain.

• Authenticating between Active Directory forests.

• Authenticating to Windows NT 4.0 domains.

• Authenticating to computers running Windows NT 4.0 or Windows 98 acting as file or print servers.

• Authenticating to servers that are not domain members.

Because Trey has a mix of computers running Windows Server 2003 (for domain controllers), Windows 98, and Windows NT 4.0, it needs to choose an NTLM authentication level that provides the best possible security while still allowing existing clients to operate properly. Windows NT, Windows 2000, and Windows Server 2003 support six levels of LM compatibility, controlled through the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel registry key:

• 0 (Send LM & NTLM responses). This setting offers the most interoperability, because clients may use LM or either version of NTLM to authenticate. However, it allows insecure LM traffic on the network.

• 1 (Send LM & NTLM–use NTLMv2 session security if negotiated). This setting offers more security, but it requires the DSClient software for Windows 98. When this value is chosen,NTLMv2 can be negotiated if both computers support it. This value is the best setting to use during deployment; all computers with DSClient will use NTLMv2, while all other clients with earlier version of Windows can still authenticate.

• 2 (Send NTLM response only). This value will restrict the use of Windows 98 clients without the DSClient installed because servers will not answer LM requests from unmodified computers running Windows 98.

• 3 (Send NTLMv2 response only). Use this value only if all clients running versions of Windows prior to Windows NT 4.0 SP4 have DSClient installed.

• 4 (Send NTLMv2 response only\refuse LM). Like the previous setting, with the addition that if LM authentication is requested, no NTLMv2 response is sent.

• 5 (Send NTLMv2 response only\refuse LM & NTLM). Like the previous setting, except that NTLM requests are ignored, as well. This setting is only appropriate for networks where all computers are either running Windows 2000 or later or running Windows 98 with the DSClient installed.

Upgrading NTLM Authentication for Windows 98

The DSClient extension allows Windows 98 systems to use NTLMv2 for authentication. By default, NTLMv2 session security encryption uses a 56-bit maximum key length. To enable 128-bit NTLMv2 support, ensure that Internet Explorer 4 or higher is installed and that 128-bit support is installed and configured. This preparation must be performed before you install the DSClient.

After you have distributed the DSClient software to your client computers, you can restrict which versions of the LM protocol family can be used for authentication. You must configure these restrictions on all domain controllers and other servers that provide accounts used for remote authentication.

Upgrading NTLM Authentication on Windows NT 4.0

Windows NT 4.0 SP4 and later include the ability to selectively use and respond to LM, NTLM, and NTLMv2 authentication requests. This change requires the addition of a registry key (described in the following implementation section). Trey chose to set the compatibility level to 5 (allow NTLMv2 only) on its Windows NT systems, but it waited to make this change until all Windows 98 systems had the DSClient extension installed.

Upgrading NTLM Authentication on Windows 2000 and Windows Server 2003

Trey’s IT administrators created a new GPO on the company's domain controllers to set the NTLM authentication level for computers and domain controllers and attached it to the Domain Controllers organizational unit (OU). They accomplished this by modifying the Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\LAN Manager Authentication Level setting. Be sure to use the Domain Controllers policy for domain controllers, the Domain policy for Active Directory members, and local policy for stand-alone computers or computers that are members of Windows NT domains.

After DSClient is fully deployed on all Windows 98 systems, it is appropriate to change the LM authentication level setting to 3, 4, or 5, which disallows the use of LM authentication. Until then, systems running earlier versions of Windows without DSClient will lose access to all network data.

Because Trey’s environment includes Windows 98 clients, all of which have the DSClient extension, Trey set this value to 5 on Windows NT-based computers (Windows NT, Windows 2000, and Windows XP) and to 3 on computers running Windows 98. Otherwise, settings higher than 3 on computers not running Windows 98 will prevent those computers without the DSClient extension from authenticating.

Refer to KB article 305379, “Authentication Problems in Windows 2000 with NTLM 2 Levels Above 2 in a Windows NT 4.0 Domain” at https://support.microsoft.com/?kbid=305379 for information about a hotfix that ensures that this setting works in networks with a mix of Windows 2000 and Windows NT 4.0 systems.

Windows systems create communication channels, known as secure channels, which are used to authenticate computer accounts and user accounts in trusted domains. Secure channels prevent man-in-the-middle attacks and allow clients to access account databases in trusted domains. Secure channels can be digitally encrypted or signed, but all domain controllers must be running Windows NT 4.0 SP6a or higher. Because secure channel signing affects all clients in the domain, as well as clients in trusting domains, think carefully before enabling this feature.

Defining Effective Password and Lockout Policies

One of the fundamental principles of security is to avoid transmitting or storing plaintext passwords. A password stored in plaintext is easily revealed, both from examination of the SAM or from sniffing network sessions. Modern Windows authentication protocols use encryption algorithms known as hashes to protect all transmission of authentication credentials as well as to store that password from the moment the user enters it. However, it is necessary to define policies that control password length and strength, as well as how many failed logon attempts are allowed before the account is locked out.

The Microsoft Security Guidance Kit (SGK), available at https://www.microsoft.com/downloads/details.aspx?FamilyID=c3260bd0-2ebb-4496-ad07-7e9d55d0ef1f\&displaylang=en, contains a number of reference documents that can help in choosing and implementing a strong password and account lockout policy.

Hardening the File System

In conjunction with boot hardening, you need to increase security of the file systems and storage devices on each computer running Windows NT 4.0 in the organization.

The first critical step is to make sure that all of your computers running Windows NT 4.0 are using NTFS file system (NTFS). NTFS provides file and folder permissions, in addition to the share-level permissions offered in Windows NT, Windows 98, and their descendants. Using NTFS permissions restricts the ability of users on a computer to read files belonging to other users, and it makes it more difficult for attackers who gain physical access to the console to steal or modify data without booting into an alternate operating system. Windows NT includes a command that nondestructively converts file allocation table (FAT) or FAT32 volumes to NTFS, although it requires exclusive access to the volume.

When a volume is converted to NTFS with the convert utility, the default permission applied is Everyone:Full Control. You need to change this permission, because it is unnecessarily permissive; existing NTFS systems also might have unnecessarily lax permissions.

The National Security Agency (NSA) has developed a set of recommended permissions for Windows NT servers and workstations and published them in the Guide to Securing Microsoft Windows NT Networks. You can apply these recommendations manually with scripts that use the xcacls tool (described in KB article 318754, “HOW TO: Use Xcacls.exe to Modify NTFS Permissions” at https://support.microsoft.com/?kbid=318754) or by using predefined SCM templates. The recommendations contained in chapters 11 and 13 of the guide are quite extensive, so you must refer to that publication for detailed instructions for implementing them.

Hardening Services

There are several configuration changes centered on securing services and accounts that are usually appropriate for all Windows NT environments.

One of the many improvements that Windows NT 4.0 SP3 delivered was the creation of the Authenticated Users security group. This group is intended to replace the Everyone security principal in all areas where you want to prohibit any user or process, regardless of authentication status, to be able to access files and services. This group should be replaced in every file ACL that you create and manage, unless you truly need to allow anonymous connections. For most services, this should not be necessary; IIS, as an example, maps all anonymous requests to a specified account. Third-party applications should be carefully tested, however, because they may depend on inclusion of the Everyone group.

In addition to the Authenticated Users group, you also need to disable anonymous connections to the registry and restrict the ability of anonymous users to enumerate the domain user account list and share lists on servers via the following registry entries:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
LSARestrictAnonymous (REG_DWORD)

• A value of 0 disables this restriction and allows anonymous users (null sessions) to enumerate the user list and share list.

• A value of 1 enables this restriction; null sessions will not be allowed to enumerate the user list and share list.  

RestrictNullSessAccess (REG_DWORD)

• A value of 0 disables this restriction and allows anonymous users (null sessions) to connect to the registry.

• A value of 1 enables this restriction; null sessions will not be allowed to connect to the registry.  

KB article 143474, “Restricting information available to anonymous users” at https://support.microsoft.com/?kbid=143474 demonstrates how you can use the Authenticated Users group in conjunction with manual registry edits to completely restrict anonymous connections to the registry and enumerations of users and shares. KB article 153183, “How to Restrict Access to the Registry from a Remote Computer” at https://support.microsoft.com/?kbid=153183 gives additional information on restricting remote access to the registry for authenticated users.

Another important change that you must make, especially on domain controllers, is to properly secure the Directory Replicator Service (DRS). This service allows the contents of specified directories to be replicated to multiple servers and is important in ensuring that system policies and other critical files are propagated to all domain controllers. It can be extremely useful in maintaining load-balanced file services for critical applications.

Replication connections are configured in the Server Manager for Domains, by clicking the Replication button. For each replication partnership, there is an Exporter (the source) and an Importer (the destination). The details of each partnership must be separately configured on each side of the connection (similar to the way that trust relationships are created between domains).

By default, the DRS uses the Local System account, something you should change right away. Create a separate domain user account specifically for the DRS to use so that the same account is used on all your computers; do not use local accounts. After you have created the accounts, you can use the Service Manager to ensure that the DRS is running as this account and not the Local System account.

Many services are enabled by default and can be disabled to reduce the threat surface for your computers running Windows NT; still others you can configure to run as non-privileged accounts, rather than the Local System account. For more information about securing the DRS and disabling unnecessary services, including a thorough set of recommendations for each service based on the role of the computer, see Chapter 10, "Managing Server Security," of the Microsoft NT 4.0 Security, Audit, and Control Technical Reference, which is available for preview on Microsoft TechNet at https://microsoft.com/technet/prodtechnol/winntas/maintain/nt4sac/sacch10.mspx.

Other Hardening Measures

A number of other hardening measures may be appropriate for various environments.

Disabling Auto Generation of 8.3 Filenames

Windows NT supports 8.3 file name formats for backward compatibility with16-bit applications. The 8.3 file name convention is a naming format that allows file names up to eight characters long, which means that an attacker only needs eight characters to refer to a file that may be 20 characters long. For example, a file named Thisisalongfilename.doc, could be referenced by its 8.3 file name, Thisis~1.doc. If you avoid using 16-bit applications, you can turn this feature off. Disabling short name generation on an NTFS partition also increases directory enumeration performance.

Attackers could use short file names to access data files and applications with long file names that would normally be difficult to locate. An attacker who has gained access to the file system could access data or execute applications.

You can control this through the following registry entry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Control\FileSystem\NtfsDisable8dot3NameCreation

The 16 – bit applications in your organization will not be able to access files with names longer than the 8.3 format allows if those files are stored on computers where this change has been made. Applying this setting to an existing server that already has files with auto generated 8.3 file names does not remove them. To remove existing 8.3 file names, you will need to copy those files off the server, delete the files from the original location, and then copy the files back to their original locations.

Disabling Autorun

The Autorun feature begins reading from a drive on your computer as soon as media is inserted into it. As a result, the setup file of programs and the sound on media starts immediately. To prevent a possible malicious program from starting when a CD or DVD is inserted, Group Policy disables Autorun on all drives.

An attacker with physical access to the system could insert Autorun enabled media into the computer and automatically launch malicious code that will run in the context of the currently-logged-in user.

You can control this through the following registry entry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CDROM\Autorun

After you make this change, Autorun will no longer work when autorun-enabled discs are inserted into drives on the computer.

Removing OS/2 and POSIX Subsystems

OS/2 is a family of Microsoft protected-mode, virtual-memory, multitasking operating systems for personal computers based on the Intel 80286 and 80386 processors. The Portable Operating System Interface for UNIX (POSIX) is an Institute of Electrical and Electronic Engineers (IEEE) standard that defines a set of operating system services. The OS/2 subsystem is required if the server needs to significantly interact with OS/2 clients; the POSIX subsystem is required to run applications that use POSIX services.

These subsystems introduce a small degree of security risk relating to processes that can potentially persist across logons. That is, if a user starts a process and then logs off, a potential exists that the process will be accessed by the next user who logs on to the system. The process started by the first user may retain the user's system privileges.

In order to disable these subsystems, the binary files and following registry entries required for these subsystems can be deleted:

• The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OS/2 Subsystem for NT registry key and subkeys.

• The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\OS2LibPath registry key.

• The POSIX and OS/2 subkeys of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
  Control\Session Manager\Environment\Subsystems registry key.

• The \winnt\system32\os2 directory and subdirectories.  

Applications that rely on the OS/2 or POSIX subsystems will no longer operate.

Increasing Object Protection Levels

The Windows NT kernel may allow callers to change attributes of kernel objects under various conditions. In some circumstances, this may allow malicious callers to escalate their privileges.

You can control this through the following registry entry:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\EnhancedSecurityLevel

This change only allows kernel-mode code to change kernel object attributes for the current process.

There is no potential impact for user-mode applications.

Preventing Users from Adding Printer Drivers

Windows NT default permissions allow users to install additional printer drivers. In some circumstances, this may allow malicious or poorly written drivers to escalate privileges.

You can control this through the following registry entry:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
  Control\Print\Providers\LanMan Print Services\Servers\AddPrinterDrivers

This change only allows members of the Printer Operators and Administrator groups to add new printer drivers.

There is no potential impact for user-mode applications.

Confirming That Automatic Administrator Logon Is Disabled

Windows NT may be configured to allow the automatic logon of the administrator account when the computer is restarted. This exposes the console and creates a new registry key that contains the administrator password in plain-text format. KB article 97597, “How to Enable Automatic Logon in Windows NT 3.x and 4.0” at https://support.microsoft.com/?kbid=97597 discusses this setting in more detail.

You can control this through the following registry entries:

• HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\
  CurrentVersion\Winlogon\AutoAdminLogon

• HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\
  CurrentVersion\Winlogon\DefaultPassword

There is no potential impact for user-mode applications.

Disabling Notifications for the Novell Client

Windows NT is configured by default to notify the Novell networking client (FPNWCLNT.DLL) when passwords are changed; however, unless the client is installed, a copy of this dynamic-link library (DLL) is not installed. This allows an attacker to craft a replacement DLL and hijack all user password change events.

To disable this behavior, ensure that the value “FPNWCLNT” is not contained in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Control\LSA\Notification Packages registry entry.

Password synchronization between Windows and Netware is disabled in environments that use Netware.

Implementation

Implementation Prerequisites

For these implementation details to work correctly, you must have a basic Trey Research infrastructure implemented as introduced in Chapter 2, "Applying the Security Risk Management Discipline to the Trey Research Scenario."  

Implementation Overview

To implement this solution scenario, you will need to perform the following activities:

• Establish a baseline and patch the operating system

• Enable the Syskey

• Reduce the boot timeout

• Install the SCM

• Load the SCM snap-in

• Apply the Trey policy template

• Prevent the storage of LM password hashes

• Set the NTLM authentication level

• Convert the server volumes to NTFS

• Perform other hardening measures  

Establishing a Baseline for the Operating System

Whenever you build a new computer or reinstall the operating system on an existing system, you must install the correct set of security patches to ensure that the computer is adequately protected. Patch management is a complicated topic covered more fully in Chapter 6, “Patch Management”; however, the process of baselining new systems is a necessary part of securing computers running Windows NT. Every computer running Windows NT in your organization should have the following patch installed:

Service Pack 6a (SP6a) for Windows NT 4.0, which is the most recent service pack for Windows NT 4.0. It contains a complete and regression-tested set of fixes that are designed to be installed as a unit. Since the release of Windows NT 4.0 SP6a, U.S. law on exporting cryptographic software has changed. You might be able to increase the encryption strength available to your computers running Windows NT 4.0 by upgrading to the high encryption version of SP6a. Installing the high encryption version of SP6a on a standard encryption version will automatically upgrade the operating system. Windows NT 4.0 Service Pack 6a is available at https://microsoft.com/ntserver/nts/downloads/recommended/sp6/128bitx86/.

To check the encryption version of Windows NT 4.0

1. As an Administrator, log on to the target computer running Windows NT 4.0.

2. Use Windows Explorer to open the \winnt\system32 folder.

3. Locate the schannel.dll file, select it, and then click File and Properties.

4. Click the Versions tab.

5. Review the contents of the Description field.

   If it says “Export Version”, you have the standard encryption version; if it says “U.S. domestic version,” you have the high-encryption version.

   • The Post-Windows NT 4.0 Service Pack 6a Security Rollup Package (SRP) incorporates several patches that were released after the original SP6a release and is a prerequisite for follow-up patches from Windows Update. It is documented in KB article 299444, "Post-Windows NT 4.0 Service Pack 6a Security Rollup Package (SRP)” at https://support.microsoft.com/?kbid=299444; the Security Rollup Package itself can be downloaded from https://download.microsoft.com/download/winntsp/Patch/q299444/NT4/EN-US/Q299444i.exe.

   • Microsoft has not released an integrated SRP or service pack for Windows NT 4.0 since the release of the SRP, but individual components such as portions of the operating system, Internet Explorer, and add-on utilities such as the Routing and Remote Access Service (RRAS) and Internet Information Services (IIS) have been updated. You can obtain a current list of patches from Microsoft TechNet, or you can manually review the list of patches available through Windows Update.

   • Internet Explorer 6.0 Service Pack 1 (SP1) is the current version, available at https://microsoft.com/windows/ie/. It incorporates hundreds of security fixes and improvements. Depending on your environment, you may choose to download Internet Explorer directly from the Microsoft Web site, order it on a CD, or install it on multiple computers by using the Internet Explorer Administration Kit, available at https://microsoft.com/windows/ieak/.

Because of the length of time since the release of Windows NT, Trey’s IT staff had already applied SP6a and the SRP to all of the computers running Windows NT. However, it lacked a consistent policy for ensuring that other necessary patches released by Microsoft had been applied, which led directly to the company's adoption of the patch management methodology described in Chapter 6, "Patch Management."

Enabling Syskey

You must enable Syskey to allow encrypted protection of the computer SAM. Trey chose to apply this protection to all of the company's computers, servers, and workstations alike running Windows NT.

To enable Syskey

1. As an Administrator, log on to the target computer running Windows NT 4.0.

2. Start the Rdisk.exe utility from a command prompt or by using the Run command.

3. When Rdisk starts, click the Update Repair Info button, and then when prompted, click Yes.

4. After the repair information update completes, insert a blank floppy disk into the floppy disk drive and then, in the Repair Disk Utility dialog box, click Yes.

5. Click OK to confirm that you want the repair disk to be created.

6. When the disk creation is finished, click OK to acknowledge the security warning, and then click Exit to close the Rdisk utility.

7. Start the Syskey.exe utility.

8. When the Securing the Windows NT Account Database window appears, click the Encryption Enabled button, and then click OK.

9. Click OK in the confirmation dialog box.

10. From the Account Database Key dialog box, click Store Startup Key Locally (see Figure 4.1), and then click OK.

11. When the Success dialog box appears, click OK.

12. Restart the computer.

Note   On domain controllers, the recovery data gathered by Rdisk will probably be too large for a single floppy disk, but it is also saved to the %systemroot%\repair directory. Having an up-to-date ERD allows quick recovery in case of a problem with Syskey. The Rdisk /s command is more fully described in KB article 122857, “RDISK /S and RDISK /S- Options in Windows NT” at https://support.microsoft.com/?kbid=122857.

Note   For more information on how Syskey protects SAM data against attack, see KB article 143475, "Windows NT System Key Permits Strong Encryption of the SAM" at https://support.microsoft.com/?kbid=143475.

Reducing the Boot Timeout

This procedure explains how to modify the boot timeout value.

To reduce the boot timeout

1. As an Administrator, open a command prompt.

2. Change to the root directory of the system volume (usually C:\).

3. Reset the read-only, hidden, and system attributes on the Boot.ini file by using the attrib command:

   attrib –s –h –r boot.ini

4. Open the Boot.ini file with a text editor such as Notepad.

5. Find the line that says timeout=30 and change the timeout value to 0.

6. Save the file, and then close the text editor.

7. Restore the read-only, hidden, and system attributes on the Boot.ini file by using the attrib command:

   attrib +s +h +r boot.ini

Installing the SCM

This procedure explains how to install the SCM tools. The SCM can run on any computer running Windows NT 4.0 SP4 or later, on both Server and Workstation editions. For ease of use, the Trey IT staff installed the SCM on their personal workstations, where it can be run against any of the computers running Windows NT 4.0 in their domain.

To install the SCM

1. As an Administrator, open Windows Explorer.

2. Create the directory c:\temp if it does not already exist.

3. Download the SCM installer from https://support.microsoft.com/?kbid=245216 and save the downloaded file to C:\Temp.

4. Open C:\Temp and double-click the Scesp4i.exe application.

5. When prompted by the installation utility, specify a temporary file path of C:\Temp\scminstall in which to uncompress the support files, and then click OK.

6. Use Explorer to open C:\Temp\scminstall.

7. Double-click the Mssce utility to install the SCE and the Microsoft Management Console (MMC) tool required for the GUI version of the SCE. The installer will automatically place the SCM components in the correct location on the computer where you are installing.  

Loading the SCM Snap-in

After the SCM has been installed on a workstation or server, you can execute it. This procedure explains how to load the SCM snap-in into the MMC.

To load the SCM snap-in

1. As an Administrator, log on to a computer where you have previously installed the SCM.

2. Launch the MMC.

3. Select Console, and then select Add/Remove Snap-In.

4. Click Add.

5. Select Security Configuration Manager.

6. Click OK, and then click OK again.  

Applying the Trey Policy Template

This procedure explains how to use the SCE GUI and command-line interface (CLI) tools to apply the Trey policy template. Trey decided to use the Comp* templates because they provide the best balance between backward compatibility and security.

To customize the policy template from the SCE GUI

1. Log on to a test Windows NT 4.0 workstation.

2. Make backup copies of %systemroot%\security\templates\compws4.inf and %systemroot%\security\templates\compdc4.inf.

3. Use Notepad to open %systemroot%\security\templates\compws4.inf.

4. Search for the line that contains “MACHINE\System\CurrentControlSet\
   Services\Rdr\Parameters\EnableSecuritySignature”.

5. Edit that line so that the value for EnableSecuritySignature is 1.

6. Save the file, and then close Notepad.

7. Use Notepad to open %systemroot%\security\templates\compdc4.inf.

8. Repeat steps 4-6 with the new file.  

To apply the policy template from the SCE GUI

1. As an Administrator, launch the Security Configuration Manager.

2. Select the Security Configuration Manager node.

3. Select the Configurations node.

4. Select the default configuration file directory (%systemroot%\security\templates) to show the configuration templates.

5. Select the appropriate configuration file (compws4.inf or compdc4.inf).

6. Familiarize yourself with the various objects and settings in the policy template.

7. Select the Security Configuration Manager node.

8. Right-click the Database node, and then select Import Configuration.

9. Choose the corresponding policy template, and then click OK.

10. Right-click the Database node, and then select Configure System Now.

11. Click OK to accept the default log file path.

12. Wait for the policy to apply, and then review the log file results.

13. Close the log file.

14. Close the MMC.  

To apply the policy template from the command line

1. Log on to the target computer.

2. Open a command prompt.

3. Run the following command:

   secedit /configure /cfg c:\winnt\security\templates\treysec.inf /overwrite

4. Examine the results.

5. Close the command prompt.

Preventing the Storage of LM Password Hashes

This procedure explains how to configure your domain controllers to prevent storage of the LM password hashes using either policies or direct registry editing.

To prevent the storage of LM hashes by using Group Policies or local policies on Windows 2000 SP2 or later , Windows XP , or Windows Server 2003

1. Open the Group Policy editor.

2. Expand Computer Configuration , Windows Settings , Security Settings, and Local Policies, and then click Security Options.

3. In the list of available policies, double-click Network security: Do not store LAN Manager hash value on next password change.

4. Click Enabled, and then click OK.

5. Restart your computer, and then change your password.

Setting the NTLM Authentication Level

This procedure explains how to configure the level of NTLM authentication used on your domain controllers.

To set the NTLM level by using Group Policies on Windows 2000 , Windows XP , or Windows Server 2003

1. Log on to a domain controller as an Administrator.

2. Launch Active Directory Users and Computers.

3. Open the Group Policy editor.

4. Right-click the domain to which you want to apply the NTLM authentication level setting, and then select Properties.

5. In the Properties dialog box, click the Group Policy tab.

6. Click the New button to create a new Group Policy object (GPO).

7. Type NTLM Authentication Level and then press ENTER.

8. Click the Edit button.

9. Expand Computer Configuration, Windows Settings, Security Settings, and Local Policies, and then click Security Options.

10. In the list of available policies, double-click Network Security: LAN Manager Authentication Level.

11. Select Send NTLMv2 response only\refuse LM, which provides the best balance between security and compatibility for mixed networks that include computers running Windows 98 and Windows NT.

12. Click OK.

13. Close the Group Policy Editor.

14. In the domain Properties dialog box, right-click the NTLM Authentication Level GPO ,and then select the No Override command.

15. Click Close.  

To set the NTLM level through registry entries on Windows NT 4.0 SP3 or later

1. Start Registry Editor (regedt32.exe).

2. Locate and then click the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

3. On the Edit menu, click Add Value.

4. For Data Type, select DWORD Value.

5. For Value Name, type LMCompatibilityLevel and then click OK.

6. For Data, type 3 (or your desired level) as a Decimal value.

7. Quit Registry Editor.

8. Restart the computer.  

To set the NTLM level through registry entries on Windows 98

1. Start Registry Editor (regedit.exe).

2. Locate and then select the following subkey in the registry:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control.

3. On the Edit menu, point to New, and then click Key.

4. Type Lsa and then press ENTER.  

5. On the Edit menu, point to New, and then click DWORD Value.

6. Type LMCompatibilityLevel and then press ENTER.

7. On the Edit menu, click Add Value, and then add the following registry value:

   • Value Name: LMCompatibility

   • Data Type: REG_DWORD

   • Value: 3  

8. Quit Registry Editor.

9. Restart your computer.

Converting a Volume to NTFS

This procedure explains how to convert a FAT volume to NTFS.

To convert a FAT volume to NTFS

1. As an Administrator, open a command prompt.

2. Use the convert command to specify which drive is to be converted:

   convert d: /fs:ntfs

3. If prompted, reboot to allow the conversion utility to gain exclusive access to the selected drive.

Rebooting will be necessary if you convert the system partition, the volume which contains the current working directory for the command interpreter, or a volume on which applications have files open.

Note   KB article 214579, “How to Use Convert.exe to Convert a Partition to the NTFS File System” at https://support.microsoft.com/?kbid=214579 describes the convert command and its operation in more detail.

Performing Other Hardening Measures

These procedures explain the steps necessary to implement additional hardening measures.

Disabling Auto Generation of 8.3 Filenames

This procedure disables the automatic generation of 8.3 format filenames for 16-bit applications.

To disable 8.3 filename generation

1. Start Registry Editor (regedt32.exe).

2. Locate and then click the following key:
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem

3. If the NtfsDisable8dot3NameCreation value does not exist, on the Edit menu, click Add Value; type NtfsDisable8dot3NameCreation and ensure that it is a REG_DWORD type. Then press ENTER

4. Select the NtfsDisable8dot3NameCreation value.

5. On the Edit menu, click Modify.

6. Type 1 (or your desired level), and then click OK.

7. Quit Registry Editor.

Note   Trey has a number of 16-bit applications that must continue to run normally. However, these applications run on a subset of computers in the domain. All file and print servers have had this change applied; it has been selectively applied to member servers and workstations that are not running 16-bit applications.

Disabling Autorun

This procedure disables the autorun feature for CD-ROM drives.

To disable autorun

1. Start Registry Editor (regedt32.exe).

2. Locate and then click the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CDROM

3. On the Edit menu, click Add Value.

4. Type Autorun and ensure that it is a REG_DWORD type. Then press ENTER.

5. On the Edit menu, click Modify.

6. Type 0 (or your desired level), and then click OK.

7. Quit Registry Editor.

Removing OS/2 and POSIX Subsystems

This procedure disables the OS/2 and POSIX compatibility subsystems.

To disable OS/2 and POSIX

1. Start Registry Editor (regedt32.exe).

2. Locate and delete the following key: HKEY_LOCAL_MACHINE\SYSTEM\
   CurrentControlSet\Control\Session Manager\Environment\OS2LibPath

3. If the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
   Control\Session Manager\Subsystems key exists, locate and delete its OS/2 and POSIX subkeys.

4. If the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
   Control\Session Manager\Environment\Subsystems key exists, locate and delete its POSIX and OS/2 subkeys, if present.

5. Locate and delete the following key: HKEY_LOCAL_MACHINE\
   SOFTWARE\Microsoft\OS/2 Subsystem for NT

6. Quit Registry Editor.

7. Open Windows Explorer.

8. Delete the \winnt\system32\os2 directory and all its subdirectories.

9. Restart the computer.

Increasing Object Protection Levels

This procedure increases the protection levels for kernel objects.

To increase object protection levels

1. Start Registry Editor (regedt32.exe).

2. Locate and then click the following key: HKEY_LOCAL_MACHINE\SYSTEM\
   CurrentControlSet\Control\Session Manager

3. On the Edit menu, click Add Value.

4. Type EnhancedSecurityLevel and ensure that it is a REG_DWORD type. Then press ENTER.

5. On the Edit menu, click Modify.

6. Type 1 (or your desired level), and then click OK.

7. Quit Registry Editor.

Preventing Users from Adding Printer Drivers

This procedure disables the ability of normal users to add printer drivers.

To disable addition of printer drivers by normal users

1. Start Registry Editor (regedt32.exe).

2. Locate and then click the following key:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
   Control\Print\Providers\LanMan Print Services\Servers

3. On the Edit menu, click Add Value.

4. Type AddPrinterDrivers and ensure that it is a REG_DWORD type. Then press ENTER.

5. On the Edit menu, click Modify.

6. Type 1 (or your desired level), and then click OK.

7. Quit Registry Editor.

Confirming That Automatic Administrator Logon Is Disabled

This procedure disables the automatic logon of the Administrator account.

To disable automatic Administrator logon (which is not on by default)

1. Start Registry Editor (regedt32.exe).

2. Locate and then click the following key:
   HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\
   CurrentVersion\Winlogon

3. Locate and then click the following value if it exists: AutoAdminLogon.

4. On the Edit menu, click Modify.

5. Type 0 (or your desired level), and then click OK.

6. Delete the DefaultPassword value if it exists.

7. Quit Registry Editor.

Disabling Notifications for the Novell Client

This procedure disables the automatic notification of password changes to the Novell networking client.

To disable the default password change notifications to the Novell client

1. Start Registry Editor (regedt32.exe).

2. Locate and then click the following key:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

3. Locate and then click the following value: Notification Packages.

4. On the Edit menu, click Modify.

5. Ensure that the value FPNWCLNT is not listed, and then click OK.

6. Quit Registry Editor.

Testing the Solution

After the Trey scenario implementation is complete, you are ready to validate your implementation to ensure that it meets the requirements.

Validation

You can use the information in the following table to test the Trey scenario and validate your implementation of this guidance.

Table 4.2: Validation Tests

Description	Test steps	Expected result
Validate installation of Internet Explorer 6 SP1	Start Internet Explorer. On the Help menu, click About Internet Explorer.	Version information should show 6.0.2800.xxxx.
Validate installation of Windows NT 4.0 (SP6a)	Run the Windows NT Diagnostics applet in the Administrative Tools group and then select the Version tab.	Version information should show SP6a.
Validate the boot sequence	In mode1 (store Startup Key locally for most of Trey's servers and all of its workstations). At boot time, the key is decrypted and loaded, allowing the computer to be restarted without administrator intervention. In mode2 (the Password Startup button and associated text fields - for high-value servers). At boot time, the administrator must type the pass phrase into the console to complete the boot.	Client can successfully log on.
Validate that DSClient successfully installed	Click Start, and then Search and For People.	Ability to search Active Directory indicates successful installation of DSClient.
Validate system policies    Attempt to access resources restricted by system policies.	Double check the location of the system policies, which is usually in the C:\Winnt\system32\repl\import\scripts folder.	You cannot access forbidden resources. System policies should be available at given location.
Validate NTLMv2 authentication	Set the domain controller to require NTLMv2 authentication.	Client can successfully log on.
Validate the security configuration manager	Build and apply the security templates automatically to one or more computers in a domain. Check the set of templates in the %winnt%\security\templates folder.	You are able to secure the member servers and workstations. Templates should be available at given location.
Check the long file name creation	Create a new file with a name longer than the 8.3 format.	You are not able to access the file with 8.3 format.
Validate the autorun functionality	Insert the autorun-enabled discs into drives on the computer.	Autorun will no longer work when autorun-enabled discs are inserted into drives on the computer.
Validate that the OS/2 or POSIX subsystems will no longer operate	A user starts a process and then logs off, a potential exists that the process will be accessed by the next user who logs on to the system.	Applications that rely on the OS/2 or POSIX subsystems will no longer operate.
Validate the object protection levels	Malicious users try to change the attributes of kernel objects under various conditions.	System should not allow malicious callers to escalate their privileges.
Prevent users from adding printer drivers	Malicious users try to escalate privileges through adding some printer drivers.	Members of the Printer Operators and Administrator groups are able to add new printer drivers.
Validate that the automatic administrator logon is disabled	Try to automatically log on as administrator when the computer is restarted.	Automatic Administrator Logon should be disabled.
Validate the boot timeout	Restart and check the boot timeout.	The boot timeout should have changed from 30 to 0.
Validate the SCM installation	Client Start, Run, type mmc and press ENTER.	SCM Microsoft management console should be available.

Summary

Even though Windows NT does not have the full complement of modern security features, there are still many features and techniques to mitigate threats and security risks for your Windows NT systems. From initial operating system and patch baseline installation, through boot hardening, deployment of the Directory Services Client add-in, to the effective use of system policies to control security-critical aspects such as NTLM authentication and password generation, to file system and service hardening, and finally to a number of other hardening measures, there is still a lot that you can do at the operating system level to keep Windows NT as secure as it can be.

More Information

• Windows NT 4.0 Service Pack 6a is available at https://support.microsoft.com/kb/241211.

• The Windows NT Server Service Pack 6a FAQ includes security-specific information, and is available at https://microsoft.com/technet/archive/winntas/downloads/default.mspx?mfr=true.

• The Post-Windows NT 4.0 Service Pack 6a Security Rollup Package is available at https://support.microsoft.com/kb/q299444/.

• The Internet Explorer Administration Kit is available at https://microsoft.com/windows/ieak/.

• Active Directory Client Extensions for Windows NT 4.0 are available at https://www.microsoft.com/technet/archive/ntwrkstn/downloads/utils/dsclient.mspx.

• The “Guide to Microsoft Windows NT 4.0 Profiles and Policies” white paper is available for downloading at https://www.microsoft.com/technet/archive/winntas/maintain/prof\_pol.mspx.

• Information about the System Policy Editor is available on the Using the System Policy Editor page on MSDN at https://msdn.microsoft.com/library/en-us/policy/policy/using\_the\_system\_policy\_editor.asp.

• The Security Configuration Manager is available from the Microsoft FTP server at ftp://ftp.microsoft.com/bussys/winnt/winnt-public/tools/scm/.

• A complete guide to the SCM for Windows NT 4.0 is available for download at https://www.microsoft.com/technet/archive/winntas/maintain/security/scmnt4.mspx.

• The National Security Agency's "Guide to Securing Microsoft Windows NT Networks" is available at https://www.nsa.gov/snac/os/win2k/w2k_cert_services_checklist.pdf.  If you are directed to the NSA Home page you can locate the document by following these steps:

1. Click View HTML Site.

2. Click Information Assurance.

3. In the Search box, type Guide to Securing Microsoft Windows NT Networks, and then click Go.

4. You may need to click More Results to see the document listed.

Download

Get the Microsoft Windows NT 4.0 and Windows 98 Threat Mitigation Guide

Solution Accelerator Notifications

Sign up to stay informed

Feedback

Send us your comments or suggestions