During day-to-day operations, NT is likely to store the SAM database in two
places on a hard disk: the %systemroot% repair directory and the
%systemroot%system32\config directory.
Although the \config directory contains a working version of the SAM database that
the live OS uses, programs such as Windows Explorer can't directly access the database
for copying while the system is running. This inaccessibility results from the fact
that the Local Security Authority (LSA) system process (lsass.exe) has locked the file
for exclusive use.
The \repair directory contains the same information as an ERD, which you create using rdisk.exe and use for system recovery. Both the \repair directory and the ERD contain copies of the SAM database and require ample protection. Protect your ERD with the same security as your backup tapes.
To protect the \repair directory, set the permissions to disallow unwanted users from accessing the directory and its files, especially the sam._ file, which contains a copy of the SAM database. To protect files in the \repair directory, carefully perform the following steps using cacls.exe from the Microsoft Windows NT Server 4.0 Resource Kit, or a similar tool.
To Remove all users except Administrators and SYSTEM and verify that Administrators and SYSTEM both have Full Control, Open a command prompt, navigate to %systemroot% (usually C:\winnt), and type cacls repair /g administrators:F system:F /t
In addition to the \repair and \config directories, NT is likely to write SAM-derived information in one of the following files, depending on your system configuration: pagefile.sys, memory.dmp, or user.dmp. NT uses pagefile.sys as an additional virtual memory space that adds to the system's installed hardware-based RAM. NT creates memory.dmp when it crashes and you have your system configured to write a memory dump to disk. NT creates user.dmp when a desktop application crashes and you have Dr. Watson configured to write a memory dump file.
Configuring the system so that it doesn't create these two files is your best bet. However, this method creates a situation in which programmers who must debug a crash problem won't have any data to work with.
To configure Dr. Watson to not write user.dmp files, run drwtsn32.exe, clear the Create Crash Dump File check box, and close the program. To configure NT to not write a memory.dmp file, open the System applet in Control Panel and choose the Startup/Shutdown tab. Next, clear the Write debugging information to check box. If you must have the memory dumps from NT system crashes, consider configuring the system and Dr. Watson to store the dump files in a secure directory that only administrators can access.
By default, NT caches the logon credentials for the past 10 users who logged on interactively. The purpose of this functionality is to let a user still log on to the system even if you disconnect the system from the network or if the domain controllers are unavailable. NT provides some protection for the logon credential cache, but if your environment requires a higher level of security, you might want to disable the caching completely because someone could attack it. Keep in mind that the logon cache credentials contain password hashes of other hashes, which makes this data difficult to crack or use for an unauthorized logon attempt. To date, no publicly known exploit of this cache has occurred. To disable credential caching, change the CachedLogonsCount entry (type REG_DWORD, value 0) in the HKEY_LOCAL_MACHINE \SOFTWARE Microsoft\Windows NT\CurrentVersionWinlogon Registry key.
L0phtCrack's built-in sniffer utility silently grabs SMB password hashes and stores them for cracking. Once cracked, these passwords provide easy access to whatever network resources the user account had access to—ouch! The risk here is obvious, and the prevention is simple.
To protect against such an attack, you'll need to use NTLMv2, which shipped with SP4 and SP5, or a VPN tool, such as Microsoft's PPTP. NTLMv2 should be sufficient to protect data as it travels over your internal LAN, and PPTP will help guard your information as it travels over untrusted networks (e.g., the Internet). If you implement PPTP, be certain to load the latest service pack and all the post-service pack hotfixes. We give you this warning because, at one time, compromising a PPTP connection was very easy. Microsoft has long since remedied those shortcomings, but you won't have these remedies in place unless you load the post-SP3 hotfixes or a later service pack.
To help thwart tools such as L0phtCrack, you might want to restrict NT from sending LanManager (LM) password hashes across the network. LM hashes are much easier to crack than NTLM challenge/response-based hashes because NTLM allows the use of case-sensitive passwords and can use extended keyboard characters, a feature that effectively expands the encryption key space by 26 characters. Remember that strong passwords are difficult for hackers to crack, even with tools such as L0phtCrack. Consider including a carriage return in your password because L0phtCrack doesn't handle this character very well. To insert a carriage return, press Alt+0+1+3 on your keyboard's numeric keypad.
Microsoft released a post-SP3 hotfix that implements a new Registry key for handling this problem. This fix is also present in service packs later than SP3. The new Registry entry is LMCompatibilityLevel (type REG_DWORD) in HKEY_LOCAL_MACHINE \SYSTEM CurrentControlSet\Control\Lsa.
Using NTLMv2, you can set the value to 0, 1, 2, 3, 4, or 5. Setting the value to 0 causes NT to send both NTLM and LM password forms across the network when NT authenticates a network connection (NT's default method of authentication compatibility). Setting the value to 1 causes NT to send both password hashes only if the server requests this action. Setting a value of 2 never lets NT transmit the LM password hash over the network. Setting a value of 3 causes the system to use only NTLMv2 authentication. A value of 4 causes domain controllers to refuse LM authentication, and a value of 5 causes a domain controller to accept only NTLMv2 authentication. Setting this value to 2 is safest, but keep in mind that with this setting, systems that support only LM-style authentication (e.g., Windows 95 and Windows for Workgroups—WFW—systems) can't connect to that particular NT system because they support only the LM type of authentication. For complete details about this configuration setting, see the Microsoft article "How to Disable LM Authentication on Windows NT" ( http://support.microsoft.com/default.aspx?scid=kb;en-us;Q147706&sd=tech ). Note that with the release of SP4, this Registry key value can have six possible settings.
Be aware that SQL Server stores passwords in Registry keys when you configure it to handle its own user authentication. Those particular Registry keys have very little protection. For example, when you register a SQL Server using the SQL Executive, it writes the username and password for that server to the Registry under the HKEY_LOCAL_MACHINE \Software \Microsoft \MSSQLServer tree. Obtaining SQL Server passwords is easy, if not outright trivial work for any savvy user with interactive logon rights to the server, so be careful which users you grant the right to log on locally to your SQL Servers (or any servers for that matter). Now is probably a good time to remind you that you'd be wise to disallow remote Registry access on all NT systems that you can. But you must carefully plan this configuration because many network management packages and software installation routines require remote Registry access to operate correctly.
The moral is to protect yourself by examining your system very carefully before, during, and after installing new software products, especially if those products aren't mainstream commercial items. A good way to keep a close eye on the Registry is to use SYSDIFF in Microsoft Windows NT Resource Kit. With SYSDIFF you can make an image of the Registry before you install new products, then compare that image to the working Registry after you install the product. SYSDIFF reveals any changes between the two Registry images. As a great alternative, Mark Russinovich's REGMON tool (available at http://www.sysinternals.com ) lets you watch Registry access in realtime, which makes it an awesome addition to your toolkit.
start the scheduler service and run it as system
c:\>at 11:32 /interactive "regedt32.exe"