[Editor's Note: Share your NT discoveries, comments, problems, solutions, and experiences with products and reach out to other Windows NT Magazine readers (including Microsoft). Email your contributions (400 words or less) to r2r@winntmag.com. Please include your phone number. We will edit submissions for style, grammar, and length. If we print your letter, you'll receive $100.]
SBS Console Blues
You need an open Internet connection to run Microsoft's Small Business Server (SBS) Manage Server console. I faced a problem related to this requirement at one of my client's sites.
I had installed and configured SBS 4.0 on a new machine. When I attempted to open the Manage Server console, Microsoft Internet Explorer's (IE's) dialog box opened and asked whether I wanted to dial out to my ISP.
This problem occurred because, during installation, SBS installs IE 4.0 on the SBS server, and I had configured the browser's Connection property page to dial out to my ISP on startup (using a phone-book entry I created). The Manage Server console is closely integrated with IE and Internet Information Server (IIS). Thus, the Manage Server console defaulted to the ISP dial-up.
To solve the problem, I reconfigured IE to connect via the network. The Manage Server console then worked without any problems.
—Shailendra Shenoy
shailendra.shenoy@tatainfotech.com
NT Security
A colleague recently informed me of a Windows NT security problem. He found this information on a hacker's Web site.
A user with a user-level account can rename the logon.scr file in the \winnt\system32 directory to logon.old and rename usrmgr.exe (or musrmgr.exe on the workstation) to logon.scr. Then, the user logs off and waits for logon.scr to start. When the file starts, User Manager runs instead of the screen saver.
At a minimum, the user can see all the user accounts on the machine. When I tested the hack on my server, I could move the mouse without stopping the screen saver. In addition, I created an administrator-level account without logging on to the server or supplying a username or password. Then, I pressed Ctrl+Alt+Del and logged on to the server with the new administrator-level account. The hack worked even after I installed Service Pack 4 (SP4).
To secure your systems against this hack, ensure that users with user-level accounts can't log on to your PDCs and BDCs. Also, set NTFS permissions on logon.scr and usrmgr.exe to no access for users (the files can still run before logon, but users can't rename them). Finally, make sure your users don't have access to the HKEY_USERS\DEFAULT\Control Panel\Desktop Registry key, where they can also change the logon.scr and usrmgr.exe files. (For more information about NT security, see Sean K. Daily, "NT Server Security Checklist," Parts 1 and 2, July 1998 and October 1998.)
—Bob Bauer
bbauer@cuningham.com
Event Viewer Tip
I recently ran into problems using Windows NT Event Viewer. My Application log became corrupted, and I couldn't figure out how to access it. I decided to delete the log file and start over. Unfortunately, I couldn't delete the Application log, because the event log was running and therefore the system was using the file that contained the log.
To solve the problem, I disabled the event log startup. I started the Services applet in Control Panel, selected EventLog, and clicked Startup. Then, I selected Disabled and clicked OK in the dialog box that opened. After I shut down and restarted my computer, I had full access to the event-log file. Then, I deleted the Application log file (i.e., appevent.evt).
Next, I changed the event-log startup to automatic (via Control Panel, Services, EventLog, Startup, Automatic). I shut down and restarted my computer, and the system created a new Application log that has worked flawlessly ever since. (For more information about Event Viewer, see Michael D. Reilly, "Windows NT Event Viewer," November 1998.)
—Steve Hong
steveho@juno.com
Previous
Register
