Site and content rules
You can grant or deny access to the Internet by creating site and content rules. Site and content rules determine if and when content on specific destination sets can be accessed by users or client address sets.
When a client requests an object, Microsoft Internet Security and Acceleration (ISA) Server checks the site and content rules. If a site and content rule specifically denies the request, access is denied. Furthermore, the request will be fulfilled only if a site and content rule specifically allows the client access to the content and if the client is allowed to communicate using the specific protocol. In other words, to allow access to the Internet, you must perform the following steps:
1. | Create a site and content rule indicating clients that are allowed access to specific destination sets. |
2. | Create a protocol rule indicating which protocols can be used to access the specific destinations. |
For configuration instructions, see Create a site and content rule.
Processing order
Although site and content rules are not ordered, rules that deny access are processed before rules that allow access. For example, if you create two rules, one of which allows access to all clients and one of which denies access to all users in the Sales department, the Sales department cannot gain access to the Internet.
For more information on how ISA Server processes requests, see Controlling outgoing requests and Rules and authentication.
Action
Site and content rules can either allow or deny access to specific sites. If access is denied, then for Hypertext Transfer Protocol (HTTP) objects, the request can be redirected to an alternate Uniform Resource Locator (URL)—typically a page on an internal server—explaining why access is denied.
When you specify the destination to which to redirect the request, you can specify a whole different location by typing http:// and then the URL of the location to which to redirect the request.
When access is denied, ISA Server sends the URL specified here to the Web browser client. The client Web browser then tries to access the object from the destination to which ISA Server redirected.
For example, suppose a site and content rule denies access to http://example.microsoft.com/, redirecting requests for this site to http://widgets.microsoft.com/accessdenied.htm. When a client requests an object on http://example.microsoft.com/, ISA Server denies the request, and returns http://widgets.microsoft.com/accessdenied.htm to the client. The client then requests http://widgets.microsoft.com/accessdenied.htm.
Important
| • | If you choose to redirect the request, then the URL that you specify must be accessible to the selected clients or users. In other words, either the URL must be on an internal computer or some rule must explicitly allow access to the URL. |
For more information, see Configure an action for a site and content rule.
Destination sets and path processing
When you create a site and content rule, you specify which destinations are accessible. Destination sets can include Internet protocol (IP) addresses of specific computers or computer names. In either case, you can specify a particular path on the computer to include in the destination set. For more information, see Configuring destination sets.
ISA Server processes the site and content rule differently, depending on which type of client requests the object and what type of content is requested. In particular, ISA Server may ignore any path specified in the destination set, for particular clients or protocols used. The table below details whether ISA Server processes the path specified for the computers in the destination set.
| Web Proxy client | Secure network address translation (SecureNAT) client | Firewall client | |
File Transfer Protocol (FTP) content | Yes | No | No |
HTTP content | Yes | Yes | Yes |
Secure Hypertext Transfer Protocol (HTTPS) content | No | No | No |
This is true only when the HTTP is enabled and configured to redirect to the local Web Proxy service. For more information, see HTTP redirector filter.
When ISA Server processes a request for which path processing is not supported (for example, any non-HTTP request), ISA Server ignores all destinations for which a path is specified. This does not imply that ISA Server ignores the rule that references the destination. For example, assume that you have a rule that denies access to two destinations: //example.microsoft.com/example and widgets.microsoft.com. A request to access Network News Transfer Protocol (NNTP) content from example.microsoft.com will not be denied. A request to access NNTP content from widgets.microsoft.com will be denied.
For Secure Hypertext Transfer Protocol (HTTPS) requests, if a rule denies requests to a destination that specifies a path, ISA Server denies all content on the computer, not limited to the path. For example, if a rule is configured to deny HTTPS access to example.microsoft.com/example, then ISA Server will deny access to all access at example.microsoft.com.
Array-level and enterprise-level site and content rules
Site and content rules can be created at both the array level and at the enterprise level. When an array policy is allowed, then its site and content rules can only further restrict enterprise-level site and content rules. The array-level site and content rules can only deny access to specific sites or content. For more information on enterprise policy, see Applying enterprise policy.
Example
If you want to deny access to all images in http://example.microsoft.com/stuff, create a site and content rule with the following properties:
| • | Set Destination set to a set that includes the following path: example.microsoft.com/stuff/* |
| • | Set Schedule to Always. |
| • | Set Action to Deny access to the requested site. |
| • | Set Applies to to All requests. |
| • | Set Content to the Images content group. |
For a deployment scenario that illustrates the use of protocol rules, see Firewall scenario.