The Permissions Maze

By James Morey, Web Technology Writer

Internet Information Services Documentation Team
Microsoft Corporation

October 15, 1999

This article discusses interactions between Web permissions and NTFS Permissions. It is aimed at helping the Web professional learn how to secure Web sites and network content. This article concentrates on the issue of Web and file system permissions, how they differ, how they work independently, and how they work together.

Before reading this article you should have a basic understanding of the security features in both Internet Information Services 5.0 (IIS) and Microsoft Windows® 2000. To better understand these concepts, see the IIS online product documentation on your server at https://localhost/iisHelp/iis/misc/default.asp and the Windows 2000 online product documentation.

In this article we will discuss:

• How NTFS Permissions Work

• How Web Permissions Work

• WebDAV and Permissions

• When Web and NTFS Permissions Collide

• The Permissions Wizard

• Permissions Problems and Solutions

When an administrator creates a user account, Windows creates and associates a security identifier (SID) with the user account. This SID is absolutely unique and lasts as long as the user account exists.

When the user makes a request (see UNC request box in the diagram below) for network resources, a user access token containing the SID is created and passed with the request. The file system compares the SID in the token to SIDs listed in the Access Control List (ACL) for the requested object. If a match is found, the user is granted the level of access in the ACL. If no match is found then the user gets an error and no access.

You can configure file system access permissions for specific directories and files. These permissions apply to only the individual user accounts or user groups for which they are set. If you grant one user Read and Write access to a file, that doesn't mean that another user also has access. For more information, see the Windows 2000 online product documentation.

The most common file system permission levels include:

• Full Control - Users can modify, add, move, and delete files, and their associated properties, and directories. In addition, they can change permissions settings for all files and subdirectories.

• Modify - Users can view and modify files and file properties, including deleting and adding files to a directory or file properties to a file.

• Read & Execute - Users can run executable files, including scripts.

• List Folder Contents - Users can view a list of a folder's contents.

• Read - Users can view files and file properties.

• Write - Users can write to a file.

• No Access - When no check boxes are selected, users have absolutely no access to the resource, even if a user has access to a higher-level parent directory.

Below are some helpful permissions suggestions that will help you secure your server:

• Use the NTFS file system on your server.

• Always give the Administrator Full Control on everything unless you have special security concerns.

• Never remove all access to a resource. If you do this, the file becomes a block of unusable space on your drive. If the file was a System DLL, you get to format your hard drive.

• The file system automatically gives the Everyone group Full Control to all new directories. As soon as you create new directories, change this setting to one that better serves your security needs.

• Inappropriately set permissions can deny valid users access to required files and directories. For example, even though a user has the right to view and execute a program, the user may not have permission to access a particular dynamic-link library (DLL) required to run that program. To guarantee users secure and uninterrupted file access, place related files in the same directory, and then assign the appropriate NTFS permissions.

When an HTTP request is made for server resources, such as files, the user's Web browser creates a request header containing information about the request such as authentication information, the HTTP verb requested, the IP address of the requesting party, and so on. The browser then sends this header to the server.

When the server receives the request header, IIS first compares the IP address supplied and determines whether it is allowed access to the resource. If access is granted, then IIS compares the authentication information to see if the user is granted access. If yes, then IIS looks at the HTTP verb in the request header to determine whether this verb is allowed for the resource.

An HTTP verb is a command added to the HTTP request that tells IIS what sort of access the user is requesting. For example if Frank wants to see a file on his server, his browser would send the GET command to retrieve the file from the server.

At this point, one of two things can happen. If Anonymous authentication is being used by IIS for the resources, then IIS "impersonates" the user and tries to access the file system resource on behalf of the user. If the IUSR_computername Windows user account has been given the correct user rights then the request is granted and the file is displayed in the Web browser of the user. If the correct access rights were not given to the IUSR_computername account, the request fails and the user gets an error message in their browser.

If client certificate mapping, Basic, integrated Windows, or Digest authentication is being used, then IIS passes the authentication information to Windows and checks for a match in the Windows user account database.

Note: For an anonymous HTTP request, IIS only processes the username/password part, so IP address, Web permission, and NTFS permission restrictions still apply.

You can configure your Web server's access permissions for specific sites, directories, and files. These permissions apply to all users regardless of their specific access rights. This means that if you set Read Web permissions on your site, all users are granted Read access by IIS (their individual NTFS permissions still apply though). For more information, see the IIS online product documentation.

The Web permission levels include:

• Read (selected by default) - Users can view file content and properties.

• Write - Users can change file content and properties.

• Script Source Access - Users can gain access to source files. If Read is selected, then source code can be read. If Write is selected, then source code can be written to. Script Source Access allows access to the source code for files, such as the scripts in an ASP application. This option is only available if either Read or Write is checked.

• Directory browsing - Users can view file lists and collections.

Caution: When you select Script Source Access, users may be able to view sensitive information, such as a user name and password, from the scripts in an ASP application. They can also change source code that runs on your server, and seriously affect your server's security and performance. Access to these types of information and functions are best controlled through individual Windows accounts and higher-level authentication, such as Digest or integrated Windows authentication.

The Executable Permissions levels are:

• None - Don't run scripts, such as ASP applications, or executables on the server.

• Scripts only - Run only scripts, such as ASP applications, on the server.

• Scripts and Executables - Run both scripts, such as ASP applications, and executables on the server.

WebDAV and Permissions

Web Distributed Authoring and Versioning (WebDAV) extends the HTTP/1.1 protocol to allow clients to publish, lock, and manage resources on the Web. WebDAV does this by using an extended set of HTTP verbs, such as PROPFIND or LOCK, which allow clients to manipulate resources, modify properties, lock and unlock files, and search for files or properties.

Because WebDAV is integrated with Windows 2000 and IIS 5.0, it borrows the security features provided by both. These features include the IIS permissions specified in the IIS snap-in and the discretionary access control lists (DACLs) in the NTFS file system. Below is a summary of the Web permissions settings and how they affect how clients can use WebDAV to access resources on your server.

• Read, Write, Directory browsing enabled - Turning on these permissions lets clients see a list of resources, modify them (except for those resources without Write permission), publish their own resources, and manipulate files.

• Write enabled, Read, and Directory browsing disabled - If you want clients to publish private information on the directory, but do not want others to see what has been published, set Write permission, but do not set Read or Directory browsing permission. This configuration works well if clients are submitting ballots or performance reviews.

• Read and Write enabled, and Directory browsing disabled - Set this configuration if you want to rely on obscuring file names as a security method. However, be aware that security by obscurity is a low-level security precaution, because a vandal could guess file names by trial and error.

• Index this resource enabled - Be sure to enable Indexing Service if you plan to let clients search directory resources.

When Web and NTFS Collide

If you enable read-only Web permissions are you setting read-only in NTFS as well? No. Web permissions only control which HTTP verbs can be used in HTTP requests. If you set read-only in NTFS, are you setting read-only in IIS? Yes. Even if Web permissions are set at Read and Write, if NTFS has read-only, the HTTP Write request will fail.

For example, suppose you set up "SiteB" as a Web site that points to the folder "Site_B" on an NTFS drive. You set Web permissions as Read and Write and NTFS permissions as Read. When a user tries to Write to https://www.SiteB.com, the request will fail. Even though IIS will allow the user to Write to the Web site "SiteB," and therefore to the folder "Site_B," NTFS will not allow it. If someone on the SiteB network tries to paste a file into Site_B, they will be restricted by NTFS from writing to the folder.

Now let's try switching the permissions around: NTFS is Read and Write and Web is read-only. The result is that the Web user still can't write to the Web site because NTFS denies permission. However, the network client can paste the file because IIS does not control UNC access to the resource. IIS can only control access on HTTP requests, not file system requests.

The Permissions Mantra: If Web and NTFS permissions do not agree, the more restrictive of the two will be used for HTTP requests.

The Permissions Wizard

So, how can an administrator be sure Web and NTFS permissions are in perfect synchronization? Use the IIS Permissions wizard. The wizard automatically takes synchronizes Web permissions and ACLs. The wizard can be used to create a virtual directory or just to modify it.

There are three things to keep in mind when using the wizard:

• Record the security settings on the virtual directories, file system directories, and files before changing them. This will make restoring these settings much easier. (Or perform a metabase backup. For more information, see the IIS online product documentation).

• The Permissions wizard changes both Web and NTFS permissions for the directories and files (virtual and file system) involved. If you have special security concerns regarding these resources, set the Web and NTFS permissions manually, rather than using the wizard.

• The choices given in the wizard are limited in order to make it simple to use. These settings are not extensible at this time and may not be adequate for your site. Review the security settings for both Web and file system if you have any special security needs.

Permissions Problems and Solutions

Now that we have discussed how NTFS and Web permissions work and interact, let's look at some of the common problems involving permission settings, the probable causes, and the solutions. They might sound familiar and hopefully give you some idea of the more baffling problems you face:

Summary

We can move through the permissions maze more easily if we remember that:

• IIS adds an additional layer of access control on top of NTFS; it doesn't replace NTFS Permissions . IIS makes it possible for anonymous HTTP users, that is users without Windows user accounts, to gain access to file system resources that they wouldn't otherwise have. IIS also gives the user with Windows accounts an additional method for accessing file system resources: over HTTP lines using WebDAV.

• Unless you're using the Permissions wizard, changing Web permissions does not change NTFS permissions automatically . And vice versa. If you alter Web permissions manually, you need to reflect those changes in NTFS. If you change NTFS permissions, you might need to change Web permissions as well.

• NTFS permissions only apply to the individuals they are granted to and only for the object to which they are applied. Another way of saying this is that NTFS permissions are granted on an individual-user, object-by-object basis . However, Web permissions apply to all users accessing a particular site, directory, or file. Therefore, Web permissions are granted on an all-users, object-by-object basis .

• NTFS permissions apply to all types of requests. Web permissions apply only to HTTP requests.

• If you are making a UNC request and you don't have permission, you will get a dialog box asking you to logon as someone with permission. If you don't have the right logon information, you will see this dialog a lot. If you attempt an HTTP request and don't have the right access permissions, you will see a "403: Access denied" error message.

• The IUSR_computername account is created automatically by IIS for anonymous access. It must have Log On Locally rights and belong to the Guests group in order to "impersonate" the users and give them anonymous access.

• If you wish to change the IUSR_computername account, such as changing its password, create another account, like ANON_computername, and use this account. Changing the IUSR_ computername account can lead to unforeseen trouble.