Access Denied: Auditing Users Who Might Be Starting and Stopping Services

Every day, for no apparent reason, someone restarts my organization's Telnet service. Many users have Administrator authority out of necessity, so anyone could be restarting the service. How can I track down the culprit?

Like files and folders, services are access-controlled objects, and every access-controlled object has a security descriptor. Part of a service's security descriptor is the system ACL (SACL), which you can use to track access to that object. The only way to view or change a service's current SACL is through security templates.

To reach the security templates, log on to the server and open the Microsoft Management Console (MMC) Security Templates snap-in. To create a new template, right-click on the security templates path. Select New Template, click System Services, then double-click the appropriate service (i.e., Telnet). Select the Define this policy setting in the template check box, then click Edit Security to open the Security for Telnet dialog box that Figure 1 shows. This dialog box contains the service's ACL, which you can use to fine-tune who has start and stop authority. (For more information about permission to start and stop services, see "Troubleshooting problems with the Start, stop and pause permission," March 2002, InstantDoc ID 23964.)

Click Advanced, then select the Auditing tab in the Access Control Settings for Telnet dialog box, which Figure 2 shows. As you can see, no auditing is currently enabled on the Telnet service because auditing isn't enabled by default. Click Add, then add an entry to track successful start and stop events that members of Everyone initiate, as Figure 3 shows. Close all the dialog boxes, then save the template. Import the template into the MMC Security Configuration and Analysis snap-in, then apply the template. Now, you can check the Security log for event ID 560 (success audit: object open), where Object Type is SERVICE OBJECT, the Object Name is the short name of the service you're monitoring (in the case of the Telnet Service, TlntSvr), and the logged accesses include Start the service and Stop the service. In the example that Figure 4 shows, you can see that Joe stopped the Telnet service.

Note that although you enabled auditing only for successful starts and stops, Windows 2000 apparently started logging all accesses to the service. Therefore, the Security log will show numerous instances of event ID 560, with accesses such as Enumerate dependencies and Query status of service. These instances are typical and require no response.

Even after you enable auditing for stop and start events on a service, you might not find any instances of event ID 560—for several reasons. First, your Security log might be full, in which case you need to clear it, increase its size, or extend the event-log wrapping options that specify what the log does after it's full. Second, the computer's system audit policy might not be enabled for successful object access events. To check the audit policy, open the MMC Local Security Policy snap-in and maneuver to security settingslocal policiesaudit policy. Make sure that Audit object access is enabled for success. Finally, make sure that the template you applied has successfully enabled auditing on the service. To do so, repeat the process I described previously to create a new template and view the service's current security settings.