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.
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.