Windows NT4 FAQ

NT4 Remote Management

While PC ANYwhere is the traditional method of remotely administrating NT4 servers, there is now an alternative that allow fairly comprehensive management, from any standard browser. The only restriction is that the NT4 server to be managed must also be running the IIS4.0 Web server.

To install download the "Web Administration 2.0" ntswebadmin2.0_x86.exe from:-

http://www.microsoft.com/ntserver/nts/downloads/management/NTSWebAdmin/

Once downloaded simply run it on the NT4 server, this will extract to any folder, it defaults to "\Program Files\NT WebAdmin Setup\" and automatically runs. It creates a new virtual web NTADMIN under your default web site to access it simply type in the address section of your Browser "http:///ntadmin/default.asp", and begin administering the server.

SERVICE PACK 6a

128bit Security Patch now available for Europe use from Microsoft web site

Service Pack 6a (SP6a) resolves the SP6 issue with Lotus Notes and other Winsock based applications and provides the latest updates to Microsoft Windows NT Workstation 4.0 and Windows NT Server 4.0 (including Enterprise Edition). SP6a contains known Year 2000 updates for Windows NT 4.0. These Year 2000 updates are also available as separate Web downloads that customers may apply to a Service Pack 4 system. Providing these options gives organisations the flexibility to choose which path is easier for them to address Year 2000 issues. SP6a is not a required upgrade for Year 2000;

The main advantage of applying service pack 6a is it provides all the security patches since SP5 is one hit. If your running a server as a web server or other Internet connected devices I strongly recommend you upgrade to take advantage of the security patches

For a full listing of all the fixes in SP6a check out www.microsoft.com/ntserver/downloads/recommended/sp6/updates.asp

How you check which service pack you have 6 or 6a? At the run menu type "WINVER".

SERVICE PACK 5

Microsoft doesn't indicate SP5 as a required upgrade for Year 2000 compliance. Having said that it does include four specific Year 2000 updates as well as a host of other bug fixes several which were introduced by SP4. The four new Year 2000 fixes are as follows:-

MFC40.DLL Year 2000 Update A fix for this DLL which adds 1900 to two-digit dates passed to it, therefore programs using this utility might return incorrect dates after the Millennium.
IIS4 HTMLA Year 2000 Update This fix's the possibility that the HTML version of Internet Server Manager for IIS4.0 will generate an incorrect date when a configuration backup is taken after the Millennium.
MSMQ Year 2000 Update This fixes the Microsoft Message Queue Certificate renewal on leap days after the Year 2000. The MSMQ control panel utility has an option to renew a certificate. If it tried to renew certificate created on the 29th February 2000 or other leap day, you would get the following error "Error while creating MSMQ internal certificate. Error 0x80000ffff".
BIOS Data Value Year 2000 Update This fixes the delay in 1 hour of the NT system writing the century byte to the real-time clock at midnight on the 30 December 1999.

For a full listing of all the fixes in SP5 check out www.microsoft.com/ntserver/downloads/recommended/sp5/updates.asp

SERVICE PACK 4 (Year 2000)

Year 2000
Service Pack 4 Year 2000 checker will check your system for the following Microsoft products and update them on your system as necessary to the following: -

Microsoft Internet Explorer 4.01 Service Pack 1
Microsoft Data Access Components 2.0 Service Pack 1
Microsoft Site Server Express 3.0.,

Installation Problems
First ensure you have an up to date full-backup and Emergency Repair Disk ERD. My Service Pack 4 installation was not uneventful and took approximately 3 hours to complete and at one stage looked like needing my full backup.

Having downloaded the full Service Pack 4 and Year 2000 update "Nt4y2k4i.exe" 74.6MB expand it. Running I386/update/update.exe or y2Ksetup.exe starts the installation.

In my case everything went well and the system rebooted successfully. Soon after the SP4 update the "File Server for Macintosh" service which was already installed but disabled, was restarted. The system immediately locked up. It seems SP4 had not updated the "File Server for Macintosh" service because it was disabled even though it was already installed. Unfortunately I had set the faulty service to automatically start on reboot. This resulted in the server spending 100% of its time running this "File Server for Macintosh" service.

I was unable to login and disable the service before the system locked up. I was lucky and had another copy of NT on another volume of this server just for such problems. Having booted this other NT system, I was able to locate the faulty "sfmatalk.sys" service in the servers %system root%/system32/drivers directory and rename it. This allowed me to reboot the server,; and yes, it complained of not finding sfmatalk.sys in the event log.

Having got the NT server back I removed the "services for Macintosh" and reinstalled them from the original installation media. This reinstalled all the AppleTalk services without problem and set them all running. I reapplied SP4 this time with no problems.

Since then I have encountered no problems with Service Pack 4, but you have been warned to ensure you have a up to date backup and sufficient time to recover the system if necessary.

WINS / LMHOSTS CHANGE
SP4 now does not revert to resolving names through WINS if an entry is in the LMHOSTS file and is preloaded (using the #PRE switch). If you have a LMHOSTS file check all the entries are correct before applying the service pack. Refer to Microsoft’s support article Q195672 at: - http://support.microsoft.com/support/kb/articles/Q195/6/72.asp

BETTER SECURITY WITH SERVICE PACK 3 & 4/5

Anonymous user access
To stop anonymous network users (also known as NULL session connections) listing account names and enumerating network shares, it's necessary to make the following registry entry:

Hive------HKEY_LOCAL_MACHINE\SYSTEM
Key-------System\CurrentControlSet\Control\LSA
Name----RestrictAnonymous
Type-----REG_DWORD
Value----1

This stops systems that aren't logged on from getting lists of users, groups and shares, such as when setting up a network share and setting permissions in NT Internet Explorer.

Null Password Bug in Service Pack 4
The Windows NT Security Account Manager (SAM) database stores the hashed password for each user account in two forms: an "NT hash" form that is used to authenticate users on Windows NT clients, and an "LM hash" form that is used to authenticate users on Windows 95, Windows 98, and down level clients such as DOS, Windows 3.1, Windows for Workgroups, OS/2 and Macintosh.
When a user changes his password via a Windows NT, Windows 95 or Windows 98 client, both the "NT hash" and "LM hash" forms of the password are updated in the SAM. However, when the user changes his password via a down level client, only the "LM hash" form of the password is stored; a null value is stored in the "NT hash" field. This is normal operation.

When a user attempts an interactive logon or a network share connection from a Windows NT system, the Windows NT authentication process uses the "NT hash" form of the password. If the "NT hash" is null, the "LM hash" of the password is used for verification. (Windows 95, Windows 98 and down level clients always use only the "LM hash" for verification.) The logic error in Service Pack 4 incorrectly allows a null "NT hash" value to be used for authentication from Windows NT systems. The result is that if a user account’s password was last changed from a DOS, Windows 3.1, Windows for Workgroups, OS/2 or Macintosh client, a user can logon into that account from a Windows NT system using a blank password.

By far the most likely machines to be affected by this vulnerability would be domain controllers running Windows NT 4.0 SP 4, in networks that contain any a mixture of clients listed above. However, any server or workstation running Windows NT 4.0 SP 4 that contains a SAM database with active users who communicate from down level clients would be vulnerable to this problem. For example, a workgroup of Windows NT 4.0 SP 4 systems, one of which is accessed by Windows for Workgroups clients, would be affected by this vulnerability.

It is worth reiterating the following points:

Even on an affected network, a user whose most recent password change was performed via Windows NT, Windows 95 or Windows 98 workstations will have a non-null "NT hash" value, and hence will not be at risk.
Customers who are affected by the vulnerability need only apply the patch to machines that contain SAM databases with active user accounts.
There is no need for users to update or change their passwords after applying the patch. Even in vulnerable systems, the SAM database entries are valid; the problem lies in the way SP4 processes them. The patch corrects the authentication process logic in SP4 without changing the SAM database entries in any way.

Microsoft Knowledge Base (KB) article Q214840, Service Pack 4 Incorrectly Allows Network Connections for Specific Accounts details this problem and the appropriate patch
http://support.microsoft.com/support/kb/articles/q214/8/40.asp

Anonymous registry access
Service pack 3 defines a registry key that stops anonymous users connecting to specifically named pipes. The registry is excluded by default along with any others. You can exempt pipes from this restriction by modifying the following registry entry:

Hive------HKEY_LOCAL_MACHINE\SYSTEM
Key-------System\CurrentControlSet\Control\LSA
Name----RestrictAnonymous
Type-----REG_DWORD
Value----1

All of these options only apply to NT4.0 with SP3 or SP4 applied.

INTERNET SECURITY

FTP Service

Internet Information Server that comes with NT4.0 Server includes a FTP server. Remember with FTP that account names and passwords are sent over the network as clear text. Make sure any user accounts you use for FTP only have very restrictive rights, or better still just allow the anonymous account.
Be aware that NT4.0 doesn't support quota restriction of volume size based on service or user account. Therefore a malicious FTP client could completely fill a NT volume possibly bringing the entire NT4.0 system to a stop. To prevent this ensure the FTP directories are on a separate volume to the NT system. If you must use a directory on the same volume as the system, there are some third party quota restriction utilities for NT4.0.

RAS & WINS
When you use RAS to make a TCP/IP connection, such as to an Internet ISP who uses dynamic IP address allocation, and you have the WINS client bound to the outgoing IP [5] Remote Access WAN wrapper you will find that the machine or server's WINS entry gets over written by the ISP's dynamically assign IP address. Therefore clients who use this WINS entry on your local network get the wrong IP address.

Assuming you're accessing the Internet you have no need for WINS NetBios name resolution, so disable the binding of the "WINS client (TCP/IP)" to the outgoing IP "[5] Remote Access WAN Wrapper".
If you must have the WINS client bound to this outgoing RAS connection, then add a static mapping in the WINS database for this RAS server's IP address, so that it cannot be overridden by the ISP's dynamically allocated address

DNS suffix search Order
The NT DNS client implements an implicit search path for DNS lookup. Basically, if your site's domain name is X.Y.DOMAIN.CO.UK. it will implicitly escalate an unsuccessful DNS request for HOST.X.Y.DOMAIN.CO.UK to HOST.Y.DOMAIN.CO.UK then HOST.DOMAIN.CO.UK then HOST.CO.UK and, maybe even, HOST.UK before returning an error.

This behaviour should be restricted by ensuring you have a entry in the suffix search path field. In the case above it should be the domain name X.Y.DOMAIN.CO.UK.

DNS without WINS (Beware)
Suppose a site is not using WINS or the WINS server is down, but incorrectly sets the "Enable DNS for Windows" option. If you configure a machine HOSTA in a workgroup ADMIN and a DNS domain DOMAIN.CO.UK this will result in NetBios attempting to resolve NetBios names with HOSTA.ADMIN.DOMAIN.CO.UK and, failing that, with HOSTA.DOMAIN.CO.UK, HOSTA.CO.UK, etc.

This results in the potential to exchange classified information, and most definitely a storm of NETBIOS traffic out onto the Internet every few minutes.
Please ensure you disable the "Enable DNS for Windows Resolution" if you're not using WINS. Even if you are using WINS I suggest a Firewall filter for NetBios over TCP/IP is applied to block this potential traffic going out onto the Internet.

SHARED DATABASE CORRUPTION

Are you using a multi-user application that uses a shared database file on NT 3.51 or 4.0. Maybe you have been running successfully for several years?. You then improve your network or change the system dynamics slightly and you start getting corruption in this shared database. We have seen an example of this at sites using Symantec ACT and Access Accounts ( non SQL version), both exhibited this problem. This is almost certainly due to Opportunistic Locking: -

Explanation of Opportunistic Locking on Windows NT
With Exclusive Oplock, if a file is opened in a non-exclusive (deny none) mode, the redirector requests an opportunistic lock of the entire file. As long as no other process has the file open, the server will grant this oplock, giving the redirector exclusive access to the specified file. This will allow the redirector to perform read-ahead, write-behind, and lock caching, as long as no other process tries to open the file.

When a second process attempts to open the file, the original owner will be asked to Break Oplock or Break to Level II Oplock. At that point, the redirector must invalidate cached data, flush writes and locks, and release the oplock, or close the file.

Opportunistic Locking level II, provides a method for granting read access to a file by more than one workstation, and these workstations can cache read data locally (read-ahead). As long as no station writes to the file, multiple stations can have the file open with level II oplock.

http://support.microsoft.com/support/kb/articles/q129/2/02.asp

Try the following registry patches that disable the Oplock feature. Oplocks are a significant performance enhancement, but have the potential to cause lost cached data on some networks

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
LanmanServer\Parameters]
"EnableOplockForceClose"=dword:00000001
"EnableOplocks"=dword:0000000

Send mail to Andy Gray with any comments about this web site.
Last modified: 04 June 2005