Using trusted assemblies from classic ASP

  • Thread starter Thread starter Ken Kolda
  • Start date Start date
K

Ken Kolda

I have a .NET assembly which utilizes the System.Management classes to
retrieve information about the computer. When run under ASP.NET, I can use
this assembly with no problems. But now I'm trying to use with from within
classic ASP. The assembly is strongly-named and I've registered it using
"regasm /codebase" (I've also tried it in the GAC without the /codebase).
But when I use the component in ASP thru COM interop on either Win 2K or Win
2K3, I get the following exception when I try to execute my WMI query:

System.Exception: Error reading MAC Address information: Access denied
---> System.Management.ManagementException: Access denied

at
System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus
errorCode)
at System.Management.ManagementObjectSearcher.Get()

I even tried going into the .NET security configuration console and granting
FullTrust premissions based on the public key with which I signed my
assembly. It seemed to have no effect (although I can't say definiteively I
put the code group in the right place -- I stuck it directly under the
All_Code node in the Machine policy group).

I don't think this is identity-related because I have this ASP app running
in the same App Pool as an ASP.NET app which has no problems running the WMI
query. (I did try playing with the identity it ran with, even using a local
admin, but to no avail). Somehow, when running through COM Interop, the
component doesn't run with full trust -- does anyone know how I can
configure the system to grant FullTrust to my assembly in this scenario?

Thanks for your help -
Ken
 
This isn't a CAS issue, otherwise you would have got a SecurityException. You've got an indentity isssue somewhere, does the ASP.NET app use impersonation?

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<#[email protected]>

I have a .NET assembly which utilizes the System.Management classes to
retrieve information about the computer. When run under ASP.NET, I can use
this assembly with no problems. But now I'm trying to use with from within
classic ASP. The assembly is strongly-named and I've registered it using
"regasm /codebase" (I've also tried it in the GAC without the /codebase).
But when I use the component in ASP thru COM interop on either Win 2K or Win
2K3, I get the following exception when I try to execute my WMI query:

System.Exception: Error reading MAC Address information: Access denied
---> System.Management.ManagementException: Access denied

at
System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus
errorCode)
at System.Management.ManagementObjectSearcher.Get()

I even tried going into the .NET security configuration console and granting
FullTrust premissions based on the public key with which I signed my
assembly. It seemed to have no effect (although I can't say definiteively I
put the code group in the right place -- I stuck it directly under the
All_Code node in the Machine policy group).

I don't think this is identity-related because I have this ASP app running
in the same App Pool as an ASP.NET app which has no problems running the WMI
query. (I did try playing with the identity it ran with, even using a local
admin, but to no avail). Somehow, when running through COM Interop, the
component doesn't run with full trust -- does anyone know how I can
configure the system to grant FullTrust to my assembly in this scenario?

Thanks for your help -
Ken



---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004



[microsoft.public.dotnet.framework]
 
Thanks for the quick response. I suspect you're right with identity being
the issue although I didn't originally think this was the case.

My web.config is the standard one generated by VS.NET, so there's no
<identity> element in it. My machine.config is also the default, so it has
<identity impersonate="false" userName="" password=""/>. I tried creating a
new local user and placed him in pretty much every group (including
Administrators, IIS_WPG, etc.) and setting the AppPool to run as this user.
That seemed to have no effect (ASP.NET app worked, ASP didn't). None of
built-in accounts for the AppPool identity work either.

I also tried disabling Windows authentication in IIS on both the apps'
virtual roots (so only anonymous access was being used). Again, no effect.

Thanks again for the help -- if there's anything you can think of for me to
try, let me know.

Ken


Richard Blewett said:
This isn't a CAS issue, otherwise you would have got a SecurityException.
You've got an indentity isssue somewhere, does the ASP.NET app use
impersonation?
Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog
nntp://news.microsoft.com/microsoft.public.dotnet.framework/ said:
I have a .NET assembly which utilizes the System.Management classes to
retrieve information about the computer. When run under ASP.NET, I can use
this assembly with no problems. But now I'm trying to use with from within
classic ASP. The assembly is strongly-named and I've registered it using
"regasm /codebase" (I've also tried it in the GAC without the /codebase).
But when I use the component in ASP thru COM interop on either Win 2K or Win
2K3, I get the following exception when I try to execute my WMI query:

System.Exception: Error reading MAC Address information: Access denied
---> System.Management.ManagementException: Access denied

at
System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus
errorCode)
at System.Management.ManagementObjectSearcher.Get()

I even tried going into the .NET security configuration console and granting
FullTrust premissions based on the public key with which I signed my
assembly. It seemed to have no effect (although I can't say definiteively I
put the code group in the right place -- I stuck it directly under the
All_Code node in the Machine policy group).

I don't think this is identity-related because I have this ASP app running
in the same App Pool as an ASP.NET app which has no problems running the WMI
query. (I did try playing with the identity it ran with, even using a local
admin, but to no avail). Somehow, when running through COM Interop, the
component doesn't run with full trust -- does anyone know how I can
configure the system to grant FullTrust to my assembly in this scenario?

Thanks for your help -
Ken



---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004



[microsoft.public.dotnet.framework]
 
OK -- I figured it out. Should have tried this before... I changed the
identity of the anonymous user for the virtual root to one with sufficient
rights. The identity used for the AppPool didn't make a difference -- that's
where I was thrown off. I guess ASP pages always impersonate the identity
use by the IIS virtual root, whereas this is configurable in .NET.

Thanks for the help -
Ken


Ken Kolda said:
Thanks for the quick response. I suspect you're right with identity being
the issue although I didn't originally think this was the case.

My web.config is the standard one generated by VS.NET, so there's no
<identity> element in it. My machine.config is also the default, so it has
<identity impersonate="false" userName="" password=""/>. I tried creating a
new local user and placed him in pretty much every group (including
Administrators, IIS_WPG, etc.) and setting the AppPool to run as this user.
That seemed to have no effect (ASP.NET app worked, ASP didn't). None of
built-in accounts for the AppPool identity work either.

I also tried disabling Windows authentication in IIS on both the apps'
virtual roots (so only anonymous access was being used). Again, no effect.

Thanks again for the help -- if there's anything you can think of for me to
try, let me know.

Ken


Richard Blewett said:
This isn't a CAS issue, otherwise you would have got a
SecurityException.
You've got an indentity isssue somewhere, does the ASP.NET app use
impersonation?
Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog
nntp://news.microsoft.com/microsoft.public.dotnet.framework/ said:
I have a .NET assembly which utilizes the System.Management classes to
retrieve information about the computer. When run under ASP.NET, I can use
this assembly with no problems. But now I'm trying to use with from within
classic ASP. The assembly is strongly-named and I've registered it using
"regasm /codebase" (I've also tried it in the GAC without the /codebase).
But when I use the component in ASP thru COM interop on either Win 2K
or
Win
2K3, I get the following exception when I try to execute my WMI query:

System.Exception: Error reading MAC Address information: Access denied
---> System.Management.ManagementException: Access denied

at
System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus
errorCode)
at System.Management.ManagementObjectSearcher.Get()

I even tried going into the .NET security configuration console and granting
FullTrust premissions based on the public key with which I signed my
assembly. It seemed to have no effect (although I can't say
definiteively
I
put the code group in the right place -- I stuck it directly under the
All_Code node in the Machine policy group).

I don't think this is identity-related because I have this ASP app running
in the same App Pool as an ASP.NET app which has no problems running
the
WMI
query. (I did try playing with the identity it ran with, even using a local
admin, but to no avail). Somehow, when running through COM Interop, the
component doesn't run with full trust -- does anyone know how I can
configure the system to grant FullTrust to my assembly in this scenario?

Thanks for your help -
Ken



---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004



[microsoft.public.dotnet.framework]
 
Back
Top