These considerations are especially important with the NT Scheduler service. By default, this service runs as the local System account. If you run this service at all, run it as a nonprivileged user. In any case, be aware that members of the Server Operators group can execute commands through NT Scheduler if the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\LSA\SubmitControl value is set to 1. If NT Scheduler is running as System or an administrator, server operators can elevate their own accounts to administrator level. Make sure to set SubmitControl to 0.
A final note regarding configuration: Remember that NT is vulnerable to physical access. If intruders can boot DOS or another OS, they can gain access to a system in several ways. You can provide protection by using BIOS-level passwords that limit booting and modification of CMOS settings. Don't rely too heavily on these features, however. An intruder can circumvent them by resetting the BIOS or removing the battery or hard disk. Web pages exist that list the factory backdoor passwords for many brands of BIOS. Your best protection is to keep your server and its backup tapes and Emergency Repair Disks (ERDs) under lock and key.
Best Practices for Administrators
A solid system configuration is important for protecting your administrator accounts, but don't stop there. Just as important is implementing strict usage rules for your administrative accounts.
I recommend against using the built-in Administrator account as the active Administrator account. Because the Administrator account is the first target for intruders, you can use it to track intruder activity. If you enable logon auditing and refrain from using the Administrator account, you'll be able to quickly identify probing activity by looking for event 528 (successful logon) or event 529 (failed logon) on the Administrator account in the security log. Simply keeping your applications patched and avoiding executing downloaded files doesn't afford adequate protection. The current environment is too complex, dynamic, and bug-ridden for that approach to work.
Another good reason not to use the Administrator account is to provide accountability among administrators. If more than one person shares the Administrator account (or any account, for that matter), accountability disappears. Audit trails won't tell you exactly who did what. Therefore, creating a separate administrative account for each person is a good practice. I've observed some spirited discussions about how more administrative accounts increase the probability of system compromise, but most critics agree in the end. Whether you use one Administrator account or multiple accounts, you have the same number of users who can divulge a password. Therefore, when you create separate accounts, you can track account activity precisely and avoid the problems that shared secrets create. In addition, when an administrator leaves the group, you don't need to change the shared account's password and determine whom you need to notify; you simply disable or delete the departing person's account.
An important rule for administrators is never to run untrusted programs when you're logged on with administrator privileges. An administrator running untrusted code is like a military officer executing a missile-launch command without authenticating the order. But putting this recommendation into practice is easier said than done in today's environment of dynamic macro content and omnipresent Internet access. Web browsing, for example, is nothing less than executing untrusted code and should therefore be forbidden when you're logged on as an administrator. Unfortunately, email is also dangerous. Several well-publicized recent events have demonstrated an intruder's ability to execute arbitrary code on a second machine simply by sending email to it. In one such case, the intruder leveraged a buffer overflow bug in Microsoft Outlook 98's handling of email attachment filenames. Similar dangers exist in applications such as Microsoft Word and Microsoft Excel because of the proliferation and power of macro viruses.
To really protect administrator accounts, you need to create two accounts for each administrator—one with administrator privileges and the other without those privileges. Administrators can perform their usual day-to-day activities with their nonprivileged accounts and log on with their administrative accounts only when they need to perform an administrative task such as maintaining user accounts or updating permissions.
You might wonder how you can refrain from running your Web browser, email, and other everyday applications and still perform your duties. Many administrators must switch back and forth between User Manager for Domains and email or other workflow applications on a minute-by-minute basis. Therefore, administrators seldom implement the important but impractical rule never to run untrusted programs. Fortunately, the resource kit has a nifty utility—SU—which Screen 1 shows. SU lets you run a given program under a specified user account. You can log on to one account and run applications under a different account from the same desktop. To protect your administrator privileges, make it your policy to log on to your desktop with your unprivileged account and launch your regular applications, such as email, word processors, and Web browsers, from their usual icons. Any malicious code you inadvertently execute will run under your restricted, unprivileged account. Then, set up a shortcut for applications such as User Manager for Domains and Server Manager that must run under administrative privileges. Use SU to configure these shortcuts to launch the applications. The only inconvenience you'll experience is that you'll have to enter your password when you log on. For more information about SU, see Mark Minasi, This Old Resource Kit, "SU," January 1998.
Member Servers and Workstations
You'll benefit from monitoring security settings on member servers and workstations that you've assigned to persons with access to critical resources, because these systems are vulnerable to administrator attacks. Each member server and workstation retains its SAM for local rights assignments and membership in local groups. Many advanced user rights, such as Act as part of the operating system, and rights dealing with tokens let intruders circumvent controls and steal administrator privileges. The built-in Administrators and Power Users groups have some powerful privileges over the local system.
Finally, be sure you know who is responsible for rolling out NT workstations in your company. Contractors or interns often handle this task, and because they install the OS, they choose the passwords for built-in Administrator accounts. Most users aren't aware of the built-in Administrator account, and most administrators never think about it after a workstation is set up. In addition, the Server service is enabled by default on NT workstations, making a workstation a file server. Should outside contractors or junior staff members have administrator access to workstations after you've assigned the workstations to users? Probably not, but they often do, depending on a company's installation method. Picture this scenario: A junior IT staff person who has been at a company only a few months has access to the vice president of marketing's or human resources' (HR's) workstation. I frequently find this scenario in assessments that companies hire me to perform. Workstations are vulnerable treasure troves for system intruders because applications cache temporary files locally, as do users who store sensitive information on their local hard disks, despite policies to the contrary. Don't make system break-ins any easier. Reset the Administrator password on workstations and member servers, and consider disabling the Server service.
Some of my suggestions are controversial among systems administrators, and some administrators might argue that I'm advocating security through obscurity. But administrator privileges are an obvious target for system intruders, and with the ever-increasing frequency of intrusions, exercising vigilance is wise. Perhaps the most embarrassing thing that can happen to an administrator is for an intruder to steal administrator privileges to break into a system.
Register
Jon Brown May 24, 2000