This post originated from an RSS feed registered with .NET Buzz
by Merill Fernando.
Original Post: IIS Lockdown & .NET
Feed Title: Merill Fernando's Blog
Feed URL: http://www.merill.net/blogxbrowsing.asmx/GetRss?
Feed Description: Merill is a Software Architect at Business Technology Alliance. Merilll is an MCSD in .NET and a Microsoft Certfied Trainer.
In this feed he will be regularly posting on the challenges faced when migrating from a Microsoft DNA architecture to Microsoft .NET
I recently ran into quite a few problems when the IIS
Lockdown tool was applied on one of our production servers. I'm listing it here
so that I don't trip over it again and also end up helping anyone who comes
across the same problem.
My scenario is that we have a classic asp application relying on .NET components which
use MSMQ. After applying the lock down tool the asp application worked fine until
it called one of the .NET components that sent a message through MSMQ which threw
this exeception:
Cannot execute a program. The command being executed was
"c:\winnt\microsoft.net\framework\v1.1.4322\csc.exe".
What I found out was that the XmlSerializer which was used by System.Messaging to
send the message created a dynamic class and compiles it on the fly. The problem
is that the lockdown tool denies access to all the .exe files in the Windows system
folder (and subfolders). This prevents the csc.exe or vbc.exe which is in
C:\WINNT\Microsoft.NET\Framework\v1.1.4322 from being able to dynamically compile.
To fix this I gave the Web Applications group Execute permissions for this file but
this threw another exception.
File or assembly name sk-fuua9.dll, or one of its dependencies,
was not found.>
at System.Reflection.Assembly.nLoad(AssemblyName fileName...
After spending a couple of hours trying to figure this out, I finally got around to
using the excellent FileMon tool
which highlighted that the cvtres.exe too was used by csc.exe when attempting to compile.
So I ended up giving Execute permissions for the cvtres.exe file for the Web Applications
group and wallah problem solved!
The Microsoft KB recommends creating an seperate user and impersonating it in the
application. But I feel that going this route makes it more secure since the
default groups created by the lock down tool revokes most of the rights, which is
not the case when you create your own user.