This document is provided to point out guidelines for maximizing security of a Windows NT 4.0 Server installation. The information in this document is gathered from various Microsoft White Papers, Resource Kits and public FAQs. Recommendations made in this document may or may not be applicable to your particular environment.
If you run Internet Information Server, Exchange Server, or SQL Server on your Windows NT 4.0 Server you will want to look into specific security issues inherent in those services as they are not covered in this document.
Note: Default security has been changed in Windows 2000. Some of these changes described here may not have the desired effect on Windows 2000. Details about the default security settings in Windows 2000 can be found in SecDefs.doc
File/Share access security
Service Pack 3 improvements
Service Pack 4 improvements
Summary of Registry Keys
Summary of TCP/IP concerns
The most basic and most important security measure for any operating system is regulating who has physical access to the machine. Software exists to read even NTFS data if the drive is connected to a non-NT system (Linux or MSDOS). It is also possible to reset the built-in administrator's password with a boot floppy. Since data and/or password lists can be extracted from them, physical security must also be provided for repair disks and any system backups.
The best physical security possible is a server room with limited access, but this is not always possible. A locked cabinet for the CPU is almost as good. Failing these, a computer case that can be locked should be used. In this case, you will also have to keep the case locked down and remove or disable booting from floppy or CD-ROM drives when you are not using them. If you choose to disable the drives in BIOS, set a configuration password.
Reminder: All Windows NT computers should be logged off when not in use, this goes especially for administrators and servers where access to the keyboard isn't strictly controlled.
File/Share Access permissions
The standard permissions on files and shares are wide open, granting everyone who wants it almost complete access to your files the moment you create a share.
For all permission changes, assure that "SYSTEM" and "Administrators" retain enough permissions. If in doubt, grant "Full Access"
First and most important is changing permissions on the Windows NT system directory. By, default anyone can change any file that is not currently in use by the system. Reset the entire system path on all Windows NT machines so that "Users" have "Read" permission if interactive logon is permitted, otherwise remove "Users" from the ACL. If non-admin local profiles have been created on the machine do not use "Change permissions on existing subdirectories". Manually reset each directory.. Users should be granted "change" access to the print spool directory. Remove "Users" from the access list on the repair directory. Some applications are coded to write temporary files to the windows directory. In this case only, grant "Users" "Add+Read" access to the directory and "CREATOR/OWNER" "Change".
The boot partition should be set such that only admin and SYSTEM have access to the root directory. If non-admin users connect locally to the system, grant "Users" "Read" permission to CONFIG.NT, AUTOEXEC.NT, and the root folder itself.
The temp directory should be set such that "Users" have "Add+Read" and "CREATOR/OWNER" has "Full Control". This prevents users from seeing each other's temporary files on the system.
Other drives are a matter of personal preference. Remove all user access to root directories unless a special need arises. Configure the server such that all applications and share folders are in subdirectories under the root. Create Global Groups in the domain and Local Groups on the machine to control access to directories. It is not required that you put Global Groups into Local Groups, but it does make changes easier if one group has permissions in multiple places.
When creating a share, you could just leave default permission of "Everyone" "Full Control", since you have secured the disk ACLs and the combined restrictions apply, but you should apply identical permissions to the share to prevent an unauthorized user from taking a client access license.
Suggested User Rights
User Account Policies
There are few restrictions on accounts when a machine is first set up. In user privileges, you may want to check who has access to the machine from the network and who can shut down the machine. In account policies, force users to have a minimum password length. Set accounts to lock out. Make lockout permanent, if possible, otherwise password guessing only takes longer. You can also make passwords expire and/or remember old passwords for uniqueness, but changing passwords may increase the risk of user's writing their passwords down where someone can find them. To enforce password complexity, you can run Passprop from the Windows NT Server resource kit or the SUNet Password Filter.
Also, rename your built-in "Administrator" account, if possible, and disable the built-in Guest account. You will want to run Passprop.exe from the Windows NT Server resource kit to set the built-in administrator account to lock on bad password attempts. If "Administrator" gets locked, it is restricted to only interactive access at a domain controller (See physical security). Also, you will need to apply the registry setting for RestrictAnonymous described later in this document to prevent programs like RedButton from retrieving your "Administrator" account name. Create a user-level and an admin-level account for yourself. Only use the admin-level account when doing administrator work. Only use the user-level account to use an untrusted or Internet application.
Suggested Registry Security
As much as Microsoft warns you to stay away form the registry as much as possible, a few changes are critical. For machines that users will have interactive access to, you will want to change the permissions on many registry keys. See link above for all of them. Most importantly, change from "special" to "read" access on the "Software" key to prevent users from installing new software.
To restrict anonymous users from accessing your registry (and enumerating your account names) set:
This may cause problems with some network-based services that read remote registry entries. If this occurs, first try running the service with a named domain account. If that is not possible or does not solve the problem, add "winreg" to the "NullPipeSessions" value in:
NOTE: This keeps accounts hidden, but reopens the rest of your registry.
If you have a trust relationship, RestrictAnonymous will also prevent the trusting domain from retrieving the user list in permission dialog boxes. Group and User names from the trusted domain will have to be entered manually.
To restrict remote access to the registry, set permissions on:
To completely shut off remote access, set "Network" "No Access" permission on this key.
Note: You must use NTFS as your file system to implement auditing of objects on the system.
Auditing is one of the most effective security measures in any system. It is the only way you can track what an attacker (or errant user) is trying to do and make decisions on how to stop it. Auditing must first be turned on by using User Manager. Under the "Policies" menu go to item "Audit". Select those categories that you wish to audit and whether you would like to audit successes, failures, or both.
Example events are:
Event Success Failure
Logon and Logoff X X
File and Object Access X
Use of User Rights X
User and Group Management X X
Security Policy Changes X X
Restart, Shutdown, and System X X
You may wish to add the registry key HKLM\SYSTEM\CurrentControlSet\Control\LSA FullPrivilegeAuditing=1 to enable more user rights events (Backup and Restore Files), but this can create a huge number of events. Also "Process Tracking" is usually for debugging only, it creates many events and will affect system performance.
To Audit file and object access, you will also have to set Auditing properties on the objects (files, printers, etc.) In Windows NT 4.0, this can be done by selecting the object and right-clicking, entering "Properties" "Security" "Auditing"
Some example settings are:
Event Success Failure
Print (Printers) X
Set Value (Registry Key) X
Change Permission (Dirs and Printers) X X
Take Ownership (Dirs and Printers) X X
Also, make sure that all event logs are checked on a regular basis. This may be a large task if you have many servers. You may want to adjust what you are auditing after evaluating the number of events collected. If you have multiple servers, looking into an event log watcher program would be a good idea.
Apply Windows NT Hotfixes Service Pack 6a has been declared the last Service Pack for Windows NT 4.0. There have been many patches since then, including the Security Rollup Hotfix. Microsoft support has been dropping off, but patches for serious security issues are still coming out frequently.
Use NTFS for all drives This allows the most flexibility in setting a security policy and prevents other operating systems from being loaded on your NT system.
Remove Unneeded Services, In particular: WINS, DNS, FTP, WWW, SNMP and Simple TCP/IP services. These can fall victim of Denial Of Service attacks or allow easier access into your server.
Remove OS/2 and Posix. These subsystems are fairly limited and are less secure than the Win32 systems. You can use C2CONFIG.exe or delete os2.exe and posix.exe.
Create as few privileged accounts as possible
Do not use a privileged account for day-to-day work. This will prevent harm to the system should you fall victim to a trojan horse or other virus attack
Hide Last Logon username.
Legal Notice before logon.
Forcing Logon to Shutdown
Secure Event Log Viewing Prevent guest access to Event logs
Service Pack 3 Improvements
Several improvements to security were made in Service Pack 3 for Windows NT 4.0.
Authenticated Users is a new builtin group that contains all user accounts. This does not contain anonymous connections, as EVERYONE does. As far as possible, EVERYONE should be replaced by Authenticated Users for better protection.
Syskey.exe allows use of 128-bit security to encrypt the SAM database. This prevents extraction by programs like PWDUMP. This will require a floppy disk to store the encryption key and a System Key Password. This disk and this password are required to start your system after setting up encryption. This means that the machine will no longer be able to reboot automatically.
passfilt.dll A password strength DLL can now be implemented to enforce a password strength policy. I have written such a DLL to enforce Leland password standards: SUNet Password Filter.
SMB Signing You can force SMB signing on your NT servers by setting Registry Keys. If you do use this feature, performance will be affected and only Windows NT clients will be able to connect to the Server. Enabling SMB Signing
LANMAN By default, passwords cannot be downgraded to clear-text for LANMAN client sessions. LANMAN passwords are not encrypted as strongly as NT passwords. To disable LANMAN clients altogether, a registry change can be made. Note that this also means that only Windows NT clients will be able to connect.
RestrictAnonymous The registry change HLKM\SYSTEM\CurrentControlSet\Control\LSA RestrictAnonymous=1 removes access to enumerate usernames or access the registry from a Null session.
Service Pack 4 Improvements
Service Pack 4 for Windows NT 4.0. Microsoft's SP4 page
Encryption of secure channels The secure channel protocols used by member workstations and servers to communicate with their domain controllers and by domain controllers to communicate with other domain controllers have been updated. In addition to authentication, you can now encrypt and check the integrity of these communications. For more information, see Q183859.
SignSecureChannel REG_DWORD=0 (FALSE) or 1 (TRUE), Default=TRUE
Sign outgoing messages on the secure channel (Overriden if Seal=1)
SealSecureChannel REG_DWORD=0 (FALSE) or 1 (TRUE), Default=TRUE
Encrypt outgoing messages on the secure channel
RequireSignOrSeal REG_DWORD=0 (FALSE) or 1 (TRUE), Default=FALSE
Refuse unsigned packets
Security Configuration Manager Security Configuration Manager (SCM) is an integrated security system that gives administrators the ability to define and apply security configurations for Windows NT Workstation and Windows NT Server installations. SCM also has the capability to perform inspections of the installed systems to locate any degradation in the system's security.
NTLMv2 Security SP4 contains an enhancement to NTLM security protocols called NTLMv2, which significantly improves both the authentication and session security mechanisms of NTLM. For more information, see Q147706.
LMCompatibilityLevel REG_DWORD=0-5, Default=0
Recommend: Level 1 - Use NTLMv2 session security if negotiated
If only using NT SP4: Level 5 - DC refuses LM and NTLM responses (accepts only NTLMv2)
This parameter specifies the type of authentication to be used.
NtlmMinClientSec REG_DWORD Default=0
NtlmMinServerSec REG_DWORD Default=0
Valid Range: the logical 'or' of any of the following values:
0x00000010 Message integrity
0x00000020 Message confidentiality
0x00080000 NTLMv2 session security
0x20000000 128 bit encryption
This parameter specifies the minimum security to be used.
Summary of Registry Keys
To restrict anonymous connection to the registry and SAM database:
To reopen the registry, if applications fail, add "winreg" to:
To set permissions to remotely access the registry, set permission on:
To set auditing of Backup and Restore:
To set a password filter: (remove FPNWCLNT, if not using File/Print for NW)
To hide last logon:
To display a Legal Notice:
To force log on to Shutdown computer:
To secure Event Logs from guest/anonymous access:
Summary of TCP/IP concerns
Windows NT Hotfixes
RestrictAnonymous registry entry.
Always log off / Use less privileged account (NBTSTAT can list who is connected to a machine)
Turn off LanManager authentication in NT only environment. (NTLMv2)
Remove network services that you do not need.
Rename Administrator and lock Guest and/or deny them "Access this computer from Network" if the console is secure.
Use Passprop to set the Administrator to "lock" on bad password attempts.
Additional measures can be taken to prevent accidental or deliberate damage to a Windows NT system. Those listed here could make your system unusable by or inconvenient for valid clients.
Securing Base Objects Set permission on NT internal objects to C2 security. This can cause problems with some applications.
Secure Print Driver Installation Restrict printer driver install to Print Operators and Administrators only.
Allocating removable drives Lock removable drives to the interactive user when logged on.
Bind Server Service to a non-routable protocol or do not use TCP/IP at all. Binding server to NetBEUI or IPX/SPX limits your exposure to machines on the physical subnet with your own.
Use PPTP and activate PPTP filtering. This encrypts all communications and forces an encrypted authentication for even the most basic communication to your servers. This is listed here since it is very complex to set up and will limit access to only machines with Windows 95 and ISDN accelerator pack or Windows NT.
Desktop Policies in Explorer. Setting up a restricted desktop where the user cannot use the "Run" item and has a very restricted range of applications can insure that a machine is not misused. It can also make it very hard for the user to perform necessary tasks.
FortyPoundHead has posted a total of 1975 articles.
You can find more information from FortyPoundHead by visiting .
No comments on this post yet!
Do you have a thought relating to this post? You can post your comment here. If you have an unrelated question, you can use the Q&A section to ask it.
Or you can drop a note to the administrators if you're not sure where you should post.