IIS 7.0 : Implementing Access Control - NTFS ACL-based Authorization & URL Authorization

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019


As mentioned earlier, authorization is the second phase in the process of determining whether or not a client has the right to issue a particular request. Authorization refers to determining if the user identity determined during the authentication phase is allowed to access the requested resource.

IIS 7.0 provides several authorization mechanisms that can be leveraged to control access to resources:

  • NTFS ACL-based authorization By default, IIS 7.0 verifies that the authenticated user identity has the right to access the physical file or folder corresponding to the requested URL. This check is performed only for requests that map to physical files or directories and use authentication methods that produce Windows tokens. This authorization mechanism has multiple usage limitations that are discussed in detail later in this section.

  • URL Authorization The new IIS 7.0 URL Authorization role service enables applications to create declarative configuration-based rules to determine which authenticated users and/or roles have the right to access the Web site or specific URLs therein. This feature replaces the IIS 6.0 URL Authorization feature, which is no longer supported.

  • ASP.NET URL Authorization The ASP.NET URL Authorization feature, available since ASP.NET 1.0, is similar to IIS URL Authorization, with a slightly different configuration syntax and rule processing behavior. ASP.NET applications that use this feature today can configure it to control access to all Web site content when they run using ASP.NET integrated mode.

In addition, developers can provide custom authorization features by developing modules by using the IIS 7.0 native module APIs or the ASP.NET APIs for applications using ASP.NET Integrated mode. In fact, you can use most existing ASP.NET authorization modules immediately in applications that are using ASP.NET Integrated mode. This makes it significantly easier to develop custom authorization features that implement business authorization rules and can leverage the powerful ASP.NET membership and role infrastructures.

In the remainder of this section, we will review the authorization features in detail.

NTFS ACL-based Authorization

The IIS 7.0 server engine (rather than a module) automatically performs NTFS ACL-based authorization. During this authorization, the Web server checks that the authenticated user identity has the rights to access the physical file or folder being requested.


NTFS ACL-based Authorization is part of the IIS Web server core and therefore is always installed when the Web server is installed. Though it cannot be uninstalled or disabled, you can remove one of the requirements in the following list to configure your application to not use it.

This authorization occurs automatically when all of the following conditions are met:

  • The authenticated user identity must have a Windows token. If the request is authenticated using an authentication method that does not provide Windows tokens, for example Forms Authentication, this authorization is not performed.

  • The selected handler mapping for the request specifies a resource type of File, Directory, or Either. Some mappings use the resource type of Unspecified to enable requests to virtual URLs that do not have a corresponding physical resource on disk. For these handler mappings, this authorization is not performed.


    Most ASP.NET handler mappings are marked as Unspecified by default. However, ASP.NET includes additional functionality that ensures that if the URL maps to a physical file or folder, the access check is performed (with the exception of content located in a virtual directory that stores its files on a UNC path).

  • The request URL maps to a physical file or folder that exists on disk. If the file or directory does not exist, IIS does not perform the check.

  • The virtual directory corresponding to the request being made does not specify fixed access credentials. If the virtual directory specifies fixed credentials, they will be used to access all content for the virtual directory, and therefore IIS does not use the authenticated user to check access.

In addition, for you to successfully use NTFS ACL-based authorization, the following conditions must also be true:

  • The physical resources have ACLs configured to properly grant or deny access to each authenticated user. This is typically done by placing all of the allowed users in a group, and granting this group access to the content.

  • If the virtual directory corresponding to the request refers to a remote UNC share and does not specify fixed UNC credentials, the authenticated user identity must be able to delegate to the remote server. This requires basic authentication, or requires Constrained Delegation or Protocol Transition to be configured.

Because of the aforementioned limitations and the overhead of managing NTFS ACL permissions for multiple users, NTFS ACL-based authorization is not recommended as a generic mechanism for restricting access to IIS resources. Use it only if your application meets the preceding requirements and you would like to use ACLs as an authorization mechanism (for example, if you are sharing static resources for users with domain or local machine accounts, and the resources already have the right permissions configured).

Because this authorization happens automatically for physical resources, you must configure all required resources to grant access to the authenticated identities that need to use your application.

URL Authorization

The IIS 7.0 URL Authorization feature is new in IIS 7.0. It provides a way to configure declarative access control rules that grant or deny access to resources based on the authenticated user and its role membership.


URL Authentication is not part of the default IIS install. You can manually install it from the Windows Features IIS feature category through Windows Features on Windows Vista or from the Security role service category of the Web Server (IIS) role in Server Manager on Windows Server 2008.

Unlike NTFS ACL-based authorization, URL Authorization has the following advantages:

  • It is not tied to authentication schemes that produce Windows identities. It can be used with any authentication schemes, including Forms Authentication, which produces custom authenticated user identities.

  • It enables rules to be configured for specific URLs, not underlying files or directories. Therefore, it is not tied to specific resource types and does not require files or directories to exist.

  • It stores authorization rules in the configuration, instead of NTFS ACLs. These rules are easier to create and manage, and they can be specified in distributed web.config files that travel with the application when it is deployed or copied between servers.

  • It integrates with the ASP.NET Membership and Roles services, which enables custom authentication and role management modules to provide the authenticated users and their roles. You can use ASP.NET Forms Authentication with Membership and Roles to quickly deploy a data-driven user and roles credential store for your application.


The IIS 7.0 URL Authorization feature is new. It is not related to the similarly named IIS 6.0 URL Authorization feature, which is overly complex, difficult to configure, and not widely used. The IIS 6.0 URL Authorization feature is not included with IIS 7.0.

The ASP.NET URL Authorization feature inspired the new URL Authorization feature, which implements similar functionality. However, some key differences exist in how rules are configured and processed. We’ll discuss these differences later in this section.

Using URL Authorization to Restrict Access

To use URL Authorization to restrict access to your application, you need to configure one or more URL Authorization rules. These rules can be configured at the Web server level. Alternatively, you can configure them for a specific Web site, application, or URL. This makes it very easy to use URL Authorization to quickly restrict access to any part of your Web site to a specific set of users or roles.

These rules can be one of the following types:

  • Allow An allow rule grants access to the resource being requested and allows request processing to proceed.

  • Deny A deny rule denies access to the resource being requested, rejecting the request.

Both types of rules can specify a set of users, roles, and/or verbs that URL Authorization uses to match each rule to the request. As soon as a rule matches, the corresponding action (Allow or Deny) is taken. If the request is denied, URL Authorization will abort request processing with a 401 unauthorized response status code. If no rules matched, the request will also be denied.

Unlike ASP.NET URL Authorization, the deny rules are always processed before allow rules. This means that the relative order between deny and allow rules does not matter. In addition, the order between rules defined by parent configuration levels and the current configuration level does not matter, because all deny rules from all levels are always processed first, followed by all allow rules. Finally, the default behavior when no rules match is to deny the request.

By default, URL Authorization has a single rule configured at the Web server level that provides access to all users. You can restrict access to your Web site or a part of it by creating authorization rules by using the following techniques:

  • Remove the default allow rule for all users and create explicit allow rules only for users and roles that should have access to the current URL level. This way, by default, all requests will be denied unless the authenticated user or role matches the configured allow rule. This is the recommended practice, because it ensures that only the configured users and roles have access to the resource, and it denies access to everyone else.

  • Create explicit deny rules for users and roles that should not have access to the current URL level. This may be appropriate to prevent access for only the specific users and roles. However, it is not generally a secure practice, because the set of users and roles is typically unbounded. The exception to this rule is the technique of creating a deny all anonymous users rule to restrict access only to authenticated users.


When designing the access control rules for your application, prefer to grant access to roles instead of specific users. This makes it easier to manage authorization rules as more users are added.

See the following section titled “Creating URL Authorization Rules” for information on configuring URL Authorization rules.

Creating URL Authorization Rules

You can use IIS Manager to configure URL Authorization rules by selecting the desired node in the tree view and double-clicking Authorization Rules. In the resulting window shown in Figure 1, you can see the list of rules currently in effect at the level you selected, which will include both the rules configured at higher configuration levels and the rules configured at the current configuration level.

Figure 1. Configuring URL authorization rules.

You can remove existing authorization rules (including parent authorization rules that are not locked) by selecting them in the list and clicking Remove in the Actions pane. You can add an allow or deny rule by clicking Add Allow Rule or Add Deny Rule in the Actions pane. Figure 2 shows an allow rule that can be used to allow access to all users or specific users or roles.

Figure 2. Adding an Allow URL authorization rule.

You can also edit URL Authorization rules by configuring them directly in the system.webServer/security/authorization configuration section, by using Appcmd from the command line, or by using configuration APIs. This configuration section is unlocked by default to facilitate storing URL authorization rules in your application’s web.config files, which enables them to travel with the corresponding application content when deploying the application to another Web server.

To add a URL authorization rule with Appcmd, you can use the following syntax.

%systemroot%\system32\inetsrv\Appcmd.exe set config [ConfigurationPath]

To delete a URL authorization rule with Appcmd, you can use the following syntax.

%systemroot%\system32\inetsrv\Appcmd.exe set config [ConfigurationPath]

The parameters to these commands are shown in Table 1.

Table 1. Parameters for Adding URL Authorization Rule
ConfigurationPathThe configuration path at which this configuration is set.
usersThe comma-separated list of user names that this rule allows or denies. Each user name is matched with the user name of the authenticated user set for the request, and the rule matches as soon as a single user matches (or a role matches). For Windows identities that represent domain accounts, use the domain qualified user name format of “domain\user” rather than the fully qualified domain name format of “[email protected]”. Use “*” to refer to all users and “?” to refer to anonymous users. The default is “”.
rolesThe comma-separated list of roles that this rule allows or denies. Role membership for each role is tested for the authenticated user set for the request, and the rule matches as soon as a single role matches (or user matches). The default is “”.
verbsThe comma-separated list of verbs (case-sensitive) that matches the request verb. If specified, one of the verbs must match the request verb for the rule to apply. The default is “”.
accessTypeWhether the rule should allow or deny access. Accepted values are Allow and Deny. This parameter must be specified to add a rule.

Using ASP.NET Roles with URL Authorization

In applications using the ASP.NET Integrated mode, it is possible to configure the ASP.NET Roles feature to provide application-specific roles for each authenticated user. IIS 7.0 URL Authorization rules can specify access rules that use roles provided by the .NET Roles feature or another ASP.NET module to implement application-specific authorization schemes, much like the original ASP.NET URL Authorization feature. You can learn about setting up the ASP.NET Roles feature at

When the .NET Roles feature is enabled, and a role provider is configured for your application, you can begin configuring URL Authorization rules that rely on these roles in your application. To make sure that the roles are available for requests to non-ASP.NET content types, be sure to remove the managedHandler precondition from the RoleManager module. For information about enabling managed modules to run for all requests by removing the managedHandler precondition.

You can also create roles directly using IIS Manager by selecting the application node in the tree view and then clicking.NET Roles. In the resulting page, you can manage existing roles, create new roles using the configured Role provider for the application, and associate application users with roles.

Top 10
Free Mobile And Desktop Apps For Accessing Restricted Websites
TOYOTA CAMRY 2; 2.5 : Camry now more comely
KIA SORENTO 2.2CRDi : Fuel-sipping slugger
How To Setup, Password Protect & Encrypt Wireless Internet Connection
Emulate And Run iPad Apps On Windows, Mac OS X & Linux With iPadian
Backup & Restore Game Progress From Any Game With SaveGameProgress
Generate A Facebook Timeline Cover Using A Free App
New App for Women ‘Remix’ Offers Fashion Advice & Style Tips
SG50 Ferrari F12berlinetta : Prancing Horse for Lion City's 50th
- Messages forwarded by Outlook rule go nowhere
- Create and Deploy Windows 7 Image
- How do I check to see if my exchange 2003 is an open relay? (not using a open relay tester tool online, but on the console)
- Creating and using an unencrypted cookie in ASP.NET
- Directories
- Poor Performance on Sharepoint 2010 Server
- SBS 2008 ~ The e-mail alias already exists...
- Public to Private IP - DNS Changes
- Send Email from Winform application
- How to create a .mdb file from ms sql server database.......
programming4us programming4us