Page #45 (Chapter 5 - Securing an IIS Application)

	Chapter 5 - Securing an IIS Application
	Visual Basic Developers Guide to ASP and IIS
	A. Russell Jones

Copyright 1999 SYBEX Inc.

---

	Compile the Project

	Unlike in standard types of Visual Basic projects, running a WebClass in design mode and running it as a compiled DLL are different kinds of operations.

	Create a new directory on your C drive called SecuredSite and move the registration.txt file into that directory. Make sure to change the path reference in the Signon_frmSignon and Register_Register routines. Now run the site again. You shouldn't see any difference in the site.

	Make sure you set the project options like those shown in Figure 5.9, and then compile the program.

	You must check the Unattended Execution option, because WebClasses run on the server. Unhandled errors in a VB program display a modal dialog box—and no one's likely to see it. When you check this option, the VB runtime translates all MessageBox calls into Application log events.

	You also need to check the Retained in Memory option for WebClasses. This flag tells IIS to keep the Visual Basic runtime DLL loaded even when the last instance of a WebClass has been destroyed. If you don't check this option, the entire runtime DLL will be unloaded after each request, then loaded again for the next request, which will slow down the response time considerably.

	Note		If you're developing on Windows 95 or 98, which don't have event logs, VB writes the information into a file. You specify the name of the file with the App.Logpath property. If you haven't specified a filename, VB writes the information into a file called VBEvents.log in the Windows directory.

	After you've compiled the project, run it by opening a new instance of the browser and typing the URL for the Signon.asp page. Make sure your WebClass project is not running when you do this; otherwise, you'll still be in the development environment.

	Tip		If you don't know the URL, run the program once more in development mode and copy the URL from your browser's address field.

	You will likely get an error when the program tries to open the registration file. If you don't get an error, either your security is lax or IIS may have its security settings set to NT Challenge/Response mode. Even if you don't get an error, you may want to read through this section anyway and possibly change some settings.

	Why do you get an error while running with a compiled DLL but not while running in development mode? Because when you run the program in compiled mode, you aren't you! That's confusing, isn't it. Instead, you're running the program with the permissions assigned to the default IIS Web user—usually called IUSR_MachineName, where MachineName is the name of the server on which IIS is running. Worse, sometimes you're running with the permissions assigned to the default ISAPI extension user, usually called IWAM_MachineName. (IUSR stands for Internet User, and IWAM stands for Internet Web Application Manager.) The permission level you have in these various modes is called your security context. The reasons it can be different at different times lie in how you set up IIS and your Web application.

	When IIS is set up to allow anonymous access (the default setting), it doesn't try to authenticate the user requesting a file; instead, it impersonates another account—by default, the IUSR_MachineName account—to gain access to files and other resources.

	I'll go into more detail about this later; for now, follow these rules and you should be able to run your projects without security problems:

	•		When you run a WebClass in development mode, you have all the security permissions assigned to your account. You should be able to read and write files and access databases through your IIS application in exactly the same way as you can by changing files in Explorer or any other application.

	•		If you have security problems when running a WebClass in compiled mode (and you will), adjust the permissions assigned to the IIS anonymous user account (IUSR_MachineName). If the application runs in an isolated process, change the rights for the IWAM_MachineName account instead.

	•		Your security context can change during the course of a request, from the LocalSystem account to IUSR_MachineName, to IWAM_MachineName. You should ensure that all three of these accounts have appropriate access rights to files and COM objects.

	•		If your application runs in an isolated process, you may also need to change the MTS package permissions in order to instantiate other COM objects from your WebClass. For the present, you won't have to worry about that. I'll take it up in more detail in Chapter 12, "IIS Applications and Microsoft Transaction Server."

	To solve the security problem associated with the registration file, open Windows Explorer, navigate to the registration.txt file or the SecuredSite directory, and right-click it. Select the Security tab. Add the IUSR_MachineName account and the IWAM_MachineName account to the access control list (ACL) for that file or to the directory. Make sure you give these accounts Change (Read, Write, eXecute and Delete—usually abbreviated as RWXD) permissions, or at least read/write (RW) permissions for the file, depending upon your needs. Run the project again. This time, you should not get an error.

	Unfortunately, security problems are the most common problems you'll run into when you deploy your application. If you're building an in-house application and are lucky enough to have an all-Windows intranet-only client base, you might want to consider changing the default to NT Challenge/Response mode and removing the Anonymous browse option. Figure 5.10 shows the properties dialog for the SecuredSite virtual directory. These are the default security settings.

	To get to the screen shown in Figure 5.10, open the Internet Service Manager, expand the Default Web Site item, then right-click the SecuredSite entry. Select Properties from the pop-up menu. Click the Directory Security tab, then click the Edit button. If you don't want to run IIS under the default IUSR_MachineName account, click the Edit button next to Allow Anonymous Access and change the account to a different network account. Alternately, you can disable anonymous access altogether by clearing the check box, but you should do that only if all users of the application can authenticate on your network

	Try to keep this security model in mind as you design your Web applications. It becomes especially important if you'll be using COM objects from other servers, connecting to a separate SQL server, or accessing remote files. If you need anything more than read-only resource access to files inside your Web site, you'll need to make sure that the account permissions for IIS are properly set. It's a good idea to write down the application's security settings somewhere where you or the server administrator will be able to find them later. Servers aren't static—they change all the time. If an administrator rebuilds the server, if resources are moved or renamed, or if an administrator accidentally changes permissions for your directories or accounts, you'll need to restore the permissions before your application will execute properly.