LSA Problems; Enabling Kerberos Event Logging

Paula Sharic describes two problems with Win2K’s Local Security Authority, several issues relating to Win2K and NT 4.0 migration and coexistence, and a handy tip about Kerberos event logging.

Paula Sharick

April 23, 2001

4 Min Read
ITPro Today logo

This week, we return to bugs and fixes. As I researched today’s column, I found a couple of articles that directed me to install Windows 2000 Service Pack 2 (SP2) to correct known problems. A recent letter from Microsoft about dropping SP7 for NT 4.0, which I discussed last week, also stated that SP2 is due out soon, so I suspect that the release date is imminent. This week, I describe two reasonably serious problems with Win2K’s Local Security Authority (LSA), several issues relating to Win2K and NT 4.0 migration and coexistence, and a handy tip about how to enable and disable Kerberos event logging.

Error Message: Invalid Heap Free In LSA
Win2K has a bug that surfaces when you add more than 2000 members to one of the OS’s built-in groups (e.g., the Local Users, Power Users, or Guests group). Microsoft article Q279286 doesn’t describe how to reproduce the error, but it explains that you have this problem if the LSA sends you an "Invalid Heap Free" error message. You must call Microsoft Support to get the code fix, which contains new versions of 13 files involved in authentication and managing the local security context. Most of the files have a release date of January 25, 2001.

SetPassword Call, Security Package Cause LSA Memory Leak
The LSA leaks memory during a Kerberos change-password request and when the LSA loads a security package. These leaks cause the lsass.exe process to grow until it consumes all available memory. The only way to recover is to reboot the system. Apparently, this problem is common because Microsoft offers the bug fix for download. Microsoft article Q288861 explains how you can get the bug fix for certain international versions of Win2K. You can download the English version from the Microsoft Web site.

Slow File Write From Win2K to NT 4.0
When you write a file from a Win2K Professional system to an NT 4.0 server, the process can take up to four times longer than reading the same file from an NT 4.0 server. The slow performance on the write side results from the way each OS implements the code that reads and writes remote files. On Win2K workstations, the redirector doesn’t support RAW Server Message Block (SMB) mode, but instead uses Large File support. NT 4.0 includes Large File Read support, but not Large File Write support.

You can speed up the NT 4.0 server response by increasing the buffer size for NT 4.0 LanMansServer, the component that buffers data during a file write from a remote system. To do so, open a registry editor, find the key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanserverparameters, add the value entry SizReqBuf:DWORD:65535, and reboot.

After you make this registry change, the write-process performance should approximate that of a read operation between the two computers. Note that the SizReqBuf value controls the buffer size for CORE SMB requests. Setting the value to 64KB will have about the same effect as Large Write support, which uses 60KB buffers. This adjustment causes the server services to use slightly more memory. Microsoft article Q279282 documents this problem and the solution.

How to Run NT 4.0 WINS Manager on Win2K
If you’re migrating to Win2K, you might be running NT 4.0 WINS until the migration process is complete. If so, consider running NT 4.0’s WINS Manager on a Win2K system. Microsoft updated the winsrpc.dll file in Win2K, and it conflicts with NT 4.0’s version. To avoid a DLL version conflict, copy all the NT 4.0 WINS files to a Win2K system.

Start by creating a directory (e.g., LegacyWins) for the legacy NT 4.0 WINS code. Next, copy the WINS files Ipadrdll.dll, winsadmn.hlp, winsadmn.cnt, winsrpc.dll, and winsadmn.exe from an NT 4.0 system or the NT 4.0 distribution media to the new directory on the Win2K system. Note that you probably can’t copy these files from an NT 4.0 system if WINS is running, so stop the service before you copy the files.

To ensure that the legacy utility runs only legacy code components, run NT 4.0 WINS Manager only from the new directory. If you attempt to run the NT 4.0 WINS manager from anywhere else, you’ll encounter a DLL conflict when the legacy utility references winsrpc.dll. Microsoft article Q255781 documents this procedure.

Enabling Win2K Kerberos Event Logging
If you have trouble with Kerberos authentication, you can use the following handy registry modification to implement Kerberos event logging. Open a registry editor and find the key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaKerberosParameters. If the Parameters key doesn’t exist, create it. Next, add the value LogLevel:REG_DWORD:0x1 to the Parameters key. After you make this modification, restart the system to activate Kerberos event logging. You’ll find detailed Kerberos events in the System event log. Remember to remove the LogLevel value when you finish troubleshooting so that you don’t fill the System event log with useless information. See Microsoft article Q262177 for details.

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like