1 minute read

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.</MESSAGE> at System.Reflection.Assembly.nLoad(AssemblyName fileName...</FONT></P>

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.