Hi,

I have an XML web service which exports a method that allows consumers of
the service to update a backend system using an out of process com server.
The only way I can get this to work is to set the Anonymous access user to
administrator or another high access user which is obviously not ideal. I
have tried giving the standard IUSR_PCNAME account access to the directory
where the COM server is located and access to any registry keys it might use
but all that happens is that the consuming user gets an Access Denied message.

After trawling the net I have also tried adding a COM+ application and
adding the required interfaces to it and this had no positive affect. I'm
really stuck and I need to know what rights I need to give to the anonymous
user to enable the web service to access the COM server.

Thanks for any help

Hi Aidan,

I experience the same problem with the same setup.
I've create a COM server in VFP which I try to access from a Webservice
using SOAP.
The webservice contains code:
loComServer = CREATOBJECT('myComServer.app')
where myComServer.app is the class name as registered in the registry.

The only way I've been able to make it work is to adjust the Identity in the
DCOM Config tool of the component services.
There seems to be a way of doing it useing the IUSR_xxx account (see text
below) but I could not get that to work either.

Do you have got this working yet ?


From:
http://blogs.msdn.com/david.wang/archive/2006/04/28/HOWTO-Run-Console-Applications-from-IIS6-on-Windows-Server-2003-Part-2.aspx

If you want to run executables on IIS from a script (i.e. an ASP, ASP.Net,
or PHP page is considered a script resource executed by ASP.DLL,
ASPNET_ISAPI.DLL, or PHP-CGI.EXE / PHPISAPI.DLL Script Engine,
respectively), then you need to configure "Scripts" execute permission as
well as Web Service Extension for the appropriate Script Engine. i.e.

MyScript.asp contains the following content which executes FSUTIL.EXE:

<%
set objShell = Server.CreateObject( "WScript.Shell" )
objShell.Run( "FSUTIL.EXE" )
%>1.. /cgi-bin has "Scripts" execute permission enabled.
2.. %systemroot%\System32\inetsrv\ASP.DLL is enabled as a Web Service
Extension.
3.. /cgi-bin has a ScriptMaps property which associates .asp extension to
%systemroot%\System32\inetsrv\ASP.DLL as a Script Engine.
4.. You make a request to http://localhost/cgi-bin/MyScript.asp
5.. IIS identifies ASP.DLL as the ISAPI Script Engine to process the
/cgi-bin/MyScript.asp resource and checks it against Web Service Extension.
Since it is allowed, it executes ASP.DLL using the user token obtained
through whatever authentication protocol is negotiated between the browser
and server.

Note: even though the ASP page runs FSUTIL.EXE, FSUTIL.EXE does NOT need
to be in Web Service Extension because IIS never runs nor knows about
FSUTIL.EXE. IIS only knows it is running ASP.DLL so that is what needs to be
enabled as a Web Service Extension.
6.. ASP.DLL will keep the impersonated identity from IIS and parse/execute
the script code in MyScript.asp using Windows Scripting Host. objShell.Run()
translates into a CreateProcess() Win32 API call, and FSUTIL.EXE runs using
the Process Identity (this is how CreateProcess is documented to work!)
7.. FSUTIL output is unknown to ASP (and IIS) unless you capture the
output of objShell.Run() somehow and then Response.Write() it so that IIS
knows about it.

[quoted text, click to view]