Stefan said:
Any easy way to start an app on boot that has admin privilege that will
run (and work) with all users regardless of their individual privileges?
Other than using the Registry, I mean?
THE DETAILS
Just cleaned up a horribly infected desktop that had multiple user
accounts (all, of course, with admin privilege--Windows default), and no
security at all. Want to run Avast! anti-virus and Spybot S&D for all
users, but want users to be Limited type with password. Also, will have
one Guest user, no password. Unfortunately, Spybot won't run without
admin privilege. And I don't want to install and configure the two apps
on a user by user basis as users are added and deleted regularly as
needed.
The system is a general user desktop and not part of a local network.
The Internet is accessed through a dedicated router. Windows XP Home
SP3. Fully updated.
Thanks.
Stef
Why not use the registry (to add an entry under the HKLM Run key)?
After all, you are professing to be enough of a wizard to clean up an
infected host which means you should have the expertise to edit the
registry.
Otherwise, you'll have to define a scheduled event; however, you won't
be able to use the GUI for Task Scheduler since it requires you specify
the account under which to run the scheduled event - and you cannot
select the SYSTEM account when you define events in Task Scheduler.
You'll have to use the 'at' command in a command shell. Run 'cmd.exe'
to open a command shell. Enter 'at /?' to get help on using the 'at'
command. Scheduled events defined by the 'at' command run under the
System account.
http://support.microsoft.com/kb/313565
"Note When you use the at command, the scheduled task is run by using
the credentials of the system account."
The problem with using 'at' is that you have to specify a date and time
on which to run the scheduled event. You cannot elect to run on Windows
startup as you could when using the GUI for Task Scheduler. The GUI for
Task Scheduler requires you enter the login credentials for the account
under which a task gets ran; however, the SYSTEM account doesn't have
any login credentials because, well, you aren't allowed to logon under
that account.
So why not add an entry to the HKLM Run key? You don't even have to do
the editing yourself via regedit.exe. Just define a .reg file with the
appropriate entries to add the item to the Run key and run the command
"regedit.exe /s <regfile>". If you don't even want to have a separate
..reg file, you can use reg.exe to enter the commands directly to modify
the registry and put those commands in a batch file, like:
(File: addBasicMode.bat - each @ line is one line despite wrapping here)
@rem - Create "Basic User" (reduced privileges) level for Software
Restriction Policies.
@reg.exe add
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers" /v
"Levels" /t REG_DWORD /d 0x20000
The above is a .bat file used to add Basic mode as a policy that I can
select when defining SRPs (software restriction policies) to force a
program to run under a LUA (limited user account) token even when I am
logged under an admin-level account. You use add or del as the operands
to specify whether you are adding a new entry at the specified location
in the registry or deleting one (if you're deleting the entry then
obviously you don't need to specify its value using the /v parameter).
You never mentioned the workstations are on a domain but you indicate
such. That means you use push via policy the execute of the reg.exe
command to update the registry everytime the users login, or push to
them a login script that runs when they login. Obviously you can't push
anything when Windows isn't running (and I'm not a domain admin to know
if you can push anything before a user logs in). So you could push a
login script that runs the reg.exe commands, one for each registry
add/del you want to commit. You could have the login script run the
"regedit.exe /s <regfile>" command but then you would need to use the
"net use" command beforehand to define a network share of where to find
the .reg file whereas the login script running reg.exe commands is self
contained (no networked resources needed).
If the host, as you indicate (but not clearly state), is not part of a
domain then you'll have to be physically wandering over to the host to
make the changes whether they be scheduled events running under the
SYSTEM account or adding an item under the HKLM Run key in the registry.
Well, since you're at the host, it really doesn't matter whether you use
regedit.exe or reg.exe to modify the registry and more likely you'll
just used regedit.exe (with no parameters) to do direct manual editing
to add the Run key item. Of course, and if you really trusted the user,
you could e-mail them the command line (as reg.exe commands or the
regedit.exe command line and attach the .reg file) but then you said
they don't have admin privileges on that host which means that user
won't be able to modify the registry. They might be able to run the
'at' command provided you tell them to run it inside a command shell
(cmd.exe) but they'll have to pick a time to run the scheduled event.
They won't be able to use the GUI for Task Scheduler to schedule the
event to run at Windows startup because they cannot define SYSTEM tasks
using the GUI.
By the way, if you're looking to provide anti-malware protection for
your workstations, start investigating better solutions than Spybot.
Dump Spybot and just use Avast. Spybot is worthless when already using
a far superior anti-malware product (Avast).