Setting Appropriate Permissions on Web Applications

I recently developed a Web application for IIS, but I'm having trouble properly setting permissions. The application uses include (.inc) files, databases on other servers, and files that reside on the Web server. Determining which permissions to set on some of the content is difficult, and I want to avoid configuring resources with liberal permission settings. Do you know of any tools that can help me determine what's going on with permissions in this application?

As you've discovered, managing permissions in a Web-based application can be challenging. With applications, the user account that IIS is using at any given time isn't necessarily obvious. For example, users usually first connect to the server through the Internet Guest Account (i.e., IUSR_ servername). However, if users access content on a remote system, they're probably using virtual directories, which have a unique user account designated for use in authenticating to the remote system. When accessing the remote content, IIS switches to the account designated for the virtual directory. When accessing a database, either the script or program that accesses the database or the ODBC database connection setup information usually designates which user account IIS will use. Consequently, the security context (i.e., user account) can change again when the Web application accesses the database. Finally, if when users access the database you require them to provide credentials other than those with which they initially accessed the Web application, still another user account comes into play. As if these possibilities weren't enough, IIS will access programs and files as it reads information it requires; so, the System account, which hosts inetinfo .exe (the process that runs IIS), requires systemwide permissions.

Such account changes can be a lot to manage. Implementing permissions such as Everyone Change on content is tempting, but doing so is clearly not a good idea because it gives the IUSR account the right to upload and execute content. Here are a couple of tips you can use to help you determine the appropriate permissions for your content.

Auditing. One tip is to enable auditing. (Auditing is available in Windows 2000 and Windows NT 4.0.) With auditing, you can configure your server to record successful Read and Write events on any file or folder. Each successful event will appear in the event log and reveal the identity of the user who triggered the event.

W3who.dll. Another tip is to use the w3who.dll Internet Server API (ISAPI) program, which is available in the Microsoft Windows 2000 Server Resource Kit, to troubleshoot authentication problems. To use w3who.dll, simply call the program from within the script or page with which you're having trouble. The resulting report provides a wealth of information about the user account calling the program, including group membership and associated SIDs, as well as the server variables. Figure 1 shows a sample w3who.dll report. In this example, you'll notice that the IUSR account is a member of several groups that you might not usually associate with Anonymous access, including the Guest account, the Users group, the Authenticated Users group, and the Network group. Because w3who.dll is an executable file, you need to provide both Scripts and Executables permission in the Microsoft Management Console (MMC) Internet Information Services snap-in and NTFS Execute permission to run it.

Filemon. Finally, I would be remiss if I didn't mention Sysinternals' Filemon (filemon.exe) utility. This free utility shows you any Access Denied messages that occur while running your application on the server.