More Win2K Pre-SP2 Bug Fixes
Today, I discuss the account and password bugs and the security vulnerabilities that Windows 2000 Service Pack 2 (SP2) corrects. When I searched the Knowledge for a list of all pre-SP2 fixes, the response contained the maximum 200 entries, so it’s definitely time for a new service pack. No installation can manage 200 or more individual patches for known problems and security vulnerabilities.
The Knowledge Base refers to downloading and installing SP2, so I expect the release is imminent. To that end, instead of calling Microsoft Support, you can just wait a week or two for the SP2 update, which will eliminate today’s bugs as well as those I’ve written up over the past few months.
Password Security Hotfix
A new patch eliminates a vulnerability that lets a malicious user implement a brute-force password-guessing attack against a Win2K computer that's not a member of a Win2K domain. A flaw in the way that NT LAN Manager (NTLM) authentication operates in Win2K lets a malicious user bypass the domain account lockout policy on a local Win2K machine.
The security bulletin for Microsoft article Q274372 explains that when a domain account lockout policy is in place and an attacker attempts a brute-force password-guessing attack, the system locks out the domain user account at the domain controller (DC), as expected. However, if the attacker can find the correct password, the local Win2K machine logs on the attacker using cached credentials, in violation of the account lockout policy. Because the attacker can only log on to the local machine, he or she can't authenticate to the domain or gain access to resources on other machines in the domain.
A malicious user can exploit this vulnerability only with domain accounts that have successfully logged on to an NT 4.0 domain or Win2K workgroup and thus have cached logon credentials stored on the local machine. Microsoft originally published this security issue on November 21. You can download the security fix, Q274372_Win2K_sp2_x86_en.exe, from the Microsoft Web site.
Win2K Account Lockout Bug
Microsoft article Q263821 indicates that in a mixed environment of Win2K and Windows NT 4.0 domains, user accounts might intermittently be locked out. The account lockout occurs when you enable the "User Must Change Password at Next Logon" option and a user changes his or her password during logon. If the user connects to Win2K or NT 4.0 servers immediately upon logon, the account can become locked out within seconds, depending on the number of bad passwords that the Account Lockout threshold allows.
When a Win2K DC receives an NTLM authentication request, it tries to validate the password in its database. If the validation attempt fails, the DC increments the bad password count and passes the request to the PDC because the database might not be synchronized. If the PDC responds with successful validation, the bad password count for the user on the DC should reset to 0. However, the DC doesn't reset the count to 0.
You might encounter this problem only in the Win2K environment because account replication doesn't occur in the Win2K domain environment as frequently as in the NT 4.0 domain environment—which means that passwords between Win2K DCs are out of synchronization for longer periods. Also, the bad password count field doesn't replicate between the DCs.
To eliminate these intermittent account lockout problems, you can wait for SP2 or call Microsoft Support for the bug fix. The fix updates three files, dnsapi.dll, netapi32.dll, and netlogon.dll. The files have release dates of July 13, April 13, and June 21, respectively. You should install this fix on all Win2K DCs.
Password Change Misinformation
When you change a user’s password and then change it back to its previous value and you have an account policy that requires a password history, Win2K writes a misleading message in the Security event log. Microsoft article Q263190 indicates that Win2K changes the password to the previous value as you requested, but a logic error in the code that changes passwords causes Win2K to write an erroneous password change failure event. You can safely ignore the failure event message. To eliminate the problem, call Microsoft Support and ask for the bug fix that updates samsrv.dll, kdcsrv.dll, and ntdsa.dll. The files all have a release date of August 2.
Local Security Authority Access Violation
Heap damage in the Win2K module ntdsa.dll generates an lsass.exe access violation on a Win2K DC, and this failure can prevent the DC from restarting successfully. Although the details are vague, Microsoft article Q279093 indicates that this problem appears after many addressBookContainer objects are created. One symptom is a System event log message with Event ID 1173 with a source of NTDS General and message text that states "Internal event: Exception c0000005 has occurred with parameters 757ddeef and 0 (Internal ID 3040442)." Microsoft has two bug fixes available, one for standard encryption and one for high encryption. The bug fix updates four files—lsasrv.dll, lsass.exe, ntdsa.dll, and samsrv.dll—and you must get the patch from Microsoft Support.
