"Charles Leonard" <elmsdn13_xm***@hotmail.com> wrote in message
news:B8243032-9E67-4377-910A-6A3FD72834EF@microsoft.com...
>I have a web service running impersonation of a domain account on Windows
> Server 2003.  I need to access a share which the Web Service classes,
> themselves, appear to be able to create and access.  However, when an
> assembly (that is in the GAC, strongly named, etc.) is called by the web
> service to process the file, I receive the message:  "Access to the path
> is
> denied."  This installation works fine on Windows 2000 and Windows XP
> Professional.  However, Windows Server 2003 appears to require more
> security
> settings.
>
> I think this has something to do with the Global Assembly Cache and
> trusted
> assemblies.  Although, I don't know for sure.
>
> Does anybody have any ideas regarding what I can do to get the assembly to
> read the share drive file properly?
>
> Any help will be greatly appreciated.
>
> Thanks.
>
> -Charles V. Leonard
>

"Joseph MCAD" wrote:

> April 12, 2005
>
>    If I understand right, you need to call an assembly in the GAC and when
> trying to call the assembly it errors. I can think of two possiblities...
>
> 1) You are not allowed to call the assembly, because strong named assemblies
> require that all callers have FullTrust also, Except when the GAC assembly
> has the AllowPartiallyTrustedCallers() attribute.
>
> 2) Your call is allowed to be processed by the assembly (meaning that my
> first suggestion is not happening), but your user account is not allowed to
> access the file share. If your user account does not have permission to
> access the file share and try to call another assembly to access it for you,
> then the GAC assembly would have to impersonate a different user account to
> get the job done. I would check and make sure that your Windows Server 2003
> computer allows you to access the file share. It is quite possible that this
> new server has restricted ACLs on the share. I would check this out and I
> hope this helps! :-)
>
>                                                          Joseph MCAD
>
>
>
> "Charles Leonard" <elmsdn13_xm***@hotmail.com> wrote in message
> news:B8243032-9E67-4377-910A-6A3FD72834EF@microsoft.com...
> >I have a web service running impersonation of a domain account on Windows
> > Server 2003.  I need to access a share which the Web Service classes,
> > themselves, appear to be able to create and access.  However, when an
> > assembly (that is in the GAC, strongly named, etc.) is called by the web
> > service to process the file, I receive the message:  "Access to the path
> > is
> > denied."  This installation works fine on Windows 2000 and Windows XP
> > Professional.  However, Windows Server 2003 appears to require more
> > security
> > settings.
> >
> > I think this has something to do with the Global Assembly Cache and
> > trusted
> > assemblies.  Although, I don't know for sure.
> >
> > Does anybody have any ideas regarding what I can do to get the assembly to
> > read the share drive file properly?
> >
> > Any help will be greatly appreciated.
> >
> > Thanks.
> >
> > -Charles V. Leonard
> >
>
>
>

"Charles Leonard" <elmsdn13_xm***@hotmail.com> wrote in message
news:9AA00ACA-E3A4-4948-A3C2-BB90940F6628@microsoft.com...
> Joseph,
>
> Thanks for the reply.
>
> 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
>
> "Joseph MCAD" wrote:
>
>> April 12, 2005
>>
>>    If I understand right, you need to call an assembly in the GAC and
>> when
>> trying to call the assembly it errors. I can think of two possiblities...
>>
>> 1) You are not allowed to call the assembly, because strong named
>> assemblies
>> require that all callers have FullTrust also, Except when the GAC
>> assembly
>> has the AllowPartiallyTrustedCallers() attribute.
>>
>> 2) Your call is allowed to be processed by the assembly (meaning that my
>> first suggestion is not happening), but your user account is not allowed
>> to
>> access the file share. If your user account does not have permission to
>> access the file share and try to call another assembly to access it for
>> you,
>> then the GAC assembly would have to impersonate a different user account
>> to
>> get the job done. I would check and make sure that your Windows Server
>> 2003
>> computer allows you to access the file share. It is quite possible that
>> this
>> new server has restricted ACLs on the share. I would check this out and I
>> hope this helps! :-)
>>
>>                                                          Joseph MCAD
>>
>>
>>
>> "Charles Leonard" <elmsdn13_xm***@hotmail.com> wrote in message
>> news:B8243032-9E67-4377-910A-6A3FD72834EF@microsoft.com...
>> >I have a web service running impersonation of a domain account on
>> >Windows
>> > Server 2003.  I need to access a share which the Web Service classes,
>> > themselves, appear to be able to create and access.  However, when an
>> > assembly (that is in the GAC, strongly named, etc.) is called by the
>> > web
>> > service to process the file, I receive the message:  "Access to the
>> > path
>> > is
>> > denied."  This installation works fine on Windows 2000 and Windows XP
>> > Professional.  However, Windows Server 2003 appears to require more
>> > security
>> > settings.
>> >
>> > I think this has something to do with the Global Assembly Cache and
>> > trusted
>> > assemblies.  Although, I don't know for sure.
>> >
>> > Does anybody have any ideas regarding what I can do to get the assembly
>> > to
>> > read the share drive file properly?
>> >
>> > Any help will be greatly appreciated.
>> >
>> > Thanks.
>> >
>> > -Charles V. Leonard
>> >
>>
>>
>>

> Joseph,
>
> Thanks for the reply.
>
> 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
>
> "Joseph MCAD" wrote:
>
>> April 12, 2005
>>
>> If I understand right, you need to call an assembly in the GAC and
>> when trying to call the assembly it errors. I can think of two
>> possiblities...
>>
>> 1) You are not allowed to call the assembly, because strong named
>> assemblies require that all callers have FullTrust also, Except when
>> the GAC assembly has the AllowPartiallyTrustedCallers() attribute.
>>
>> 2) Your call is allowed to be processed by the assembly (meaning that
>> my first suggestion is not happening), but your user account is not
>> allowed to access the file share. If your user account does not have
>> permission to access the file share and try to call another assembly
>> to access it for you, then the GAC assembly would have to impersonate
>> a different user account to get the job done. I would check and make
>> sure that your Windows Server 2003 computer allows you to access the
>> file share. It is quite possible that this new server has restricted
>> ACLs on the share. I would check this out and I hope this helps! :-)
>>
>> Joseph MCAD
>>
>> "Charles Leonard" <elmsdn13_xm***@hotmail.com> wrote in message
>> news:B8243032-9E67-4377-910A-6A3FD72834EF@microsoft.com...
>>
>>> I have a web service running impersonation of a domain account on
>>> Windows
>>> Server 2003.  I need to access a share which the Web Service
>>> classes,
>>> themselves, appear to be able to create and access.  However, when
>>> an
>>> assembly (that is in the GAC, strongly named, etc.) is called by the
>>> web
>>> service to process the file, I receive the message:  "Access to the
>>> path
>>> is
>>> denied."  This installation works fine on Windows 2000 and Windows
>>> XP
>>> Professional.  However, Windows Server 2003 appears to require more
>>> security
>>> settings.
>>> I think this has something to do with the Global Assembly Cache and
>>> trusted
>>> assemblies.  Although, I don't know for sure.
>>> Does anybody have any ideas regarding what I can do to get the
>>> assembly to read the share drive file properly?
>>>
>>> Any help will be greatly appreciated.
>>>
>>> Thanks.
>>>
>>> -Charles V. Leonard
>>>