Windows NT 4.0 Server Baseline Security Checklist

This checklist outlines the steps you should take to improve the security of server's running Windows NT either on their own or as part of a Windows NT domain. These steps apply to Windows NT 4 Server, Standard Edition, and Enterprise Edition.

Important: The purpose of this checklist is to give instructions for configuring a baseline level of security on server's running Windows NT 4.0. Additional advanced settings are provided in the complete Windows NT 4.0 Server Configuration Checklist on the Microsoft TechNet Security Web site.

This checklist contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe.

On This Page

Windows NT 4.0 Server Configuration
Windows NT 4.0 Server Configuration Checklist: Further Details

Windows NT 4.0 Server Configuration

Windows NT 4.0 Server Configuration Checklist: Further Details

Verify that all disk partitions are formatted with NTFS

NTFS partitions offer access controls and protections that aren't available with the FAT, FAT32, or FAT32x file systems. Make sure that all partitions on your server are formatted using NTFS. If necessary, use the convert utility to non-destructively convert your FAT partitions to NTFS.

Warning: If you use the convert utility, it will set the ACLs for the converted drive to Everyone: Full Control. Use the fixacls.exe utility from the Windows NT Server Resource Kit to reset them to more reasonable values.

Verify that the Administrator account has a strong password

Windows NT allows passwords of up to 14 characters. In general, longer passwords are stronger than shorter ones, and passwords with several character types (letters, numbers, punctuation marks, and nonprinting ASCII characters, generated by using the ALT key and three-digit key codes on the numeric keypad) are stronger than alphabetic- or alphanumeric-only passwords. For maximum protection, make sure the Administrator account password is at least nine characters long and that it includes at least one punctuation mark or nonprinting ASCII character in the first seven characters.

Disable unnecessary services

After installing Windows NT Server, you should disable any network services not required for the server role. In particular, you should consider whether your server needs any IIS components and whether it should be running the Server service for file and print sharing.

You should also avoid installing applications on the server unless they are absolutely necessary to the server's function. For example, don't install email clients, office productivity tools, or utilities that are not strictly required for the server to do its job.

Disable or delete unnecessary accounts

You should review the list of active accounts (for both users and applications) on the system in User Manager, disable any nonactive accounts, and delete accounts that are no longer required.

Make sure the Guest account is disabled

By default, the Guest account is disabled on systems running Windows NT Server. If the Guest account is enabled, disable it.

Protect files and directories

A number of file system permissions need to be changed to provide adequate security for server's. These permissions require you to use NTFS for your system volume, but you should be doing that anyway. The definitive reference for these changes is the white paper NSA Windows NT System Security Guidelines, produced by Trusted System Services. Their recommendations call for setting file and directory ACLs as shown below. In the table, "Installers" refers to any accounts that have privileges to install application or system software.

Protect the registry from anonymous access

The default permissions do not restrict remote access to the registry. Only administrators should have remote access to the registry, because the Windows NT registry editing tools support remote access by default. To restrict network access to the registry:

1. Add the following key to the registry:

   Hive	HKEY_LOCAL_MACHINE\SYSTEM
   Key	\CurrentControlSet\Control\SecurePipeServer's
   Value Name	\winreg

2. Select winreg, click the Security menu, and then click Permissions.

3. Set the Administrators permission to Full Control, make sure no other users or groups are listed, and then click OK.

The security permissions (ACLs) set on this key define which users or groups can connect to the system for remote registry access. In addition, the AllowedPaths subkey contains a list of keys to which members of the Everyone group have access, notwithstanding the ACLs on the winreg key. This allows specific system functions, such as checking printer status, to work correctly regardless of how access is restricted via the winreg registry key. The default security on the AllowedPaths registry key grants only Administrators the ability to manage these paths. The AllowedPaths key, and its proper use, is documented in Microsoft Knowledge Base article 155363.

Apply appropriate registry ACLs

A number of registry keys need changes to their default ACLs for maximum security. The definitive reference for these changes is the white paper NSA Windows NT System Security Guidelines, produced by Trusted System Services. Their recommendations call for removing the Everyone ACE from the keys listed in the table below (where it exists), and then changing the ACL as noted in the table. In the table, "Installers" refers to any accounts that have privileges to install application or system software.

Warning: Unless the table says "Entire tree", change permissions only on the indicated key, not on its subkeys.

Restrict access to public Local Security Authority (LSA) information

You need to be able to identify all users on your system, and therefore you should restrict anonymous users so that the amount of public information they can obtain about the LSA component of the Windows NT Security Subsystem is reduced. The LSA handles aspects of security administration on the local computer, including access and permissions. To implement this restriction, create and set the following registry entry:

Enable SYSKEY protection

The SAM database stores password hashes for domain and local computer accounts. An attacker who gains access to the SAM database files (from the server itself, the server's emergency repair disk, or a backup tape) can use a password-cracking tool to attack these hashes. The SYSKEY tool allows you to encrypt the SAM database to make it more difficult for an unprivileged attacker to use password-cracking tools against your stored password hashes. Microsoft Knowledge Base article 143475 details how to install and use SYSKEY.

Warning: Before you install SYSKEY, make sure to update your server's emergency repair disk. After installing SYSKEY, make a second ERD using a new, separate floppy. Do not attempt to use the pre-SYSKEY ERD to restore your system after SYSKEY is installed.

Set stronger password policies

Use the Account Policy dialog in the User Manager or User Manager for Domains application (choose the Policies | Account command) to strengthen the system policies for password acceptance. Microsoft suggests that you make the following changes:

• Set the minimum password length to at least eight characters.

• Set a minimum password age appropriate to your network (typically between 1 and 7 days).

• Set a maximum password age appropriate to your network (typically no more than 42 days).

• Set a password history maintenance (using the "Remember passwords" option) of at least 6.

Windows NT Service Pack 3 and later contain a password filtering tool, passfilt.dll, that allows you to enforce strong password rules for password changes. The tool allows only passwords that meet all of the following criteria:

• Must be at least six characters long

• May not contain user account name or any portion of the users full name

• Must contain characters from three of the four character groups (uppercase, lowercase, numeric, and nonalphabetic punctuation characters)

Warning: This change must be performed on all domain controllers in a domain. If you fail to make the change to BDCs, when a BDC is promoted to the PDC role strong password checking will be disabled. You should also make the change on member servers so that local computer accounts are adequately protected.

To install passfilt.dll, make the following Registry change (see Microsoft Knowledge Base article 151082 for more details about writing your own filters).

Set account lockout policy

Windows NT includes an account lockout feature that will disable an account after an administrator-specified number of logon failures. To turn this feature on, use the Account Policy dialog in User Manager for Domains, and then select the Account lockout option. For maximum security, enable lockout after three to five failed attempts, reset the count after not less than 30 minutes, and set the lockout duration to "Forever (until admin unlocks)."

The Windows NT Server Resource Kit includes a tool you can use to adjust some account properties that aren't accessible through the normal management tools. This tool, passprop.exe, allows you to lock out the administrator account. The /adminlockout switch allows the administrator account to be locked out.

Configure the Administrator account

Because the Administrator account is built in to every copy of Windows NT, it presents a well-known objective for attackers. To make it more difficult to attack the Administrator account, do the following both for the domain Administrator account and the local Administrator account on each server:

• Rename the account to a nonobvious name (e.g., not "admin," "root," etc.).

• Establish a decoy account named "Administrator" with no privileges. Scan the event log regularly looking for evidence of attempts to use this account.

• Enable account lockout on the real Administrator accounts by using the passprop utility.

• Disable the local computers Administrator account.

Remove all unnecessary file shares

All unnecessary file shares on the system should be removed to prevent possible information disclosure and to prevent malicious users from leveraging the shares as an entry to the local system.

Set appropriate ACLs on all necessary file shares

By default, all users have Full Control permissions on newly created file shares. All shares that are required on the system should have the ACL restricted such that users have the appropriate share-level access (e.g., Everyone = Read).

NOTE: The NTFS file system must be used to set ACLs on individual files in addition to share-level permissions.

Install anti-virus software and updates

It is imperative to install antivirus software and keep up-to-date on the latest virus signatures on all Internet and intranet systems.

Install the latest Service Pack

Each Service Pack for Windows NT includes all security fixes from previous Service Packs. Microsoft recommends that you keep up-to-date on Service Pack releases and install the correct Service Pack for your server's as soon as your operational circumstances allow. The current Service Pack, 6a, is available from the Microsoft Download Center:

• Intel version:https://www.microsoft.com/ntserver/nts/downloads/recommended/SP6/x86Lang.asp

• Alpha version:https://www.microsoft.com/ntserver/nts/downloads/recommended/SP6/alphaLang.asp

Service Packs are also available through Microsoft Product Support. Information about contacting Microsoft Product Support is available at https://support.microsoft.com/support/contact/default.asp.

Install the appropriate post-Service Pack security hotfixes

Start by installing Windows 29944 Post-Windows NT 4.0 Service Pack 6a Security Rollup (link is https://www.microsoft.com/NTServer/sp6asrp.asp), and then use one of the two following tools to determine the remaining hotfixes that should be applied:

• Although it does not run natively on NT 4.0, consider running Microsofts Baseline Security Analyzer (MBSA) (https://www.microsoft.com/technet/security/tools/mbsahome.mspx) from a Windows 2000 or XP machine to analyze multiple networked NT 4.0 machines at once. Besides revealing missing patches and updates, the MSBA will look for common vulnerabilities and recommend solutions.

Microsoft issues security bulletins through its Security Notification Service. When these bulletins recommend installation of a security hotfix, you should immediately download and install the hotfix on your member server's.

If your company is interested in C2 compliance, you should install the post-Service Pack 6a "C2 Update" hotfix, which makes a number of changes required to ensure complete C2 compliance. The C2 update is available from the Microsoft Download Center:

• Intel version: https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=5FD6D447-AEA5-4EF8-82DF-B2CB140C7BB1

• Alpha version: https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4CCF83EC-EB41-4C5F-B68B-9A83CC3BB274.

The update also can be ordered on various media through Microsoft Product Support Services.

Update the system Emergency Repair Disk

When you are finished with all critical updates and hotfixes, you should update the system's Emergency Repair Disk (ERD) to reflect these changes. For instructions, see "Update Repair Info" in Repair Disk Utility Help. (Run rdisk.exe, and then click Help.)

THE INFORMATION PROVIDED IN THIS CHECKLIST IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, SO THE FOREGOING LIMITATION MAY NOT APPLY.