Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working in a high security corporate environment on a Windows 8 machine.

I don't have administrator privileges, but am a developer.

I won't go into the absurdity of this. The short is; there are certain programs I need admin rights for. Starting XAMPP with Apache is one, as it opens ports which requires privileges.

Are there ways in Windows 8 I can configure programs like XAMPP to start with admin privileges pre-approved?

share|improve this question

closed as off topic by Jenny D, Sven, Dave M, mdpc, kce Apr 17 '13 at 16:29

Questions on Server Fault are expected to relate to server, networking, or related infrastructure administration within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

Perhaps you could ask your IT staff to provide a VM for your development needs? – jscott Apr 17 '13 at 14:06
VM's are just frustrating though. I want the full power of my machine, and I want to use it natively. I don't want to have an 800px by 600px size VM I have to boot up everytime I want to use a program. Others must share my pain. – Barney Apr 17 '13 at 14:21
You have some misconceptions of VM fundamentals. – jscott Apr 17 '13 at 14:23
Just a lack of education. Link me some reading! – Barney Apr 17 '13 at 14:24
I'm sorry, but if you're not the admin of your server, you can't start stuff that require admin privileges. This is a social problem (i.e. your company not trusting you to run your computer), and there's no easy technical solution to it. – Jenny D Apr 17 '13 at 14:33

There are two approaches.

  1. Disable UAC. A blunt-force approach that applies globally to the entire system. Suboptimal from an overall security perspective.

  2. Launch the application with another executable that enables the administrator privileges that are disabled by default. You can either create your own, and use something like ProcessPrivileges to enable the disabled privileges, or use another tool like SysInternals' psexec.

It's worth mentioning that running an exe as a scheduled task, and specifying 'Run with highest privileges' accomplishes the same thing, but you probably do not want to be confined to running this as a scheduled task. This would however, be a useful approach for a system administrator to provide this on a per-application basis, and give another person permission to run the scheduled task, so that they would not need excessive privileges.


psexec.exe -h yourprogram.exe

Or you can even run the process as local system:

psexec.exe -s yourprogram.exe

Or run the process as local system, that can interact with the desktop:

psexec.exe -s -i yourprogram.exe

More information:

PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals -

PsExec executes a program on a remote system, where remotely executed console
applications execute interactively.

Usage: psexec [\\computer[,computer2[,...] | @file]][-u user [-p psswd][-n s][-l][-s|-e][-x][-i [session]][-c [-f|-v]][-
w directory][-d][-<priority>][-a n,n,...] cmd [arguments]
     -a         Separate processors on which the application can run with
                commas where 1 is the lowest numbered CPU. For example,
                to run the application on CPU 2 and CPU 4, enter:
                "-a 2,4"
     -c         Copy the specified program to the remote system for
                execution. If you omit this option the application
                must be in the system path on the remote system.
     -d         Don't wait for process to terminate (non-interactive).
     -e         Does not load the specified account's profile.
     -f         Copy the specified program even if the file already
                exists on the remote system.
     -i         Run the program so that it interacts with the desktop of the
                specified session on the remote system. If no session is
                specified the process runs in the console session.
     -h         If the target system is Vista or higher, has the process
                run with the account's elevated token, if available.
     -l         Run process as limited user (strips the Administrators group
                and allows only privileges assigned to the Users group).
                On Windows Vista the process runs with Low Integrity.
     -n         Specifies timeout in seconds connecting to remote computers.
     -p         Specifies optional password for user name. If you omit this
                you will be prompted to enter a hidden password.
     -s         Run the remote process in the System account.
     -u         Specifies optional user name for login to remote
     -v         Copy the specified file only if it has a higher version number
                or is newer on than the one on the remote system.
     -w         Set the working directory of the process (relative to
                remote computer).
     -x         Display the UI on the Winlogon secure desktop (local system
     -priority  Specifies -low, -belownormal, -abovenormal, -high or
                -realtime to run the process at a different priority. Use
                -background to run at low memory and I/O priority on Vista.
     computer   Direct PsExec to run the application on the remote
                computer or computers specified. If you omit the computer
                name PsExec runs the application on the local system,
                and if you specify a wildcard (\\*), PsExec runs the
                command on all computers in the current domain.
     @file      PsExec will execute the command on each of the computers listed
                in the file.
     program    Name of application to execute.
     arguments  Arguments to pass (note that file paths must be
                absolute paths on the target system).

You can enclose applications that have spaces in their name with
quotation marks e.g. psexec \\marklap "c:\long name app.exe".
Input is only passed to the remote system when you press the enter
key, and typing Ctrl-C terminates the remote process.

If you omit a user name the process will run in the context of your
account on the remote system, but will not have access to network
resources (because it is impersonating). Specify a valid user name
in the Domain\User syntax if the remote process requires access
to network resources or to run in a different account. Note that
the password is transmitted in clear text to the remote system.

Error codes returned by PsExec are specific to the applications you
execute, not PsExec.
share|improve this answer
But... you need Admin access to turn UAC off. And you need Admin access to launch processes as Localsystem. – Ryan Ries Apr 17 '13 at 14:17
Not only what @RyanRies has said, but turning off UAC does not give one rights to run a program in elevated mode, it merely doesn't prompt for credentials. If a user doesn't have rights then it will run normal. A user will still need the appropriate permissions to run the program elevated. – BigHomie Apr 17 '13 at 14:29

I have a solution, but it depends on a couple of things:

  1. How tech-savvy the IT Staff is

  2. If what you're trying to run can be called from a command line

Basically, they can compile an exe that calls the program you need ran, while passing the necessary credentials to run in elevated mode. .Net can be used for this and it's quite trivial. Since the exe is compiled (vs a script) the account credentials used to run the exe aren't in clear-text.

share|improve this answer
A string literal inside a compiled EXE is also trivial to dump. Even if you tried to hide it in something like a SecureString, I'd use DotPeek on your silly .NET program and still have your creds. – Ryan Ries Apr 17 '13 at 14:04
@RyanRies oh there are definitely ways to get the creds inside of a compiled exe, but that's beyond the scope of the question: It's easier to double click a script and read the text than it is to 1) know for a fact that there are creds inside an exe and 2)How to read them. And who said anything about a string literal??? :-) – BigHomie Apr 17 '13 at 14:21

No, you can't do this. Or more accurately, you shouldn't do this. Most of the people on this site are the IT department, and as such, are not really keen on discussing ways to circumvent your IT department's regulations and controls. Your IT department doesn't want you to have admin access or else they would have given it to you.

Try going through the proper channels (i.e. talk to your admins) and explain to them that you need admin access in order to do your job effectively. They probably won't be able to give you admin access on your corporate laptop per company policy, but they might be able to give you a VM in a lab to play on.

PS: Sorry if I sound grumpy. Not enough coffee yet.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.