Is it possible to run as administrator without password?

  • Thread starter Thread starter iandad
  • Start date Start date
I

iandad

I help to administer a small set of computers used for teaching. One
of the courses requires a program that won't run unless "run as
administrator" is used. Then, of course, it asks for the password.
However, we don't the tutors/pupils to have the password. Does anyone
know how to run the program and hide the administrator password from
the user?

Thanks
Michael
 
Open a CMD prompt and type

runas /?

then hit the <Enter> key. What you are looking for is the use of the runas
command in combination with its /user and /savecred switches. You create a
shortcut to the application you want to run with admin credentials, but the
shortcut invokes the application through runas instead of directly.

The first time you launch the software in the end user's account using that
shortcut you will be prompted for a password. You supply the password that
one time. From then on the shortcut uses the stored credentials you gave it.

Unfortunately, the /savecred switch will not work for Vista Home versions or
Starter Edition, so you're out of luck with this technique of you're running
one of those versions.
 
... Unfortunately, the /savecred switch will not work for Vista Home versions or
Starter Edition, so you're out of luck with this technique of you're running
one of those versions.

Thanks for that. Unfortunately it is Vista Home Premium.
Michael
 
Well, shucks. Then you may have to do this the hard way.

Access Control Lists aren't exposed through the GUI in this version of Vista
when you're booted up normally. However, there are many ways to skin this
particular cat.

The first step is gathering data on the application. The technical support
people for the application should be able to tell you exactly what areas of
the file system and registry that software must have permissions for -- in
other words, why it has to be run as an admin. (They should also be providing
feedback from end users like you to their development folks that they need to
get off their keisters and join the best practices crowd.)

But I'm not going to assume that their tech support folks will be any help
at all, that being par for the course with companies that are still selling
software that requires the end users to write to protected system locations.
In that case you can download Process Explorer and / or Process Monitor from
Microsoft. My guess is that Process Monitor may be your best bet for this
job. You can start it up, set it to filter strictly for events that pertain
to the processes that are created by the errant software application. When
you run the application, as a non-admin, you should get a log of the failures
the software has as it tries to do its thing. Make sure you turn off the
logging function of Process Monitor as soon as you've gathered your data.
Logs, especially if gathering data for multiple processes, can become quite
large, quite quickly. You can make a list of the registry and file system
locations that it is trying (and failing) to write to.

After you have your list you can boot the system to Safe Mode, log on as
admin, and alter the Access Control Lists to grant write access (or, heaven
forfend, full control if it turns out that its required) to the failure
locations for the specific end users who need to run the software. Not having
any of the home versions of ANY Windows product around here I'm not exactly
certain what this is all going to look like. I seem to recall helping someone
with a WinXP system several years ago in a similar circumstance. I think we
actually saw the Permissions locations in the properties dialogs for various
file system locations. Or we may have used a command line utility like XCACLS
to modify the file system permissions. Of course you should try to make the
changes to the most limited number of file system locations possible. Chances
are that you'll be lucky, and the only real problem this application has is
that it tries to write some type of data back to its installation location
instead of to the end users profile (which is the proper way to handle things
like user settings, for instance). So you might only have to give write
permission to the installation directory of the application.

If there are restricted registry locations involved, you can grant
permissions for changing those to the end users using regedit. (If you
haven't done this before, you really, really, really want to be careful about
doing this.)

As you may have surmised already, this process may not be much fun. The
primary reason for that would be that you may go through the whole process,
launch the application, and then have it fail (or have features of it fail)
later on. At that point you have to break out Process Monitor again and find
out why the application is failing, and then make some more permissions
changes wherever they're required.

The other utility I mentioned, Process Explorer, can actually show you
exactly what files and registry locations an application is accessing as it
runs, but I'm thinking that this might be too much information with a scope
that's too general for this purpose.

There may be, and probably are, simpler ways to do this. This is my process
because I'm always having to make really bad software run on recent operating
systems for the company where I work as a sysadmin. I need to more-or-less
stick with Microsoft's own tools when working with Windows because adding in
extra third party vendors while trying to make crappy software work is a good
way to get finger-pointing instead of technical support when something goes
wrong.

I hope this information is helpful, and I hope you'll forgive me if my
warnings about changing ACLs and registry location permissions are not
needed. I included them because I'm not sure about your level of familiarity
with this stuff.
 
I just wanted to add a note regarding tools for altering ACLs. I mentioned
XCACLS in my other message. That is not a part of Vista. (I was talking about
having used it on a WinXP system several years ago.) In Vista you've got a
nicer command line tool than the CACLS tool that came with previous Windows
versions. It's called ICACLS.

Remeber, it's also possible that you may be able to alter file system
permissions through the GUI when logged on in Safe Mode as an admin. I just
don't know because I've never had my hands on a home version of Vista.
 
I just wanted to add ....

Thanks for all that technical stuff. It sounds very daunting indeed.
I didn't expect it to be so difficult. I haven't got a Vista system
at home, so can't check up except during the times the classroom is
not being used.

There's a few other ways out of this too.

First is to create a new admin user just for the duration of the
course (and hope nothing gets fiddled with!) - a fairly dangerous
option.

Second is to abandon the use of this particular version of the product
for the course and use a different version or a completely different
product.

Third, and knowing Windows I'm fairly sure this is not be possible, is
to create a captive account that can only run the one program.

I'll have a discussion with some of my family and see if they can come
up with any further options. They've succeeded in rescuing me once
this weekend when a Vista system that I was checking failed to do the
SP1 automatic update properly.

Thanks once again
Michael
 
The only one of the three options you mention that sounds very good is the
second one. Far and away the best and easiest solution -- if such is
available.

It just occurred to me that you might be able to use Windows SteadyState to
help you in this situation. Take a look at this link, and see what you think.

http://www.microsoft.com/protect/products/family/steadystate.mspx

The home versions of Windows XP and Vista do not have a policy editor or the
usual exposures for control of file system permissions that are available to
those who use the versions that are designed for business use. But this
Steady State software (which is a free download) does enable restoration of
the system from untoward changes. Might be worth a look.

Good luck!
 
Good luck!

Please let us know how it works out, and what steps, if any, you were able
to take to avert a disaster.

;)
 
Back
Top