Troubleshooting Client Authentication on Access Rules in ISA Server 2004

This troubleshooting guide describes common issues encountered when clients protected by Microsoft Internet Security and Acceleration (ISA) Server are required to authenticate for access to external resources. It also suggests actions you can take to resolve these issues.

This document is divided into the following sections:

• Introduction
• How client authentication on access rules works
• Common issues in client authentication
  • Domain Firewall Client Users Prompted for Authentication
  • Allow Anonymous Access to Specific Sites
  • Users Have to Reauthenticate Multiple Times
  • Some Web Sites Applications Not Opening as Expected
  • ISA Server Requests Credentials from Non-Internet Explorer Browsers
  • Limit Users from Accessing the Internet with MSN Messenger
  • Allow Anonymous Users to Provide Credentials
  • Users Receive Multiple Authentication Prompts to Allowed Sites
  • Unauthenticated Users Appear in Logs
  • Java Content on Web Sites Not Displaying as Expected
  • Allow Authenticated Users to Provide Credentials
  • Web Proxy Clients Accessing Intranet Sites in the Perimeter Network Prompted for Credentials
  • SecureNAT Clients Cannot Access the Internet
  • Poor Internet Access Performance for Clients in a Windows NT Server 4.0 Domain
  • Clients Repeatedly Prompted for Authentication in a Chaining Scenario
  • Users Repeatedly Prompted for Credentials
  • Allow Anonymous Access to Specific Sites for SecureNAT Clients
  • WPAD Not Working
  • Anonymous Entries in Logs
  • Domain Authentication Not Working as Expected
  • Credentials Required for Each Instance of Internet Explorer
  • Cannot Use Visual Interdev 6.0 NTLM Pass-through Authentication
  • Cached Client Credentials May Cause Unexpected User Prompts

If you have a suggestion for a troubleshooting tip, contact ISA Server Documentation Feedback at Microsoft.

Client Authentication

You may choose to allow internal corporate clients to access resources on other networks freely without identifying themselves, or require that they authenticate themselves before access is allowed. You can use either or both of the following methods to specify that authentication is required for client requests:

• Enable Require all users to authenticate. You can specify that every Web request on a particular network requires authentication by enabling Require all users to authenticate on the Web Proxy settings of the network’s properties. With this setting enabled:
  • Anonymous access for Web Proxy requests on the network is disabled.
  • User credentials are requested and validated before firewall policy rules are evaluated.
• Configure client authentication on access rules. You can configure individual access rules to require authentication. When a client makes a request, ISA Server evaluates access rules in the order in which they appear in the rules list in ISA Server Management. System policy rules are evaluated first.
  • A rule that is configured with the default All Users setting is in effect an anonymous rule.
  • A rule that applies to All Authenticated Users is valid only for users presenting valid credentials.

If a rule that matches a request requires authentication, client credentials are validated. If credentials are valid, access policy is implemented in accordance with the rule. If a client cannot present credentials, or credentials cannot be validated, the rule denies access (even if it is an allow rule), and no further rules are evaluated. This may happen for a number of reasons. For example, a request from a SecureNAT client who cannot authenticate, or Web Proxy listener settings that are incorrectly configured, such as not enabling an authentication method on the listener.

Different ISA Server clients authenticate differently:

• Firewall clients. The Firewall client authenticates the user to the ISA Server computer on behalf of the application requesting access. Credentials are provided at the beginning of a session, before specifically requested. In the ISA Server logs, a question mark appears when a request arrives from a Firewall client (with credentials) but rules do not require authentication.

• SecureNAT clients. SecureNAT clients are client computers that do not have Firewall Client software installed, and whose default gateway points either directly to the ISA Server computer, or indirectly through a router whose endpoint is ISA Server. SecureNAT clients cannot present authentication credentials. Note that some applications running on the ISA Server computer (Local Host) run as SecureNAT clients. For example, the ISA Server prefetcher component that allows automatic download of Web content for caching to the ISA Server computer or to array members operates as a SecureNAT client.

  Note

  Firewall Client software cannot be installed on the ISA Server computer.

• Web Proxy clients. Both Firewall client computers and SecureNAT client computers can be configured as Web Proxy clients. A Web Proxy client is any proxy-aware application running on the client computer that makes a proper request to the ISA Server Web Proxy filter.

The way in which different clients authenticate is summarized in the following table.

Common Authentication Issues

This section describes common authentication issues and possible solutions.

Domain Firewall Client Users Prompted for Authentication in ISA Server 2004 Standard Edition

Problem: Firewall clients with Web Proxy settings specified in their browsers are being prompted with a 401: Authentication Required message, even though they are domain members in the ISA Server domain.

Cause: This problem arises when Firewall clients have automatic discovery enabled, and Require all users to authenticate is enabled on the Web Proxy listener of the Internal network. The Winsock Proxy Autodetect (WSPAD) request must be authenticated because Require all users to authenticate is set. The Firewall Client program cannot respond to the 401 response and the request fails.

Solution: Install ISA Server 2004 Standard Edition Service Pack 1. For more information, see the Microsoft Knowledge Base article 885683: "You receive error messages if the Internet Security and Acceleration Server 2004 Firewall Client program is configured for auto-discovery or if you try to configure this program for auto-discovery."

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 Reauthenticate 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 Knowledge Base article 842686: "ISA Server does not maintain client credentials between requests."

Some Web Sites Applications Not Opening as Expected

Problem: A public Web site has a link to resources that require 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. Then Firewall Client 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 non-Internet Explorer browsers.

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.

Limit Users from Accessing the Internet with MSN Messenger

Problem: Users are accessing the Internet with MSN Messenger, and you want to limit this access.

Cause: Specific allow and deny access rules are needed to configure this scenario.

Solution: Do the following:

• Create a rule that denies the MSN protocol for all users except the allowed group.
• Note that MSN Messenger may use proxy to access MSN servers using HTTP if the MSN protocol is not available.
• Create a rule to prohibit access to *.messenger.hotmail.com, and *.msn.hotmail.com for all users except the allowed group.
• Configure client computers as Web Proxy clients to provide credentials to ISA Server.

Allow Anonymous Users to Provide Credentials

Problem: When users that do not belong to a user group try to access the Internet through ISA Server, they do not get prompted for credentials.

Cause: There may be specific circumstances in which you want to allow users who do not belong to a user group to input credentials. With Windows Integrated (NTLM) authentication enabled, users are not prompted for credentials.

Solution: To provide such users with the opportunity to input credentials, do any of the following:

• Choose both Integrated and Basic on the Web Proxy tab of the network properties on which such requests are received.
• Launch Internet Explorer using the RunAs command to provide credentials.
• Log on to the computer temporarily using an account with permissions to access the Internet.

Users Receive Multiple Authentication Prompts to Allowed Sites

Problem: Access is allowed to specific sites, but users are still receiving multiple authentication prompts.

Cause: Prompts may be requested for authentication to sites that are linked from the specific set of sites that are allowed.

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.

Unauthenticated Users Appear in Logs

Problem: Users are showing up as unauthenticated in the logs although authentication is required.

Cause: Some clients may be using direct access, rather than going through ISA Server to access the Internet.

Solution: Create an access rule to control access to the locations in question. Make sure that Internet Explorer Web Proxy settings are configured correctly on client computers. You can also try resetting Web Proxy settings on client computers.

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, 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 and an example Microsoft Visual Basic script to set this property, see the ISA Server SDK. Note that if an access rule includes a content type, clients may not be prompted for alternative credentials even if the COM property is set to true. For more details of this issue, see Microsoft article 905767 (https://go.microsoft.com/fwlink/?LinkID=79576).

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 these workarounds will solve the problem:

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

For SecureNAT client applications running on the ISA Server computer (Local Host) the first 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.

Poor Internet Access Performance for Clients in a Windows NT Server 4.0 Domain

Problem: Clients in a Microsoft Windows NT Server 4.0 domain that are authenticating for Web site access are experiencing loss of access or slow access.

Cause: In a Windows NT Server 4.0 domain, there are no options to increase authentication performance for ISA Server against a Windows NT Server 4.0 domain controller. A Windows NT Server 4.0 domain controller only allows one channel for authentication and the process is serial.

Solution: As a short-term solution, allow access to specific sites without requiring client authentication. In the long term, consider upgrading the user domain. In addition, keep ISA Server in its own domain, and users in a separate domain. Make domains part of the same forest. This means implicit trust in the Active Directory directory service, making authentication faster.

Clients 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 Windows Integrated authentication (NTLM) 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 Knowledge Base article822458: "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 anonymous on the downstream server.
• 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 through 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 Knowledge Base article821098: "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 Windows integrated authentication (NTLM) 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, do any of the following:

• Use SecurID instead of NTLM on the ISA Server computer.
• Use RADIUS instead of NTLM on the ISA Server computer.
• Use Basic authentication instead of NTLM on the internal Web server.
• Use an SSL connection with Basic authentication delegation.

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 or ISA Server 2006. For ISA Server 2004 Standard Edition, install ISA Server 2004 Standard Edition Service Pack 1 to resolve this issue.

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 in and out of the Local Host network. To allow only certain traffic types, limit the protocols allowed.
• Look at 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.
• On the Monitoring node, on the Alerts tab, check for misconfiguration 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 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.

Cannot Use Visual Interdev 6.0 NTLM Pass-through Authentication

Problem: The Microsoft Visual Interdev 6.0 client receives repeated authentication prompts.

Cause: Visual Interdev 6.0 uses a version of FrontPage 3.0 to connect to Web servers. The Visual Interdev 6.0 client does not recognize HTTP 1.1 proxy authentication with NTLM. It only negotiates HTTP 1.1 using Basic authentication. This is a limitation of older versions of FrontPage.

Solution: Possible workarounds include:

• Set up the Web site to use Basic authentication.
• Bypass the proxy with direct access by pointing the client directly to the Web server through an alternative gateway to ISA Server.

Cached Client Credentials May Cause Unexpected User Prompts

Problem: ISA Server unexpectedly prompts users to input credentials.

Cause: If incorrect client credentials are cached on the client computer, clients making requests through ISA Server may be prompted for alternative credentials, even though the ISA Server COM property ReturnAuthRequiredIfAuthUserDenied is set to its default false value for outbound traffic.

Solution: Clear the cached credentials, as follows:

1. Click Start, and then click Run.
2. In the Run dialog box, type control keymgr.dll. Then click OK.
3. In the Stored User Names and Passwords dialog box, select the entry that you want to remove, and then click Remove.
4. Click Close to close the Stored User Names and Passwords dialog box.
5. Restart the client computer.

For more information on the ReturnAuthRequiredIfAuthUserDenied COM property, see the ISA Server SDK documentation (https://msdn2.microsoft.com/en-us/library/ms826234.aspx).

Additional Information

Additional ISA Server 2004 documentation is available at the ISA Server 2004 TechCenter at Microsoft TechNet (https://go.microsoft.com/fwlink/?LinkID=82086).

Additional ISA Server 2006 documentation is available at the ISA Server 2006 TechCenter at Microsoft TechNet (https://go.microsoft.com/fwlink/?LinkID=82085).