IIS Security Updates; Win2K and NT Trusts; An RPC Fix

New IIS Combination Security Updates
In the ongoing battle to help us stay on top of security issues, Microsoft has released two security updates that combine hotfixes for vulnerabilities in Microsoft IIS 4.0 and 5.0. According to Microsoft article Q297860, the IIS 5.0 rollup includes all the security hotfixes released for IIS 5.0 through the end of May, including code fixes for 16 security vulnerabilities. You can download the IIS 5.0 security update, q293826_w2k_sp3_x86_en.exe, from the Microsoft Web site.

You can install the IIS 5.0 update on all Windows 2000 systems, including Service Pack 1 (SP1) and SP2 machines.

The rollup package for IIS 4.0 contains all 21 security hotfixes released since Windows NT 4.0 SP5. You can install the rollup package on systems running NT 4.0 SP5 or SP6a. Download the IIS 4.0 package, q295534i.exe, from the Microsoft Web site.

For information about the specific security hotfixes that each download includes, see the Microsoft article. These combination security updates don't include fixes for vulnerabilities involving other products that you might install on IIS servers, such as the Front Page Server Extensions and Index Server.

Win2K and NT 4.0 Trusts
Do you support a mix of Windows 2000 and Windows NT 4.0 domains with cross-domain trusts? If so, you'll experience problems if you set the RestrictAnonymous registry value to anything other than 0 or 1 on any Win2K domain controller (DC) that maintains a secure channel to an NT 4.0 system in the trusted or trusting domain. If you apply the Win2K high-security DC security template to a Win2K DC, the template sets RestrictAnonymous to a value of 2. If you copy this template and add your own modifications, the copy also sets RestrictAnonymous to 2.

When RestrictAnonymous is set to 2, NT 4.0's User Manager for Domains can't browse accounts in the Win2K domain. This problem has two symptoms. First, User Manager displays users and groups from the Win2K domain as "Account Unknown." Second, when you try to add users or global groups from a trusted Win2K domain to a local group in the NT 4.0 domain, User Manager responds with the error "Unable to browse the selected domain because the following error occurred: There are currently no logon servers available to service the logon request."

This setting can adversely affect other NT 4.0 components, including Netlogon, the Service Control manager, and the Computer Browser service. See my article A Win2K DC and NT 4.0 BDC Interoperability Problem for a description of other symptoms you might use to diagnose this problem.

You can eliminate this problem by manually setting the RestrictAnonymous (REG_DWORD) value entry to 0 or 1 on the Win2K DC in the registry subkey HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa. After you make the registry modification, reboot the Win2K DC system to activate the change and then delete and recreate the NT 4.0 trust. User Manager should be able to browse the Win2K account database in Active Directory (AD) and successfully enumerate all Win2K user and group accounts. The only time you can safely set the RestrictAnonymous value entry to 2 is if you run native Win2K environments. See Microsoft article Q296405 for more information.

NT 4.0 Crashes on Compaq Proliant Multiprocessor Hardware
If you run Windows NT 4.0 on a Compaq Proliant DL580 multiprocessor machine, the system might intermittently crash at startup and display a "Stop 0x50" error message. This error typically occurs when the system is loading Compaq’s sysmgmt.sys driver, which then references an invalid memory address. The problem occurs only when you set sysmgmt.sys to the default "system" startup mode. If sysmgmt.sys starts in "automatic" mode, the problem doesn't occur. You can get the bug fix for NT 4.0 Service Pack 6a (SP6a) systems from Microsoft Support. The fix contains two files, ntkrnlmp.exe and ntoskrnl.exe. The files have a release date of March 15. Microsoft article Q291781 documents this problem.

Disabling the NT 4.0 Browser
Did you know that you can permanently disable Windows NT 4.0 browser functionality with a set of three batch files and a few NT Server 4.0 Resource Kit utilities? You might want to disable browser operation for several reasons. Browsers operate by broadcasting NetBIOS packets, and this broadcast traffic does little more than clog the airwaves. On a large network, each system takes a long time to update and display the shared resources available. Once produced, the complete list of resources can be overwhelming to novice users.

Browsers routinely become confused and hold elections to argue about which system should function as the master browser, even when an election isn't required (e.g., when a Windows 9x system boots up on the network). When you have a system that incorrectly thinks it should be the master browser for its subnet, the Event Log fills up with messages informing you that the confused system is trying to take control. When you disable the browser, of course, NT 4.0 and legacy systems can't scan for shared resources, and nothing appears in Network Neighborhood. However, as long as an NT system can resolve a NetBIOS name via WINS, the system can successfully connect to shared resources.

If you’re interested in the procedure and the tools you need to disable NT’s browser on all or selected systems, see Microsoft article Q297789.

NT 4.0 RPC Bug Fix
Microsoft article Q297534 reports a problem that impacts programmers who develop remote procedure call (RPC)-based applications. When a program uses RPC for socket communication, the program might stop working for no apparent reason. You can stop and restart the program, but it will stop responding. RPC uses a socket called a SyncSocket to optimize data communication. RPC assumes that the SyncSocket will always be a valid socket and doesn't function properly when another function closes the SyncSocket. When a program incorrectly closes the Syncsocket function, the RPC code enters into an infinite error loop.

To diagnose this problem, run the command netstat –n. If netstat reports many open connections on the RPC port in a CLOSE_WAIT state, you most likely need this bug fix. Microsoft Support has a new version of rpcltscm.dll that handles this error situation correctly. The file has a release date of May 17. You can install this fix only on NT 4.0 Service Pack 6a (SP6a) systems.