Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We are about to roll out several hundred new machines running Windows 7 x64, with the OS installed via WDS so at the moment we can make changes and sysprep them into the build.

The problem is a .NET application we wrote years ago which itself spawns a modified command shell. That shell runs a DataFlex (DataFlex 3.2 dfruncon) application that itself needs to run with elevated permissions.

We don't grant users any general administrator rights.

Is there a mechanism where we can pre-allow our .NET application to run as administrator so that the command control runs as Administrator?

I'm aware of the changes I can make in the app.manifest file to require that the program runs as Administrator. I'm not aware of how I can (as an Administrator) configure the machine to allow that to happen without giving the user more rights or credentials than I would want them to have. Is there something the equivalent of CasPol to allow me to specify that a given EXE file can run as administrator? If not, how on earth would I go about figuring out exactly what rights the user needs to have to allow DataFlex's dfruncon to run?

share|improve this question
    
Are you familiar with using ProcMon to determine read and write failures? –  Tim Brigham Dec 30 '11 at 14:23
    
No I'm not. But after a quick google, that might be very useful. I'll be back on site next year to try it :-) –  Andiih Dec 31 '11 at 11:05

2 Answers 2

What you can do, is:

  1. Create a Scheduled Task and configure it to run with elevated privileges as an administrator account
  2. schedule it to never run, and then place a shortcut to running the task from the standard users dekstop.

This way, the user is able to run the specific program with an admin token, but no others (if users try to modify the scheduled task, they will not be able to apply the changes without the administrator credentials).

There's a pretty explanatory step-by-step guide over at win7 forums: http://www.sevenforums.com/tutorials/11949-elevated-program-shortcut-without-uac-prompt-create.html

share|improve this answer
    
Is that right? I'd look at this technique and was led to believe (as per the top of the page you linked to) "This shortcut and task can only be created and work while logged in as an administrator account. This shortcut will not work in a standard user account.". I've also looked at sevenforums.com/tutorials/… but this requires someone to type the admin password into each users account, and I also have security issues with the credential storage with this technique. –  Andiih Dec 30 '11 at 16:04
    
You need to select the "Run whether user is logged on or not" radio button, for this to work when only a standard user is logged on. What issues do you have with credential storage? Personal issues or technical issues? –  Mathias R. Jessen Dec 30 '11 at 16:34
    
Will try that. re Creds storage with /savecred - I've got to get this past an XGSI (Gov Secure Intranet) audit and I'd seen this mcabee.org/lists/ntbugtraq/Jul-03/msg00061.html which indicates once savecred has been run any command can be run with /savecred which would fail audit. –  Andiih Dec 30 '11 at 17:20
    
That security assesment is based on the original Task Scheduler (the NT 5.x) version, the security isolation model for credential management in windows has been significantly improved since then, also for the task scheduler –  Mathias R. Jessen Dec 30 '11 at 17:29
    
Greg is right though, determining the cause of your need to run it with elevation would be a better approach in terms of the principle of least privilege –  Mathias R. Jessen Dec 30 '11 at 17:35

A better approach would be to determine what resources your custom application and the Dataflex application are accessing, and grant the Authenticate Users permissions to those resources. You may even be able to grant access by using group policy. This is not specific to Dataflex, this is the approach that should be taken with every application.

The resources are typically files, folders, and registry keys. Less often, it may also need to do special functions, such as create global sections in memory, which is a Windows right that can be granted through group policy.

You can determine the resources that are accessed by using SysInternals' Process Monitor.

If you find that an application needs write access to a folder, and that folder has executables that you prefer that the user not have write access to, one trick is to disinherit the access for the executable files from the parent folder, and grant Authenticate Users only Read and Execute to those files.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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