View Single Post
  #4 (permalink)  
Old October 14th, 2004, 08:45 AM
amsouth_jeffreygale amsouth_jeffreygale is offline
Registered User
Join Date: Oct 2004
Location: , , .
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts

Thanks you so much for solving my problem - I've searched and searched on the web and waded through post after post of IMarshal this and Regsvcs that, only to find that the solution was as simple as the web.config entry you provided.

Here's my question: what are the implications of adding the impersonate appSetting? Am I trading off anything - performance or security, for instance?

Thanks again!!!

quote:Originally posted by sweta
I found the answer to the problem.
I tried th option 2, by just specifying
<identity impersonate="true"/>
in the web.config file.
And working absoultely fine.

It is properly related with security. The ASPNET account needs to have
sufficient permission to execute the DLL and any other DLLs that it
requires. If it has permissions, then try the following steps:

1. Check whether legacy COM Component References ASP.tlb and tries to use
Response/Request objects.
In this case set the <%@Page AspCompat="true"%> Attribute in the ASP.NET

2. Check whether WebService or WebForm calls remote COM+ Component.
Auditing Logon/Logoff Failures will show ASPNET failing to logon to the
Remote COM+ Server. In this case set the following Tag in Web.Config file

<identity impersonate="true" userName="uid" password="pwd"/>

NOTE, if using Integrated security just setting Impersonate to true should
workfine. If using Anonymous, then can change the Anonymous user in IIS to
a domain account, and only set impersonate="true". This may be needed if
you do not want to specify a user and password in the web.config file.

Thank All,

Reply With Quote