Web application uses old style ASP pages at the front, and a vb.net 2005 DLL at the backend.
The IIS web is setup with Integrated authentication, and Anonymous is turned off.
One option in the app involves running through the shell command a .NET EXE. That .NET EXE attempts to do some WMI stuff but it doesn't have the permissions to do that. The Shell command is inside the vb.net 2005 DLL. I log into the browser as Administrator, and the winapi username shows up correctly as administrator in debug sessions.
So why doesn't my shelled application have all the permissions that administrator has
------------------------------ more info..
ASP Page >
x = createobject("mydll.myclass")
c = x.shellthatEXE ()
In MyDLL.MyClass:
Shell(sExe, AppWinStyle.MinimizedNoFocus, False)
Inside the EXE
dim x as system.management.managementscope
....
x.Connect ' fails with permissions problems
The exe runs OK, but the WMI bits within the exe bomb out with a permission denied exception. The exe runs fine when I run it from windows explorer, including the wmi parts.
Logically this must be because the IIS process is probably in the INTRANET zone, so anything it spawns will also be in the same zone. How can I call "shell" or "Process.Start", or some other api/framework method, in a way that launches the EXE in the local machine zone
Permissions problem running from IIS
keroed1
Thanks for replying. This is ASP - not ASP.NET
What I really need to do is launch the process outside of its current zone. I don't want to promote the main IIS process to a lower security level as that could be a genuine risk. I just want this one piece of code to be able to shell in a different security context.
There is a securitypermission object and the msdn documentation on .net framework Shell command actually refers to it as a way of doing this, but there's no examples out there on how to use it.
Bbeilam
You shouldn't need to debug to capture the exception details. For example, you should be able to write to a previously registered event log source or a file on which you've granted appropriate permissions to the run context account.
WRT to the IWAM_machinename account, if your application requires high privilege to run, failure under this account obviously shouldn't be too surprising. If you've configured your IIS application to run in high isolation, it will actually run as a COM+ application under the IWAM_machinename account context. You can change the identity account for the application using the Component Services MMC. Of course, configuring the application to run under a high privilege account carries its own set of risks...
TheDevilsJoker
I need to find out how to debug it to capture the exception. I can put a STOP statement in the code and compile it, but because the exe is created through compiler services, it doesn't have a vbp file. I have the .vb file in the same folder as the exe, but when the debugger attaches to it and I open that vb file, it doesn't seem to be able to recognise the vb file as being associated with the exe.
Any idea The program is running under IWAM_MACHINENAME so that explains half of it.
I can't even write the exception detail to a file or registry because the process doesnt have permissions, so debugger seems to be the only way
RyanH314
Hi,
Unless you use impersonation, your website will use ASPNET account to access the resources (if IIS 5), on IIS 6 it will use the user that you have selected on you application pool.
Options:
1) IIS5 : Give permissions to the ASPNET user
2) IIS6: Create an application pool with a special user that has the permissions
3) Change the web.config/machine.config to use impersonation, to use the user from the website.
Regards
smargroth
No, it's a direct consequence of the configuration of the COM+application that is hosting your high-isolation IIS application. For some additional background information and techniques for dealing with the impersonation consequences, see http://www.microsoft.com/msj/1199/security/security1199.aspx and http://support.microsoft.com/kb/248187/.
gcox18
Could you please provide the full exception details (including call stack listing), as returned by its ToString method
John Shiangoli
It is running High(isolated), and its under Integrated Authentication in IIS (must be working because its connecting to sql ok as well)
This is interesting. I changed both the calling DLL and the resultant EXE to print the current username using winapi GetUserName() in advapi - the calling DLL is running under administrator (my credentials), but the shelled exe process is running under IWAM
This must be some kind of IIS protection thing
So what I really want is some way of launching it under the same credentials as the IIS launching process.
I've made a start with using
System.Diagnostics.Process.Start
but whatever I seem to do it gives me "Access Denied"