Managing the performance of a Windows system often involves managing the services that run on that system. This isn't always as easy as it seems, even if you just allow for default settings.
This tip, excerpted from InformIT, discusses setting up how services will access various system functions and capabilities. It is a portion of a chapter from the authors' Maximum Windows 2000 Security.
Because services run independently of the user, they are controlled by a process named the Service Control Manager (SCM). The SCM knows about all services installed on a system and which ones are currently running. It also makes sure that autostart services are run at startup, and it handles user requests to start and stop services.
When Windows 2000 is started, the SCM determines which services must be started, and it logs each one in to the system to obtain a security token. Although most services will log in as SYSTEM, a service can be set to log in as any locally authorized user provided the user account has the Log on as a Service right assigned to them in the Domain Security Policy MMC Snap-in found under the Administrate Tools. Assigning a user account to run the service can be accomplished by using the Services MMC Snap-in found under the Administrative Tools. By selecting a service and viewing its properties, an administrator can set the user account the service runs under. By default, every service that comes with Windows 2000 is automatically installed to run as SYSTEM. Normally, when it comes to security, you run an application with least privilege. That means that only the minimal set of privileges required to accomplish the task should be assigned. However, SYSTEM is an account with full access to everything, so giving every service that kind of access clearly breaks the rule of least privilege.
The alternative is to spend the time to create service accounts that have lesser privileges and set each service to use those accounts. However, because creating and managing those accounts is a headache that most administrators would rather not deal with, permissions are rarely changed from the default. Furthermore, it is difficult to know if reducing a service's permissions will cause the service to stop functioning, and most administrators do not have the time to research each individual service.
To add to this problem, auditing the SYSTEM account yields countless event log entries and does not allow you to distinguish between the activities of different services. Rather than going through the trouble of giving each service its own logon and experimenting with the rights of each, we control services in other ways. We make sure that only administrators can start services, remove unsafe services, and make sure that the SYSTEM account cannot access certain files, such as cmd.exe. Sure, there is a certain amount of exposure by running services as SYSTEM, but with some things, the amount of work does not warrant the returned benefit.
To read the entire article from which this tip is excerpted, click over to InformIT. You have to register there, but the registration is free.