When I run System.Diagnostics.Process.Start from my console application it works but the same code when I run from my web service hosted in IIS doesn't work.
Is it some thing to do with ASP.Net privileges?? if yes how can I configure it from my C# code.
ASP.NET Web page and server control code executes in the context of the ASP.NET worker process on the Web server. If you use the Start method in an ASP.NET Web page or server control, the new process executes on the Web server with restricted permissions. The process does not start in the same context as the client browser, and does not have access to the user desktop.
http://msdn.microsoft.com/en-us/library/0w4h05yb.aspx
- Give permission for ASP.NET worker process account
to interact with desktop or allow ASP.NET worker process to run in SYSTEM account.
To know how to allow worker process to run in SYSTEM account
and to know the default permissions of ASPNET account, check this article
INFO: Process and Request Identity in ASP.NET: http://support.microsoft.com/default.aspx?scid=kb;en-us;317012
- Enable IIS Admin Service to interact with desktop
To configure this, follow this steps.
a. Open Control Panel and follow these steps:
For Windows NT: click Services.
For Windows 2000, Windows XP, and .NET Server: click Administrative Tools, and then click Services.
b. Double-click IIS Admin Service.
c. On the Log On tab, select the Allow Service to Interact with Desktop check box.
Remember to run IIS Admin Service as a local system.
d. Stop and restart the IIS Admin Service.
Changing the AppPool worked for me.
IIS > Application Pools
Select Advance Setting for the website
Change Identity to LocalSystem
Restart IIS
I had a similar problem, and the ability to access the desktop from the service wasn't the problem. It worked fine when not impersonating another user, but when trying to run the process as a different user it failed.
The first thing to do when it won't start is find out all the information you can about the problem. The first question is whether Process.Start returned true or false. Secondly, did you get any kind of exception when trying to start the process.
Before you can investigate fully it relevant to know whether Process.Start was run using UseShellExecute or not - this has to be false for impersonation, but otherwise you can choose whether to use it and it calls different Win32 functions depending on this setting.
If you're doing a process that needs to run as another user, don't bother trying to use .NET impersonation - the StartInfo username, password, domain are what you need to set. However, under IIS you've got some additional lockdown, and the only solution I found on Windows Server 2008 actually involved some Win32 calls and implementations of abstract security libraries. Many of the scenarios you can run into are outlined here: http://asprosys.blogspot.co.uk/2009/03/perils-and-pitfalls-of-launching.html
The sample code from that page shows how to call the library and add Windows Station and Desktop access to a user before starting a process as that user. This was what I needed to get Process.Start to work from IIS, having ruled out UAC, DEP and any other three letter acronym I could think of ;)
I had tried upper solutions but didn't work for me. What I need was, a command should run via Windows Command Prompt as Administration.
Below the codes that didn't work but need to execute:
Process sysProcess = new Process();
sysProcess.StartInfo.FileName = "cmd.exe";
sysProcess.StartInfo.Verb = "runas";
sysProcess.StartInfo.CreateNoWindow = true;
sysProcess.StartInfo.RedirectStandardInput = true;
sysProcess.StartInfo.RedirectStandardOutput = true;
sysProcess.StartInfo.RedirectStandardError = true;
sysProcess.StartInfo.UseShellExecute = false;
sysProcess.Start();
sysProcess.StandardInput.WriteLine("cal.exe");
sysProcess.StandardInput.Flush();
sysProcess.StandardInput.Close();
//localProcess.WaitForExit();
sysProcess.StandardOutput.ReadToEnd();
Solution:
It was an API project and when I Enable SSL from project's properties and debug tab (see, Image 1 and Image 2).
Image 1:
Visual Studio 2019
Image 2:
Visual Studio 2022
This solution will works on any Web App projects.
If you are application is running windows 7 then you can't. basically services running session 0 and user desktop running session 1 so you can't communicate from session 0 to session 1. even if you try to communicate from win logon process (which is used to start the user session for every new user) you can't get some local information (browser settings like local storaage information)
For me what is working is something like this:
ProcessStartInfo psi = new ProcessStartInfo();
psi.UseShellExecute = true;
psi.LoadUserProfile = true;
psi.WorkingDirectory = sender.Server.MapPath("../");// This line solved my problem
psi.FileName = sender.Server.MapPath("../myexecutable.exe");
psi.Arguments = "Myargument1 Myargument2";
Process.Start(psi);
`
Related
I have a powershell script file called Script1.ps1 And I execute it from a web application in ASP.NET with the following code:
process.StartInfo.FileName = #"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe";
process.StartInfo.Arguments = $"-File \"{ScriptNameOne}\" \"{param1}\" \"{param2}\" \"{param3}\"";
process.StartInfo.UseShellExecute = true;
process.Start();
The problem is when I deploy my web app in IIS the process doesn't start.
I don't get any error, just my powershell doens't run.
the code works fine in my IIS express from visual Studio, because my user in the computer is executing all the process, so I have permissions to every source in the machine.
Important: I need to execute this powershell script LOCALLY IN THE SERVER WHERE THE SITE IS.
I know that is user/permissions Issue, so...
In IIS, which permissions do I need?
What of all IIS users should I use?
Do I need give permissions in the folder where the powershell.exe is?
ASP.NET Web page and server control code executes in the context of the ASP.NET worker process on the Web server. If you use the Start method in an ASP.NET Web page or server control, the new process executes on the Web server with restricted permissions. The process does not start in the same context as the client browser, and does not have access to the user desktop.
Give permission for ASP.NET worker process account
to interact with desktop or allow ASP.NET worker process to run in SYSTEM account.
To know how to allow worker process to run in SYSTEM account and to know the default permissions of ASPNET account, check this article INFO: Process and Request Identity in ASP.NET: http://support.microsoft.com/default.aspx?scid=kb;en-us;317012
Enable IIS Admin Service to interact with desktop
To configure this, follow this steps.
a. Open Control Panel and follow these steps: For Windows NT: click Services. For Windows 2000, Windows XP, and .NET Server: click Administrative Tools, and then click Services.
b. Double-click IIS Admin Service.
c. On the Log On tab, select the Allow Service to Interact with Desktop check box. Remember to run IIS Admin Service as a local system.
d. Stop and restart the IIS Admin Service.
More infor about this question you can refer to this link: https://stackoverflow.com/a/4679686/13336642.
WHAT WORKED FOR ME:
Right click the directory where the .EXE file is and select Properties
Select the Security tab
Click the Edit button and then Add button
Click the Locations button and make sure that you select your computer
Enter IIS AppPool<appoolname> (eg: IIS AppPool\DefaultAppPool)
https://support.pkware.com/home/smar/latest/sem-knowledge-base/kb-granting-folder-permissions-to-iis-application-pools
Hope you can help.
We have a web application (.NET 2.0) that has some custom code that is used to poke a windows service when a file is uploaded. We issue a command using the following code:
Dim serviceName As String = "Processor Service 1.0"
sc = New ServiceController(serviceName)
sc.ExecuteCommand(200)
Running this code in a standalone app works fine but when running through website throws an access denied error. Code works fine in IIS 6.
We are using an application pool with a user and is in Admin group. I figure it's something to do with IIS but now sure what.
Hoping you guys can help.
Thanks
The permissions that are needed to interact with local services are pretty high. Your asp.net app is likely running as anonymous (local account IUSR), or the "application pool identity". You would have setup your app in IIS (app pool) to use a different account with greater permissions.
In IIS Admin, under the section "IIS", "Authentication", you need to enable a stronger authentication method. If "Anonymous Authentication" is the only one enabled, then check the settings "Edit" to see if it is running as IUSR or "Application pool identity". This is where you determine, or set, the account (and permission set) that your ASP.NET app is using.
I feel that I should strongly warn against elevating the permissions for IIS and anonymous users. This would create a very dangerous back-door into your system. The suggestion from bgs264 is a very good one: make a separate service (or scheduled process) that watches for file uploads, or modify the existing service to use the file-watcher to monitor for uploaded files. It could run under a higher permission set and would be much more isolated from your IIS. Granting admin permissions to IIS or its app pools, is just like begging for trouble.
I am attempting to upgrade an existing system from Windows XP Professional / IIS 5.1 to Windows 7 Ultimate (32-bit) / IIS 7.5. The original system ran a classic ASP website (only available to the localhost) that used 'ASPExec' to launch desktop applications on the local machine (.bat, .cmd, .exe, etc). Under Windows 7 Ultimate / IIS 7.5, the applications fail to launch from the ASP page.
As tests (The end goal is not to launch notepad), I have tried:
<%
Set Executor = Server.CreateObject("ASPExec.Execute")
Executor.Application = "notepad.exe"
Executor.ShowWindow = True
strResult = Executor.ExecuteWinApp
%>
I have also tried:
<%
Set wshell = CreateObject("WScript.Shell")
wshell.run "notepad.exe"
Set wshell = Nothing
%>
Both methods will cause notepad.exe to show in the Windows Process list, but fail to launch the application on the desktop. This is true for any .exe I try to run, and .bat or .cmd files simply fail to do anything.
With IIS 5.1, the original author of the ASP application used the "Allow Service to Interact with the Desktop" option on the "IIS Admin" service and "World Wide Web Publishing" service to make this work. All issues aside with allowing desktop interactive services, IIS 7 no longer uses the "IIS Admin" service, so this is not an option.
I am looking for either a workaround from the Windows/IIS side or another option in ASP that might acheive the same desired end result.
You won't be able to do this with Windows 7/IIS 7.5. The reason this worked was because you were running IIS5.1. Back in the days of IIS5.0/5.1 you had three different process models:
In Process (or Low Isolation mode) - where every site ran inside the inetinfo.exe process
Pooled Process - sites ran in an external surrogate process inside COM+
Out of Process (or High Isolation mode) - where each site runs inside it's own COM+ process
Most likely your IIS5.1 instance is configured to run in "In Process" mode and under the SYSTEM account. Because you can configure the IIS service to interact with the desktop, and because your Classic ASP script is being executed inside this process it is able to launch executables and they appear on the desktop.
In IIS7 life is different. Your code will run inside an application pool process which is spun up on demand. There is no way to configure pool processes (w3wp.exe) and allow them to interact with the desktop, even if running under the local system account.
Also unlike IIS6 you can't configure IIS7 to behave as if it's IIS5; IIS7 is a bottom up rewrite with a new architecture.
A possible workaround would be to write a simple WCF service with a HTTP endpoint that starts when the user logs on (hosted in a Windows app that hides or minimises itself to the notification area). You could then make calls to this service from your Classic ASP code using something like MSXML2.ServerXMLHttp and get the WCF service to launch these processes on your behalf.
This archived copy of chapter 29 of Keith Brown's "The .NET Developers Guide to Windows Security" explains the machinations involved in getting a service application to interact with the desktop:
The .NET Developers Guide to Windows Security - chapter 29 - How to Display a User Interface from a Daemon (source: archive.org)
Quote:
Option one is to get yourself into the interactive window station, and
option two is to have a process already in the interactive window
station display a UI for you.
An easy way to put a daemon in the interactive window station
(WinSta0) so it can have its own user interface is to package it as a
service that runs as SYSTEM and check the box that says, "Allow
service to interact with the desktop." This tells the SCM to launch
your service process in the SYSTEM logon session (WhatIsALogonSession)
and to attach your process to WinSta0 instead of the noninteractive
window station in which the SYSTEM daemons normally run,
Service-0x0-0x3e7$.
This is what you probably have already on your XP box. But as I explained, there is no way to configure worker processes to do this because you can't configure the "Allow service to interact with the desktop." flag, even though you can configure a pool to run as the local SYSTEM account. When the book was written this applied to Windows 2000/2003. With the advent of Windows Vista/2008 and onwards you have the added complication of UAC and getting past that as well.
What you should consider instead is option two: Use two processes
instead of just one. One process must be launched in the interactive
user's logon session and WinSta0. It should contain all the user
interface elements you need, and it can connect to your daemon process
using any secure form of interprocess communication you're comfortable
with
This is essentially what I've suggested.
In my Web application I need to open an Autodesk inventor exe on the server. I tried some thing but it is not working while hosting in IIS. Here is my code:
Dim info = New System.Diagnostics.ProcessStartInfo()
info.FileName = "C:\Program Files\Autodesk\Inventor 2013\Bin\Inventor.exe"
info.UseShellExecute = True
Dim process = New System.Diagnostics.Process()
process.StartInfo = info
process.Start()
What is the problem. anyone have any idea?
Before doing anything, that exe file should be runnable by IIS and network accounts.
The problem is probably a permissions thing.
Your IIS/asp.net process doesn't have security access to that folder to execute the app.
Broadly speaking you need to give the permissions to the user so it can execute the app.
First go to the files on your server that are inside a valid website via RDC and right click on them, then go to properties and click Security tab.
You will see some user accounts and permissions. Depending the server setup (dif versions of IIS, running plesk, etc) you might have different names but look for something thats has iis in the name.
You need to then goto the autodesk exe and give the permissions for the account you found so that it can execute it.
I have an ASP.NET application on Windows 2008 R2 (.NET Framework 4.0, IIS 7.5) and I want to run a console application when I click a button on a web page. Here is the code:
protected void btnUpdate_Click(object sender, EventArgs e)
{
string fileLocation = #"D:\DTDocs\App_Code\LoadDTDocsXML.exe";
ProcessStartInfo oStartInfo = new ProcessStartInfo();
oStartInfo.FileName = fileLocation;
oStartInfo.UseShellExecute = false;
Process.Start(oStartInfo);
}
When I run ASP.NET application from within Visual Studio 2010 (with its internal IIS), the console application run Ok. But when I run the ASP.NET application outside the VS 2010, I haven't an error but the console application doesn't make his job (it must create an xml file on the disk).
I think the problem is the configuration of IIS 7.5, I don't know exact to which account I must give access rights to the folders involved in my console application.
In IIS 7.5, I set Physical Path Credential for Specific User = my windows account, but that not solve the problem.
Thanks.
Just to add to the other 2 answers - Do you really need to run an exe from your webserver?
I've had to do it in the past and it's almost always the option of last resort - It weakens your security considerably (Now all someone has to do to run executables on your system is find a single flaw in your code) and has a whole host of other problems (the webserver isn't "logged on" to the server so it doesn't have a desktop, impersonation is a real pain in the a$$ to get working properly (assuming you're going to run the executable with different permissions to the webserver), etc.
If there's any other way to accomplish your goal, it'll almost certainly be simpler.
An option we went for was to have a new app with a WCF endpoint that the webserver can communicate with. So, when someone pushes the button, the WS call's our app via WCF and tells it to run various commands. This way, you've got:
Clean seperation between web and console code.
A dodgy console app won't take down the webserver & vice-versa
If the console app is long-running, this allows you to stagger your releases for website/console app so that you don't kill the app mid-execution just because you need up upodate some CSS and publish.
Huge security benefits - web server can't run executables even if compromised.
The WCF app will be able to closely examine requests to decide if they're valid before execution.
Be aware that however you do it, if someone malicious works out what's going on and can kick off the process, they could probably DoS you with almost zero effort - Make sure that this method is locked down TIGHT.
Edit: having read your comments above, I think you're hitting the "desktop" issue. When launching an executable from the server, the app will never be visible to the logged on user as the logged on user's desktop isn't accessible from IIS and vice-versa. This is very similar to the issue of having a GUI on a windows service.
This may also be of interest.
the first problem I see is security/file access. when running from within VS the server and client are the same machine under your credentials. when run in testing/production environment the server and client are physically different machines and IIS will run the website under restricted permissions. therefore there is a very good chance that IIS cannot access the file at D:... because of security.
the next issue is running a console app from the website. console is another form of UI just like html and a WPF. personally I wouldn't execute the console from the web (unless there was no other choice). I would integrate the API into the web application. 2 UIs sharing the same logic.
ASP.NET Dev Server runs under credentials of current user (it's you).
IIS 7.5 runs ASP.NET applications under user specified in application pool settings -- usually ApplicationPoolIdentity (to which you can refer as user "IIS AppPool\[ApplicationPoolName]", when configuring file permissions). You can also change it to "Network Service" (Default value in IIS 7.0).
Please check, which identity is configured for your application pool, and give this user required permissions.