Impersonation causes a server error

[Phil]

Hi,


I've currently setup a local user as described in:


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnne...



This users has been created on the remote server, and locally on our
web farm servers. All access to NTFS file system has been setup and the

users local privileges. However, when I add the


<identity impersonate="true" userName="YourAccount"
password="YourStrongPassword" />


Code in the web.config file, the website starts behaving in an
unpredictable manner - mainly blowing up with the following error:


Server Error in '/admin' Application.
--------------------------------------------------------------------------------



Cannot execute a program. The command being executed was
"c:\windows\microsoft.net\framework\v1.1.4322\csc.exe" /noconfig
@"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET
Files\admin\1afb246b\8ae84806\pu6rzxdn.cmdline".
Description: An unhandled exception occurred during compilation using
the CodeDomProvider 'Microsoft.CSharp.CSharpCodeProvider'. Please
review the stack trace for more information about the error and where
it originated in the code.


Exception Details: System.Runtime.InteropServices.ExternalException:
Cannot execute a program. The command being executed was
"c:\windows\microsoft.net\framework\v1.1.4322\csc.exe" /noconfig
@"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET
Files\admin\1afb246b\8ae84806\pu6rzxdn.cmdline".


Source Error:


An unhandled exception was generated during the execution of the
current web request. Information regarding the origin and location of
the exception can be identified using the exception stack trace below.


Stack Trace:


[ExternalException (0x10b): Cannot execute a program. The command being

executed was "c:\windows\microsoft.net\framework\v1.1.4322\csc.exe"
/noconfig @"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary
ASP.NET Files\admin\1afb246b\8ae84806\pu6rzxdn.cmdline".]


System.CodeDom.Compiler.Executor.ExecWaitWithCaptureUnimpersonated(IntPtr

userToken, String cmd, String currentDir, TempFileCollection tempFiles,

String& outputName, String& errorName, String trueCmdLine) +2054
System.CodeDom.Compiler.Executor.ExecWaitWithCapture(IntPtr
userToken, String cmd, String currentDir, TempFileCollection tempFiles,

String& outputName, String& errorName, String trueCmdLine) +260
System.CodeDom.Compiler.CodeCompiler.Compile(CompilerParameters
options, String compilerDirectory, String compilerExe, String
arguments, String& outputFile, Int32& nativeReturnValue, String
trueArgs) +383


System.CodeDom.Compiler.CodeCompiler.FromFileBatch(CompilerParameters
options, String[] fileNames) +548
System.CodeDom.Compiler.CodeCompiler.FromDomBatch(CompilerParameters

options, CodeCompileUnit[] ea) +428
System.CodeDom.Compiler.CodeCompiler.FromDom(CompilerParameters
options, CodeCompileUnit e) +90


System.CodeDom.Compiler.CodeCompiler.System.CodeDom.Compiler.ICodeCompiler.CompileAssemblyFromDom(CompilerParameters

options, CodeCompileUnit e) +37
System.Web.Compilation.BaseCompiler.GetCompiledType() +227


--------------------------------------------------------------------------------

Version Information: Microsoft .NET Framework Version:1.1.4322.2300;
ASP.NET Version:1.1.4322.2300


If I remove the impersonation - the site works fine, apart from the
fact I can't read/write to the remote server. I have googled till I'm
blind, anyone any ideas?

Sorry, I have aslo posted this in microsoft.public.dotnet.general but
haven't had any help there...

 

[alantolan]

I had a problem with impersonation that seems similar

1) I set up the web service with no impersonation and ran it... it
worked fine.
2) I turned on the impersonation, using a restricted user and got an
access error on

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET
Files\<my service>\ffc157b7\...

The solution I found was to delete all the temporary files\folders for
the service

i.e.

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET
Files\<my service> and below

and then invoke the service with impersonation turned on.

It then worked fine.


My hypothesis - though I haven't confirmed it - is that if you start
the service without impersonation, the owner of the temp files is
ASPNET. When you turn impersonation on, unless the new account has
enough privileges to read these temp files (say it is in the admin
group) you will get an access error.

If you delete the temp files and start the service/site with
impersonation on, then the owner is the impersonating ID and everything
works fine.


hth,
Alan.

 

[Phil]

Thanks for your solution. I have already granted access to the
temporary asp.net directory to the impersonated user. So they
shouldn't be any issues. but knowing MS there probably is.

Unfortunatley, tried it, but it hasn't solved my problem. Anyone out
there with any other ideas, or better yet - hoe can I write these files
to this remote server in .net NOT using impersonation?

 

[Willy Denoyette [MVP]]

| Thanks for your solution. I have already granted access to the
| temporary asp.net directory to the impersonated user. So they
| shouldn't be any issues. but knowing MS there probably is.
|
| Unfortunatley, tried it, but it hasn't solved my problem. Anyone out
| there with any other ideas, or better yet - hoe can I write these files
| to this remote server in .net NOT using impersonation?
|

According the stacktrace, the problem is that you can't run
"c:\windows\microsoft.net\framework\v1.1.4322\csc.exe" while impersonating,
that means that the impersonated account has not "execute rights" for
csc.exe.

Note that impersonating at this level is a bad thing, you should inpersonate
in code, or better run this outside your web application, for instance in an
out-proc COM+ server application that runs with a fixed identity.

Willy.

 

[Phil]

Willy,

Thanks, I understand the risks invovled but just need to get this
working in test. I read the error message to mean the same. The problem
is the impersonation account has access to read & execute in the
c:\windows\microsoft.net\framework\v1.1.4322\ folder.

This is why it doesn't make sense. Also I only get this error after
writing to the shared drive, which works. Anyone else any pointers.
(whilst I've been away I've also coded the impersonation, and that
isn't working either!).

 

[Willy Denoyette [MVP]]

| Willy,
|
| Thanks, I understand the risks invovled but just need to get this
| working in test. I read the error message to mean the same. The problem
| is the impersonation account has access to read & execute in the
| c:\windows\microsoft.net\framework\v1.1.4322\ folder.
|
| This is why it doesn't make sense. Also I only get this error after
| writing to the shared drive, which works. Anyone else any pointers.
| (whilst I've been away I've also coded the impersonation, and that
| isn't working either!).
|

What's the asp.net process identity? The CSC command is run by the worker
process, not by the impersonated client.


Willy.

 

[Phil]

Thanks again Willy, I don't know how to check what the asp.net process
identity is. How do I find out?

 

[Willy Denoyette [MVP]]

| Thanks again Willy, I don't know how to check what the asp.net process
| identity is. How do I find out?
|

Hmmmm, if you don't know it, it's probably because you never changed the
default, in that case I must be wrong, in that the CSC command doesn't run
under the process identity, but uses the impersonated identity to execute
CSC [1].

Anyway, it's defined in your machine.config file (note this is only for W2K
and XP) in the section processModel (look under Framework\v1.1.4322\CONFIG
for the file).
In this section you'll find userName attribute, possible values are:
- machine which defaults to "aspnet" for W2K and XP
- SYSTEM stands for "localsystem" or "SYSTEM"
- or a windows user name. (local or domain).


On W2K3 the default worker process identity is "network user"

[1] Try to enable "file access auditing" on the framework directory path,
that way you will get a message in the security event log telling exactly
which user fails to access this directory.

Willy.

 

[Phil]

Willy,

userName="machine"

Is in my machine.config.

I've enabled logging I think on NETWORK, NETWORK SERVICE, ASP.NET,
Internet User Account and my imperonsated user. I've caused the
program to fall over, and there's nothing in the security logs
(assuming you mean, Computer Management>System Tools>Event
Viewer>Security).

 

[Phil]

Willy,

Some more information. The error in accessing csc only happens after a
files has been written to the sharded directory. Until then the .net
application works fine runnin under the impersontation.

After writing to the shared folder, every application running under IIS
starts to error showing the same error page - even .net applications
that aren't using impersonation.

The servers are all being hosted by a third party, there is no domain
(all machnies are under the WORKGROUP, workgroup). I have setup
duplicate local users one each machine with the same username and
password.

I really think I've found a bug in .net 1.1, should I raise a MS
support ticket?

 

[Willy Denoyette [MVP]]

| Willy,
|
| Some more information. The error in accessing csc only happens after a
| files has been written to the sharded directory. Until then the .net
| application works fine runnin under the impersontation.
|
| After writing to the shared folder, every application running under IIS
| starts to error showing the same error page - even .net applications
| that aren't using impersonation.
|
| The servers are all being hosted by a third party, there is no domain
| (all machnies are under the WORKGROUP, workgroup). I have setup
| duplicate local users one each machine with the same username and
| password.
|
| I really think I've found a bug in .net 1.1, should I raise a MS
| support ticket?
|

IMO this is not a bug, if I understand you correctly, it means that
everything is fine until some-one writes new data to the share, right? Does
it also mean that all existing CS files aren't accessible any longer? Who is
the user writing to this share? Have you checked the security privileges
before and after a write of a new file, somehow these must have changed.
I'm also not clear on how you did set you "duplicate users", your asp.net
worker process runs as "aspnet" (as per your previous posting), this is a
local machine account (automatcally created) and CANNOT be duplicated, so I
wonder how/what you did! Note that this is the account running CSC, so I'm
affraid you messed with the configuration settings of your web server.

Willy.

 

[Phil]

Thanks Willy for getting back to me.

The duplicated account is the impersonation account. This account has
the access to read/write to the share. This account is setup on both
our webservers, and on the server with the shared folder that we are
writing too.

I haven't changed any settings on the webserver apart from giving this
impersonation account the access specified in the MSDN article. (Things
like read/write access to the .net temporary folders, read access to
the assembly folder, etc).

How can writing to a shared folder in one .net application, have the
impact that all other .net applications running then start to fail? I
have double checked the access, and as I say, everything works fine
under impersonation - until the point of writing the file (which does
work so authority to write to the share folder is being given by
windows 2003).

I don't think anyone can solve this problem, so I'm now looking to
setup real-time synchronisation between our web servers, so that files
created on one are accessible to the other.

From all my googling - it looks like I'm the only one in the world

with the issue.