Troubleshooting Web Access for Internal Clients

  • Article

This document describes a troubleshooting strategy for common issues with outbound Internet requests from internal clients. Typical symptoms you might experience in this scenario include the following:

  • No internal users have Internet access.
  • Specific Web sites are not available to internal users, or parts of Web sites are not appearing as expected.
  • Specified users have no Internet access.
  • Access rules are not allowing or denying traffic as expected.

This document provides the following methods for troubleshooting outbound issues:

  • Run the Microsoft® Internet Security and Acceleration (ISA) Server Best Practices Analyzer tool. The ISA Server Best Practices Analyzer scans the configuration settings of the local ISA Server computer and reports issues that do not conform with recommended best practices. It can run on any computer with Microsoft .NET Framework 1.1 installed and one of the following versions of ISA Server:
    • ISA Server 2006 Standard Edition
    • ISA Server 2006 Enterprise Edition
    • ISA Server 2004 Standard Edition
    • ISA Server 2004 Enterprise Edition
      For ISA Server Enterprise Edition, run the ISA Server Best Practices Analyzer on each array member.
  • Work through a troubleshooting flowchart that helps you troubleshoot typical symptoms of outbound Web access issues.
  • Work through a question and answer list of typical known errors that customers have experienced.

Running the ISA Server Best Practices Analyzer

The first step in troubleshooting outbound client issues is to install and run the ISA Server Best Practices Analyzer, as follows:

  1. Download the ISA Server Best Practices Analyzer from the Microsoft Download Center. Installation files are copied to the %SystemDrive%\Program Files\IsaBPA folder.
  2. Run the tool from the Start menu. To do this, click Start, point to All Programs, point to Microsoft ISA Server, point to ISA Tools, and then click ISA Server Best Practices Analyzer. Click Start a scan to run the tool.
  3. Fix the issue. When you run the ISA Server Best Practices Analyzer, each error or warning has an associated Help topic, with instructions about how to fix the issue.

Using the troubleshooting flowchart

The following flowchart guides you through steps to troubleshoot outbound Web access issues. The flowchart helps you to identify where in the deployment process the issue occurs, the scope of an issue, and the general symptoms you may experience. If you do not know what the issue is, work your way through each of the troubleshooting sections.

Installation issues

For problems with outbound Web access following installation, check the following steps:

  1. Understand the ISA Server network model required to configure and allow outbound Web access.
  2. Understand what access is allowed and denied by the default rules following installation.
  3. Create a rule to allow outbound access.
  4. Check the order of access rules to be sure that the rule allowing outbound access is applied correctly.
  5. Check the ISA Server log to verify that traffic is being allowed.

The following sections discuss each of these steps.

Step 1: Understand the ISA Server network model

Ensure that you understand the network model used by ISA Server to define different networks, and enable traffic to flow between them. ISA Server requires the following rules to allow rtaffic:

  • **Network rules   **Networks bound to ISA Server require a network rule to communicate. A network rule determines whether there is a relationship between two networks, and the type of relationship defined. If there is no network rule defined between two networks, ISA Server drops all traffic sent between them.
  • **Access rules   **When a relationship between networks has been defined by means of a network rule, you must define an access rule that specifically allows hosts in different networks to communicate.

For more information, see "Network Concepts in ISA Server 2006" at the Microsoft TechNet Web site.

Step 2: Understand default rules following installation

ISA Server is secure by default following installation, and client access is blocked. The following rules are defined:

  • There is a default network rule named Internet Access. This rule defines a network address translation (NAT) relationship between all predefined ISA Server networks and the External network. This means that networks can communicate, and traffic between the networks has NAT applied to it. For more information, see the section "Network Rules" in "Network Concepts in ISA Server 2006" at the Microsoft TechNet Web site.
  • There is a default access rule named Last that denies all traffic. This rule is always processed last in the rules list, and it cannot be deleted. You must specifically create an access rule to allow internal users to access the Internet.

Step 3: Create an outbound access rule

You must create an access rule to allow internal clients outbound access to the Internet. There are two ways to do this:

  • You can apply a network template that most closely matches your network configuration. When you apply a network template, you can choose a number of policies for the template that create access rules automatically. For more information about running the Network Template Wizard to configure your firewall, see the section "Network Templates" in "Network Concepts in ISA Server 2006" at the Microsoft TechNet Web site.
  • You can create an access rule manually.
    To create an access rule to allow outbound Internet access

    1. In ISA Server Management, right-click the Firewall Policy node, point to New, and then click Access Rule.

    2. On the Welcome page of the New Access Rule Wizard, type a name for the rule. Then click Next.

    3. On the Rule Action page, click Allow. Then click Next.

    4. On the Protocols page, leave the default Selected protocols, and then click Add.

    5. In the Add Protocols dialog box, expand Web.

    6. Select the protocols you require. For example, to allow HTTP, HTTPS, and FTP outbound access, select FTP, and then click Add. Select HTTP, and then click Add. Select HTTPS, and then click Add. Note that the FTP Server and HTTPS Server protocols are not used for outbound access. Then click Close. On the Protocols page, click Next.

    7. On the Access Rule Sources page, click Add.

    8. In the Add Network Entities dialog box, expand Networks.

    9. Select the network source from which traffic will originate. For example, if you want to allow clients located in the Internal network to access the Internet, select Internal. Click Add, and then click Close. On the Access Rule Sources page, click Next.

    10. On the Access Rule Destinations page, click Add.

    11. In the Add Network Entities dialog box, expand Networks.

    12. Select the network destination to which traffic will go. For example, if you want to allow clients located in the Internal network to access the Internet, select External. Click Add, and then click Close. On the Access Rule Destinations page, click Next.

    13. On the User Sets page, specify users that can access the Internet using this rule. To allow anonymous access for all users, leave the default All Users setting. To specify that only users that are authenticated can access the Internet using this rule, click Add. In the Add Users dialog box, select All Authenticated Users. Click Add, and then click Close. In the User Sets dialog box, select All Users, and then click Remove. Then click Next. The All Authenticated Users set represents all users that can be authenticated, regardless of the authentication method used.

    14. On the Completing the New Access Rule Wizard page, check the settings, and then click Finish to complete the wizard.

    15. In ISA Server Management, click Apply to apply the rule.

Step 4: Check access rule order

If you have created an access rule to allow client access to the Internet, and traffic is not flowing as expected, check that that the rules are ordered correctly. For example, if there is a deny rule blocking access to the site and this rule appears in the rule list before the rule allowing access, the deny rule will be processed first and traffic will be blocked. Your rules should follow this order from the top of the rule list:

  1. Global deny rules, which are rules that deny access to all users.
  2. Global allow rules, which are rules that allow specific access to all users.
  3. Rules that allow or deny access to specific computers.
  4. Rules that allow or deny specific users, URLs, and MIME types.
  5. Other allow rules.
  6. Default deny rule, which is at the bottom of the list. Requests that are not matched by any other rule in the list are blocked by this rule.

Step 5: Check the log

  • Check the ISA Server log to see what rule is denying the traffic. For example, to check what rule is denying outbound Simple Mail Transfer Protocol (SMTP) traffic, do the following.

To run the log filter

  1. In the console tree of ISA Server Management, click Monitoring.

  2. In the details pane, click the Logging tab.

  3. On the Tasks tab, click Edit Filter.

  4. To log all SMTP traffic, do one of the following:

    • In Filter by, select Destination Port, and then in Condition, select Equals. Then in Value, type 25.
    • Alternatively, in Filter by, select Protocol, and then in Condition, select Equals. Then in Value, select SMTP.

  5. Click Add to List, and then click Start Query.

  6. Try to send SMTP mail, and then monitor the Logging tab to check the query results.

The logging query may show a number of results. For example, the query may show that ISA Server is letting traffic through.

Bb794787.5ba6178f-052b-4a46-bc43-2a810473ce93(en-us,TechNet.10).gif

The query can also show that traffic was denied.

Bb794787.cb435749-6819-4a93-8bec-b5f5f83cb14d(en-us,TechNet.10).gif

If there is no rule available, this may be indicated in the log query.

Bb794787.ef7959d2-a21a-4ad7-af3c-1ea8ae556118(en-us,TechNet.10).gif

Specific site issues

If internal clients are unable to access specific Web sites, check the following steps:

  1. Use PING to check access to the external Web site.
  2. Check Domain Name System (DNS) settings for name resolution issues.
  3. Check access rules.

Step 1: Verify that PING is allowed from the ISA Server computer to the external Web site

Check whether you have access to the Internet by using PING to access the fully qualified domain name (FQDN) of the Internet server (for example, www.microsoft.com). ISA Server provides a number of predefined system policy rules that allow traffic to and from the ISA Server computer. One of these rules allows PING from the ISA Server computer to all networks. This rule is enabled by default. Verify that the default setting is specified as follows.

To verify that PING is allowed from the ISA Server computer

  1. In ISA Server Management, right-click the Firewall Policy node, and then click Edit System Policy.

  2. In the Configuration Groups list, click ICMP in the Diagnostic Services group. Verify that Enable this configuration group is selected on the General tab.

Using the PING protocol to access the FQDN consists of the following actions:

  • The FQDN is resolved to an IP address.
  • PING accesses the FQDN using the IP address.
  • If an IP address appears, and PING is not successful, this may indicate that the server is not available. If the IP address does not appear, a name resolution issue may be occurring.

Step 2: Check DNS settings

If PING indicates a possible name resolution issue, check whether the issue originates with the ISA Server computer, or with the client computer, as follows:

  • If the client computer requesting the Web site is a Web Proxy client (usually with browser settings set to use ISA Server as a proxy) or a Firewall client application, ensure that the DNS server used by ISA Server to resolve external names is able to resolve the name of the Internet site.
  • If the client computer requesting the Web site is a SecureNAT client (with only a default gateway pointing to the ISA Server computer) or a client computer directly accessing the site without going through ISA Server, check the DNS server settings specified in the TCP/IP parameters of the client. Ensure that the DNS server used by the client is able to resolve the Internet site FQDN name to an IP address.

For more information about ISA Server clients, see "Internet Client Concepts in ISA Server 2006" at the Microsoft TechNet Web site. The general information in this document also applies to ISA Server 2004.

Step 3: Check ISA Server access rules

If the Web site is available, the issue may be with ISA Server access rules. Check the following:

  1. An access rule is configured to allow access to the site.
  2. There is no access rule denying access to the site. In addition, check other network elements that reference the destination, such as computer sets, URL sets, and domain sets. If there is a rule denying access to the specific site, evaluate whether it is needed. If the deny rule is needed, check that the rule allowing access is placed higher in the rule order.
  3. If the access rule is not anonymous and requires users to authenticate, verify that the users who should be granted access by the rule are able to authenticate successfully. For more information about client authentication and access rules, see the next section, Client issues, in this topic.

Client issues

If specific clients are having issues accessing Web sites, check whether the issue is server-based or client-based, as follows:

  1. Understand how client requests are handled by ISA Server.
  2. Check that ISA Server can handle name resolution on behalf of clients.
  3. Ensure that clients are able to carry out name resolution if required.
  4. Check that clients are able to access ISA Server to make the request.
  5. If authentication is required on the listener, check that clients are able to authenticate.
  6. If authentication is required by the rule, check that clients are able to authenticate.

Step 1: Understand client requests

ISA Server supports the following types of clients:

  • Firewall clients   Firewall client computers are those with Firewall Client software installed. Internet requests from these clients go through ISA Server, and ISA Server handles name resolution. The only exception is when Firewall clients make requests for local resources in their own network, or when sites in other networks are set up for direct access. In this case, requests bypass ISA Server, and the client handles name resolution. For the ISA Server computer to handle name resolution, it must be able to contact a DNS server to resolve external names on behalf of the client. For the client to handle name resolution for local resources or sites that bypass ISA Server, the client must be able to access a DNS server that can resolve internal and external names. With each request sent to ISA Server, Firewall clients automatically send credentials with the request.
  • Web Proxy clients   Web Proxy clients are client computers with proxy settings pointing to the ISA Server computer. By default, HTTP requests from Firewall clients and SecureNAT clients are handled transparently by Web Proxy Filter and are also treated as Web proxy requests. Internet requests from these clients go through Web Proxy Filter, and ISA Server handles name resolution. The only exception is when sites are set up for direct access, and then the client handles name resolution. Web Proxy clients send credentials only when requested.
  • SecureNAT clients   SecureNAT client computers have a default gateway, either directly or indirectly, pointing to the ISA Server computer. These clients do not rely on ISA Server for name resolution. SecureNAT clients cannot provide authentication credentials.

For troubleshooting purposes, it is important to understand how all types of internal clients make requests, resolve names, and provide credentials. For more information, see "Internet Client Concepts in ISA Server 2006" at the Microsoft TechNet Web site.

Step 2: Verify ISA Server name resolution

If Web Proxy clients or Firewall clients cannot access Web sites, check that ISA Server is able to contact a DNS server to resolve Internet names. For more information, see "Configuring DNS Servers for ISA Server 2004" at the Microsoft TechNet Web site.

Step 3: Verify client name resolution

Check that clients can perform name resolution as follows:

  • SecureNAT clients handle their own name resolution. Ensure that they are able to connect to a DNS server for Internet name resolution.
  • Name resolution for sites specified for direct access is handled directly by the client computer. Ensure that the TCP/IP settings for the client point to a DNS server. This server should be available and be able to resolve the destinations specified in direct access requests, or point to a DNS server that can. For more information about direct access sites, see "Internal Client Concepts in ISA Server 2006" at the Microsoft TechNet Web site.

Step 4: Check that clients can contact ISA Server

Check that clients can contact ISA Server as follows:

  • SecureNAT clients rely on routing to locate the ISA Server computer that they should use. In simple networks, the default gateway of such clients should point to the IP address of the network adapter associated with the ISA Server network in which the client is located. In complex networks, the default gateway should point to intermediate routes or switches so that Internet requests are sent through ISA Server.
  • For clients making Web proxy requests to ISA Server, ensure that Web proxy browser settings are configured correctly. If an automatic configuration script is used, or a Web Proxy Automatic Discovery (WPAD) entry is configured for automatic detection, ensure the mechanism is working as expected. For more information, see "Automatic Detection Concepts in ISA Server 2006" at the Microsoft TechNet Web site and "ISA Server: Troubleshooting Automatic Detection" at the Microsoft TechNet Web site.
  • Check that Firewall clients are configured with the ISA Server computer that they should use for Internet requests. On the Firewall client computer, the Firewall client dialog box can be accessed from the Microsoft Windows Server® taskbar. If Firewall clients are set up to use automatic discovery, read about common automatic discovery issues in "Automatic Detection Concepts in ISA Server 2006" at the Microsoft TechNet Web site and "ISA Server: Troubleshooting Automatic Detection" at the Microsoft TechNet Web site.
  • Ensure that Firewall client computers have the latest configuration settings specified on the ISA Server computer. Clients receive an updated configuration from the ISA Server computer each time a client computer is restarted, when a manual refresh is activated on the Firewall client computer, or every 6 hours after an initial refresh is made. To force a manual refresh in Firewall Client for ISA Server 2004, click Detect Now on the Settings tab of the Firewall client dialog box. For later versions of Firewall client, click Apply Default Settings Now on the Settings tab. When the configuration is updated, Web proxy settings specified on the ISA Server computer for Firewall clients are updated. To get a printout of current configuration settings on a Firewall client computer, run the Firewall Client Tool (fwctool.exe) located in the Firewall Client installation folder. For Firewall Client for ISA Server 2004, you can download this tool from the Microsoft Download Center. Instructions are included in the Help documentation downloaded with the tool.

Step 5: Check listener authentication settings

  • Check whether Web Proxy Filter for the network on which clients are located requires authentication. If authentication is enabled, any client making a request through Web Proxy Filter will be required to authenticate. This will affect Web clients with Web proxy browser settings pointing to ISA Server, or Firewall client and SecureNAT clients making HTTP requests that are handled transparently by Web Proxy Filter. Check the network setting as follows.

To check listener authentication settings

  1. In ISA Server Management, expand the Configuration node, and then click Networks.

  2. On the Networks tab in the details pane, right-click the network in which clients are located (usually the Internal network), and then click Properties.

  3. On the Web Proxy tab, click Authentication.

  4. In the Authentication dialog box, check whether Require all users to authenticate is enabled.

If authentication is required, note that computers configured as SecureNAT clients with their default gateway pointing to ISA Server cannot authenticate. If Require all users to authenticate is enabled, requests from these clients will be denied before rules are evaluated.

Step 6: Check access rule authentication settings

If you require authentication on an access rule allowing outbound client access, check the following:

  • Computers configured as SecureNAT clients cannot authenticate and will not be allowed access if the rule requires authentication. For SecureNAT clients, an anonymous allow rule is required.
  • Ensure that Web Proxy clients and Firewall clients are able to comply with the authentication requirements of the access rule.

Single network adapter issues

When running ISA Server on a computer with a single network adapter, check the following:

  • Understand what outbound scenarios are supported. These include:
    • Forwarding Web proxy requests from internal clients (HTTP, HTTPS, or FTP) for downloads. Firewall client requests are not supported with a single network adapter.
    • Caching Web content for use by clients on the corporate network.
    • For more information about supported scenarios, see "Configuring ISA Server 2004 on a Computer with a Single Network Adapter" at the Microsoft TechNet Web site. The information in this article also applies to ISA Server 2006.
  • In a single network adapter environment, ensure that any edge firewall device is configured to forward relevant Internet requests from ISA Server to the Internet.
  • We recommend that you apply the Single Network Adapter network template. To verify the network template you have applied, and to apply the single network template, do the following.

To apply the Single Network Adapter network template

  1. In ISA Server Management, expand the Configuration node, and then click the Networks node.

  2. In the details pane, click the Network Rules tab. The graphic on the tab displays the name of the network template currently applied.

  3. To apply the Single Network Adapter network template if required, click the Templates tab, and then select the Single Network Adapter option.

  4. On the Welcome to the Network Template Wizard page, click Next.

  5. On the Export the ISA Server Configuration page, click Export, and then follow the instructions in the Export Wizard. After completing the Export Wizard, click Next.

  6. In the Internal Network IP Addresses page, the Internal network IP address range is predefined for the Single Network Adapter network template. By default, this includes all IP addresses except 0.0.0.0, 255.255.255.255, and the address ranges of the Local Host network (127.0.0.0–127.255.255.255).

  • In a single network adapter scenario, ISA Server is only aware of two networks: the Local Host network that represents the ISA Server computer itself, and the Internal network. When an internal client browses the Internet, ISA Server sees the source and destination addresses of the Web request as belonging to the Internal network. After applying the Single Network Adapter network template, rules should be configured as follows:
    • A default deny rule is configured, and no Internet access is allowed.
    • When you create a rule to allow access, the source defined in an access rule should consist of actual Internet IP addresses. This is required because in a single network adapter configuration, every IP address is considered part of the Internal network, apart from the loopback address and the Local Host network range. For more information about defining ISA Server network elements for IP addresses, see the section "Predefined Network Objects" in "Network Concepts in ISA Server 2006" at the Microsoft TechNet Web site.
    • The destination defined in an access rule should either be the Internal network or the specific destination IP address.
    • Even with the Single Network Adapter network template applied, ISA Server still protects itself (the Local Host network) from the Internal network. There are a number of predefined system policy rules that allow traffic to and from the Local Host network. To allow other traffic, you must create explicit access rules.
    • To accept outbound Web requests from internal clients, Web Proxy Filter for the Internal network must be enabled to listen for Web Proxy client requests. For more information, see the section "Configuring Network Properties" in "Network Concepts in ISA Server 2006" at the Microsoft TechNet Web site.
    • If Web pages include items that require use of protocols other than HTTP and FTP (download), Web Proxy clients accessing the site in a single network adapter scenario will not be able to access these items. One workaround is to configure direct access to these sites. For more information, see "Internal Client Concepts in ISA Server 2006" at the Microsoft TechNet Web site.

Network configuration issues

If ISA Server network settings are incorrectly configured, internal users may not be able to access the Internet. Common issues to check include:

  • Configuring ISA Server networks correctly is pivotal for successful deployment. For more information about understanding ISA Server network architecture, see the following resources at the Microsoft TechNet Web site:
  • If client requests are not being handled as expected, check that networks are configured correctly. In particular, note the following:
    • Each ISA Server network must have a network adapter associated with it. Each adapter should only be associated with one ISA Server network. If you add a custom ISA Server network, you must have a unique network adapter to associate with it.
    • A network definition should include all IP addresses that can be reached directly from the associated network adapter, including remote subnets. Do not create separate networks for remote subnets physically connected to local subnets.
    • The IP address range of the ISA Server network should match the routing table. Persistent static routes should be defined in the routing table for each remote subnet.
    • Each IP address can only belong to one ISA Server network. Do not define ISA Server networks with overlapping IP address ranges.
    • ISA Server 2006 and ISA Server 2004 do not support multiple external network interfaces.
    • Dynamic IP addresses should only be used on the adapter associated with the external network.
    • Any IP address that is not contained in ISA Server-protected networks is considered part of the External network.

Access rule issues

Incorrectly configured rules may cause issues with Internet access. Check the following:

  • Verify that you have an access rule allowing traffic to required Web sites.
  • When you apply an ISA Server network template, access rules may be created automatically. Ensure that you have the correct template applied for your scenario, and that the rules are configured as required. For more information, see "Network Concepts in ISA Server 2006" at the Microsoft TechNet Web site.
  • Check the properties of access rules allowing the traffic. Questions to consider:
    • Is the protocol configured correctly?
    • Are the destination and source correctly configured in the rule?
  • Check that there is no deny rule being applied before an allow rule. Rules are matched in the order in which they appear in the rules list.
  • Check that your rules follow this order, from the top of the rule list:
    1. Global deny rules, which are rules that deny access to all users.
    2. Global allow rules, which are rules that allow specific access to all users.
    3. Rules that allow or deny access to specific computers.
    4. Rules that allow or deny specific users, URLs, and MIME types.
    5. Other allow rules.
    6. Default deny rule, which is at the bottom of the list. Requests that are not matched by any other rule in the list are blocked by this rule.

Infrastructure issues

Issues with infrastructure can affect IP address assignment and name resolution. Check the following:

  1. Following installation, ISA Server enables a set of default access rules, known as system policy rules. These system policy rules allow access to and from the ISA Server computer (the Local Host network), to infrastructure servers such as DNS and Dynamic Host Configuration Protocol (DHCP) servers. The system policy rules assume that these servers are located in the default Internal network. If they are not, system policy rules may not allow access as expected. For example, if you installed ISA Server on a domain controller, network access will not be configured to infrastructure services running on the ISA Server computer. (This does not refer to the Microsoft Windows® Small Business Server 2003 (Windows SBS) server software with ISA Server 2004 installation that uses the Configure E-mail and Internet Connection Wizard (sometimes known as CEICW).) For more information about default system policy rule settings, see "ISA Server System Policy" at the Microsoft TechNet Web site.
  2. Check that the ISA Server computer can connect to infrastructure servers.
  3. Check that DNS servers are configured as required. ISA Server requires name resolution for itself, and handles name resolution for Firewall clients and Web Proxy clients. A DNS server should be configured in the TCP/IP properties of the network adapter associated with the Internal network. You can use an internal DNS server to resolve internal and external names. You can also configure the internal DNS to forward requests to an external Internet service provider (ISP) DNS server. This requires an access rule to allow DNS traffic from the internal DNS server to the External network using the DNS protocol. For more information, see "Configuring DNS Servers for ISA Server 2004" at the Microsoft TechNet Web site.

Common issues

The following are common problems, possible causes, and suggested solutions for your review.

Allow anonymous access to specific sites

Problem Some users cannot access the Internet.

Cause Require all users to authenticate is enabled on the network listening for Web requests from users, so all user requests must be authenticated. Requests from users unable to authenticate (for example, users who are not members of a domain, or client computers configured as SecureNAT clients) are denied.

Solution Disable Require all users to authenticate. Instead, require authentication on access rules to sites to which you want to limit access. On sites for which you want to allow anonymous access, specify that rules should apply to all users.

Users have to authenticate multiple times

Problem Web Proxy clients in the Internal network have to present credentials more than once when making a Web request.

Cause This behavior can occur when Require all users to authenticate is enabled on the Internal network, and ISA Server connects to an upstream proxy for Web Proxy client requests. With these two conditions, a connection is always closed for a client connection request that requires authentication.

Solution If you disable Require all users to authenticate, the initial Web Proxy client request is kept alive. For more information, see the Microsoft Knowledge Base article 842686, "ISA Server 2004 does not maintain client credentials between requests."

Some Web site applications not opening as expected

Problem A public Web site has a link to resources that require Microsoft Windows Media® Player. The resources are not opening properly.

Cause Windows Media Player may be attempting to connect anonymously, and access is denied because authentication is required for the request.

Solution Use either of the following workarounds:

  • The preferred method, to authenticate traffic and log user names, is to install Firewall Client on client computers. Firewall Client then authenticates on behalf of the application.
  • Allow outgoing access without authentication by creating a rule to allow a set of computers anonymous outgoing access so that they can access the content. Such traffic will not be logged with a user name.

ISA Server requests credentials from non-Internet Explorer browsers

Problem ISA Server is requesting credentials from browsers other than Microsoft Internet Explorer®.

Cause Require all users to authenticate is enabled on the network from which requests are received from these browsers.

Solution Disable Require all users to authenticate, and instead enable client authentication on specific access rules as appropriate.

Users prompted for credentials when accessing forbidden sites

Problem Users may be prompted for authentication credentials when accessing forbidden pages from allowed sites.

Cause Users are not allowed to access the sites referenced by links that they click.

Solution One workaround may be to add a generic no access allowed page. To do this, add a new rule before the last default rule in the ordered rule list. This rule should redirect users to an internal page explaining that there is no access allowed to restricted sites. With this workaround in place, users will no longer be prompted for authentication credentials every time an allowed site refers to a forbidden site. Users will receive the placeholder page instead.

Java content on Web sites not displaying as expected

Problem Java applications on Web sites accessed through ISA Server are not displaying properly.

Cause This may be a problem for Web proxies (including ISA Server) connecting to Java sites that do not support authentication.

Solution Add a rule to allow anonymous access to the site, or configure the site for direct access.

Allow authenticated users to provide credentials

Problem When authenticated users are not members of a group allowed access by a specific rule, they receive an error message. Users should receive a logon prompt instead.

Cause In ISA Server 2004, if a user has already been authenticated and denied access by the rule, ISA Server returns an HTTP 502 Bad Gateway error, and Internet Explorer does not prompt again for credentials.

Solution To change this default behavior, you must set the ReturnAuthRequiredIfAuthUserDenied COM property to True. When set to True, users are presented with a dialog box to input credentials. This was the default setting in ISA Server 2000. For more information, see the Microsoft Knowledge Base article 905767, "The ReturnAuthRequiredIfAuthUserDenied property setting does not work if the access rules include a Content Type rule in ISA Server 2004."

Web Proxy clients accessing intranet sites in the perimeter network prompted for credentials

Problem Web Proxy clients that only have access to intranet sites in the perimeter network are prompted for credentials.

Cause With Basic authentication, Web Proxy clients send an anonymous packet first, and are then prompted for credentials.

Solution Configure clients as Firewall clients that automatically send credentials.

SecureNAT clients cannot access the Internet

Problem Clients configured as SecureNAT clients only (no Web proxy settings pointing to ISA Server) cannot access Internet sites.

Cause There may be access rules that require authentication, or Require all users to authenticate may be enabled on the network from which client requests are received. SecureNAT clients cannot present authentication credentials.

Solution Any of the following workarounds may solve the problem:

  • Configure Internet Explorer to point to ISA Server in the Web proxy settings.
  • Install Firewall Client on computers (with or without Web proxy settings specified in Internet Explorer).
  • Remove authentication requirements from rules.

For SecureNAT client applications running on the ISA Server computer (Local Host) the last two workarounds may not work for the following reasons:

  • Firewall Client cannot be installed on the ISA Server computer.
  • Removing authentication requirements from rules may not be effective in some circumstances. If system policy rules requiring authentication are enabled on the Local Host network (for example, the Scheduled Download Jobs rule), requests from SecureNAT client applications, such as the prefetcher, may be blocked. This is due to the behavior of the rules engine. If a client request matches rule criteria, and the rule requires authentication that the client cannot provide, the request is denied by the rule (even if it is an allow rule), and rules lower in the ordered rule list are not evaluated. In this case, system policy rules requiring authentication are evaluated before other rules, and may block SecureNAT client requests that cannot authenticate.

Clients are repeatedly prompted for authentication in a chaining scenario

Problem After supplying credentials for a Web site, credentials are again requested.

Cause This problem may occur if you use Integrated Windows authentication (and the NTLM protocol) on more than one proxy server in a chained proxy configuration. Internet Explorer does not support NTLM authentication with more than one proxy server. Where NTLM authentication is required on each proxy server, authentication will succeed on the first proxy server in the chain. But when the proxy server sends a 407: Proxy Authentication Required response, the user is prompted for credentials. The problem does not exist if Require all users to authenticate is disabled, or NTLM authentication is set only on the first proxy in the chain.

Solution Configure NTLM authentication on the downstream proxy server in the chain, and configure it to pass credentials to the upstream proxy server. For more information, see the Microsoft Knowledge Base article 822458, "You are repeatedly prompted to enter your credentials to use a proxy server in Internet Explorer Service Pack 1."

It is not possible to have a client authenticate against more than one level of ISA Server. Clients can authenticate against either a downstream server or an upstream server, but not both:

  • To authenticate with NTLM against the upstream server, configure the downstream server as anonymous.
  • To authenticate with NTLM against the downstream server, either configure the upstream server as anonymous, or provide credentials in the downstream routing rule to provide to the upstream server.
  • Note that if you pass client authentication requests to the upstream server, the downstream server must allow anonymous access, unless you use the same set of client credentials for both servers in the chain. If you use an anonymous setting on the downstream server, for information about the effect on caching, see the Microsoft Knowledge Base article 821098, "Content cache issues on downstream ISA Server computer."

Users repeatedly prompted for credentials

Problem Users visiting a Web site published through ISA Server that requires authentication are repeatedly prompted for credentials, even after supplying valid credentials.

Cause This may occur if Integrated Windows authentication is enabled on both the ISA Server computer and on Internet Information Services (IIS) of the published Web server. This occurs in a publishing scenario when ISA Server uses the same HTTP headers for authentication as those used by the Web server. The client is prompted for credentials by ISA Server, and ISA Server forwards the request without the credentials to the published Web site. This causes the Web site to prompt for authentication. Multiple authentication requests cause the Web browser to interpret the credentials as incorrect, and users may be prompted multiple times for credentials if the Web browser opens multiple connections.

Solution As a workaround, use alternative authentication methods for publishing. For more information, see "Secure Web Publishing" at the Microsoft TechNet Web site.

Allow anonymous access to specific sites for SecureNAT clients

Problem SecureNAT client access to specific sites is needed, while authentication on other sites is still required.

Cause SecureNAT clients cannot provide authentication credentials.

Solution Create a rule denying access to specific sites, and then create exceptions to the rule for all users.

WPAD not working

Problem Web Proxy Automatic Discovery (WPAD) is configured, and authentication is required on the network. Automatic discovery is not working as expected.

Cause WPAD cannot authenticate and does not provide credentials. Internet Explorer sends credentials and ISA Server sends back an HTTP 407 message. Firewall clients cannot respond to HTTP 407. Note that it should work as expected for Web Proxy clients configured for automatic discovery.

Solution This issue does not exist in ISA Server 2004 Enterprise Edition. For ISA Server 2004 Standard Edition, install ISA Server 2004 Standard Edition Service Pack 1 to resolve this issue.

For more information about troubleshooting automatic discovery, see "ISA Server: Troubleshooting Automatic Detection" at the Microsoft TechNet Web site.

Anonymous entries in logs

Problem Anonymous entries, instead of user names, appear in the ISA Server logs.

Cause This may be caused by rules allowing anonymous access. In addition, Web Proxy clients always make the first connection anonymously.

Solution Ensure you do not have any rules allowing anonymous access. Then user names for Firewall clients and Web Proxy clients will always be recorded.

Domain authentication not working as expected

Problem Users cannot authenticate in a domain configuration.

Cause Failure to authenticate to a domain may have a number of causes.

Solution Check the following:

  • Make sure you have system policy rules enabled for traffic you want to allow into and out of the Local Host network. To allow only certain traffic types, limit the protocols allowed.
  • Review the log to determine which traffic ISA Server is denying during the authentication attempt.
  • Ensure that ISA Server networks are correctly defined. Specifically, ensure that the Internal network is correctly defined.
  • In the Monitoring node, on the Alerts tab, check for configuration warnings.

Credentials required for each instance of Internet Explorer

Problem Users are prompted for credentials every time they open an instance of Internet Explorer.

Cause This is the default behavior when Web proxy settings on the network on which user requests are received are configured for Basic authentication. Basic authentication is per-request (for each instance of opening a browser), not per-session. This is in accordance with Request for Comments (RFC) 2617.

Solution None. This is standard behavior for Basic authentication.