Re: Access to the path is denied: Assembly Permission Problem
- From: Charles Leonard <elmsdn13_xmail@xxxxxxxxxxx>
- Date: Wed, 13 Apr 2005 08:47:04 -0700
Thanks for the reply.
You are right. It was a delegation configuration problem (and, I myself,
was not entirely convinced it was a GAC problem).
Unfortunately, my initial analysis of the problem was a little off. There
was another distinctive feature occurring in this part of the code that I had
overlooked (besides it being a portion of code in the GAC). This entire
portion of the code was also launched within a new child thread.
It was a thread permission problem not a GAC permission problem. The thread
did not receive the impersonation attributes of the parent and instead
reverted to the "NETWORK SERVICE" account (which, of course, doesn't have
access to the share). After talking to a Microsoft engineer, I discovered
that this occurred because the default application pool I was using
("DefaultAppPool", defined in IIS 6.0) always uses the "NETWORK SERVICE"
account when a new thread is created despite the credentials of its parent.
Luckily, the account for the pool can be changed. But, instead of doing
that, I decided to create a new application pool, assign the pool my domain
account and then assign the virtual directory the newly created application
pool (replacing the reference to the default pool). Once I did that,
everything worked fine.
One note about changing a virtual directory to use a new application pool;
you need to add back the permission for your domain account to access the
registry key "ASPNET_SETREG" (if you are using "aspnet_setreg.exe" to encrypt
your username and password).
While everything works now; ideally, it seems to me that the new thread
should have received the parent's impersonation credentials and that the
"NETWORK SERVICE" account should have only been used for the default pool if
impersonation had not been specified. Regardless, I have a workable
solution, so, I probably don't care anymore about what I think should have
happened…
Thanks again.
--Charles
"richlm" wrote:
> Are you sure this is not related to configuration of delegation?
>
> Even if the logged-on-user has access to the share, a process running-as or
> impersonating the user does not, by default, have the same level of network
> access.
>
> In Windows server 2000 domains, delegation is either on or off for each user
> account.
>
> In domains raised to "Windows 2003" functional level it can be configured
> for each server/service for each user.
>
> Try following KB articles for more info
> http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/a9fd0aa2-301c-42b3-a7b1-2595631c389f.mspx
> (or search google with - including quotes - "Allow a user to be trusted for
> delegation")
>
> Also http://support.microsoft.com/kb/810572
>
>
>
.
- Follow-Ups:
- References:
- Access to the path is denied: Assembly Permission Problem
- From: Charles Leonard
- Re: Access to the path is denied: Assembly Permission Problem
- From: richlm
- Access to the path is denied: Assembly Permission Problem
- Prev by Date: specified cast is not valid
- Next by Date: Unmanaged code in WebService gives DNS error when HTTP KeepAlive=f
- Previous by thread: Re: Access to the path is denied: Assembly Permission Problem
- Next by thread: Re: Access to the path is denied: Assembly Permission Problem
- Index(es):
Relevant Pages
|
