Impersonation causes a server error

[Phil]

Hi,
I've currently setup a local user as described in:
http://msdn.microsoft.com/library/de...ary/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="tr ue" userName="YourA ccount"
password="YourS trongPassword" />
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\mic rosoft.net\fram ework\v1.1.4322 \csc.exe" /noconfig
@"C:\WINDOWS\Mi crosoft.NET\Fra mework\v1.1.432 2\Temporary ASP.NET
Files\admin\1af b246b\8ae84806\ pu6rzxdn.cmdlin e".
Description: An unhandled exception occurred during compilation using
the CodeDomProvider 'Microsoft.CSha rp.CSharpCodePr ovider'. Please
review the stack trace for more information about the error and where
it originated in the code.
Exception Details: System.Runtime. InteropServices .ExternalExcept ion:
Cannot execute a program. The command being executed was
"c:\windows\mic rosoft.net\fram ework\v1.1.4322 \csc.exe" /noconfig
@"C:\WINDOWS\Mi crosoft.NET\Fra mework\v1.1.432 2\Temporary ASP.NET
Files\admin\1af b246b\8ae84806\ pu6rzxdn.cmdlin e".
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:
[ExternalExcepti on (0x10b): Cannot execute a program. The command being

executed was "c:\windows\mic rosoft.net\fram ework\v1.1.4322 \csc.exe"
/noconfig @"C:\WINDOWS\Mi crosoft.NET\Fra mework\v1.1.432 2\Temporary
ASP.NET Files\admin\1af b246b\8ae84806\ pu6rzxdn.cmdlin e".]
System.CodeDom. Compiler.Execut or.ExecWaitWith CaptureUnimpers onated(IntPtr

userToken, String cmd, String currentDir, TempFileCollect ion tempFiles,

String& outputName, String& errorName, String trueCmdLine) +2054
System.CodeDom. Compiler.Execut or.ExecWaitWith Capture(IntPtr
userToken, String cmd, String currentDir, TempFileCollect ion tempFiles,

String& outputName, String& errorName, String trueCmdLine) +260
System.CodeDom. Compiler.CodeCo mpiler.Compile( CompilerParamet ers
options, String compilerDirecto ry, String compilerExe, String
arguments, String& outputFile, Int32& nativeReturnVal ue, String
trueArgs) +383
System.CodeDom. Compiler.CodeCo mpiler.FromFile Batch(CompilerP arameters
options, String[] fileNames) +548
System.CodeDom. Compiler.CodeCo mpiler.FromDomB atch(CompilerPa rameters

options, CodeCompileUnit[] ea) +428
System.CodeDom. Compiler.CodeCo mpiler.FromDom( CompilerParamet ers
options, CodeCompileUnit e) +90
System.CodeDom. Compiler.CodeCo mpiler.System.C odeDom.Compiler .ICodeCompiler. CompileAssembly FromDom(Compile rParameters

options, CodeCompileUnit e) +37
System.Web.Comp ilation.BaseCom piler.GetCompil edType() +227
--------------------------------------------------------------------------------

Version Information: Microsoft .NET Framework Version:1.1.432 2.2300;
ASP.NET Version:1.1.432 2.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.publi c.dotnet.genera l but
haven't had any help there...

[Willy Denoyette [MVP]]

"Phil" <ph***********@ gmail.com> wrote in message
news:11******** *************@g 47g2000cwa.goog legroups.com...
| 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.