Article ID: 214840
This article has been archived. It is offered "as is" and will no longer be updated.
A problem occurs in Windows NT 4.0 Service Pack 4 when a user has changed the password for his or her Windows NT domain account from a LanManager client (such as a Windows for Workgroups or the Macintosh desktop). After the user's password is changed from the LanManager client, that account may be used to log on interactively and to make network connections from other systems using a blank password.
The security problem does not affect user accounts where the password change is initiated from Windows 95, Windows 98, or Windows NT systems. Furthermore, user account password changes can only be initiated by the user who knows the current password for the account. There is no opportunity for an unauthorized user to change the password of another user account.
LanManager remote file access clients on Windows for Workgroups, Macintosh, or OS/2 use a different change password protocol than Windows NT, Windows 95, or Windows 98 systems. The older password change protocol for these clients uses only the "LM hash" form of the password for authentication. The Windows NT domain controller stores only the LM hash form of the password credentials for that user in the security account manager (SAM) database. The "NT hash" form of the password for the user account is set to a NULL value.
The problem introduced in Windows NT 4.0 Service Pack 4 is a logic error in validating network authentication for users with the NULL value for the NT hash of the password. The result is that a network connection to a server can be made from Windows 95, Windows 98, or Windows NT systems for those accounts using a blank password.
To resolve this problem, obtain the latest service pack for Windows NT 4.0 or the individual software update. For information on obtaining the latest service pack, please go to:
http://support.microsoft.com/contactus/?ws=supportThis hotfix has been posted to the following Internet location:
Microsoft has confirmed that this problem may result in some degree of security vulnerability in Windows NT version 4.0 Service Pack 4. This problem was first corrected in Windows NT version 4.0 Service Pack 5.