ISA Server Troubleshooting Policy (1) _ Servers

ISA Server Troubleshooting Policy
10.2 ISA Server Troubleshooting Policy
The system method is a necessary condition for successful troubleshooting. When an unexpected ISA Server error is encountered, it is possible to troubleshoot by identifying whether the error is based on a user or a packet. This section provides troubleshooting strategies for two types of connectivity problems.

Learning objectives in this section
Excludes user-based access issues.

Excludes packet-based access issues.

Troubleshoot the VPN connection in ISA Server.

Estimated study time: 30 minutes
Troubleshooting 10.2.1 User Access
When user account access is interrupted or unavailable, it may be caused by overly stringent user security requirements, improper configuration of rules, and insufficient authentication methods. When this happens, tools such as Ping,tracert can be useful.

To troubleshoot user-based access issues, first check the access policy rules. By using configured access policy rules, users who are unable to establish a network connection are authorized to have permission to connect to the site, content groups, and protocols.

If the configured rule is not successfully applied to the user session, verify that the array properties are configured to require authentication to the unauthenticated user. Also note that if you create an access policy that allows types and apply to the specified users and groups, the user session is required to authenticate through ISA Server. On the other hand, if you want all Web sessions to remain anonymous, access to the Web session is denied, so determine that the array properties do not require anonymous users to authenticate. In addition, delete all site and content rules or protocol rules that apply to the allowable types on the specified Win2000 users and groups.

Authentication

In the array properties, the selection of the authentication method affects the user's ability to connect. Each authentication method is designed for a network environment. If you select an incompatible authentication method in your network configuration, or if the method is configured incorrectly, users will not be able to access the ISA Server computer and network.

For example, the default authentication mode for an array is Integrated Windows authentication. However, this method does not authenticate clients running non-Windows operating systems. If you want to provide authenticated access services for such customers in ISA Server, you must configure the array properties to use a different authentication method. Also, Integrated Windows authentication is not compatible with Netscape because Netscape cannot pass a user certificate in NTLM format. Another limitation is that it relies on the Kerberos V5 authentication protocol or its own challenge/Response authentication protocol, whereas in the Passthrough authentication scenario, as shown in Figure 10.3, ISA server does not support the Kerberos V5 authentication protocol because Kerberos V5 requires the client to identify the authenticating server.

In ISA Server, the optional authentication methods are basic, Digest, Client certificate, and so on. Basic authentication is compatible with all customer types, however, because this method passes the user name and password in plaintext and unencrypted format, it is not secure enough. Digest authentication can only be used in the Windows2000 domain, and the password is delivered using plaintext but encrypted text

Yes. Client certificate authentication uses an SSL channel for authentication. It requires a client certificate to be installed in the Web Proxy service card stack on the ISA Server computer, and the certificate should be mapped to the appropriate user account. ISA Server provides client certificates only when SSL bridging is configured.

10.2.2 packet-based access troubleshooting
A packet-based access problem can be determined when none of the users are able to access the network, or if an ip-based utility such as ping or tracert operation fails.

In ISA Server, to eliminate packet-based access failures, simplify the network configuration as much as possible to form a test environment.

Ø Establish network Troubleshooting configuration

1. Start packet filtering, create a custom packet filter to allow any IP protocol to be passed in and out.

2. Create a protocol rule that allows any requested IP traffic to determine that there is already a site and content rule to allow access to all sites and content groups.

3. Restore all program filters and routing rules to the default settings.

4. Verify that the Local Address table is defined within the ISA Server internal customer scope.

5. In the IP Packet Filters Properties dialog box, start IP Routing.


Note The IP routing option provides routing capability for protocols with secondary connections. This setting is particularly important for boundary network configurations. You can start IP routing options in the IP Packet Filters Properties dialog box of ISA Management or Routing and Remote Access console.


6. On the ISA server computer, ensure that no default gateway is defined for the internal interface. However, make sure that the appropriate default gateway is specified on the external interface.

7. On the client attempting to establish an access connection, disable the Firewall Client software and designate ISA server as the default gateway.

Once you have configured ISA Server in this simplified manner, restart the ISA Server service. If you still cannot access the network, restart the ISA Server computer. If this does not solve the problem, then it may not be a problem with ISA Server configuration. At this point, you should perform network troubleshooting. Use Network Monitor to track and need to check DNS, routing tables, reports, logs, and so on.

If you have access to the Internet in this simplified mode, then one by one will import the network unit to determine the cause of the problem. For example, if you can access the Internet on a given client, you can try to use the specified Internet program from that computer. If you encounter a problem, you can assume either that the application is not configured properly to use ISA Server as a proxy, or that the program cannot use a proxy server. For programs that cannot use a proxy server, you must configure the client to be a secure network address translation client or to run Firewall Client software. After reconfiguring the client, be aware of changes in its behavior. You can assume that the Autodiscover feature is not configured correctly. This problem is resolved until all the required network components have been added to the specific configuration.

VPN Network considerations
In the VPN network, the troubleshooting also starts from the above establishment simplifies the network environment. If you have already run the new VPN wizard, you should verify that you have run the Routing and Remote Access service. Then, make sure that the client is configured as a secure network address translation client, not a firewall client.

Additionally, it is necessary to verify that the Locaisa Server VPN Configuration Wizard has created the appropriate demand-dial interface in Routing and Remote Access. This can be checked at the Routing interfaces node, as shown in Figure 10.4.

After that, verify that each authentication protocol selected for the VPN connection creates 2 IP data packet filters. For example, if the VPN network is configured to use L2TP or PPTP, the Locaisa Server VPN Configuration Wizard should create and start 4 IP data packet filters. (for L2TP, the Configuration Wizard creates a custom general filter for ports 500 and 1701.) For PPTP, the configuration Wizard creates predefined filters for PPTP calls and PPTP reception.