Troubleshooting Authentication and Access Problems

One of the purposes of ISA Server is to control unauthorized access; however, improper configuration or conflicts can result in the inability of authorized users to access the resources they need. In some cases, this could be due to authentication requirements and inability of clients to be authenticated; in other cases, it could be due to the ISA configuration, browser settings, or other reasons. In the following sections, we discuss some common authentication and access problems and what to do about them.

Authentication Problems

Authentication requirements depend on the client type making the request (firewall, Web proxy, or S-NAT) and whether rules have been configured that apply to specific users and groups. When a client makes a request for a Web object, authentication information is passed to the ISA server only if it is required, such as when the Web Proxy Service must identify the user in order for the request to be allowed.

With S-NAT clients, no authentication is involved (unless you are using the Web proxy client in conjunction with S-NAT). Only client address sets can be used to restrict outbound access.

Note

ISA Server can be configured to always require authentication for Web requests. To do so, you configure the array's Outgoing Web Requests properties by checking the option to ask unauthenticated users for identification.

HTTP requests that are made by firewall clients are treated as though they come from unauthenticated users if the filter to pass requests to the HTTP redirector is enabled. The ISA server will not ask for authentication information in this situation, so ISA is unable to pass the requests from unauthenticated users, and the request will be denied. A solution to this problem is to configure the Web proxy client.

User's HTTP Request Is Sometimes Allowed, Although a Site and Content Rule Denies Access

If you have configured a site and content rule that denies access to a specific user, you could find that the user's HTTP request is still allowed if the user's computer is set up as a Web proxy client and Web access is configured to allow anonymous access. If you have protocol rules that allow everyone to use all protocols, and you have site and content rules that allow everyone to access all sites, and you have an additional site and content rule that denies access to the specified user, the user might still be able to access the content.

If the computer is configured as a Web proxy client, no authentication will be required and the user will be allowed access.

If the computer is configured as a firewall client, the request will likewise be allowed because authentication will not be requested. (If non-HTTP content is requested, authentication will be required by the Firewall Service and the user's request will be denied.)

Note

Remember that access problems in general point to misconfiguration of permissions. This is true whether the problem is that users are unable to access resources to which they should have access or that users are being allowed to access resources that should be restricted.

If authentication is not requested, ISA Server will not know that this is the user who is supposed to be denied access. To make the rule that applies to the specific user work in these scenarios, configure the array to ask unauthenticated users for identification, as discussed previously.

Failure to Authenticate Users of Non-Microsoft Browsers

Users of Netscape or other non-Microsoft browsers might be unable to be authenticated by ISA Server. This happens because ISA can be configured to accept only Windows integrated authentication. If the client's browser cannot provide the user's credentials in NTLM format, those users will not be able to access the requested Web objects if authentication is required.

The supported authentication methods are configured in the array's incoming and outgoing Web request properties. In order to be authenticated, the client browsers must be able to use at least one of the authentication methods that ISA is configured to use.

To specify authentication methods, edit the listeners' properties, as shown in Figure 26.11.

Figure 26.11: The Authentication Method Is Configured Via the Listeners' Properties Sheet for Incoming and Outgoing Web Requests

The following authentication methods can be used:

• Basic

• Digest

• Integrated Windows

• Client certificate

Microsoft Internet Explorer 5.x and later supports all of the preceding authentication methods. Some browsers might support only Basic or Digest authentication.

Warning

Basic authentication transmits and receives the users' credentials as plain text. No encryption is used to protect the confidentiality of the information.

Error Message When Using Pass-Through Authentication with NTLM

Pass-through authentication could fail if you are attempting to use ISA pass-through authentication with NTLM authentication, using one of the following browsers:

• Microsoft Internet Explorer Versions 4.x or 5.x for Windows 95

• Microsoft Internet Explorer Versions 5.x for Windows 98 and 98 SE

• Microsoft Internet Explorer Versions 5.x for Windows 2000

• Microsoft Internet Explorer Versions 3.02, 4.x, and 5.x for Windows NT 4.0

This failure results in the following error message:

HTTP 401.2 unauthorized - Logon failed due to Authentication Failure Internet  Information Services 

This is a problem identified with the Microsoft Internet Explorer browser software, which was corrected in MSIE version 5.5 with Service Pack 1. The solution is to install the latest version of MSIE, which you can download from the Microsoft Internet Explorer Web site at www.microsoft.com/windows/ie/default.asp.

Access Problems

Access problems include both the inability of authorized clients to access needed resources and the ability of unauthorized users to access resources that should not be available to them. Incorrect ISA Server configuration can result in both kinds of access problems.

Inability of Clients to Browse External Web Sites

When clients cannot access external Web sites, this can be related to one of two things:

• The ISA Server settings

• The client's browser settings

By default, ISA Server allows no communications to and from the Internet by internal clients. You must create rules to allow access. If you have just installed ISA Server and have not configured rules and your clients are unable to reach the external Web servers, this is normal ISA Server behavior. In this case, you can create protocol rules that will allow users (all users or selected users) to use the protocols and then create site and content rules to allow access to particular sites or all sites, using the protocols that are allowed by your protocol rules.

If the ISA Server settings are configured to allow client access and there is still a problem, it could be due to the client's browser settings. The proxy port must be set correctly (to 8080 if you are using the default port).

Problems with Specific Protocols or Protocol Definitions

If clients are unable to use specific protocols to communicate with the external network, you can allow the use of particular protocols in one of two ways:

• Configure IP packet filters to allow the protocols

• Configure protocol rules to allow the protocols

Protocol rules can be created to apply to all IP traffic, to only a specific set of protocol definitions, or to all but a selected set of protocols. A list of preconfigured commonly used protocol definitions is included with ISA Server, but you can also add protocol definitions.

Note

Protocol rules can only be applied to HTTP, Secure HTTP, Gopher, and FTP protocols when ISA Server is installed in caching mode.

Inability of Clients to PING External Hosts

A common complaint in regard to a new deployment of ISA Server is that internal clients are not able to ping computers on the external network. The ping command is often used to send an ICMP echo request message to a host on the Internet for the purpose of testing connectivity. By default, S-NAT clients do not pass ICMP messages between internal and external computers (a process called ICMP proxying).

To enable this feature, you must enable IP routing. Follow these steps:

1. In the ISA Server Management MMC, expand the array or server object node for the appropriate array or server.

2. Expand the Access Policies object.

3. Right-click IP Packet Filters.

4. Select Properties.

5. Switch to the General tab, and check the Enable IP routing check box.

In addition to having IP routing enabled, there must be a packet filter that allows ICMP packets to be transmitted and received by the external network interface. The default ISA Server installation package includes filters for outbound and inbound ICMP requests.

Redirection of URL Results in Loop Condition

A redirection loop can occur when URL redirection is specified in the site and content rules so that when you request the URL www.aaa.com, you are redirected to www.bbb.com, which in turns redirects you back to www.aaa.com, and so forth.

This can happen if the site and content rule you have created denies all destinations. When you select Redirect the request to an alternate URL and set the rule to apply to all requests, client browsers will continually try to reach the original destination and be redirected to the URL specified in the rule.

There are two ways to solve this problem:

• You can create a rule that denies all destinations except the destination to which you want to redirect the request.

• You can choose not to specify a URL to which requests will be redirected when you select Redirect the request to an alternate URL.

Ability of Clients to Continue Using a Specific Protocol After Disabling of Rule

You could find that even after you have disabled a protocol rule, clients are still using the protocol that was allowed by the rule. This happens because disabling a protocol rule does not terminate any of the existing client sessions. Until the session has been disconnected, clients can continue to use the protocol after you disable the rule.

Experienced administrators will recognize that this is the same thing that happens when you change the permissions on a file or folder; a user who is currently logged on must log off and log back on before the change applies, because the access token that specifies the users' permissions is issued at logon.

To solve this problem, you can disconnect the current client sessions that are using the protocol. To do so, expand the server or array name in the left console tree, expand the Monitoring object, and expand the Sessions object. Then, right-click the session that you want to disconnect and select Abort Session, as shown in Figure 26.12. Clients will not be able to use the protocols when they reconnect.

Figure 26.12: Disconnect the Sessions of Clients Who Are Using Protocols You Want to Disable

Dial-Up and VPN Problems

In the following sections, we look at some common troubleshooting scenarios that involve dial-up and VPN connections.

Inability of ISA Server to Dial Out to the Internet

If the ISA server is not able to dial out to connect to the ISP, but you can dial out manually, you should check the dial-up entry's credentials. If the incorrect username and password are entered (or if the credentials are not specified), the ISP's dial-up server will not authenticate the connection and it will disconnect before a logon is established.

The properties for the dial-up entry can be edited by expanding the server or array name in the left console pane, expanding Policy Elements, and selecting Dialup Entries. In the right detail pane, right-click the dial-up entry you want to edit, and select Properties.

Dial-Up Connection Is Dropped

A dial-up connection can be dropped because it was inadvertently disconnected. If you restart the ISA Server services, the connection should be automatically reestablished.

To restart the ISA Server services, expand the name of the server or array in the left console pane of the ISA Management MMC, expand Monitoring, and select Services. Right-click the service that you want to restart, and select Start.

Inability of PPTP Clients to Connect Through ISA Server

If internal clients are unable to create PPTP tunnels to a destination on an external network (on the other side of the ISA server), this could be due to the fact that you have not configured a PPTP pass-through in the ISA Management MMC. By default, this option is not configured.

To allow your internal clients to create PPTP connections through the ISA server, you need to do the following:

1. In the ISA Management MMC left console pane, expand Access Policy under the server or array name.

2. Right-click Packet Filters, and select Properties.

3. Ensure that Enable IP Routing is checked on the General tab.

4. On the PPTP tab, check the PPTP through ISA firewall check box.

PPTP sessions can now be established through the ISA server by S-NAT clients. Note that you cannot establish PPTP connections using the firewall client.

This is a very common problem and a good example of where one little check box can make all the difference.