The length of your reply seems in direct proportion to the absurdity
of providing, or not greying out, a task scheduler that doesn't work
with single-user accounts and doesn't give an error message until after
users have spent time trying to set up a task. Let's add that MS's
tech paper on LUAs is addressed to "business decision makers" and "IT
Professionals," hardly your typical single user set up or a very
practical way to use a home computer.
If you actually have a suggestion to offer, perhaps a workaround,
I'm all ears. But do limit yourself to a sentence or two or three
(and I'll go back to bottom posting).
Btw, the two instances of Google Task Update User (each followed by a
alphanumeric and either Core or UA at the end) are situated in the Task
Scheduler. If they aren't scheduled tasks, what are they doing there?
Gene
On Fri, 25 Sep 2009 20:46:14 -0500
VanguardLH wrote:
wrote:
gene wrote:
Is it possible to schedule a task without providing a user
password, even if it's a single-user XP setup without one?
Scheduled tasks run under the specified Windows account. To use that
account requires logging into it. That you chose to reduce or
eliminate logon security doesn't obviate the other security measures
in Windows.
It seems that only scheduled tasks installed from outside, so to
speak, such as google updater, are actually accepted and run.
Only if you installed while logged on under an admin-level Windows
account because then that installer can modify the registry to, in
your example, define NT services. Under an admin-level account, an
installer can also, for example, add registry entries to the Windows
Firewall to add exceptions for itself (so you never get prompted).
Scheduled tasks do NOT require you or the host to actually login
before the tasks can be executed. It's not like those tasks are
waiting around for you to login. If you schedule a task then it runs
at that time whether or not anyone has logged into their Windows
account. Task Scheduler runs as an NT service. That means it is
running even when no one is logged in. For it to run its tasks, it
needs to run them under an account and that means having to prove it
has the proper credentials to use that account. Any account with a
blank password is an insecure account. Don't expect Microsoft to
make everything insecure because it is convenient for you by
eliminating the login screen.
Google Updater does not run as a scheduled task. It runs as a
background job. It is an NT service set to Manual mode which means it
will start when a Google program calls it. Google is a company so you
never did identify WHICH of their programs you installed that added a
scheduled task. It would've helped to know. In a virtual machine, I
installed Google Toolbar. It did not add a scheduled task. I then
installed Google Earth and it did install a task (by creating a .job
file). Did it need a password? No. Why? Because it configured the
task to run under the "System" account, not under your own admin or
LUA account. Don't need a password for the System account. It has
higher privileges than admins but it does require that you were
logged in as an admin to create this task. You cannot use the
*wizard* to define a task to run as SYSTEM but you can use the 'at'
command to add the job under that account; see
http://support.microsoft.com/kb/223375. Try running the 'at' command
while logged under a limited account. See, it won't run. You get an
"access denied" error. For Google to have added the scheduled task
that doesn't use a password then it runs under the SYSTEM account and
you ran that installer while logged in as an admin. There are many
reasons why you must be logged in as an admin to install programs.
Google often gets around Windows security regarding permissions for
installing programs and to execute them by copying (rather than
installing them) into your user profile folder. %userprofile% for
your account has both read and write permissions. Executables you
copy there can run even when not logged on under an admin-level
account. They simply side stepped security by placing their files
where the user that logs on has full permissions which is their %
userprofile% folder. It is rude behavior and some companies have
changed permissions on %userprofile% to prevent this security
workaround. Google is not interested in preserving the security of
your host. Infiltration doesn't like security.
You will be far safer if you create a LUA account and use that from
now on as your normal login account. The Administrator account should
*never* be used for normal work. It shouldn't even be used as the
normal admin-level account. It may be the only account you have left
when your user profile(s) gets corrupted for the account under which
you normally login. Administrator should only be used in
emergencies. In fact, if you plan on using an admin-level account,
you should create an alternate admin-level account and log onto that
one WHEN you need to perform admin duties. Administrator is for
emergencies, alt-admin is account for normal admin duties, and a LUA
account should be your normal login account. If you use an
admin-level account as your normal login account, it's up to you to
control security. After all, you've elected yourself the admin.
Scheduling my own tasks always returns a "maybe-it-won't-run" error
message at the end of the wizard, and they don't. Examples are MSE,
which I don't have running real time but want to run manually, and
JkDefrag.exe, an executable not installed via Control Panel.
Thanks.
How does a program login to an account without using its login
credentials? You use a blank password for convenience and thereby
reduce security. One convenience feature does not mean it propagates
across all security components of the OS. Also, in the example
scenario you gave using Google, it is not running a scheduled task
under a user account but instead under the SYSTEM account (but you
had to be logged in at the time that scheduled job got defined to run
under SYSTEM).
I just found the answer:
http://technet.microsoft.com/en-us/kb/kb00310715.aspx
Seems strange to set up a scheduler and then not make it available
to a large bulk of users who don't use passwords with their XP
installations.
Not strange at all. NT-based versions of Windows are MULTI-user
operating systems (well, multi-account since concurrent active
accounts is a kludge in Windows whereas UNIX was designed for
concurrent multi-user) that include account privileges and access
control. You aren't running a DOS/9x version of Windows geared to
just one user.
Care to come up with your statistics regarding "large bulk of users"?
If Microsoft lost all its single user licensed, non-corporate,
consumer- grade customers, they would still flourish. The bulk of
Windows features are not geared toward personal one-user insecure
scenarios.