> I also did some research and adjusted the Web Server Extensions
> to allow all unkown CGI extensions to run (which was disable
> by default) and restarted this particular site.
You should stick with the default -- disable all unknown CGI extensions to
run -- and add a specific entry just to allow the particular PLUSrun.exe
program file to run. This is for security reasons. For example, your
current setup removes one protective mechanism against hackers launching
attacks using cmd.exe -- also another "unknown CGI" with a .exe extension.
> I did set the IUSR account up with Read and Execute permissions
> for the folder housing the .dbw files.
This is unnecessary and actually further weakens your server's security.
All you need to do is enable "Scripts" Execute permission in IIS Manager UI
for that virtual directory/application and ensure that the remote
authenticated user has NTFS Read access to the .dbw files. You are
literally one configuration away from opening your server to hackers at this
point.
> Im not sure where else to look here. Any help would be greatly
appreciated.
My suspicion is that the dBase EXE requires looser security requirements (I
have no idea what they are -- can you locate if your dBase is supported to
run on Windows Server 2003?). Please run FileMon from <a style='text-decoration: underline;' href="http://www.sysinternals.com" target="_blank">www.sysinternals.com</a>
during the request to .dbw files to see if any "access denies" crop up and
if so, for what resource. Maybe we can try to creatively tighten dBase
security.
IIS5 is insecure in that as LocalSystem, it could always read/write
anywhere -- IIS6 is far tighter in security and requires you to declare what
user is allowed to read/write and where -- which may surprise existing
programs and cause them to break. However, we have decided that this
incompatibility is worth the security gain -- because you now know that you
are implicitly weakening the server's security, so you are better informed
to manage risk. It is better for the server to scream about security
vulnerability and refuse to run than for it to silently keep running with a
hidden/unknown security vulnerability.
--
//David
IIS
<a style='text-decoration: underline;' href="http://blogs.msdn.com/David.Wang" target="_blank">http://blogs.msdn.com/David.Wang</a>
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"mkay334@newsgroup.nospam"
<mkay334.DeleteThis@newsgroup.nospam@discussions.microsoft.com> wrote in message
news:9C7D6A75-5F79-41D4-954E-3544702002FE@microsoft.com...
Greetings everyone,
We are in the process of integrating all of our previous web sites and
applications from our previous server to our new SBS 2003 machine. Our
sites
include several forms that submit data to dBASE .DBW files that process the
SQL lookups and return the results to the browser.
In IIS5, all that was needed was to add the .dbw to the Application Mappings
within the virtual direcory where the .DBW file was stored. Before mapping
this .dbw extension, any attempt to access this file through the browser
would result in a prompt to download the file. After mapping the .dbw
extension to the PLUSrun.exe file, the .dbw processed the data and properly
rendered the HTML ouput to the browser.
Now this entire folder structure has been moved to the new SBS 2003 Server,
and a web site was created pointing to this folder. All static pages were
viewable, but any attempt to invoke a .dbw file generated a 404 error,
rather
than a download prompt.
I added the application mappings for the .dbw files to point to the dBASE
runtime as I did on the previous server. I also did some research and
adjusted the Web Server Extensions to allow all unkown CGI extensions to run
(which was disable by default) and restarted this particular site. Now any
form submissions to the .dbw files just take forever, and eventually end up
in a CGI timeout.
I did set the IUSR account up with Read and Execute permissions for the
folder housing the .dbw files.
Im not sure where else to look here. Any help would be greatly appreciated.<!-- ~MESSAGE_AFTER~ -->
>> Stay informed about: Compatibility question between IIS5 and IIS6