Lesson 2: Designing an Authorization Strategy

Once users have been authenticated, they’ll want to access resources on your site. For example, for users to be able to read HTML files, they must be authorized to access those files and the directories that contain the files. Authentication alone doesn’t provide users with the rights they need to access these resources. As a result, you must a develop an authorization strategy that will provide users with these rights without compromising the security of other resources on your network. In this lesson you’ll learn what factors you must consider when designing an authorization strategy. You’ll also learn how to set up your NTFS and IIS security to support authorization.

After this lesson, you will be able to

• Describe how access to resources is granted to Web clients
• Determine how users will be authorized to access resources on your Web site

Estimated lesson time: 25 minutes

User Authorization

In a Windows 2000 domain, authorization refers to the process of allowing a user to access resources in your network. Unlike authentication, which verifies the identities of the users and allows them initial access to the operating system, authorization allows access to specific Web sites, directories, and files (by configuring IIS permissions) and specific NTFS files and folders (by configuring NTFS permissions). However, in order for a user to be authorized to access a resource, that user must first be authenticated.

Configuring user authentication is a complex process, particularly when implementing distributed applications in a multitiered environment. You must take into account considerations such as delegation, application access, application topology, clustering, and a number of other factors, depending on your network configuration and security requirements. This lesson provides an overview of how to plan your authentication; however, you should review other resources as well to acquire a complete picture.

Overview of Access Process

When a user attempts to access a resource through IIS, a number of sequential events occur, as shown in Figure 10.6. The following sections describe these various events.

Figure 10.6 - Accessing resources through IIS

1. IP Address Access Control

When a request is made for a resource, IIS determines whether the client’s Internet Protocol (IP) address should be denied access to the Web site or virtual directory. You can configure IIS to grant or deny access to specific IP addresses, networks, or domain names. You can either grant access to all computers except those specifically listed, or you can deny access to all computers except those specifically listed. However, keep in mind that some users might try to access your site through proxy servers or firewalls—in which case the incoming connection will appear to have originated from the proxy server or firewall.

2. IIS Authentication

If IIS accepts a user’s IP address, the user is authenticated by one of the following authentication methods supported by IIS: Anonymous, Basic, Integrated Windows, Digest, or client certificate mapping. A successful logon must meet the following criteria:

• Valid username and password
• No applicable Windows 2000 account restrictions (such as time of day allowed to log on)
• Account not disabled or locked out
• Account password not expired
• An applicable logon policy (such as Log On Locally)

3. IIS Authorization

Once a user is authenticated, IIS determines what permissions have been assigned to the resource that the user is trying to access. In IIS, Web permissions apply to all users trying to access one of the site’s resources. Only NTFS permissions can be configured to apply to a specific user or group of users. For example, if you configure a Web site to support the Read permission, all users who are authenticated to access that site are granted the Read permission unless NTFS permissions restrict which users can access that site. IIS and NTFS permissions are discussed in more detail later in this section.

4. Custom Application Authentication

Some organizations develop their own methods for authenticating users. For example, they might use Internet Server Application Programming Interface (ISAPI) filters or Active Server Pages (ASP) applications to support a custom authentication scheme. If custom authentication is used, users are authenticated after they’ve been authorized by IIS.

5. NTFS Authorization

At the base of the IIS access model is NTFS security. IIS uses the authenticated user’s security context to try to gain access to a specific resource. For anonymous users, the IUSR_computername account is used. For authenticated users, a valid Windows account is used. If NTFS permissions don’t allow specific accounts to access a resource, users associated with those accounts can’t access that resource, even if they’ve been authenticated and authorized by IIS. NTFS permissions are discussed in more detail later in this section.

Planning IIS Permissions

As mentioned earlier, IIS permissions apply to all users who are authenticated to access a Web site. IIS permissions control access to virtual directories, whereas NTFS controls access to physical directories. You can set IIS permissions on Web sites, virtual directories, directories, and files. Table 10.2 describes the types of permissions that you can configure through IIS. Note that the Directory Browsing permission and the Index This Resource permission aren’t available as file-level permissions.

Table 10.2 IIS Permissions

Permission	Description
Script Source Access	Users can access the source code for files, such as the scripts in an ASP application. This permission is available only if the Read permission or the Write permission is selected. If the Read permission is selected, the user can read source code. If the Write permission is selected, the user can write to source code.
Read	Users can view file content and properties. This permission is selected by default.
Write	Users can change file content and properties.
Directory Browsing	Users can view files lists and collections.
Log Visits	A log entry is created for each visit to the Web site, directory, or file.
Index This Resource	The Indexing Service can index this resource.

IIS permissions also allow you to set up how executable content (such as ASP pages) in a directory will operate. Table 10.3 describes the types of executable permissions that you can configure through IIS.

Table 10.3 IIS Executable Permissions

Permission	Description
None	No scripts or executables can run in this directory.
Scripts Only	Scripts can run in this directory, without having Execute permission. Use the Scripts Only permission for directories that contain ASP pages, Internet Database Connector (IDC) scripts, or other scripts.
Scripts and Executables	Executables and scripts can run in this directory, including .asp, .dll, and .exe files.

Note that if both IIS and NTFS permissions are set, the most restrictive settings take effect. For example, if you disable the IIS Read permission on a file, users won’t be able to view that file, even if they’re explicitly granted NTFS permissions.

Planning NTFS Permissions

NTFS permissions are based on how access to Windows 2000 objects is controlled. As you learned in Lesson 1, "Designing an Authentication Strategy," once a user is authenticated, Windows 2000 attaches a security token to all processes (applications) that the user runs. The token identifies the user and the Windows groups to which the user belongs. If the user tries to access a file, Windows 2000 compares the user information in the token to the information with the object’s ACL.

Each object in Windows 2000 contains a security descriptor, which is the access control information associated with that object. When a user tries to access the object, Windows 2000 examines the security descriptor to determine whether the user is allowed to access the object and what action the user is allowed to take with that object. A security descriptor is a binary data structure that contains the following parts:

• Header Contains a revision number and a set of control flags that describe the security descriptor’s characteristics.
• Owner Contains the security identifier (SID) for the object’s owner.
• Primary Group Contains the SID for the owner’s primary group.
• Discretionary Access Control List (DACL) Contains a list of access control entries (ACEs). Each ACE includes a header that specifies whether the ACE allows or denies access, a SID that identifies a particular user or group, and information about which operations are allowed or denied.
• System Access Control List (SACL) Contains a list of ACEs used to audit access to an object.

The DACL controls access to the specific object. For example, if an authenticated user tries to access a directory, the security token attached to the IIS process is compared to the information in the DACL to determine whether that user has permission to access that directory. Figure 10.7 provides an overview of the authorization process that occurs when a user tries to access a directory in an NTFS partition.

You can control the information in the DACL by setting NTFS directory and file permissions, which allows you to secure individual files and directories from unauthorized access. Table 10.4 describes the types of NTFS permissions that you can configure in the DACL of a file or directory. You can either allow or deny each of these permissions. Denied permissions take precedence over allowed permissions.

When you define NTFS permissions, you must first select the specific users and groups to which you’ll grant or deny access, and from there, you must specify the access permissions for each user or group. Make sure you remove all unnecessary users and groups from the DACL, as well as remove groups that are too general for your purpose. However, be careful about removing the Everyone group because removing it can cause even nonanonymous access to fail. To support nonanonymous access, you should grant the Full Control permission to the Administrator, Creator/Owner, and System accounts. In addition, you should grant the appropriate permissions to any authenticated users or groups that will be accessing the resource.

Figure 10.7 - Accessing an NTFS directory through IIS

Table 10.4 NTFS Permissions

Permission	Description
Full Control	Users can modify, add, move, and delete files, their associated properties, and directories. They can change permission 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 directory’s content.
Read	Users can view files and file properties.
Write	Users can write to a file.

Making a Decision

When authorizing users to access Web resources, you must configure IIS permissions and NTFS permissions. Table 10.5 provides an overview of the considerations that you should take into account when setting up permissions.

Table 10.5 IIS and NTFS Permissions

Type of Permissions	Considerations
IIS permissions	IIS permissions apply to all users authenticated to access your Web site. You can set permissions on individual Web sites, virtual directories, directories, and files.
NTFS permissions	NTFS permissions apply to specific users and groups. You can set permissions on individual directories and files. You can either allow or deny each type of NTFS permission. Denied permissions take precedence over allowed permissions.

Recommendations

An authorization strategy is unique to the organization that’s implementing the Web site. However, whatever strategy you implement, you must take into account the following characteristics of IIS and NTFS permissions:

• IIS permissions apply to all users, and NTFS permissions apply to specific users and groups. If your site supports anonymous users, you must ensure that the appropriate NTFS permissions are granted to the IUSR_computername account. If your site supports nonanonymous users, you must ensure that the appropriate NTFS permissions support those specific users or groups of users.
• If IIS permissions and NTFS permissions are in conflict, the most restrictive permissions are used. You must make sure that both IIS and NTFS permissions are configured in a way that prevents conflict.
• Deny permissions take precedence over allow permissions. If you deny access to an NTFS directory to a specific user, it doesn’t matter what IIS permissions you grant. The user won’t be able to access that directory. Also, if a user or group isn’t included in the NTFS permissions, Windows 2000 interprets this as meaning that the user or group is being denied access to that directory, and directory access is denied.

You should remove all unnecessary users and groups. For example, suppose you have a Web site that supports anonymous and nonanonymous users. However, you want only the nonanonymous users to be able to access a specific directory. You grant Read permission in IIS to that directory, and you grant Read permission in NTFS to the nonanonymous users. However, you fail to remove the Everyone group in the DACL for the directory. As a result, all users will have access to that directory.

Example: Authorization Strategy for Wide World Importers

Wide World Importers implemented a Web site that supports anonymous users and a set of users who must enter a name and password in order to log on to secure areas of the site. Administrators at the company created a separate virtual root for the secure information. In addition, they created a user group (PrivateUsers) to contain all the users who had to be authenticated. As a result, the administrators had to develop two authorization strategies: one for the anonymous users and one for the nonanonymous users. The site supports static content only.

The administrators assigned the following IIS permissions to both the public site and the private site:

• Read
• Log Visits
• Index The Resource

However, they assigned different NTFS permissions to each site. Table 10.6 shows the permissions that were assigned to each user and group in the Public site.

Table 10.6 NTFS Permissions for the Public Site

User or Group	Type of Permission
Administrators	Full Control
System	Full Control
Creator/Owner	Full Control
IUSR_computername	Read

Table 10.7 shows the permissions that were assigned to each user and group in the Private site.

Table 10.7 NTFS Permissions for the Private Site

User or Group	Type of Permission
Administrators	Full Control
System	Full Control
Creator/Owner	Full Control
PrivateUsers	Read

Lesson Summary

Authorization allows access to specific Web sites, directories, and files (by configuring IIS permissions) and specific NTFS files and folders (by configuring NTFS permissions). When a user attempts to access a resource through IIS, a number of sequential events occur, including IP address access control, IIS authentication, IIS authorization, custom applications authentication, and NTFS authorization. IIS permissions apply to all users who are authenticated to access a Web site. You can set IIS permissions on Web sites, virtual directories, directories, and files. NTFS permissions are specific to users and groups. When a user tries to access the object, Windows 2000 examines the object’s DACL to determine whether the user is allowed to access the object and what action the user is allowed to take with that object. You can control the information in the DACL by setting NTFS directory and file permissions, which allows you to secure individual files and directories from unauthorized access. When you define NTFS permissions, you must first select the users and groups to which you’ll grant or deny access, and from there you must specify the access permissions for each user or group. If IIS permissions and NTFS permissions are in conflict, the most restrictive permissions are used.