Re: Access Denied w/Impersonate=true

From: Andrea D'Onofrio [MSFT] (andreado_at_online.microsoft.com)
Date: 05/28/04 

Date: Fri, 28 May 2004 10:48:55 +0200

I'm sorry but I didn't mean use MUST use Everyone full control to to solve
your issue.
The best things to do is to set the appropriate permission settings, this is
because I've sent the article link: specifically for the temp folder you
must have the read/write access for the process account. This is
configuration dependent: the default is aspnet, but if you use impersonation
and Windows Integrated/Basic/Digest Authentication all the requester users
MUST have this grant. In this this case you can create a domain group and
grant the read/write access to this group.
If you use the Anonymous authentication you must grant the read/write access
to this account configured in IIS (default is IUSR_MachineName).

HtH,
Andrea 

-- 
This posting is provided "AS IS" with no warranties, and confers no rights.
"Raymond Lewallen" <Raymond.CTR.Lewallen@nospam.faa.gov> wrote in message
news:%23opfwx0QEHA.3616@TK2MSFTNGP09.phx.gbl...
> Is giving Everyone Full Control a sound solution?  Isn't this bypassing
> pinning down the appropriate permission settings and setting access rights
> appropriately?
>
> "Andrea D'Onofrio [MSFT]" <andreado@online.microsoft.com> wrote in message
> news:u2pEqJzQEHA.964@TK2MSFTNGP10.phx.gbl...
> > The error says that the user doesn't have permission to access to the
temp
> > folder. Using impersonate=true the user identity is the identity of the
> user
> > that opens the browser.
> > Please, check this article
> > http://support.microsoft.com/default.aspx?kbid=317012#4 in order to
check
> > the permission needed.
> > Probably you may solve your problem setting for Everyone Full control on
> the
> > Temp folder.
> >
> > HtH,
> > -- 
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> >
> > "Rich Yadach" <ryadach@travelers.com> wrote in message
> > news:u0delWoQEHA.1160@TK2MSFTNGP09.phx.gbl...
> > > Does anyone have any ideas or comments on this?
> > >
> > >
> > >
> > > The problem seems to stem from having Impersonate=True set in our
> > web.config
> > > files (Version 1.1).
> > >
> > >
> > >
> > > Here is the error we encountered .
> > >
> > >
> > >
> > > The actual filename changes every time you try to load the page:
> > >
> > > An error has occurred: Access to the path
> > > "C:\DOCUME~1\servername\ASPNET\LOCALS~1\Temp\olvtg0lf.0.vb" is denied.
> > >
> > >
> > >
> > > This is what I grabbed from the server's event viewer:
> > >
> > > 1) Exception Information
> > >
> > > *********************************************
> > >
> > > Exception Type: System.UnauthorizedAccessException
> > >
> > > Message: Access to the path
> > > "C:\DOCUME~1\servername\ASPNET\LOCALS~1\Temp\olvtg0lf.0.vb" is denied.
> > >
> > > TargetSite: Void WinIOError(Int32, System.String)
> > >
> > > HelpLink: NULL
> > >
> > > Source: mscorlib
> > >
> > >
> > >
> > > StackTrace Information
> > >
> > > *********************************************
> > >
> > >    at System.IO.__Error.WinIOError(Int32 errorCode, String str)
> > >
> > >    at System.IO.FileStream..ctor(String path, FileMode mode,
FileAccess
> > > access, FileShare share, Int32 bufferSize, Boolean useAsync, String
> > msgPath,
> > > Boolean bFromProxy)
> > >
> > >    at System.IO.FileStream..ctor(String path, FileMode mode,
FileAccess
> > > access, FileShare share)
> > >
> > >    at
> System.CodeDom.Compiler.CodeCompiler.FromDomBatch(CompilerParameters
> > > options, CodeCompileUnit[] ea)
> > >
> > >    at System.CodeDom.Compiler.CodeCompiler.FromDom(CompilerParameters
> > > options, CodeCompileUnit e)
> > >
> > >    at
> > >
> >
>
System.CodeDom.Compiler.CodeCompiler.System.CodeDom.Compiler.ICodeCompiler.C
> > > ompileAssemblyFromDom(CompilerParameters options, CodeCompileUnit e)
> > >
> > >    at System.Xml.Xsl.Compiler.CompileAssembly(ScriptingLanguage lang,
> > > Hashtable typeDecls, String nsName, Evidence evidence)
> > >
> > >    at System.Xml.Xsl.Compiler.CompileScript(Evidence evidence)
> > >
> > >    at System.Xml.Xsl.Compiler.Compile(NavigatorInput input,
XmlResolver
> > > xmlResolver, Evidence evidence)
> > >
> > >    at System.Xml.Xsl.XslTransform.Compile(XPathNavigator style***,
> > > XmlResolver resolver, Evidence evidence)
> > >
> > >    at System.Xml.Xsl.XslTransform.Load(String url, XmlResolver
resolver)
> > >
> > >    at System.Xml.Xsl.XslTransform.Load(String url)
> > >
> > >    at UI.Sitemap.PortalSiteMap.TransformXML()
> > >
> > >
> > >
> > > Here is what the code is doing.simply trying to load an XSL file
> > >
> > >
> > >
> > > Dim resultsXSLT As New Xsl.XslTransform()
> > >
> > > Dim xslFile As new String = "somexslfile..xsl"
> > >
> > > resultsXSLT.Load(xslFile)           ß Exception Occurs Here
> > >
> > >
> > >
> > >                         The xsl file has imbedded within it VBScript.
> > >
> > >
> > >
> > >
> > > My theory on what is causing the error.
> > >
> > >
> > >
> > >                         Since the application code is loading the XSL
> > file,
> > > which contains VBScript, I think the CLR is trying to JIT compile the
> code
> > > at runtime, and since                            Impersonate=True, is
> > doing
> > > this under the security context of the end user.  This user does not
> have
> > > access rights to the c:\documents and Setting.
directory
> > > listed above.  When we turn Impersonate off everything works because
the
> > > security context is now ASPNET and for version 1.1 of the
> > > frameworks this account was granted full control of the above
mentioned
> > > directory (see link below).  The reason I think the CLR is trying to
JIT
> > the
> > > VBScript is when we did some testing I noticed the CLR JIT perfmon
> > counters
> > > being incremented when traversing thru this code.
> > >
> > >
> > >
> > > Here is a link to an identical problem (bet he had impersonate=true):
> > >
> > > http://www.dotnet247.com/247reference/msgs/46/231289.aspx
> > >
> > >
> > >
> > > Not the same situation but does talk about impersonate=true and the
> > > Documents and Settings Folder:
> > >
> > > http://support.microsoft.com/default.aspx?scid=kb;en-us;827190
> > >
> > >
> > >
> > > Question:
> > >
> > >
> > >
> > >            Can anyone confirm my theory and more importantly is there
a
> > way
> > > to configure the location of the temp files used for JIT compiles?
I'd
> > > rather not have to grant our end users full control to the
C:\documents
> > and
> > > settings. folder when Impersonate=true is set.
> > >
> > >
> >
> >
>
>