IIS5/XP/aspnet_wp, changing user

  • Thread starter Thread starter Mark
  • Start date Start date
M

Mark

This has been driving me absolutely mad. I've been googling for 6 hours and
all I've found are useless or incorrect answers ("Why don't you use IIS 6?"
is not an answer though it seem to be the most prevalent response)

I have a .aspx page on a controlled website in the above environment. It
wants to launch a bat file in background. I found one post that said, by
default, aspnet_wp.exe runs under the ASPNET account and can't run anything
that requires user impersonation. It suggested changing the use to the
NETWORK SERVICE account. Sounds easy, right?

That's what's started the 6 hours of googling. I have yet to find one
reference that says how to do it. All you get are fragmentary allusions at
best and often a lot of flat-out wrong advice.

I've run aspnet_regiis -ga on the network service account. It said it was
successful anyway.

I've tried changing machine.config
<system.web>...
<processModel autoConfig="true"/>

to
<processModel autoConfig="true" userName="NETWORKSERVICE" password="" />
<processModel autoConfig="true" userName="NETWORK SERVICE" password="" />
<processModel autoConfig="true" userName="NT AUTHORITY\NETWORK SERVICE"
password="" />

and a few others but all I ever get is errors in the event log saying
aspnet_wp.exe couldn't be launched because the username and password are
wrong (seemed to work for aspnet_regiis, though).

I tried some of the other suggestions, namely setting web.config
<system.web>
<identity impersonate="true" userName="NETWORKSERVICE" password=""/>

aspnet_wp.exe launches but then the says it can't use the credentials.

I don't have a choice about OS or IIS versions. How *DOES* one get
aspnet_wp.exe running under the network service account?

Thanks
Mark
 
Okay, I found that just putting <identity impersonate="true" userName="some
real user acct" password="user's password"/> magically gets aspnet_wp.exe to
run in the NETWORKSERVICE account.

Unfortunately, it seems that the original thread I found was wrong. Simply
running under NETWORKSERVICE doesn't stop "The application failed to
initialize properly (0xc0000142)" error.

My asp.net code is trying to launch either a .bat file or a free-standing
executable. Here's how I'm setting it up:
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName = "cmd.exe"; // can also be a different .exe
startInfo.RedirectStandardOutput = true;
startInfo.RedirectStandardInput = true;
startInfo.RedirectStandardError = true;
startInfo.Arguments = "/S /C " +
Path.GetFullPath(Environment.ExpandEnvironmentVariables(parent.GetAttribute("buildScript")));
startInfo.StandardErrorEncoding = Encoding.UTF8;
startInfo.StandardOutputEncoding = Encoding.UTF8;
startInfo.CreateNoWindow = true;
startInfo.UseShellExecute = false;
startInfo.UserName = user;
System.Security.SecureString ss = new System.Security.SecureString();
foreach (char c in pass) ss.AppendChar(c);
startInfo.Password = ss;
startInfo.Domain = domain;

Process cmdProc = Process.Start(startInfo);

On the last line, trying to start the process, it throws "The application
failed to initialize properly (0xc0000142)" errors.

Several threads I found implied that it was an issue with the ASPNET account
not allowing any credential impersonation. They recommended running under
NETWORKSERVICE instead. Now it appears I am, but I've still got the launch
problem...

Any ideas?

Thanks
Mark
 
This has been driving me absolutely mad. I've been googling for 6
hours and all I've found are useless or incorrect answers ("Why don't
you use IIS 6?" is not an answer though it seem to be the most
prevalent response)

I have a .aspx page on a controlled website in the above environment.
It wants to launch a bat file in background. I found one post that
said, by default, aspnet_wp.exe runs under the ASPNET account and
can't run anything that requires user impersonation. It suggested
changing the use to the NETWORK SERVICE account. Sounds easy, right?

SNIP
Click to expand...

Let's step back a moment and answer the "why" question first. Why do you
want to run under network service?

You are experiencing some problem that can probably be solved in some
way other than switching ASP.NET worker accounts (which has a huge
impact on more than just security). I understand IIS6+ run under NETWORK
SERVICE, and it seems like making IIS5 like IIS6 by changing the worker
process account will solve it, but you are probably having a security
issue you are attempting to solve that can be solved in a more secure,
and less problematic, way.

What is the root problem you are trying to solve?


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
Hi Greg...

I have an authenticated web page that wants to launch a couple of programs
(one bat file and one .exe) for authenticated users when they click a link.
The main thing is that the programs have to run under a single, specific
user's credentials.

So I wrote the program as shown in my follow-up post (ProcessStartInfo being
set as it was in there, setting .UserName, .Password, and .Domain to the
credentials it has to run under).

When the web page gets run and a user clicks on the link, it tries to launch
the process, but as soon as Process.Start() gets called, it blows up with

"The application failed to initialize properly (0xc0000142)"

Not a lot to go on, but after a lot of googling, I found a thread asserting
that it was because in the default configuration asp.net, for security
reasons, doesn't allow credentials to be impersonated. This post said that
running under NETWORK SERVICE would/should fix the problem.

That started a very long search, trying to figure out how to get
aspnet_wp.exe to run under NETWORK SERVICE... Lots of threads just flat out
wrong, incomplete, or misleading. Finally got aspnet_wp.exe to run as
NETWORK SERVICE more or less by accident. I used <identity
impersonate="true" userName="some other user" password="user pass" />. That
way I discovered that when you have impersonate="true", aspnet_wp.exe
magically runs under NETWORK SERVICE instead.

Problem is that didn't fix my ProcessStartInfo.UserName problem so I'm back
at square one.

Thanks
Mark
 
Hi Greg...

I have an authenticated web page that wants to launch a couple of
programs (one bat file and one .exe) for authenticated users when they
click a link. The main thing is that the programs have to run under a
single, specific user's credentials.

So I wrote the program as shown in my follow-up post (ProcessStartInfo
being set as it was in there, setting .UserName, .Password, and
.Domain to the credentials it has to run under).

When the web page gets run and a user clicks on the link, it tries to
launch the process, but as soon as Process.Start() gets called, it
blows up with

"The application failed to initialize properly (0xc0000142)"

Not a lot to go on, but after a lot of googling, I found a thread
asserting that it was because in the default configuration asp.net,
for security reasons, doesn't allow credentials to be impersonated.
This post said that running under NETWORK SERVICE would/should fix the
problem.

That started a very long search, trying to figure out how to get
aspnet_wp.exe to run under NETWORK SERVICE... Lots of threads just
flat out wrong, incomplete, or misleading. Finally got aspnet_wp.exe
to run as NETWORK SERVICE more or less by accident. I used <identity
impersonate="true" userName="some other user" password="user pass" />.
That way I discovered that when you have impersonate="true",
aspnet_wp.exe magically runs under NETWORK SERVICE instead.

Problem is that didn't fix my ProcessStartInfo.UserName problem so I'm
back at square one.

Thanks
Mark
Click to expand...

If this is a domain user account, the following will work:

http://www.developerfusion.com/code/5679/start-a-process-as-a-different-
user/

With ASP.NET calling the process, you might have to wrap the code in a
windows service or something (very thin wrapper). If I get a sec, I will
see if I can't check if you can fire a process off from ASP.NET.

NOTE also that an executable outside of the IIS tree (any directories
controlled by an application in IIS), you end up with strong security
implications that windows fights you on.

But, with a windows service, you should be able to fire it up. To
communicate with the Windows Service (if you have to go this route), you
can set up a service front end (like WCF) and call into the running
service.

Hope this helps!


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
Hi Greg...

I looked at that link, and essentially that's what I'm currently doing (only
with ProcessStartInfo instead of Process.Start(file, user,pass, domain).

The things I'm trying to run *are* indeed outside the IIS tree, and that may
be causing a lot of my trouble.

I wonder - would it be easy enough to fake out by creating a little bat file
*in* my iis tree that simply takes a command line to run something elsewhere?

In other words have a little bat file to the effect of
cmd /S /C %*

and then run that?

Thanks
Mark
 
Turns out the dummy.bat in the iis tree didn't help. Still blew up.

Seems to be the biggest hassle is trying to use impersonation from the
ProcessStartInfo level. If I comment out those lines, it'll let me run a
command or a bat file in or out of the IIS tree.

If I set web.config <identity impersonate="true" userName="foo"
password="bar" /> to effect the right impersonation I can probably get what I
want... Or maybe move the impersonation into some of the exe's (since we
wrote those too).

Still can't figure out how to get impersonation to work with spawning the
command though...

Thanks
Mark
 
Hi Greg...

I looked at that link, and essentially that's what I'm currently doing
(only with ProcessStartInfo instead of Process.Start(file, user,pass,
domain).

The things I'm trying to run *are* indeed outside the IIS tree, and
that may be causing a lot of my trouble.

I wonder - would it be easy enough to fake out by creating a little
bat file *in* my iis tree that simply takes a command line to run
something elsewhere?

In other words have a little bat file to the effect of
cmd /S /C %*
Click to expand...

I am not sure if that will work or not, but one possibility, if you go
that route, is to make the executable so it can be run by the ASP.NET
account. Even outside the tree, the bat might work, so I am not ruling
it out. Have never tried that route.

One other possibility is to "include" the directory in question in your
tree by adding a virtual directory. Watch this idea carefully, however,
as it can expose you to some security risks. You still have to make sure
the ASP.NET account (account ASP.NET running under, which is Network
service in newer versions of IIS) can run it (or the logged in users if
you are using Windows authentication).

Another creative way of getting around security is have SQL Server run
the code, but I would not suggest this kludge simply to run executables,
as it impacts SQL Server for nothing (unless you are doing data stuff).


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
Turns out the dummy.bat in the iis tree didn't help. Still blew up.

Seems to be the biggest hassle is trying to use impersonation from the
ProcessStartInfo level. If I comment out those lines, it'll let me
run a command or a bat file in or out of the IIS tree.

If I set web.config <identity impersonate="true" userName="foo"
password="bar" /> to effect the right impersonation I can probably get
what I want... Or maybe move the impersonation into some of the exe's
(since we wrote those too).

Still can't figure out how to get impersonation to work with spawning
the command though...
Click to expand...

I will have to think about this more. A windows service that is called
through a WCF service is still the option I come back to, as the service
could run under any account.


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
Alas we're not a 3.+ shop... We're still stuck on .net 2.0.

I figured out that I could nearly get there by taking my command and using
RUNAS.exe, but the problem I'm running into right now is that RUNAS launches
a new window, the service needs to have "can interact with desktop" checked.
I checked it on w3svc, but it didn't help. Don't know if there's even an
option to enable that on aspnet_wp.exe; it's a background process but not a
service...

Thanks
Mark
 
Hi Mark,
I figured out that I could nearly get there by taking my command and using
RUNAS.exe, but the problem I'm running into right now is that RUNAS launches
a new window, the service needs to have "can interact with desktop" checked.
I checked it on w3svc, but it didn't help. Don't know if there's even an
option to enable that on aspnet_wp.exe; it's a background process but not a
service...
Click to expand...

Please try following ways to see if it can work:

Option1:

Please open services, find "IIS Admin", click the "Log on" tab, check
"Allow service to interact with desktop". Restart "IIS Admin". View your
page to start cmd.

Option2:
ASPNET is not an interactively logged on user so the child process cannot
access the desktop. An alternative solution would be to use LogonUser,
CreateProcessAsUser(), and explicitly setting permissions on the desktop
and window station. This solution can be implemented in both unmanaged code
and managed code through Pinvoke. Please see
http://support.microsoft.com/default.aspx?scid=kb;EN-US;165194 for
information on how to do this.
For more details about the cause, please refer to the following section:
Desktop Security
------------------------
When a user logs onto the computer interactively (such as going through the
logon
screen), the user's token will have a logon SID that is unique to that
logon
session. This SID is added to the DACL on the interactive desktop to give
all
his/her applications full access to the desktop and Windows shell features.
This
desktop is named "winsta0\default". [When the user logs off, this SID is
removed
from the interactive desktop.] Since all processes that this user runs have
this
logon SID in the token, they get access to the interactive desktop.

Services running in user accounts are given separate non-visible window
stations
desktops. The DACL on these desktop objects do not have any logon SIDs.
Instead,
each is secured by the user account SID of the service process and partial
access
given to the local Administrators group.
CreateProcessWithLogonW Behavior

----------------------------------------------------
The original intention behind CreateProcessWithLogonW was to allow an
interactive
application, such as runas.exe, to be able to launch another interactive
application as a different user as long as the caller knew the user name
and
password for that other user.

When a process is launched with CreateProcessWithLogonW, the desktop it
receives
depends on the desktop name specified in the lpDesktop member of the
STARTUPINFO
parameter. If lpDesktop is set to NULL or "", CreateProcessWithLogonW gives
the
child process the same desktop as the parent process. Since the child
process is
run as a different user than the parent process, it needs acess to the
parent's
desktop or else it will fail to run. CreateProcessWithLogonW internally
gets the
logon SID from the parent process's token and adds it to the child
process's
token.

Called by Interactive Applications
----------------------------------------------
CreateProcessWithLogonW works as expected when the parent process is an
application
running on the interactive desktop because the desktop's DACL has the
parent
process's logon SID and that SID is present in the child process's token.
The
child process runs with the same access to the desktop as the parent.
Called by the Services in the Local System Account
-------------------------------------------------------------
CreateProcessWithLogonW fails when the parent process is a service running
in a
user account and the child process is being spawned in a different account.
This
is because the desktop of the service is secured by the user SID of the
service's
account, but the child process has a different user SID. However, if the
service
launchs the child process in the same user account as itself, then it willl
work
beause the child process's SID is identical to the parent's and matches the
desktop's permissions.


Regards,
Allen Chen
Microsoft Online Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Allen...

Thank you for your suggestions; they gave me a bunch of new things to try.
Unfortunately none of them worked.

I had tried option 1 before and while IIS can interact with the desktop it
doesn't seem that aspnet_wp.exe can.

As to the next suggestions,
I first tried an example using LogonUser and WindowsIdentity.Impersonate().
ProcMon showed that the process that got spawned was still NETWORK SERVICE,
even though the logon and impersonate calls were successful.

Then I tried using LogonUser/WindowsIdentity.Impersonate() and
ProcessStartInfo.UserName, etc, etc. When I did this, the "The application
failed to
initialize properly (0xc0000142)" error returned.

Then I tried the sample code you pointed me to in your response.

LaunchCommand1 (using CreateProcessWithLogonW) generates the same "The
application failed to
initialize properly (0xc0000142)" error.

LaunchCommand2 (using LogonUser and CreateProcessAsUser) creates a process,
though ProcMon still says that process is under user NETWORK SERVICE. What
was different with this one is that the command being run generates a crash
notice. I tried using Image File Execution Options to catch it in a
debugger, but while the debugger attached it didn't run.

So 5 new methods and I still can't get aspnet_wp.exe to launch a new process
as another user. This security model is strict! :)

Thanks
Mark



Allen Chen said:
Hi Mark,
I figured out that I could nearly get there by taking my command and using
RUNAS.exe, but the problem I'm running into right now is that RUNAS launches
a new window, the service needs to have "can interact with desktop" checked.
I checked it on w3svc, but it didn't help. Don't know if there's even an
option to enable that on aspnet_wp.exe; it's a background process but not a
service...
Click to expand...

Please try following ways to see if it can work:

Option1:

Please open services, find "IIS Admin", click the "Log on" tab, check
"Allow service to interact with desktop". Restart "IIS Admin". View your
page to start cmd.

Option2:
ASPNET is not an interactively logged on user so the child process cannot
access the desktop. An alternative solution would be to use LogonUser,
CreateProcessAsUser(), and explicitly setting permissions on the desktop
and window station. This solution can be implemented in both unmanaged code
and managed code through Pinvoke. Please see
http://support.microsoft.com/default.aspx?scid=kb;EN-US;165194 for
information on how to do this.
For more details about the cause, please refer to the following section:
Desktop Security
------------------------
When a user logs onto the computer interactively (such as going through the
logon
screen), the user's token will have a logon SID that is unique to that
logon
session. This SID is added to the DACL on the interactive desktop to give
all
his/her applications full access to the desktop and Windows shell features.
This
desktop is named "winsta0\default". [When the user logs off, this SID is
removed
from the interactive desktop.] Since all processes that this user runs have
this
logon SID in the token, they get access to the interactive desktop.

Services running in user accounts are given separate non-visible window
stations
desktops. The DACL on these desktop objects do not have any logon SIDs.
Instead,
each is secured by the user account SID of the service process and partial
access
given to the local Administrators group.
CreateProcessWithLogonW Behavior

----------------------------------------------------
The original intention behind CreateProcessWithLogonW was to allow an
interactive
application, such as runas.exe, to be able to launch another interactive
application as a different user as long as the caller knew the user name
and
password for that other user.

When a process is launched with CreateProcessWithLogonW, the desktop it
receives
depends on the desktop name specified in the lpDesktop member of the
STARTUPINFO
parameter. If lpDesktop is set to NULL or "", CreateProcessWithLogonW gives
the
child process the same desktop as the parent process. Since the child
process is
run as a different user than the parent process, it needs acess to the
parent's
desktop or else it will fail to run. CreateProcessWithLogonW internally
gets the
logon SID from the parent process's token and adds it to the child
process's
token.

Called by Interactive Applications
----------------------------------------------
CreateProcessWithLogonW works as expected when the parent process is an
application
running on the interactive desktop because the desktop's DACL has the
parent
process's logon SID and that SID is present in the child process's token.
The
child process runs with the same access to the desktop as the parent.
Called by the Services in the Local System Account
-------------------------------------------------------------
CreateProcessWithLogonW fails when the parent process is a service running
in a
user account and the child process is being spawned in a different account.
This
is because the desktop of the service is secured by the user SID of the
service's
account, but the child process has a different user SID. However, if the
service
launchs the child process in the same user account as itself, then it willl
work
beause the child process's SID is identical to the parent's and matches the
desktop's permissions.


Regards,
Allen Chen
Microsoft Online Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Click to expand...
 
Hi Mark,

Thanks for your update.
Thank you for your suggestions; they gave me a bunch of new things to try.
Click to expand...
Unfortunately none of them worked.
Click to expand...
I had tried option 1 before and while IIS can interact with the desktop it
doesn't seem that aspnet_wp.exe can.
Click to expand...

I've tried this means on a Windows XP SP3 machine. It works fine after
checking "Allow service to interact with desktop" option of the "IIS Admin"
service. This option should work for IIS 5.1.
Could you try again?

As to option 2 it needs ASP.NET process running as LocalSystem. In IIS 7 we
can set LocalSystem as the identity of an Application Pool. So the second
option should also work for IIS 7. Please note we need to use P/Invoke to
do this. For more details about P/Invoke please refer to:

http://msdn.microsoft.com/en-us/library/aa446536.aspx

We also have a new project that introduces how to use Microsoft development
technologies such as P/Invoke:

http://cfx.codeplex.com/

To learn how to use P/Invoke, please open CodeFx 2008 - Library.sln
And have a look at these projects:

CppDllExport
CSPInvokeDll

Regards,
Allen Chen
Microsoft Online Support
 
Hi Allen...

I emailed you the asp.net page I've been talking about yesterday; I don't
know if you've received it.

I also managed to scare up a W2k3 box so I could try it under IIS 6.
Interestingly I get a different set of symptoms but still no success.

Under IIS 6, with the Default App pool set to run under NETWORK SERVICE,
1) LogonUser returns false, even with valid credentials;
Marshal.GetLastWin32Error() returns 0.

2) *But* ProcessStartInfo.UserName, Domain, and Password successfully get a
process launched under the new user credentials.

3) Unfortunately, that process just hangs indefintely and never completes.
Originally, I had it with
FileName = "MyProgram.exe"
Arguments= " 2>&1 > C:\LogDir\MyLogfile.log"

No output file got created and the process hung. I thought maybe processes
spawned with Process.Start(ProcessStartInfo) with
UseShellExecute = false and
CreateNoWindow = true

might have trouble interpreting the io redirects, so I changed it to

FileName = "cmd.exe"
Arguments="/S /C MyProgram.exe 2>&1 > C:\LogDir\MyLogfile.log"

Still no output file, still process hanging. So I tried

FileName = "cmd.exe"
Arguments="/S /C MyProgram.exe 2>&1"
RedirectStandardOutput = true
....
string output = Process.StandardOutputStream.ReadToEnd();

The spawned process still hung. It got launched with the right creds; it
just doesn't do anything.

Before the cmd.exe /S /C experiments I tried attaching a debugger to the
hung process but it was hung in some low-level code in ntdll.dll.

Two steps forward, one and a half steps back...

Thanks
Mark
 
Hi Mark,
Before the cmd.exe /S /C experiments I tried attaching a debugger to the
hung process but it was hung in some low-level code in ntdll.dll.
Click to expand...
Two steps forward, one and a half steps back...
Click to expand...


Please check if Network Service has write permission to MyLogfile.log file.

Also try to use LocalSystem account instead:

http://technet.microsoft.com/en-us/library/cc739233(WS.10).aspx

I've tried it on IIS 7. It works on my side when running app pool as
LocalSystem. The dll I used:

http://cid-2fa13ebc6cc8e80f.skydrive.live.com/self.aspx/Public/MyDLL2.zip?cc
r=7266

Regards,
Allen Chen
Microsoft Online Support
 
Hi Allen...

In Task Manager, I can see that the creds are actually for the impersonated
user on the new process, so wouldn't it be whether the impersonated user can
write to the log file? The answer to that is yes.

The spawned process also just hangs even when I redirect the io and have the
parent process try to listen to it (no file permissions at all)...

Thanks
Mark
 
Hi Mark,
The spawned process also just hangs even when I redirect the io and have the
parent process try to listen to it (no file permissions at all)...
Click to expand...

Could you use P/Invoke to use the following unmanaged dll to see if it
works?
http://cid-2fa13ebc6cc8e80f.skydrive.live.com/self.aspx/Public/MyDLL2.zip?cc
r=7266

Try to use LocalSystem account for IIS 6:
http://technet.microsoft.com/en-us/library/cc739233(WS.10).aspx

Don't use impersonate.

Create a new Web Application project, put the dll in the bin folder of Web
Application project. The code to call it is as below:

[SuppressUnmanagedCodeSecurity]
class NativeMethod
{
[DllImport("MyDLL2.dll", CharSet = CharSet.Auto)]
public static extern int HelloWorld(string username,string domain,
string password, string appname, string commandline);

}

protected void Page_Load(object sender, EventArgs e)
{
//create a new user account on your machine.
//user name is "test", password is "Password01!"
//TestApp.exe is a managed concole application:
//static void Main(string[] args)
// {
// File.WriteAllText("C:\\log\\testlog.txt",
DateTime.Now.ToString());
// }
//Create a folder called log under C:\. After that, test the project.

int i = NativeMethod.HelloWorld("test", null, "Password01!",
"cmd.exe", "/C \"C:\\TestApp.exe\"");
Response.Write(i);
}

Regards,
Allen Chen
Microsoft Online Support
 
Hi Allen...

Thank you for your suggestion. I downloaded the code for that dll.

I did drop it in the website/bin directory, but
[DllImport("MyDLL2.dll", CharSet = CharSet.Auto)]
didn't work.; I had to completely qualify the file path.

First I tried it with the w3wp process running as NETWORK SERVICE. Running
that way, the call to the dll failed on the OpenWindowStation() call.

Changing the identity for the w3wp process to LOCAL SYSTEM (despite the
warnings not to do that) call calling MyDLL2.dll did work however; I was
successfully able to run a process from ASP.NET

I went back and tried Process.Start(ProcessInfo) with impersonation while
running as LOCAL SYSTEM, and that threw an Access Denied error.

Thanks
Mark

Allen Chen said:
Hi Mark,
The spawned process also just hangs even when I redirect the io and have the
parent process try to listen to it (no file permissions at all)...
Click to expand...

Could you use P/Invoke to use the following unmanaged dll to see if it
works?
http://cid-2fa13ebc6cc8e80f.skydrive.live.com/self.aspx/Public/MyDLL2.zip?cc
r=7266

Try to use LocalSystem account for IIS 6:
http://technet.microsoft.com/en-us/library/cc739233(WS.10).aspx

Don't use impersonate.

Create a new Web Application project, put the dll in the bin folder of Web
Application project. The code to call it is as below:

[SuppressUnmanagedCodeSecurity]
class NativeMethod
{
[DllImport("MyDLL2.dll", CharSet = CharSet.Auto)]
public static extern int HelloWorld(string username,string domain,
string password, string appname, string commandline);

}

protected void Page_Load(object sender, EventArgs e)
{
//create a new user account on your machine.
//user name is "test", password is "Password01!"
//TestApp.exe is a managed concole application:
//static void Main(string[] args)
// {
// File.WriteAllText("C:\\log\\testlog.txt",
DateTime.Now.ToString());
// }
//Create a folder called log under C:\. After that, test the project.

int i = NativeMethod.HelloWorld("test", null, "Password01!",
"cmd.exe", "/C \"C:\\TestApp.exe\"");
Response.Write(i);
}

Regards,
Allen Chen
Microsoft Online Support
Click to expand...
 
Hi Mark,
Changing the identity for the w3wp process to LOCAL SYSTEM (despite the
warnings not to do that) call calling MyDLL2.dll did work however; I was
successfully able to run a process from ASP.NET
Click to expand...

Glad to know it works. Do you have further questions?

Regards,
Allen Chen
Microsoft Online Support
 
You seemed to imply that <website>/bin should automatically be on the PATH to
find the dll, but it didn't seem to be the case. I know that ASP.Net finds
any .net dlls in /bin. Is that different for bringing in unmanaged dlls?

I'm also curious why the standard framework mechanisms and even pinvoke to
unmanaged code failed so badly when tried from inside ASP.Net in so many
different ways but it's probably beyond the scope of the forum to get to the
bottom of it.

Thanks for your help

Mark
 
Back
Top