Subscribe to Windows IT Pro
September 05, 2002 12:00 AM

IIS Informant: Handling the Script Source Access Permission for IIS

Windows IT Pro
InstantDoc ID #26258
Rating: (1)

[Editor's Note: Do you have an IIS-related question? Send it to brett@iisanswers.com and you might see the answer in this column!]

I can't determine how IIS's Script Source Access permission functions. Can you explain how this permission works and when I would want to enable or disable it?

The permission you refer to (in webbasedpermissions.tif) is one of a group of permissions (Read, Write, Directory Browsing, and Script Source Access). You can find them on the Properties page of a Web Site (through the Web Site tab), directory (through the Directory tab), or virtual directory (through the Virtual Directory tab). You can even specify some of these permissions on an individual file. These permissions are difficult to explain because they don't always behave as you might expect. Think of these permissions as Web-based because IIS—rather than any underlying programs or OS function—enforces them and because doing so helps clarify their role in the security chain of events, which is important for IIS administrators. Here's the sequence of security checks that IIS performs when it receives a request.

  1. Is the IP address OK? IIS checks the IP address of the incoming request against any restrictions entered in the IP Address and Domain Name Restrictions table. You can access this table through the Security Tab's IP Address and Domain Name Restrictions button.
  2. Can the user be authenticated? (Depending on the settings, either IIS or the OS might authenticate the user.) If you enable anonymous authentication, this test will always succeed.
  3. Do Web-based permissions permit the specific action the client requested? IIS checks the client's HTTP verb against the Web-based permissions to determine whether the client's method of accessing the resource is permitted.
  4. Do NTFS permissions allow access? Finally, the OS enforces NTFS permissions based on the user's account and group memberships to determine whether the user can access the resource.

As you can see, IIS enforces the Web-based permissions noted in Step 3 before the OS checks NTFS permissions. Knowing this sequence can help you with troubleshooting. For example, if you permit Everyone Full Control on a resource and clients are still denied access, you might have a problem with Web-based permissions.

As I mentioned, Web-based permissions might not behave as you'd expect. For example, the Read and Write Web-based permissions apply only to static content. Therefore, an Active Server Pages (ASP) script requires the NTFS Read permission but doesn't require the Read Web-based permission. This situation occurs because IIS doesn't read the script directly. The asp.dll reads the script, and asp.dll doesn't check to see whether the Web-based permissions permit the Read permission. The Web-based Read permission also isn't required for executables (e.g., .exe, .dll).

Similarly, the Web-based Write permission doesn't prevent an ASP script executable from writing to a Web site, directory, virtual directory, or file—even if you disable the Web-based Write permission.

Directory Browsing performs much as you'd think it would. If you haven't defined a default document for a Web site, directory, or virtual directory, IIS displays a list of the files and folders to the user, presuming that you've enabled the Web-based Read permission.

Note that in addition to Read, Write, Directory Browsing, and Script Source Access, another setting for Web-based permissions exists—the Execute permission. You can set the Execute permission to None, Scripts Only, or Scripts and Executables.

Now, let's look at the Script Source Access permission. In describing the Script Source Access permission, IIS documentation at http://www.microsoft.com/windows2000/en/server/iis/default.asp?url=/windows2000/en/server/iis/htm/core/iiwspsc.htm (and the online documentation) states "Users can access source files. If Read is selected, source can be read, if Write is selected, then source can be written to. Script Source Access includes the source code for scripts, such as the scripts in an ASP application. This option is not available if neither Read nor Write is selected."

As usual, the details are a bit more involved. First, let's clarify what script means in this context. Relative to the Script Source Access permission, a script is a file that has an extension mapped in the Application Mappings.

Related Content:

ARTICLE TOOLS

Comments
    There are no comments to display. Be the first one!
You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.