A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows XP » Windows XP Help and Support
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Scheduled Tasks and passwords



 
 
Thread Tools Display Modes
  #1  
Old September 26th 09, 12:15 AM posted to microsoft.public.windowsxp.help_and_support
No_Name
external usenet poster
 
Posts: 71
Default Scheduled Tasks and passwords

Is it possible to schedule a task without providing a user password,
even if it's a single-user XP setup without one? I can't find anything
in MS help that directly speaks to the matter.

It seems that only scheduled tasks installed from outside, so to speak,
such as google updater, are actually accepted and run. 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.

Gene
XP/SP3
Ads
  #3  
Old September 26th 09, 02:46 AM posted to microsoft.public.windowsxp.help_and_support
VanguardLH[_2_]
external usenet poster
 
Posts: 10,881
Default Scheduled Tasks and passwords

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.
  #4  
Old September 26th 09, 06:49 AM posted to microsoft.public.windowsxp.help_and_support
No_Name
external usenet poster
 
Posts: 71
Default Scheduled Tasks and passwords

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.

  #5  
Old September 26th 09, 03:41 PM posted to microsoft.public.windowsxp.help_and_support
Jose
external usenet poster
 
Posts: 3,140
Default Scheduled Tasks and passwords

On Sep 25, 7:15*pm, wrote:
Is it possible to schedule a task without providing a user password,
even if it's a single-user XP setup without one? *I can't find anything
in MS help that directly speaks to the matter.

It seems that only scheduled tasks installed from outside, so to speak,
such as google updater, are actually accepted and run. 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.

Gene
XP/SP3


Is that the message you see: "maybe-it-won't-run" or do you see some
other message?

It is possible to create a scheduled task to run without a password
(yes, to your question), but not recommended by Microsoft. You won't
read about it from them since it involves overriding some built in
security measures, but that is up to you.

Everyone should agree that good security requires users to have
passwords, but if it is just you on your system it may be more
convenient at times not to have one.

Please read the rest here and decide what you want to do.

Some things are not suitable for STs - like those that may require a
user response to an error or question. So after you create your task,
you should of course test it under various conditions.

Not so popular advice from me to troubleshoot STs:

It is strongly suggested that the task be assigned to a user that has
a password (not the Administrator), so create a new user with a
password just for tasks or add a password to your account if needed.
You can temporarily assign yourself a PW to test and worry about this
later.

If you don't use an account with a password, you will get an error
trying to create the task. The task will still be created, but will
not run
properly.

There is a way around this, but get this working first to be sure
your
mechanism is not afflicted.

Stop the Task Scheduler service.

Delete or rename the probably cluttered ST log file: c:\windows
\schedlgu.txt

Restart the Task Scheduler service to create a new log.

Browse to the c:\windows\tasks folder to see all your tasks. The
Next

Run Time and Last Run Time columns are of interest.

Choose to Add Scheduled Task. Create a new task to run Command
Prompt
once, now. If you don't have a PW, you will get an error trying to
create it (more on that later). It will still be created, but will
never run.

Right click the new Command Prompts task and choose Run and a command
window should open immediately. If not, something is wrong. If yes,
your mechanism is sound. Look in the log file to see your results.

You know how to remove the log now, so that is up to you. Be sure
the
Task Scheduler service is running again.

Try to Run your troublesome task, observe the columns, and the log.
If your task fails to run manually, the errors in the log file are
the
clues to what to do next.
  #6  
Old September 26th 09, 04:57 PM posted to microsoft.public.windowsxp.help_and_support
No_Name
external usenet poster
 
Posts: 71
Default Scheduled Tasks and passwords

On Sat, 26 Sep 2009 07:41:53 -0700 (PDT)
Jose wrote:

There is a way around this, but get this working first to be sure
your mechanism is not afflicted.

Stop the Task Scheduler service.

Delete or rename the probably cluttered ST log file: c:\windows
\schedlgu.txt

Restart the Task Scheduler service to create a new log.

Browse to the c:\windows\tasks folder to see all your tasks. The
Next Run Time and Last Run Time columns are of interest.

Choose to Add Scheduled Task. Create a new task to run Command
Prompt once, now. If you don't have a PW, you will get an error
trying to create it (more on that later). It will still be created,
but will never run.

Right click the new Command Prompts task and choose Run and a command
window should open immediately. If not, something is wrong. If yes,
your mechanism is sound. Look in the log file to see your results.


Thanks. The error I get is the standard one - "The new task has been
created but may not run... The specific error is 0x80070005: Access is
denied."

Tried Run with the new Command Prompt task and got no response (didn't
run at specified time either). Assuming your method works, the question
is, what could be wrong?

Gene
  #7  
Old September 26th 09, 06:04 PM posted to microsoft.public.windowsxp.help_and_support
Jose
external usenet poster
 
Posts: 3,140
Default Scheduled Tasks and passwords

On Sep 26, 11:57*am, wrote:
On Sat, 26 Sep 2009 07:41:53 -0700 (PDT)





Jose wrote:
There is a way around this, but get this working first to be sure
your mechanism is not afflicted.


Stop the Task Scheduler service.


Delete or rename the probably cluttered ST log file: *c:\windows
\schedlgu.txt


Restart the Task Scheduler service to create a new log.


Browse to the c:\windows\tasks folder to see all your tasks. *The
Next Run Time and Last Run Time columns are of interest.


Choose to Add Scheduled Task. *Create a new task to run Command
Prompt once, now. *If you don't have a PW, you will get an error
trying to create it (more on that later). *It will still be created,
but will never run.


Right click the new Command Prompts task and choose Run and a command
window should open immediately. *If not, something is wrong. *If yes,
your mechanism is sound. *Look in the log file to see your results.


Thanks. *The error I get is the standard one - "The new task has been
created but may not run... The specific error is 0x80070005: Access is
denied." *

Tried Run with the new Command Prompt task and got no response (didn't
run at specified time either). Assuming your method works, the question
is, what could be wrong?

Gene


Sounds like it is working fine.

You can create a new account with a PW just for STs.

You can assign your account a PW and use it, and still have the system
to log you in automatically when XP starts (convenient).

If your Administrator account does not have a PW, you can create a
password and use that, but if you ever forget the Administrator
password and need it you will regret forgetting it, followed by
regretting assigning one in the first place. For STs, even the
Administrator user assignment must have a PW.

You can assign your task the NT AUTHORITY\SYSTEM account when creating
it (or modify the Properties). No PW required since this is a system
account. Look at the Properties of any existing tasks - they may be
using that already.

If you assign your task to someone else, you can manually run it and
it shows running, but may not "see" it so you can then check the Task
Manager and ST log to see what it is doing. The command prompt for
example - if you use NT AUTHORITY\SYSTEM, it will run, but you won't
see it since you are not logged in that way.

This is why you may want to test your mechanism by assigning yourself
a PW temporarily and get the command task to run and open a command
window, then work on your new task.
  #8  
Old September 26th 09, 09:51 PM posted to microsoft.public.windowsxp.help_and_support
No_Name
external usenet poster
 
Posts: 71
Default Scheduled Tasks and passwords

On Sat, 26 Sep 2009 10:04:37 -0700 (PDT)
Jose wrote:

Sounds like it is working fine.

You can create a new account with a PW just for STs.

You can assign your account a PW and use it, and still have the system
to log you in automatically when XP starts (convenient).

This is why you may want to test your mechanism by assigning yourself
a PW temporarily and get the command task to run and open a command
window, then work on your new task.


Set up a second user account with admin privileges and the command
prompt task ran fine. As did the defragger I wanted to schedule. The
MSE task has a syntax error that I'm researching.

Then I came across a registry hack to turn the password-required
feature off with Scheduled Tasks, as follows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Lsa
Value name: limitblankpassworduse, Type: REG_DWORD, Data: 0 (disabled)
1 (enabled)

Is there any downside to disabling it, assuming an assortment of
anti-malware programs? One thing I notice after disabling it
(in non-password account) is that when the defragger runs, it runs
entirely in the background, no interface onscreen, unlike the password
account (and normally). Does that seem right? Thanks,

Gene
  #9  
Old September 27th 09, 01:41 AM posted to microsoft.public.windowsxp.help_and_support
Jose
external usenet poster
 
Posts: 3,140
Default Scheduled Tasks and passwords

On Sep 26, 4:51*pm, wrote:
On Sat, 26 Sep 2009 10:04:37 -0700 (PDT)

Jose wrote:
Sounds like it is working fine.


You can create a new account with a PW just for STs.


You can assign your account a PW and use it, and still have the system
to log you in automatically when XP starts (convenient).


This is why you may want to test your mechanism by assigning yourself
a PW temporarily and get the command task to run and open a command
window, then work on your new task.


Set up a second user account with admin privileges and the command
prompt task ran fine. *As did the defragger I wanted to schedule. *The
MSE task has a syntax error that I'm researching.

Then I came across a registry hack to turn the password-required
feature off with Scheduled Tasks, as follows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Lsa
Value name: limitblankpassworduse, Type: REG_DWORD, Data: 0 (disabled)
1 (enabled)

Is there any downside to disabling it, assuming an assortment of
anti-malware programs? One thing I notice after disabling it
(in non-password account) is that when the defragger runs, it runs
entirely in the background, no interface onscreen, unlike the password
account (and normally). *Does that seem right? *Thanks,

Gene


This is not in my list, but sounds interesting, but also threatening -
here's why from a Google search:

http://www.derkeiler.com/Newsgroups/...4-08/2498.html

There are other results that read to the effect that it opens a wide
hole in your security where a remote user/malware, FTP sites, Telnet,
Terminal Services, etc. may connect to your machine over the Internet
- they don't need a password either! Microsoft documentation doesn't
even want to talk about it. So why is it there?!

Even the NT_AUTHORITY method has a little eeeew factor to it, but it
is okay for me here and sometimes people don't go for the more
sensible options and insist on no passwords. I think there is some
other way that is more convoluted, so I don't even have it in my notes
- too messy. I would rather try to think of ways to do things without
circumventing security.

I don't use STs or JKdefrag, but that product has a WWW page and about
halfway down they talk about using a ST:

http://kessels.biz/JkDefrag/

Good find though - I know more now than I did.
  #10  
Old September 27th 09, 02:43 AM posted to microsoft.public.windowsxp.help_and_support
No_Name
external usenet poster
 
Posts: 71
Default Scheduled Tasks and passwords

On Sat, 26 Sep 2009 17:41:09 -0700 (PDT)
Jose wrote:

This is not in my list, but sounds interesting, but also threatening -
here's why from a Google search:

http://www.derkeiler.com/Newsgroups/...4-08/2498.html

There are other results that read to the effect that it opens a wide
hole in your security where a remote user/malware, FTP sites, Telnet,
Terminal Services, etc. may connect to your machine over the Internet
- they don't need a password either! Microsoft documentation doesn't
even want to talk about it. So why is it there?!

Even the NT_AUTHORITY method has a little eeeew factor to it, but it
is okay for me here and sometimes people don't go for the more
sensible options and insist on no passwords. I think there is some
other way that is more convoluted, so I don't even have it in my notes
- too messy. I would rather try to think of ways to do things without
circumventing security.

I don't use STs or JKdefrag, but that product has a WWW page and about
halfway down they talk about using a ST:

http://kessels.biz/JkDefrag/

Good find though - I know more now than I did.


Thanks for the help. I didn't know about the defrag's later versions or
name change.

Gene

  #11  
Old September 27th 09, 05:17 AM posted to microsoft.public.windowsxp.help_and_support
VanguardLH[_2_]
external usenet poster
 
Posts: 10,881
Default Scheduled Tasks and passwords

gene wrote:

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 therein lies the crux of your hypothesis. NT-based versions of
Windows are *not* single-user operating systems. That you use it that
way doesn't mean that's is how it was designed. You can use a
screwdriver as a hammer. You're using a rather large OS for your
personal needs; i.e., you limit the functionality of a large OS to your
specific needs. You might buy a SwissChamp Swiss Army knife (see
http://tinyurl.com/2b5bgx) but never actually use more than a third of
this "blades", and yet it might not have exactly the tool set that you
would design just for personal use.

and doesn't give an error message until after users have spent time
trying to set up a task.


It won't until it tries. As far as I know, the TS wizard only queries
the SAM database regarding login credentials when you attempt to enter
them during the wizard (you get prompted after creating the job for the
login credentials). It never verifies that the job will actually run
under that account specified within the job. It doesn't know that
until runtime.

For example, you can create jobs for existing accounts but which won't
run now but you aren't done completing your setup so that job, when it
does run, will run okay then.

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.


While Microsoft did come up with "home" editions of their Windows
product (which crippled some features), it was a derivative of a
product that was primarily geared toward corporate use and management.
The single-user schema died with the DOS/9X versions of Windows.

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


You already found the answer: you must provide *complete* login
credentials for the account under which you want to run the scheduled
tasks (with the exception of the SYSTEM account but you cannot use the
Task Scheduler wizard for that).

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?


You first mentioned "Google Updater" and that runs as an NT service (so
it gets rolled under one of the svchost process instances that you see
in Task Manager's Processes tab). Now you're mentioning other tasks
(which, I believe, are what I saw when Google Earth was installed).
Saying "Google Updater" didn't provide a clue as to which of Google
product's that you installed as that utility is included in several of
them.

The scheduled tasks you now mention are probably from you installing
Google Earth (but that is not conclusive since I didn't install all of
Google's software programs and you didn't mention which one you
installed). They are scheduled tasks but have you *looked* under which
account they are executed? If the SYSTEM account then the installer
used the 'at' command or similar to create the .job file for that
scheduled task (and no login credentials are required for SYSTEM but
then you had to be logged under an admin-level account when you ran
that installer). If not the SYSTEM account, the installer can use the
crypto API to get your login credentials to add them to the .job file
that it created (while you were logged on as an admin-level user).

If you're interested in learning more about Windows security from
participants in newsgroups, visit the:

microsoft.public.windowsxp.security_admin group

I've seen users there that are far more intimate with the inner
workings of Windows and its security mechanism than I. Since you got
the answer (which you didn't want but is still the answer), I don't see
the point of further trying to explain why someone else's code that is
geared towards a mass community of users doesn't do exactly what you
want it to do.
  #12  
Old September 27th 09, 05:16 PM posted to microsoft.public.windowsxp.help_and_support
John John - MVP[_2_]
external usenet poster
 
Posts: 1,637
Default Scheduled Tasks and passwords

wrote:
On Sat, 26 Sep 2009 10:04:37 -0700 (PDT)
Jose wrote:

Sounds like it is working fine.

You can create a new account with a PW just for STs.

You can assign your account a PW and use it, and still have the system
to log you in automatically when XP starts (convenient).

This is why you may want to test your mechanism by assigning yourself
a PW temporarily and get the command task to run and open a command
window, then work on your new task.


Set up a second user account with admin privileges and the command
prompt task ran fine. As did the defragger I wanted to schedule. The
MSE task has a syntax error that I'm researching.

Then I came across a registry hack to turn the password-required
feature off with Scheduled Tasks, as follows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Lsa
Value name: limitblankpassworduse, Type: REG_DWORD, Data: 0 (disabled)
1 (enabled)

Is there any downside to disabling it, assuming an assortment of
anti-malware programs?


Yes, this can potentially open a security hole the size of Texas on your
machine! If you do not restrict the use of blank passwords to console
logon only you should make sure that Remote Desktop is not enabled!

The real fix to the this password problem is to properly password
protect your user account! Use a good strong password on all your
accounts and use the Auto Logon feature if you wish to logon without
having type your password. Accounts with null passwords are nothing but
problems waiting to happen.

John
  #13  
Old September 28th 09, 04:32 PM posted to microsoft.public.windowsxp.help_and_support
No_Name
external usenet poster
 
Posts: 71
Default Scheduled Tasks and passwords

On Sun, 27 Sep 2009 13:16:37 -0300
John John - MVP wrote:

Then I came across a registry hack to turn the password-required
feature off with Scheduled Tasks, as follows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Lsa
Value name: limitblankpassworduse, Type: REG_DWORD, Data: 0
(disabled) 1 (enabled)

Is there any downside to disabling it, assuming an assortment of
anti-malware programs?


Yes, this can potentially open a security hole the size of Texas on
your machine! If you do not restrict the use of blank passwords to
console logon only you should make sure that Remote Desktop is not
enabled!

The real fix to the this password problem is to properly password
protect your user account! Use a good strong password on all your
accounts and use the Auto Logon feature if you wish to logon without
having type your password. Accounts with null passwords are nothing
but problems waiting to happen.


I didn't specify that this is XP Home, which doesn't have Remote
Desktop.

I was unaware of the Auto Logon feature and in the zillions
of articles I've come across about passwording accounts have never
seen it mentioned as a practical method for single users to get
around the login screen. Thanks.

Gene
  #14  
Old September 28th 09, 05:12 PM posted to microsoft.public.windowsxp.help_and_support
No_Name
external usenet poster
 
Posts: 71
Default Scheduled Tasks and passwords

MS explicitly designed and marketed and sold XP for a variety of user
setups, one of which was as a single-user OS (esp. XP Home), and knows
well from its help lines and from other sources how XP is being used.
Are you saying that MS knowingly misrepresented its product?

Your monikor Vanguard and length of posts suggests someone who once
learned the Leninist notion of propaganda as being the conveying of
many ideas to (relatively) few people, but has yet to figure out that
doing so doesn't necessarily require the use of many words. First,
however, I'd suggest your time would be well spent on a notion Lenin was
big on, namely learning how to think (one of its useful byproducts is
being able to judge better when to go long or short).

-G


On Sat, 26 Sep 2009 23:17:26 -0500
VanguardLH wrote:

gene wrote:

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 therein lies the crux of your hypothesis. NT-based versions of
Windows are *not* single-user operating systems. That you use it that
way doesn't mean that's is how it was designed. You can use a
screwdriver as a hammer. You're using a rather large OS for your
personal needs; i.e., you limit the functionality of a large OS to
your specific needs. You might buy a SwissChamp Swiss Army knife (see
http://tinyurl.com/2b5bgx) but never actually use more than a third of
this "blades", and yet it might not have exactly the tool set that you
would design just for personal use.

and doesn't give an error message until after users have spent time
trying to set up a task.


It won't until it tries. As far as I know, the TS wizard only queries
the SAM database regarding login credentials when you attempt to enter
them during the wizard (you get prompted after creating the job for
the login credentials). It never verifies that the job will actually
run under that account specified within the job. It doesn't know that
until runtime.

For example, you can create jobs for existing accounts but which won't
run now but you aren't done completing your setup so that job, when it
does run, will run okay then.

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.


While Microsoft did come up with "home" editions of their Windows
product (which crippled some features), it was a derivative of a
product that was primarily geared toward corporate use and
management. The single-user schema died with the DOS/9X versions of
Windows.

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


You already found the answer: you must provide *complete* login
credentials for the account under which you want to run the scheduled
tasks (with the exception of the SYSTEM account but you cannot use the
Task Scheduler wizard for that).

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?


You first mentioned "Google Updater" and that runs as an NT service
(so it gets rolled under one of the svchost process instances that
you see in Task Manager's Processes tab). Now you're mentioning
other tasks (which, I believe, are what I saw when Google Earth was
installed). Saying "Google Updater" didn't provide a clue as to which
of Google product's that you installed as that utility is included in
several of them.

The scheduled tasks you now mention are probably from you installing
Google Earth (but that is not conclusive since I didn't install all of
Google's software programs and you didn't mention which one you
installed). They are scheduled tasks but have you *looked* under
which account they are executed? If the SYSTEM account then the
installer used the 'at' command or similar to create the .job file
for that scheduled task (and no login credentials are required for
SYSTEM but then you had to be logged under an admin-level account
when you ran that installer). If not the SYSTEM account, the
installer can use the crypto API to get your login credentials to add
them to the .job file that it created (while you were logged on as an
admin-level user).

If you're interested in learning more about Windows security from
participants in newsgroups, visit the:

microsoft.public.windowsxp.security_admin group

I've seen users there that are far more intimate with the inner
workings of Windows and its security mechanism than I. Since you got
the answer (which you didn't want but is still the answer), I don't
see the point of further trying to explain why someone else's code
that is geared towards a mass community of users doesn't do exactly
what you want it to do.

  #15  
Old September 28th 09, 10:34 PM posted to microsoft.public.windowsxp.help_and_support
VanguardLH[_2_]
external usenet poster
 
Posts: 10,881
Default Scheduled Tasks and passwords

wrote:

MS explicitly designed and marketed and sold XP for a variety of user
setups, one of which was as a single-user OS (esp. XP Home), and knows
well from its help lines and from other sources how XP is being used.
Are you saying that MS knowingly misrepresented its product?


Do you expect a car tire manufacture to retool every assembly line for
their tire output rather than share those tools that are common to all
tire manufacture? The "home" versions are crippled "pro" versions.
Even you know that.

Your monikor Vanguard and length of posts suggests someone who once
learned the Leninist notion of propaganda as being the conveying of
many ideas to (relatively) few people, but has yet to figure out that
doing so doesn't necessarily require the use of many words. First,
however, I'd suggest your time would be well spent on a notion Lenin was
big on, namely learning how to think (one of its useful byproducts is
being able to judge better when to go long or short).


I'm sorry (well, actually not) for throwing too many ideas at your or
using too many big words for you. I don't write children's books. I
didn't realize you and I were in a competition regarding the most terse
versus the most verbose.
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off






All times are GMT +1. The time now is 06:53 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PCbanter.
The comments are property of their posters.