Windows NT 4.0 Workstation Configuration Checklist
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. |
Updated : August 14, 2000
On This Page
Windows NT 4.0 Workstation Configuration Checklist
Windows NT 4.0 Workstation Configuration Checklist: Further Details
Background and Planning
Initial Configuration & Installation
Windows NT 4.0 Configuration
Windows NT Security Configuration
Windows NT Account & Policy Configuration
Application Configuration
Ongoing Maintenance Tasks
Windows NT 4.0 Workstation Configuration Checklist
This checklist outlines the steps you should take to secure computers running Windows NT Workstation, either on their own or as part of a Windows NT or Windows 2000 domain.
IMPORTANT: 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.
Step 1: General Information
Server Name |
|
---|---|
Asset # |
|
Setup Date |
|
Manufacturer |
|
Location |
|
Set up by |
|
Step 2: Background and Planning
|
Steps |
---|---|
Read any applicable security policies for your organization |
|
Subscribe to Microsoft's Security Notification Service |
|
Review your user education and training plans |
|
Determine what services the workstation needs to offer |
Step 3: Initial Configuration & Installation
|
Steps |
---|---|
Unpack and set up hardware |
|
Enable hardware boot protection |
|
Install Windows NT |
Step 4: Windows NT 4.0 Configuration
|
Steps |
---|---|
Verify that all disk partitions are formatted with NTFS |
|
Verify that the Administrator account has a strong password |
|
Unbind unnecessary protocols |
|
Remove additional OS installations |
|
Install the latest Service Pack |
|
Install appropriate post-SP hotfixes |
|
Enable SYSKEY protection |
|
Remove the OS/2 and POSIX subsystems |
|
Disable unnecessary services |
Step 5: Windows NT Security Configuration
|
Steps |
---|---|
Make sure the Guest account is disabled |
|
Restrict the use of LanManager authentication |
|
Secure base objects |
|
Secure additional base named objects |
|
Protect files and directories |
|
Protect the Registry |
|
Apply appropriate Registry ACLs |
|
Restrict access to public Local Security Authority (LSA) information |
|
Restrict untrusted users' ability to plant Trojan horse programs |
|
Disable caching of logon information |
|
Set the paging file to be cleared at system shutdown |
|
Restrict floppy drive and CD-ROM drive access to the interactive user only |
|
Modify user rights membership |
|
Restrict network access |
|
Set security log behavior |
|
Change the Scheduler service's security context |
|
Hide the name of the last logged-in user |
|
Update the system Emergency Repair Disk |
Step 6: Windows NT Account & Policy Configuration
|
Steps |
---|---|
Disable blank passwords |
|
Set stronger password policies |
|
Set account lockout policy |
|
Use the passprop utility |
|
Use passfilt.dll |
|
Configure the Administrator account |
Step 7: Application Configuration
|
Steps |
---|---|
Review installed applications |
|
Apply appropriate security patches |
|
Implement appropriate security policies |
|
Consider use of an application deployment & monitoring tool |
|
Deploy desktop anti-virus software |
Step 8: Ongoing Maintenance Tasks
|
Steps |
---|---|
Review user accounts |
|
Review group memberships |
|
Review installed services |
|
Review security event logs |
|
Consider using password-cracking tools |
Windows NT 4.0 Workstation Configuration Checklist: Further Details
Background and Planning
Read any applicable security policies for your organization
Having a security policy is paramount. You need ready answers to questions like:
How do we react to a break-in?
Is this workstation backed up? If so, where are the backups stored? If not, why not?
Who is allowed to access this particular workstation?
What level of physical security is appropriate for this workstation?
Good sources of policy information may be found at at SANS Institute, Baseline Software, Inc. and in the Windows NT 4.0 Security, Audit, and Control GuideSANS Institute, Baseline Software, Inc. and in the Windows NT 4.0 Security, Audit, and Control Guide.
Subscribe to the Microsoft Security Notification Service
WARNING |
You MUST keep on top of new security issues as they arise. |
You can stay abreast of Microsoft-related security issues and fixes here. You will receive notice of security issues by email. You should also consider placing a 'favorites shortcut' to the Microsoft Security Advisor Program. To do so, follow these steps:
Open Internet Explorer on your desktop
Navigate to https://www.microsoft.com/security/
Select Favorites on the menu, then choose Add to Favorites
Check 'Make Available Offline'
Select Customize | Next | Yes (links to other pages) | '2' links deep
Next | Select 'I would like to create a new schedule' | use the defaults | finish
OK
Select Favorites on the menu, then choose Organize Favorites
Select Properties | Download | uncheck 'Follow links outside of this page's Web site'
OK
Close
If you now click on the Favorites icon in the toolbar, you can drag the 'Microsoft Security Advisory Program' link to your desktop. A small red mark will appear on the icon when there is new security news.
Review your user education and training plans
Part of your security depends on your users. You'll have to train them to know, understand, and practice your organization's security policies for things like password length, password aging, and what constitutes a good password. Users typically accept security measures better when they understand the reasons behind them instead of feeling like they're being jammed up with arbitrary rules. A moderate security policy that people will actually follow is better than a draconian policy that people ignore.
Determine what services the workstation needs to offer
Part of the process of deploying a workstation or server is deciding what services, if any, need to be shared on the network. For example, a CAD workstation probably doesn't need to enable the Peer Web Services component. Before adding a new computer, make a list of specific service functions that it will offer.
Initial Configuration & Installation
Unpack and set up hardware
Follow the hardware manufacturer's manuals accompanying your computer system to unpack and connect your computer system components. Physically secure the hardware to the extent necessary, including using optical fiber if cabling must pass through unsecured areas, or isolating the network in a secure building if very high security is needed. Be sure to consider fire protection, electrical service, and physical access to the machine as part of your physical security planning.
NOTE |
An intruder who can physically open the lid of a workstation cabinet can adjust hardware switches to disable the power-on password. Access to the internal components of the computer could also permit temporary installation of a drive from which a less secure OS, or a version of Windows NT that lacks your security settings, can be used to start the computer. Options for preventing unauthorized access to internal components include locking the case (if the model permits it), using hardware that transmits an alarm signal when the case is opened, or increasing physical security on the room where the computer located. |
Enable hardware boot protection
Choose appropriate boot protection measures on your computers. Depending on your needs and your hardware configuration, you can do any of the following:
Consider removing the system's floppy and CD-ROM drives to prevent booting from them. However, this will definitely have an adverse impact on recovery time.
If your computer supports it, set BIOS options to restrict boot sources, then use BIOS passwords to restrict changes to boot settings
Use a physical lock on the floppy drive
Install Windows NT
For additional information on installing Windows NT, see the instructions provided with your original installation CD. Keep in mind the following considerations:
- If you use cloning tools to deploy Windows NT to multiple workstations (a practice not recommended by Microsoft), do not use "after-GUI replication," where the copy is made after the graphical user interface (GUI) appears. Microsoft supports disk duplication for Windows NT 4.0 only if the disk is duplicated at the point in the setup process after the second reboot and before the GUI portion of Windows NT 4.0 setup.
WARNING |
Duplicating the system in the wrong part of the setup process will copy the entire tree structure of Windows NT, affecting security, hardware, and other areas of the product. Security is impossible because the two installations have the same primary SID, and thus users on one system can access accounts on the other. (Copies made by the Windows NT 4.0 Deployment Tools are not simple copies, and they do configure the OS correctly.) |
Choose the Custom Setup option.
As you proceed through the steps of Setup, use the default settings, except for the following:
All hard disk partitions must be formatted with NTFS.
When the Administrator Account Setup dialog box appears, choose a strong password. For maximum security, select a 14-character password on Windows NT systems. Using these lengths makes NT passwords much harder to guess than shorter ones. Also, use punctuation and other non-alphabetic characters in the first 7 characters. Never leave the password field blank.
When the Local Account Setup dialog box appears, you can create a user account for routine computer use. If you choose to create a local account, keep in mind that this account is placed by default in the Administrators group, which gives the user the ability to create user accounts.
Create an emergency repair disk. This makes it easier to recover your system if the operating-system configuration databases become corrupt. Secure the ERD, as it contains security-critical information. In addition, consider installing SYSKEY to protect stored information from being brute-forced.
Windows NT 4.0 Configuration
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 filesystems. Make sure that all partitions on your workstation are formatted using NTFS. If necessary, use the convert utility to non-destructively convert your FAT partitions to NTFS. Note that doing so will render the NTFS partitions unavailable to Windows 9x clients, unless you add a third-party utility like NTFSDOS.
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 non-printing 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's password is at least nine characters long and that it includes at least one punctuation mark or non-printing ASCII character within the first seven characters.
Unbind unnecessary protocols
If you're not using a particular protocol on a computer, like IPX/SPX or NetBIOS, unbind it from the network adapters it's bound to. This prevents denial-of-service attacks against that protocol, improves your overall performance, and safeguards you against protocol-specific exploits. (To unbind protocols, use the Bindings tab of the Network control panel; if you're not using a particular protocol at all, remove it from the Protocols tab to unbind it from all adapters.)
Remove additional OS installations
Whenever possible, remove any additional Linux, OS/2, or other OS installations. If you have additional Windows NT installations for disaster recovery, make sure it's secured according to the steps in this checklist.
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 computers 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.aspAlpha version:
https://www.microsoft.com/ntserver/nts/downloads/recommended/SP6/alphaLang.asp
Service packs are also available through Microsoft Product Support. Information on contacting Microsoft Product Support is available at https://support.microsoft.com/support/contact/default.asp.
Install the appropriate post-Service Pack security hotfixes
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 servers. If you're installing SP6a, you should begin by installing 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 at the Microsoft Download Center:
Intel version: https://www.microsoft.com/downloads/release.asp?ReleaseID=15927
Alpha version: https://www.microsoft.com/downloads/release.asp?ReleaseID=15928.
The update also can be ordered on various media through Microsoft Product Support Services.
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 for a workstation (either from the computer itself, the computer's emergency repair disk, or a backup tape) can use a password cracking tool to attack these hashes, making it possible to gain access to local workstation accounts. 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.
One important decision when using SYSKEY is what mode to use. SYSKEY supports three modes: one that stores the decryption key locally, and two that store it externally. Although the first mode is more convenient, it is also less secure. As long as the key is stored on the machine, it is theoretically possible to locate it. Microsoft recommends using either of the two more secure modes.
WARNING |
Before you install SYSKEY, make sure to update your computer'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 once SYSKEY is installed. |
Remove the OS/2 and POSIX subsystems
These subsystems are not necessary for the vast majority of applications and services, and removing them protects you against attacks launched from programs running in these subsystems.
First, delete the \winnt\system32\os2 directory and all its subdirectories. Then make the following registry changes, which will take effect on the next reboot: (Note: The Subkeys "Microsoft\OS/2 Subsystem for NT" and "Os2LibPath" will be recreated after the system reboots, but as long as the "optional" subkey remains empty, the OS2 subsystem is in fact removed.)
Hive |
HKEY_LOCAL_MACHINE\SOFTWARE |
Key |
\Microsoft\OS/2 Subsystem for NT |
Action |
Delete all sub keys |
Hive |
HKEY_LOCAL_MACHINE\SYSTEM |
Key |
\CurrentControlSet\Control\Session Manager\Environment |
Value Name |
Os2LibPath |
Action |
Delete |
Hive |
HKEY_LOCAL_MACHINE\SYSTEM |
Key |
\CurrentControlSet\Control\Session Manager\SubSystems |
Value Name |
Optional |
Action |
Delete values |
Hive |
HKEY_LOCAL_MACHINE\SYSTEM |
Key |
\CurrentControlSet\Control\Session Manager\SubSystems |
Action |
Delete entries for Posix and OS/2 |
Disable unnecessary services
As part of your planning, you should have generated a list of needed services. After installing Windows NT, you should disable any network services not on that list. In particular, you should consider whether your machine needs any Peer Web Services components and whether it should be running the Server service for file and print sharing.
Windows NT Security Configuration
WARNING |
The changes in this section must be performed on all workstations in a domain. If you leave even one machine unprotected, you gain very little protection from attacks, since an attacker can simply attack the unprotected computers. |
Make sure the Guest account is disabled
By default, the Guest account is enabled on Windows NT Workstation systems. If the Guest account is enabled, disable it. Restrict the use of LanManager authentication
Windows NT supports several types of challenge-response authentication:
LanManager (LM) authentication, is the original authentication protocol used in Microsoft networking products. It's not as strong as the other available authentication types.
NT Lan Manager (NTLM) authentication is significantly stronger than plain LM authentication. However, like LM, NTLM is vulnerable to some kinds of network-based attacks. NTLM uses 56-bit encryption.
NT Lan Manager version 2 (NTLMv2) authentication adds session-level security for the challenge-response authentication; it also uses 128-bit encryption, rendering it infeasible to brute-force an NTMLv2 password.
You can control which types of authentication your servers and clients will use by adjusting two registry keys: LSA and the LSA\MSV1_0 subkey. These keys allow you to regulate which types of authentication the server will accept, For complete details, see KB article 147706; it's important to balance the increased security gained from restricting the use of LM and NTLM authentication with the requirements of downlevel client support. Secure base objects
This step is necessary to further heighten security of the base objects. Among other things, it prevents users from gaining local administrator privileges by way of a dynamic-link library (DLL). This issue is explained in more detail in Microsoft Security Bulletin 99-006. Use the registry editor to make the following change to implement this security; note that making this change may cause problems on some systems. An improved version of this same fix is included in the C2 hotfix for SP6a.
Hive |
HKEY_LOCAL_MACHINE\SYSTEM |
Key |
\CurrentControlSet\Control\Session Manager |
Value Name |
ProtectionMode |
Type |
REG_DWORD |
Value |
1 |
Secure additional base named objects
This step is necessary to heighten security of additional base named objects such as RotHintTable or ScmCreatedEvent, not addressed by the ProtectionMode key entry above. To implement this setting, make the following registry change:
Hive |
HKEY_LOCAL_MACHINE\SYSTEM |
Key |
\CurrentControlSet\Control\Session Manager |
Value Name |
AdditionalBaseNamedObjectsProtectionMode |
Type |
REG_DWORD |
Value |
1 |
Protect files and directories
A number of filesystem permissions need to be changed to provide adequate security on your workstations and servers. 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 with privileges to install application or system software.
Directory or file |
Suggested Max Permissions |
---|---|
C:\ |
Installers: Change Everyone: Read Server Operators: Change |
files |
Installers: Change Everyone: Read |
IO.SYS, MSDOS.SYS |
Installers: Change Everyone: Read |
BOOT.INI, |
(none) |
AUTOEXEC.BAT, |
Installers: Change Everyone: Read |
C:\TEMP |
Everyone: (RWXD)*(NotSpec) |
C:\WINNT\ |
Installers: Change Everyone: Read |
files |
Everyone: Read |
win.ini |
Installers: Change Pu blic: Read |
Control.ini |
Installers: Change Everyone: Read |
Netlogon.chg |
(none) |
\WINNT\config\ |
Installers: Change Everyone: Read |
\WINNT\cursors\\WINNT\fonts |
Installers: Change Everyone: Add & Read Server Operators: Change |
\WINNT\help\ |
Installers: Change Everyone: Add & Read Server Operators: Change |
*.GID, *.FTG, *.FTS |
Everyone: Change |
\WINNT\inf\ |
Installers: Change |
*.ADM files |
Everyone: Read |
*.PNF |
Installers: Change Everyone: Read |
\WINNT\media\ |
Installers: Change Everyone: Read Server Operators: Change |
*.RMI |
Everyone: Change |
\WINNT\profiles\ |
Installers: Add&Read |
..\All users |
Installers: Change |
..\Default |
Everyone: Read |
\WINNT\repair\ |
(none) |
\WINNT\system\ |
Installers: Change Everyone: Read |
\WINNT\System32\ |
Installers: Change Everyone: Read Server Operators: Change |
files |
Everyone: Read |
$winnt$.inf |
Installers: Change Everyone: Read |
AUTOEXEC.NT, |
Installers: Change Everyone: Read |
cmos.ram, |
Everyone: Change |
localmon.dll, |
Installers: Change Everyone: Read Server Operators: Change |
\WINNT\System32\config\ |
Everyone: List |
\WINNT\System32\DHCP\ |
Everyone: Read |
\WINNT\System32\drivers\(including \etc) |
Everyone: Read |
\WINNT\System32\LLS |
Installers: Change Everyone: Read |
\WINNT\System32\OS2 |
Everyone: Read |
\WINNT\System32\RAS |
Everyone: Read |
\WINNT\System32\Repl |
Everyone: Read |
\WINNT\System32\Repl\, import, export, scripts |
Everyone: Read Server Operators: Change |
\WINNT\System32\spool |
Installers: Change Everyone: Read Server Operators: Full Print Operators: Change |
\drivers\ \drivers\w32x86\2\ \prtprocs\ \prtprocs\w32x86\ |
Installers: Change Everyone: Read Server Operators: Full Print Operators: Change |
\printers\, \tmp\ |
Installers: Change Everyone: (RWX)(NotSpec) Server Operators: Full |
\WINNT\System32\viewers |
Everyone: Read |
\WINNT\System32\wins |
Everyone: Read |
C:\...\*.EXE, *.BAT, *.COM, *.CMD, *.DLL |
Everyone: X |
Protect the registry from anonymous access
The default permissions grant Full Control to Administrators and SYSTEM and Read access to Everyone for the following registry subkeys and all their subkeys:
HKEY_LOCAL_MACHINE\Hardware
HKEY_LOCAL_MACHINE\Software
HKEY_LOCAL_MACHINE\System
HKEY_USERS\.Default
The default permissions do not restrict who has remote access to the registry. Only administrators should have remote access to the Registry, because the Windows NT Registry editing tools support remote access to the Windows NT registry. To restrict network access to the registry:
Using Regedt32, add the following key to the registry:
Hive
HKEY_LOCAL_MACHINE\SYSTEM
Key
\CurrentControlSet\Control\SecurePipeServers
Value Name
\winreg
Select winreg, click the Security menu, and then click Permissions.
Set the Administrators permission to Full Control, make sure no other users or groups are listed, 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.
WARNING |
Don't change Registry permissions indiscriminately. Doing so will cause unpredictable results, including possible loss of system functionality. |
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 only grants Administrators the ability to manage these paths. The AllowedPaths key, and its proper use, is documented in KB 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), then changing the ACL as noted in the table. In the table, "Installers" refers to any accounts with privileges to install application or system software.
WARNING |
Unless the table says "Entire tree", change permissions only on the indicated key, not its subkeys. |
Key path |
Permissions |
Notes |
---|---|---|
\Software |
Installers: Change |
Only accounts that can install software should have change rights to this tree. |
\Software\Classes |
Installers: Add |
Tree needs special treatment because restricting to read access for Everyone may break some applications.] |
\Software\Microsoft\Windows\CurrentVersion\App Paths |
Installers: Change |
Apply to entire tree. At install time this key is empty; set ACLs to prevent its misuse. |
\Software\Microsoft\Windows\Current Version\Explorer |
Everyone:Read |
Apply to entire tree |
\Software\Microsoft\Windows\Current Version\Embedding |
Installers: Change |
Apply to entire tree |
\Software\Microsoft\Windows\Current Version\Run, RunOnce, Uninstall, and AEDebug |
Everyone: Read |
See "Restrict untrusted users' ability to plant Trojan horse programs" below |
\Software\Microsoft\Windows NT\CurrentVersion\Font*, GRE_Initialize |
Installers: Change |
Change only keys that begin with "Font," except FontDrivers, and Gre-Initialize. |
\Software\Microsoft\Windows NT\CurrentVersion\Type 1 Installer\Type 1 Fonts |
Installers: Change |
|
\Software\Microsoft\Windows NT\CurrentVersion\Drivers, Drivers.desc |
Everyone: Read |
Apply to entire tree |
\Software\Microsoft\Windows NT\CurrentVersion\MCI, MCI Extensions |
Installers:Change |
Apply to entire tree. |
\Software\Microsoft\Windows NT\CurrentVersion\Ports |
INTERACTIVE: Read |
Apply to entire tree. |
\Software\Microsoft\Windows NT\CurrentVersion\WOW |
Everyone: Read |
Apply to entire tree. |
\Software\Windows 3.1 Migration Status |
Everyone: Read |
Apply to entire tree. |
\System\CurrentControlSet\Services\LanmanServer\Shares |
Everyone: Read |
Apply to entire tree. Prevents users from adding new shares. |
\System\CurrentControlSet\Services |
Everyone: Read |
Apply to entire tree. This setting prevents non-administrators from changing service settings. |
Restrict access to public Local Security Authority (LSA) information
You need to be able to identify all users on your system, so 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:
Hive |
HKEY_LOCAL_MACHINE\SYSTEM |
Key |
CurrentControlSet\Control\LSA |
Value Name |
RestrictAnonymous |
Type |
REG_DWORD |
Value |
1 |
Restrict untrusted users' ability to plant Trojan horse programs
Trojan horses can take advantage of the Run utility if it is unguarded. There are some Trojan horses that are written to execute during an Uninstall operation. To restrict the ability of users to plant Trojan horse programs:
Use the Registry Editor to find the following keys:
Hive
HKEY_LOCAL_MACHINE\SOFTWARE
Key
Microsoft\Windows\CurrentVersion
Values
Run, RunOnce, Uninstall (if present), AEDebug and all their subkeys
Select each subkey, click the Security menu, and then click Permissions
For each subkey set the permissions for Everyone and all untrusted users to a maximum of Read, and then click OK.
Disable caching of logon information
Windows NT 4.0 has the capability to cache logon information in short-term memory. If the domain controller cannot be found during logon and the user has logged on to the system in the past, it can use those credentials to log on. If the Administrator disables a user's domain account, the user could still use the cache to log on by disconnecting the net cable. To prevent this, Administrators should disable the cache. This results in a somewhat longer logon time, but prevents hackers from tapping logon information from short-term memory.
Hive |
HKEY_LOCAL_MACHINE\SOFTWARE |
Key |
Microsoft\Windows NT\CurrentVersion\Winlogon |
Value Name |
CachedLogonsCount |
Type |
REG_SZ |
Value |
0 |
Set the paging file to be cleared at system shutdown
Clearing the paging file ensures that no unsecured data is contained in the paging file when the shutdown process is complete. Shutdown time will increase proportional to the amount of installed RAM, so this change may not be appropriate for installations where restart time is at a premium. To force Windows NT to clear the page file at shutdown, make the following Registry change:
Hive Key |
CurrentControlSet\Control\Session Manager\Memory Management |
Value Name |
ClearPageFileAtShutdown |
Type |
REG_DWORD |
Value |
1 |
Restrict floppy drive and CD-ROM drive access to the interactive user only
Only the currently logged-on user should be able to access floppy disk drives and CD-ROM drives. To ensure this, allocate the drives at logon. To restrict floppy and CD-ROM drive access to the logged-on user, use the Registry Editor to create and set the values for the following registry entries:
Hive |
HKEY_LOCAL_MACHINE\SOFTWARE |
Key |
Microsoft\Windows NT\CurrentVersion\Winlogon |
Value Name |
AllocateFloppies and AllocateCdRoms |
Type |
REG_SZ |
Value |
1 |
If the entry does not exist, or is set to any other value, floppy devices will be available for shared use by all processes on the system.
These values take effect at the next logon. If a user is already logged on when the values are set, they will have no effect for that logon session. The user must log off and log on again to cause the device or devices to be allocated.
Note |
Windows NT allows all users access to the floppy disk drive, and therefore any user can read and write the contents of any floppy disk in the drive. In general this is not a concern, because only one user is logged on at a time. However, in rare instances, a program started by a user can continue running after the user logs off. When another user logs on and puts a floppy disk in the drive, this program can secretly transfer sensitive data from the floppy disk. If this is a concern, restart the computer before using the floppy disk drive. |
Modify user rights membership
Use User Manager for Domains to restrict the use of user rights as shown in Table 3.
User Right |
Membership |
---|---|
Access this computer from network |
Trusted users who need remote access to the workstation |
Act as part of the operating system |
(no one)Do not assign to any user. |
Add workstations to domain |
Domain Admins |
Back up files and directories |
trusted users (e.g. the Backup Operators group) |
Bypass traverse checking |
Authenticated Users |
Change the system time |
trusted users (e.g. Server Operators) |
Create a pagefile |
trusted users (e.g. Server Operators) |
Create a token object |
(no one) |
Create permanent shared objects |
(no one) |
Debug programs |
(no one) |
Force shutdown from a remote system |
trusted users (e.g. Server Operators) |
Generate security audits |
(no one) |
Increase quotas |
trusted users (e.g. Server Operators) |
Increase scheduling priority |
trusted users (e.g. Server Operators) |
Load and unload device drivers |
trusted users (e.g. Server Operators) |
Lock pages in memory |
(no one) |
Log on as a batch job |
trusted users |
Log on as a service |
trusted users |
Log on locally |
Trusted users |
Manage auditing and security log |
trusted users (e.g. Domain Admins) |
Modify firmware environment values |
trusted users (e.g. Domain Admins) |
Profile single process |
trusted users |
Profile system performance |
trusted users |
Replace a process level token |
(no one) |
Restore files and directories |
trusted users (e.g. Backup Operators) |
Shut down the system |
trusted users (e.g. Server Operators) |
Take ownership of files or other objects |
trusted users (e.g. Domain Admins) |
Restrict network logon access
Depending on what your workstation is doing, you may be able to disable network logon access. You should do this whenever possible so that the workstation may only be accessed by authorized users who log on interactively. Failing that, be sure to restrict access over the network to only those administrators and users who must have it.
Set security log behavior
Use Event Viewer to set security log behavior. Choose Do Not Overwrite Events (Clear Log Manually). Optionally, you can also force Windows NT to halt when it cannot generate an audit event record. Also optionally, you can set the registry key to enable auditing of the use of all rights. In addition, you can force the system to shut down when the security log is full by making the following change. Note that applying this change may result in unexpected shutdowns if the security event log fills unexpectedly.
Hive |
HKEY_LOCAL_MACHINE\SYSTEM |
Key |
CurrentControlSet\Control\LSA |
Value Name |
CrashOnAuditFail |
Type |
REG_DWORD |
Value |
1 |
Change the Scheduler service's security context
The context in which a system service runs determines what it can do. By default, the Schedule service runs in the LocalSystem context, meaning that users may be able to schedule jobs that run in a context that exceeds their own permission level. To change the security context for the Scheduler service, do the following:
Open the Services control panel (Start | Settings | Control Panel | Services).
Select the Schedule service, then click the Startup button. The Service information dialog will appear.
In the Log On As group, select the "This account" radio button. Enter a set of account credentials for the service to use, then click the OK button.
Stop and restart the service.
Hide the name of the last logged-in user
By default, the name of the last user who successfully logged on is displayed in the logon dialog box. To turn this display off, make the following Registry change:
Hive |
HKEY_LOCAL_MACHINE\Software |
Key |
Microsoft\WindowsNT\CurrentVersion\winlogon |
Value Name |
DontDisplayLastUserName |
Type |
REG_SZ |
Value |
1 |
Update the system Emergency Repair Disk
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, then click Help.) Remember to use the emergency repair disk, rather than the Restore utility, if system files are lost. Backup and restore do not copy system access control lists (SACLs). The emergency repair disk does restore this information.
Windows NT Account & Policy Configuration
Disable blank passwords
Blank passwords are unacceptable. You can prohibit blank passwords using User Manager or User Manager for Domains; open the Account Policy dialog using the Policies | Account command, then make sure that the minimum password length is set to a reasonable value.
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 8 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" radio button) of at least 6
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 on, use the Account Policy dialog in User Manager for Domains, then select the "Account lockout" radio button. For maximum security, enable lockout after 3-5 failed attempts, reset the count after not less than 30 minutes, and set the lockout duration to "Forever (until admin unlocks)". Use the passprop utility
The Windows NT Server Resource Kit includes a tool that allows you to adjust some account properties that aren't accessible through the normal management tools. This tool, passprop.exe, allows you to turn on complex password checking and to lock out the administrator account:
The /complex switch turns on a requirement that all passwords must have at least one uppercase letter, one number, or one ASCII symbol. If you use passfilt.dll, this switch is not necessary.
The /adminlockout switch allows the administrator account to be locked out
Notice that this must be done on the domain,
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 computer:
Rename the account to a non-obvious name (e.g. not "admin", "root", etc.)
Establish a decoy account named "Administrator" with no privileges. Scan the event log regularly looking for attempts to use this account.
Enable account lockout on the real Administrator accounts by using the passprop utility
Disable the local machine's Administrator account.
Application Configuration
Review installed applications
For a variety of reasons, it makes sense to review the applications installed on your workstations:
If you're using more licenses of an application than you've paid for, you're exposed to legal liability for copyright infringement and a host of other related torts.
If you're using applications with known security flaws, your network is vulnerable to attackers who exploit those flaws.
If you're running software whose mere presence may get your company in trouble (e.g. Napster or Gnutella), ideally you won't find out about it as a surprise.
Apply appropriate security patches
Security patches like the Outlook 98/2000 Security Update are designed to fix vulnerabilities and add new security capabilities. It's important to stay abreast of the patches released by the vendors who make applications you deploy on your desktop. For Microsoft applications, the best place to get this information is at the TechNet Security site. For other vendors, check their web site to see whether they have a dedicated security or support area.
Implement appropriate security policies
If your vendor releases updates that provide additional security capabilities (e.g. integration with Active Directory Group Policy Objects or support for restricting the types of executable objects that can be used), study these capabilities to make sure you configure them properly and that doing so is strengthening your overall security policy.
Consider use of an application deployment & monitoring tool
Management tools like Microsoft's Systems Management Server offer a broad range of application-related services, including metering, inventory control, and automatic distribution. These systems can generally be used to automate the distribution and installation of applications and associated patches or updates, making them a worthwhile addition if you have a large number of workstation seats or a geographically distributed network.
Deploy desktop anti-virus software
A good antivirus strategy includes protective software at any point where a virus might enter your network. In particular, that means you need an effective anti-virus package on every end-user computer in your organization. It only takes one unprotected machine to begin the spread of an infection that can end up costing you much more than the life-cycle cost of a good anti-virus tool. Of course, for maximum protection you need to integrate server, messaging, and content virus scanners as well.
Ongoing Maintenance Tasks
Review user accounts
Review the list of user accounts on the local workstations to make sure that accounts you no longer need have been deactivated or removed. In addition, review the user policy settings for domain accounts in User Manager for Domains to make sure that logon hours, logon workstation restrictions, and other per-user settings remain in accordance with your requirements.
Review group memberships
Review the list of groups locally defined on your workstations. Remove any outdated user accounts from whatever groups they're in. Periodically check group memberships and ACLs (using a tool like SomarSofts DumpACL) to make sure that you're not accidentally giving access where you don't intend to. Be particularly careful with the membership of privileged groups like Administrators and Power Users.
Review security event logs
Regular review of the security event logs is a critical, and often overlooked, security requirement. Government systems which process classified information are required to review these logs, and it's a good idea for any sensitive system. During your review you should be looking for security-related failures, as well as any other occurrence that strikes you as unusual based on your knowledge of your users and their activity patterns. Event log management tools like SomarSoft's DumpEvt and RippleTech's Logcaster can help you automate the gathering and analysis process.
Consider using password-cracking tools
Weak passwords present a significant security risk. Even if you implement proactive measures like using SYSKEY and forcing a strong password policy, it may be worthwhile to use a password-cracking tool as part of your regular security maintenance and monitoring. In some organizations, users are very resistant to good password security, and an objective way to measure the strength, or weakness, of your overall network's password usage. Since these tools are widely available, it's likely that an attacker will attempt to run them against your network.
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.