Scheduler Service lets you set administrative tasks to be performed when you’re not around—but it also poses security threats to your system. Here’s how to use the tool wisely.

While the Cat's Away

Scheduler Service lets you set administrative tasks to be performed when you’re not around—but it also poses security threats to your system. Here’s how to use the tool wisely.

• By Michael Chacon
• 09/01/1999

There are lots of times when an administrator may want to perform a task at a specified time, or on a regular basis, without being present at the moment of execution. Common examples are running NTBackup, deleting temporary files, tracking who’s logged onto the system during the evening, or even shutting down and restarting applications on a regular basis to close memory leaks that haven’t been resolved. Regardless of the reason, the service responsible for providing this function is called the Scheduler Service.

At Your Service

The Scheduler Service is currently a Win32 application registered as a service that’s manifested on Windows NT as ATSVC.EXE. It’s located in the \%SystemRoot%\System32 directory. A command-line program called AT.EXE is the interface that controls the Scheduler Service. AT.EXE is a holdover from the OS/2 LAN Manager days. The syntax for the AT command is:

AT [\\Computername] time [/every:date [,…] | /next:date [,…]] "command"

• Computername is used if you want the event to be scheduled on a remote machine. You must have Administrator or, in some cases, Server Operator permissions on the remote machine to schedule an event.
• time is expressed using the 24-hour military syntax.
• /every is used to create a recurring event.
• /next is used to create a one-time or fixed-time event.
• “command” can be any batch file, program, or command that can normally be run at any command prompt.

The :date sub-parameter that complements the /every and /next switches can be expressed fully (as in Monday or Tuesday) or by using a number to express a specific day of the month (such as 3, 11, or 29). Be very careful of the syntax when using the AT command or you may have unpredictable results. Figure 1 shows examples of a task created to run a command file at 9 p.m. every weekday that lists all the users logged onto the domain at the time the event is triggered.

There are two errors in this example. First, the slash in front of the “every” switch is reversed in job ID 1. Second, the “T” parameter in the days to run the batch file should be “Th” for Thursday. The days of the week must be represented as M, T, W, Th, F, S, and Su or the Scheduler Service will ignore them. Figure 2 gives examples of the AT output after these commands have been entered, to demonstrate how the system interprets the flawed commands.

Notice that, with the slash reversed as shown in job ID 1, the parameters have been interpreted as part of the command, and job ID 2 ignores the second “T” because of the missing “Th” and thus won’t run on Thursday. The job ID 3 with the correct syntax is displayed appropriately to run the USERS.CMD file every weekday at 9 p.m.

To view the list of jobs scheduled to run, enter AT.EXE \\ComputerName at the command line. This displays the jobs and the Event ID numbers. The Event ID numbers can be used to delete a specific scheduled job by entering the command AT \\ComputerName ID Number /DELETE. For example, AT 3 /DELETE would remove the last job shown in Figure 2. The final switch to mention is the /Interactive parameter. This enables the Scheduler Service to interact with the desktop of the user who’s currently logged onto the system accepting commands from dialog boxes.

Figure 1. Examples of a task create to run a command file at 9 p.m. every weekday. Only job ID 3 shows the correct syntax.

Figure 2. The system will attempt to interpret commands, even if the syntax is flawed.

When you enter the AT command, you may get a response, “The service has not been started.” You can start the Schedule Service from the command line by entering NET START SCHEDULE. With this method, however, if the server is rebooted, the service will have to be restarted each time. This can be a pain to remember. So, the easiest way to make sure that the Schedule Service is always running—if that’s what you want—is to go to the Control Panel | Services applet, highlight the Schedule service, and select the Startup | Automatic radio button (see Figure 3).

Now that you’ve seen the Schedule Service’s natural environment, let’s make things easier by dipping into our ever-useful NT Resource Kit. There you’ll find a file called WINAT.EXE, which is a graphical interface to the Schedule Service (see Figure 4).

The same switches and parameters are available as in the Schedule Service, but it’s much easier to manage the events from WINAT.EXE. The help file explains each feature and switch of WINAT.EXE fairly well.

Figure 3. The easiest way to make sure that the Scheduler Service is always running is to go to the Control Panel | Services applet, highlight the Schedule service, and select the Startup | Automatic radio button.

Figure 4. WINAT.EXE is a graphical interface to the Schedule Service, and it can be found in the NT Resource Kit.

Security Concerns

Now it’s time for a security caveat. By default the Scheduler Service runs under the System Account privileges, not those of the user who happens to be logged onto the system. This has major security implications. For example, let’s assume we configure several machines to run the example command file I’ve been using. This .CMD contains the command USRSTAT NEWMAN > USERSLOGGED.TXT, which, when run at the scheduled time, produces the output in Figure 5.

Look at the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service key. Under the Schedule key are numbered subkeys that contain the commands scheduled to run (see Figure 6).

Why can we look into the Registry on the NT Workstation? It’s not because we’re Administrators. Look at the default Registry Key Permissions for the Schedule key (see Figure 7).

Figure 5. Output resulting from running the USRSTAT NEWMAN > USERLOGGED.TXT command.

Figure 6. If you look at the HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Service key, you'll see numbered subkeys containing the commands scheduled to run on that machine.

Figure 7. The default Registry key Permissions for the Schedule key shows why we're able to look into the Registry on the NT Workstation.

Although users can’t edit this Registry key, they can read its contents as shown by the Everyone | Read permission. This informs the inquisitive user where to look for the .CMD file. Remember the constant drumbeat to use NTFS file permissions? If users have Change permission to the directory where the scheduled command file exists, they can commit great acts of mischief. Remember, the Schedule Service runs under the System Account context, and this context has administrative privileges. So, a user could enter the command NET LOCALGROUP ADMINISTRATORS Bob /add to our USERS.CMD file. Although this command won’t successfully execute under a user context, the next time the command file runs under the System Account context, Bob will be added to the Administrators group.

To prevent this type of occurrence, you should remove the Everyone | Read permission from this key. You may also consider removing the Server Operators Group Read permission as well, depending upon the level of control you want to create. By default, only Administrators can schedule jobs. However, you can permit the Server Operators group to schedule jobs by adding the following Registry Key:

Hive: HKEY_LOCAL_MACHINE\System\
Key: CurrentControlSet\Control\Lsa
Name: SubmitControl
Type: REG_DWORD
Value: 1

By changing the value to 0, you can remove the Server Operators permissions from scheduling jobs without removing the key.

Once the .CMD file location information is out, you may want to consider creating a specific NTFS protected directory to contain Scheduler Service .CMD files. Always use a fully qualified file location that points to this directory when creating scheduled jobs. When a .CMD file is added to the Schedule Service, the default location is the \WINNT\SYSTEM32 directory. If there’s a directory before the \WINNT\SYSTEM32 directory in the PATH statement a user has write access to, then a .CMD file with the same name could be placed there and would be found by the operating system first. A fully qualified file location such as \WINNT\SYSTEM32\SCHEDULED\USERS.CMD eliminates this remote but possible security gap.

What’s Next? Task Scheduler

Now that we know one of the major security problems with the Scheduler Service, let me show you an easier way to solve the problem without editing the Registry. Simply install Internet Explorer 5. When you install IE5, it changes how the Schedule Service parameters are reflected in the Registry, which tidies up the security breach a bit (see Figure 8).

Figure 8. The security breach in Scheduler Service can be tidied up by installing Internet Explorer 5. This changes how the Schedule Service parameters are reflected in the Registry.

During the installation of IE5, the ATSVC.EXE schedule program is replaced with MSTASK.EXE, and the service is now referred to as Task Scheduler; this is how the Scheduler Service will be implemented with Windows 2000, too. MSTASK.EXE creates a new folder in My Computer called Scheduled Tasks. Here you’ll create and manage scheduled tasks instead of with the AT.EXE command or the Resource Kit’s WINAT.EXE, although you still can use these programs as well.

Task Scheduler has several other new features as well. The most important one is that in addition to the Administrator, users can also schedule jobs, and they’ll always run within the security context of the user who creates the job. Other features include the ability to drag and drop programs into the Task Scheduler, copy jobs from one computer to another, and schedule tasks to be invoked during events such as boot time, logon, or even when the computer is idle.

Although the Schedule Service isn’t among the more fashionable services, it still can have a great impact on a given system. It’s a simple service that shouldn’t be ignored or taken for granted. Not only is there a risk that unscrupulous users can use it for great mischief, but it also provides fundamental support for other services that keep the operating system working.