configuring isa server phần 6 pdf

Chapter 8 Configuring ISA Server for Outbound Access Solutions in this chapter: · Configuring the Server for Outbound Access · Network Configuration Settings · Creating Secure Outbound

server On a simple network, the SecureNAT client has it default gateway set to theinternal interface of the ISA server On more complex or routed networks, the SecureNAT client has a default gateway set to a router interface that can route Internet-bound

requests to the internal interface of the ISA server The primary disadvantage of using the SecureNAT client is that it cannot pass authentication information to the ISA server, and therefore you cannot configure access controls based on user or group information

Solutions Fast Track

Understanding ISA Server Architecture

n Proxy Server 2.0 was built on three basic services: the Web Proxy Service, the Winsock Proxy Service, and the SOCKS Proxy Service

n The four components that form the foundation of the ISA Server are: the Web Proxy Service, the Firewall Service, the Network Address Translation Protocol driver, and the Scheduled Content Download Service

n The Web Proxy Service (w3proxy.exe) provides and controls access to the Web protocols, which are Application layer protocols

n The Web Proxy Service is implemented as the w3proxy.exe file You can start and stop the service via the net start w3proxy.exe and the net stop

w3proxy.exe commands

n The Web Proxy Service is also responsible for the Web cache, which provides a

mechanism that allows content retrieved from the Internet to be stored on the ISA server

n The Firewall Service (fwsrv.exe) provides the same functionality to network clients as the Winsock Proxy Service did in Proxy Server 2.0

n The firewall client installs a special version of the Windows Sockets (Winsock) interface The Winsock interface is a Session layer interface and is implemented

as an API

n The firewall client software captures Winsock API calls and forwards them to the

Firewall Service via the Firewall Service’s control channel

n The Network Address Translation (NAT) Protocol driver allows network clients

on a network that uses a private IP addressing scheme to access the Internet

n To solve the problem of Internet access for private network hosts, Windows

2000 provides the Network Address Translation Protocol, or NAT This protocol allows private network clients to send requests to the NAT server rather then directly to the Internet host

n ISA Server takes advantage of the NAT Protocol driver included with Windows

2000 and extends its functionality so that it is able to work with the other ISA Server services

n The Scheduled Content Download Service provides ISA Server a mechanism to automatically download Web content from sites you want to have available on the ISA server before a user actually makes a request for the content

n All requests, regardless of whether they are from SecureNAT, firewall, or Web proxy clients, must pass though the ISA server’s packet filters

n HTTP requests issued by a Web proxy client, or a SecureNAT or firewall client with the HTTP redirector enabled, can also be subjected to a custom set of

Application layer filters known collectively as Web filters

Installing and Configuring ISA Server Clients

n The SecureNAT service provides virtually transparent proxy services for your network clients

n Whether you install a DNS server on your internal network or configure your

SecureNAT clients to use a DNS server on the Internet, you must have site and content as well as protocol rules in place that will allow your SecureNAT clients

to query an external DNS server

n If you choose to implement a single, centralized DHCP server, you must

configure multiple scopes to service all network IDs that have DHCP clients

n In order to ping an external client, the ISA Server must be configured to allow

IP Routing

n The firewall client installation file can also be accessed via a Web page, but the Web installation information files must be manually moved to a directory in the Internet Information Server WWW service accessible hierarchy

n If you have Mac, UNIX, or other non-Microsoft operating systems on the

network, you will not be able to install the firewall client and therefore will not

be able to take advantage of the complete range of protocols provided by the firewall client

n You should not configure servers that are published to the Internet to use the firewall client

n When you use the software deployment tools in the Windows 2000 Group Policy objects, you’ll typically have an organizational unit (OU) or a set of OUs to which you will make the software available

n The firewall client supports a process known as autodiscovery, in which the

firewall client is able to query either a DHCP server via a DHCPINFORM message

or directly query a DNS server via a DNS query for the name

wpad.<domain_name>

n The most compelling reason to use DHCP, rather than DNS, when configuring your wpad entries is that DCHP allows you a more granular approach to

assigning your ISA servers to the network clients

n ISA Server allows you to publish servers by configuring them as SecureNAT clients, therefore virtually obviating the need to set up the published servers as firewall (Winsock) clients

n A Web proxy client is a CERN-compliant Web browser or other application that can be configured to send requests to the Web Proxy Service on the ISA server

n When the Web proxy client is configured to support autodiscovery, it can take advantage of a wpad entry contained in either a DHCP or DNS server

Frequently Asked Questions

Q: Do I have to install Internet Information Server to use the Web Proxy Service, as I did

with Proxy Server 2.0?

A: No Unlike Proxy Server 2.0, you do not need to install IIS in order to take advantage

of the Web Proxy Service on ISA Server In fact, it is recommended that you do not

install IIS on the same machine as ISA Server

Q: How do I know if my Web browser is CERN compliant?

A: The best way for you to determine whether or not your browser is CERN compliant is

to configure it to use the Web Proxy Service You can do this by configuring it to use port 8080 on the internal interface of the ISA server If it works, it is CERN compliant

If it does not work, it is not CERN compliant Almost all browsers released in the last three to four years are CERN compliant and will work with the ISA Server Web Proxy Service

Q: Do I have to install the firewall client? I am concerned that if I install the firewall client

software, my existing network applications will not work correctly

A: You do not have to install the firewall client software You can still access the Internet

through the ISA server if you configure your clients as SecureNAT clients However,

you lose out on some of the convenience that the firewall client offers, and you also lose authentication information that would allow you to configure access control based on users or groups Do not worry about the firewall client software breaking your existing applications We had the same concern with the Proxy Server 2.0 software, but the firewall client software doesn’t break anything, and it is easy to disable or remove if you decide that you do not want to use it

Q: I’ve read a lot of books on Proxy Server 2.0, and it is always said that the control

channel uses UDP 1745 What makes you think that it also uses TCP 1745?

A: Much of the research we did for this book included network-monitoring sessions that

were used to determine ISA Server protocol behavior We noticed that if we stopped and started the firewall service, the LAT was being transferred from the ISA server’s internal interface’s TCP port 1745 to the firewall clients UDP is still used for

communications that can fit inside a single UDP packet Larger control messages use TCP instead of UDP

Q: Can I run RRAS and ISA Server on the same machine? Also, can I run the RRAS NAT

service at the same time I run ISA Server?

A: You should not run the RRAS NAT Protocol on the same machine as ISA Server Even

though ISA Server will disable the RRAS NAT Protocol, we have seen many explain errors when the NAT Protocol was still installed You should delete it from the RRAS Service The RRAS Service will run on the ISA server and is used by the ISA server, especially when you want to configure VPN connections

difficult-to-Q: Sometimes when I make a change, it doesn’t seem to work But then when I come

back to the computer later, things suddenly work What is causing this?

A: If the change you’ve made requires the service to restart and you let the ISA server

restart the service for you, it could take a few seconds to a few minutes for the service

to complete the restart purpose If you need the change to take effect sooner, tell the ISA server that will you restart the service yourself

Q: Before using ISA Server, I used the RRAS NAT Service Now my computer seems to be

dropping off the network and not receiving IP addresses What might be the problem?

A: Unlike the RRAS NAT Protocol, ISA Server does not include a DHCP allocator If you

want to automatically assign addresses to ISA Server clients, you need to install a DHCP server

Q: I want to run programs like Napster and various Internet games on my ISA Server

clients I do not want to install the firewall client However, it seems that these things work only with the firewall client installed What can I do about this?

A: Napster and various Internet games required complex protocol connections that

require primary connections and often multiple secondary connections The easiest way to handle these is to use the firewall client If you use the SecureNAT client, you might have to configure multiple protocol definitions to make them work correctly

Q: When I use the firewall client, I can connect to mail servers on the Internet from my

internal computers, but if I use the SecureNAT client, it does not work I would rather not use the firewall client software, but I can’t connect to mail servers on the Internet without it Is there anything I can do about this?

A: The problem is likely due to the DNS configuration of your SecureNAT clients The

reason that you are able to access your mail servers when the firewall client is

installed is that the Firewall Service is able to take advantage of DNS proxy via the Firewall Service The Firewall Service resolves the name for the firewall client and returns that address to it The SecureNAT client must have a DNS server address configured on it or it will not be able to resolve Internet names

Chapter 8

Configuring ISA Server for Outbound Access

Solutions in this chapter:

· Configuring the Server for Outbound Access

· Network Configuration Settings

· Creating Secure Outbound Access Policy

· Configuring Application Filters That Affect Outbound Access

· Understanding and Configuring the Web Proxy Cache

· Summary

· Solutions Fast Track

· Frequently Asked Questions

Introduction

In this chapter we focus on ISA Server configuration issues that have their primary

influence on outbound access and outbound access control Although we often think of a firewall as something to prevent external intruders from accessing internal resources, just

as much havoc can result if we fail to control what internal users can access on the

Internet

The major issues we tackle in this chapter include:

· Configuring ISA Server for outbound access

· Understanding and configuring the Network Configuration settings

· Creating a secure outbound access policy

· Configuring the application filters that affect primarily outbound access

· Understanding and configuring the Web proxy cache

Once you have a firm grasp on these issues, you will be able to configure a secure

outbound access policy and ISA Server configuration

Configuring the Server for Outbound Access

Several elements determine how outbound requests for Internet resources are handled These elements can be broken down roughly into two groups:

· Outbound Web protocol requests

· Outbound “everything else”

The “everything else” includes Winsock application requests that are not wrapped

in HTTP headers Both SecureNAT and firewall clients issue Winsock application requests Outbound access control for these clients centers around configuring protocol rules

Outbound requests from Web proxy clients are handled a little differently, since they do not have to be run through the Firewall Service However, they are still bound by protocol rules You can configure how outbound Web protocol requests are handled on the internal interface of the ISA Server via the Server’s Properties sheet

Note that this is a departure from how things were done in Proxy Server 2.0 With Proxy Server, you configured Web protocol access controls and Winsock access controls through different configuration dialog boxes In ISA Server, those dialog boxes are

consolidated, and Web and Winsock protocols are now configured through the same interface

Configuring Listeners for Outbound Web Requests

To access the configuration dialog box for Outgoing Web Requests, perform the

following steps:

1 Expand the Servers and Arrays node in the left pane of the ISA

Management console Right-click your server or array, and click Properties

2 Click the Outgoing Web Requests tab You will see something like what

appears in Figure 8.1

Figure 8.1 The Outgoing Web Requests Tab on the Server Properties Sheet

3 In the Identification frame, you have the option to configure the Outgoing Web Requests Listener for the Web Proxy Service to Use the same listener configuration for all internal IP addresses, or you can Configure listeners individually per IP address

Your decision to use the same listener configuration rather than separate listener configurations for each IP address is determined by the type of

authentication you want to require to access Web content via a particular

listener If you wanted to apply the same authentication requirements for all

outgoing Web requests, you would choose to apply the same configuration to all

IP addresses If you need a more granular control over the type of

authentication accepted for each listener, you should configure listeners

individually

Note that even though you can configure each listener to accept a different

method of authentication, the decision to require authentication is a global configuration option You do not have the choice to require authentication on

one listener and not require authentication on another listener

To add an Outgoing Web Requests Listener, click the Add button You’ll see something like Figure 8.2

Figure 8.2 Adding a Listener for Outgoing Web Requests

4 When you add a new listener for outgoing Web requests, you select the Server,

which will likely be the server on which you are configuring the listener; the IP address that is associated with this listener; and the type of authentication you want to enable for this listener

You can also configure the listener to use a server certificate to authenticate

it to internal Web clients This allows SSL connections between the Web proxy client on the internal network and the ISA Server’s internal interface

5 In Figure 8.1, note the TCP port text box This box defines the port number

listening for Web proxy client requests You can change this number to any port you like, but be sure that no other service is running on that port You can determine whether or not another service is bound to that port by running the

netstat –na command from the command prompt If the netstat command

shows that another service is listening on that port, you need to choose an alternate port assignment The default port number for outbound Web requests

is TCP 8080 We advise you to leave this value as it is, if possible

6 If you want internal clients to connect to the listener via SSL, you must Enable SSL Listeners and include a port number Note that the default port number is

8443 You should not change this port number Furthermore, if you enable SSL

on a listener, you must have a certificate installed on that listener Note that

Port 8443 is the port number to which browsers configured as Web proxy clients

send their SSL connection requests If the browser is not a Web proxy client, it does not send SSL requests to this port number The non-Web proxy client browser doesn’t need to send requests to this port number; because it is not a Web proxy client, it will not be able to authenticate with the Web proxy service

7 In the Connections frame, decide whether you want to force authentication for

Web proxy requests by selecting the Ask unauthenticated users for

identification Recall the effect this option has on SecureNAT or firewall clients

that are not also configured as Web proxy clients: Their Web protocol requests fail If this option is checked and a Web proxy client issues a request, the user

will be presented with an authentication dialog box if there is no protocol and site/content rule allowing the request to be passed for anonymous requests Also note that if you choose to use basic authentication, it will call up the logon dialog box When integrated authentication is selected, credentials are passed transparently and the user will not need to enter credential information

When you click the Configure button, you see the screen that appears in

Figure 8.3 Here you configure the number of simultaneous outgoing

connections you want to allow to the Web Proxy Service The timeout interval for dormant connections can be set here as well Limiting the maximum number

of connections can have the effect of improving the performance for users who are able to make a connection, albeit at the expense of users who are not able

to connect If you do limit the number of connections, be sure to configure the timeout to a low number so that people do not wait a long time for user

connections to time out before they can get access to the ISA server

Figure 8.3 The Connection Settings Dialog Box

Server Performance

You can configure the amount of server memory and other resources dedicated to

servicing Web requests via the Performance page If you click the Performance tab on the server’s Properties sheet, you see the screen that appears in Figure 8.4

Figure 8.4 The Web Proxy Service Performance Page

When you configure the Performance tuning slider bar to support more users per

day, you dedicate more of the system resources to the ISA Server services These

resources can include memory and thread pools Note that saying you have more users than you actually do will not improve performance In this instance, you will be wasting server resources that can be used by other system processes

Network Configuration Settings

ISA Server network configuration settings that influence outbound access controls include the following:

· Routing SecureNAT and firewall client requests

· Routing Web Proxy Service requests

· Passing outbound PPTP requests from internal clients

· The local address table (LAT)

· The local domain table (LDT)

Each of these influences how outbound requests are processed We’ll start with

how SecureNAT and firewall client requests are routed in what are known as firewall chains

Firewall Chaining: Routing SecureNAT and Firewall Client Requests ISA Server provides a great deal of flexibility in terms of how client requests are routed Rather than being limited to using the default connection on the ISA server, you can tell the ISA server to send specific requests via customized routes When firewall clients send their requests to the ISA server, the requests can be routed directly to the Internet via

the primary connection on the ISA server, or you can configure the Firewall Service on

the ISA server to forward the request to another ISA server The question is then, why would you want to do this? The immediate answer is because you can However, that answer won’t be very satisfying when you are trying to explain the rationale for your

network infrastructure design to the network security committee

One reason you might want to forward firewall client requests is that you want to partition the routing of firewall client and SecureNAT client requests from requests made

by Web proxy clients You might want to configure all the computers to use the same ISA server to make the initial connection, but once the connection is made, the Web proxy client requests would go to that server, and the firewall client requests would be routed

to another server In this way, Winsock application requests (such as SMTP, POP3, and NNTP requests) could reach the Internet via a separate computer than the requests made

by Web proxy clients

The rationale for doing this might involve the fact that most Web requests do not require a high level of security, since typically a tiny percentage of Web connections are made via HTTPS (SSL-secured HTTP) Therefore, you could forward the Winsock (firewall client and SecureNAT client) requests to another ISA server that has a more “hardened” configuration

Another reason to route firewall client and SecureNAT client requests separately is

to apportion bandwidth between the these clients and the Web proxy clients across two separate servers and their associated connections to the Internet

The most common reason to configure firewall client routing is to support chaining

of firewall client requests to upstream ISA servers For example, you might have a branchoffice in Pasadena, Texas, and a main office in Dallas When firewall client computers send a request to the ISA server located in Pasadena, you want the ISA server to forward the requests to the Dallas office, because the Internet access point for the organization is located in Dallas In this example, the ISA server might use a VPN interface to connect to the upstream ISA server This prevents users in the Pasadena office from accessing

content from the Internet directly, and content must be accessed via the upstream ISA server in Dallas

Unfortunately, you cannot configure granular Firewall Service routing rules the way that you can for the Web Proxy Service For example, it would be nice to configure a firewall routing/chaining rule so that when your users made a request to sites such as Napster, you could selectively redirect those protocol requests to a server that has a 14.4Kbps modem connection

Configuring Firewall and SecureNAT Client Routing

To configure the way that firewall and SecureNAT client requests are routed, perform the following steps:

1 In the ISA Management console, expand the Servers and Arrays node, then expand your server or array Right-click the Network Configuration node, and click Properties You will see the screen that appears in Figure 8.5

Figure 8.5 The Firewall Chaining Dialog Box

2 The Use primary connection option button is the default setting When this

option is selected, firewall client and SecureNAT client requests are sent out the external interface of the ISA server that receives the request If you are using a

dial-up connection on the ISA server, you must select the Use dial-up entry

check box if you want the connection to automatically dial when a firewall client

or SecureNAT client request arrives at the ISA server

3 The Chain to this computer option button configures the ISA server to

forward firewall client and SecureNAT client requests to another ISA server Type in the name of the upstream ISA server in the text box, or you can look

for the machine on your network via the Browse button

4 The Use this account check box should be checked if you need this ISA server

to pass credentials to the upstream ISA server To set the credentials, click the

Set Account button You will see the screen that appears in Figure 8.6

Figure 8.6 The Set Account Dialog Box

5 Enter the User in the text box, then enter the password and confirm the

password in the Password and Confirm Password dialog boxes Do not enter

credentials from your ISP in this dialog box These are domain or server

accounts Then click OK

6 The Use dial-up entry check box should be checked if the ISA Server needs to

dial a connection in order to connect to the upstream ISA server Note that the dial-up connection can be either a direct dial-up connection or a VPN

connection The dial-up entry must be included in the list of dial-up entries in

the Policy Elements on that ISA server

SECURITY ALERT!

When you enable firewall chaining and the upstream server for firewall and

SecureNAT clients is different from the server configured to route Web proxy requests, requests for Web objects from SecureNAT and firewall clients will be sent to the upstream server configured in the Firewall Chaining configuration

dialog box This point is noteworthy because the requests are forwarded before

the HTTP Redirector Filter has a change to “get at” them

Authentication and Firewall Chaining

If you have enabled firewall chaining so that firewall client requests are passed from one ISA server to another, you address the issue of authentication for the firewall client

computers If a firewall client sends its ISA server a request that requires authentication,

it will pass this authentication information to the upstream server to which the ISA server

is configured to forward firewall client requests

At times, the upstream ISA server might not be able to identify or confirm the credentials of the downstream ISA server firewall client You’ll see this happen if the upstream ISA server belongs to a domain that has no trust relationship with the firewall client that issued the initial request

To handle this situation, configure the downstream ISA server to “stand in” for the firewall client by sending credentials that the upstream ISA server will recognize This task is accomplished by setting an account for the downstream ISA server to use when

“impersonating” the downstream firewall client computer You configured these

credentials in Steps 4 and 5 in the last walk-though we did

For example, what if we don’t add any authentication information in the dialog boxes seen in Steps 4 and 5? The ISA server will send the user’s credentials However, if

we specify an account on the downstream server, that information will be sent instead of

the user credentials This option is useful in situations in which there are no trusts or when you want simplified account management for an entire branch office

NOTE

The authentication we are referring to here is authentication against the ISA server itself The ISA server can be configured to require authentication before

allowing outbound requests We are not referring to authentication information

that might be sent to a destination server on the Internet

Routing Web Proxy Client Requests

Your options to configure how Web proxy client requests are routed through the ISA server are a great deal wider than your options via the firewall chaining configuration we’ve just talked about By taking advantage of Web proxy routing rules, you can forwardWeb proxy requests to another ISA server or directly to the Internet, or you can redirect requests to another Web site Furthermore, these decisions can be made based on the URL included in the initial request In addition, you can use Web proxy routing rules to determine how content is cached

In order to understand the capabilities of these Web proxy routing features, let’s

go over a couple of examples

Suppose you have figured out from analyzing the logs that a couple of Web sites consume a large amount of bandwidth on the external interface of your ISA server Users

need access to these Web sites to download fixes, patches, and third-party utilities and demo programs in order to provide services to your clients The problem is that thesedownloads absorb a great percentage of bandwidth on the external interface of the single ISA server you have installed at this time Web pages load very slowly; email messages are retrieved and sent very slowly, too

To solve this problem, create a destination set (a concept we’ll discuss later in this

chapter) that includes the Web sites responsible for the heaviest downloads Then when the primary ISA server’s Web Proxy Service gets a request for one of these sites, it can redirect the request to another ISA server in your company The external interface of the alternate ISA server can bear the brunt of the heavy download traffic It would be nice to

be able to configure such Web proxy routing rules to apply to selective client address sets

or specific users or groups, but you can’t do that with ISA server

Another example of what you can do is redirect requests for certain sites If users try to access an unproductive site or domain, such as aol.com, you can configure a

routing rule to redirect the request to a URL that includes your appropriate use policy on your corporate home page

Web proxy routing rules allow you to restrict the pages that are cached on the ISA server For example, users might have to connect to a partner Web site where the

information changes frequently throughout the day You would prefer that your users not have to press the F5 key to manually refresh their browsers You can configure a routing rule to prevent caching of that site’s content and to access the site directly whenever a request is made

The most common application of routing rules is to support Web proxy chaining

Web proxy chains can connect ISA servers located at different sites or LAN segments in a hierarchical fashion so that downstream ISA servers can take advantage of the cache contents of upstream ISA servers

Configuring a Web Proxy Service Routing Rule

Before configuring a new routing rule, it’s worth mentioning that when ISA Server is

installed, a default routing rule is created This rule is called Default rule and it has the order number of Last This order number is important because routing rules are

represented as a hierarchical list and are evaluated according to the order that you’ve set A single request might match several different routing rules, but the rule highest on the list determines how the request is processed

To create a new routing rule, follow these steps:

1 Open the ISA Management console, expand Servers and Arrays, and

expand your server or array name Now expand the Network Configuration node, and click the Routing node You will see the current list of routing rules

in the right pane of the console

2 Right-click the Routing node, and click the New and then the Rule

commands This sequence will open the New Routing Rule Wizard On the first page, enter the name of the routing rule, and click Next

3 On the Destination Sets page, click the down arrow on the drop-down list box for Apply this rule to You’ll see the options as they appear in Figure 8.7

A destination set determines what computers or set of computers or sites

should be included in this rule Destination sets are created independently of

routing rules via the Policy Elements node Note that you have a number of

options in terms of how the routing rule is applied In this example, select the

Specified destination set, and click Next

Figure 8.7 The Destination Sets Page

4 After you click the Specified destination set option, the dialog box changes

so that you can select the destination set to which you want this routing rule applied The change in the page is reflected in Figure 8.8

Figure 8.8 The Destination Sets Page After the Rule to Apply Is Selected

5 In this scenario, we’ve created a destination set to apply to the aol.com

domain Select the AOL Website destination set, and then click Next

6 On the Request Action page, decide how you want requests for this

destination set processed Figure 8.9 shows your options

Figure 8.9 The Request Action Page

Your options are to:

· Retrieve them directly from specified destination This option allows the

ISA server to send the request to the default interface on the ISA server that receives the request Note that this does not imply that the request will bypass the Web Proxy or Firewall Services It simply sets the request to be handled by the local server to retrieve the page directly, without redirection

· Route to a specified upstream server This option allows you to forward the

request to another ISA server for retrieval When you select this option, you are

configuring a proxy chain for this route The upstream ISA server will obtain the

Web object, put it in its cache, and then return the object to this ISA server, which will put it in its cache and return the object to the host that issued the initial request

· Redirect to You can have the ISA server redirect the request to another site by typing in the server name in the Hosted site text box You can also change the

port number to which the request is sent There is no default entry In this case, we’ve entered the www.shinder.net site and told it to forward the request

to port 80 on that Web server You must also include the SSL port In this case,

configure it to use the default SSL port 443

Note that we don’t use SSL port 8443, because that is the port used by Web proxy clients to send authentication information to the Web Proxy Service In this case, the ISA server forwards the requests to a destination Web server that

uses the standard SSL port 443, not to another ISA server in the role of a Web

proxy client

7 Now click Next On the Cache Retrieval Configuration page, specify how the

rule searches the cache and what to do if the requested object is not contained

in the cache Figure 8.10 shows this page

Figure 8.10 The Cache Retrieval Configuration Page

Under Search cache for: you have the following options:

· A valid version of the object; if none exists, retrieve the request using the specified requested action A valid version of an object in the Web cache

is an object whose TTL has not expired If you choose this option and a request comes in for an object whose TTL has expired, the request will be routed

directly to the Internet or to an upstream ISA server

· Any version of the object; if none exists, retrieve the request using the specified request action If you choose this option, expired objects will be

returned to the user This increases the chance that an outdated version of a page will be returned to the user, but it decreases the amount of bandwidth consumed on the external interface If no version of the object exists in cache, the request will be forwarded to an upstream Web server or directly to the Internet

· Any version of the requested object Never route the request If you select

this option, the ISA server will search the cache for the requested object If it is

in there, it will be returned It the object isn’t in the cache, the client will

receive an error related to the object not being found

For this walk-through, select Any version of the object… to save

bandwidth on the external interface Then click Next

8 In the Cache Content Configuration page, specify whether the retrieved

object should be entered into the ISA server’s Web cache This page is shown in Figure 8.11

Figure 8.11 The Cache Content Configuration Page

Your options are to Cache content:

· All content, including dynamic content, will be cached Choose this option

if you want to ignore header information returned by Web pages that indicate whether or not content should be cached This includes caching content on dynamic pages that included a question mark (?) in the URL

· If source and request headers indicate to cache, then the content will be cached Choose this option if you want to cache content that the Web server

wants to be cached This information is contained in HTTP response headers With this option, you won’t cache dynamic content

· No content will ever be cached Choose this option if you want to cache no

content obtained via this routing rule Note that this option is used to control content that is not cached on the ISA server In Proxy Server 2.0, you had to configure cache filters In ISA Server, you create destination sets and then create routing rules to inform the server that it should not cache content from sites included in that particular destination set

In this walk-through, select the option to cache content if the headers

indicate to do so Then click Next

9 The last page of the wizard allows you to review your choices If everything

looks correct, click Finish You can use the Back button to change your

choices

After the rule is completed, you can access the properties of the rule by

double-clicking the rule or by right-double-clicking it and double-clicking the Properties command After doing

this, you’ll see the screen that appears in Figure 8.12

Figure 8.12 The Routing Rule Properties Dialog Box

The tabs include General, Destinations, Action, Caching, and Bridging The first four contain the same information you provided the wizard However, the Bridging tab allows you to further refine how the request is routed On the Bridging tab, you can

decide how the requests will be forwarded

The Redirect HTTP requests as frame contains the options:

The Redirect SSL requests as frame includes the options:

· HTTP requests (terminate the secure channel at the proxy)

· SSL requests (establish a new secure channel to the site)

The HTTP requests (terminate the secure channel at the proxy) option

allows the ISA server communicating with the client via SSL to forward the request as a plain HTTP request Note that this is more useful when configuring a routing rule for inbound requests from the Internet than when routing outbound requests from the

internal network to an external server

While you want to protect certain communications via SSL as they move through the Internet, you don’t typically require that communications be as secure once they reach a network under your control By redirecting inbound SSL requests as HTTP once they enter your network, you can reduce the processor load On the other hand, there’s not much sense in taking outbound SSL-protected sessions made by internal clients to the ISA server and then forwarding them as unprotected requests

The SSL requests (establish a new secure channel to the site) option allows

the ISA server to forward a request made over an SSL channel to the internal Web server as an SSL request In this case, the ISA server will establish a new SSL session with the destination server Note that this is not the same as SSL tunneling, in which the ISA server merely forwards the SSL requests to a destination Web server

The Require secure channel (SSL) option requires that the client enter HTTPS in

the browser to access any URL described by the routing rule If you don’t select the box,

you can use either HTTP or HTTPS Selecting this box in the Bridging tab for the routing

rule would require that the client establish an HTTPS connection when it tried to connect

to the destination described by the rule Another way to think about how this option is used with a routing rule is that this is like publishing but in a reverse sense Selecting thisbox would eliminate some choices because you must use HTTPS

You can check the Use a certificate to authenticate to the SSL Web server

check box if you want the ISA server to able to authenticate itself with the destination

site to which the request is being routed When this option is checked, the Select button

becomes available, and you can select the certificate you want to apply Note that this

certificate is a client certificate that the ISA server will present to identify itself to an

upstream server

Routing to a Linux Squid Server

Many administrators already have other proxy servers in place but would like to take advantage of the outbound access control features of ISA Server One example of this situation is an organization that wants to use an ISA server downstream from a Linux Squid proxy server

You can route Web proxy requests sent from clients to an ISA server to a Squid server and take advantage of the access controls configured on the ISA server When the request arrives at the ISA server, it will be sent through the rules engine, and if there is asite and content and a protocol rule that allows the request, the ISA server will route the Web proxy request to the upstream Squid server When the upstream Squid server

retrieves the Web object, it will be returned to the ISA server, and the ISA server will put the object in its Web cache before returning to the client that issued the request

The only disadvantage to routing to an upstream Squid proxy versus routing to an upstream ISA server is that you cannot take advantage of hierarchical routing With an upstream Squid proxy, the downstream ISA server cannot take advantage of the

Autoconfiguration script that would allow the downstream ISA server to resolve requests within an upstream Squid CARP array in the same way it can with an ISA server array We’ll go over this issue in more detail when we cover upstream routing to an ISA server

To route to an upstream squid Server, perform the following steps:

1 Open the ISA Management console, expand the Servers and Arrays node, and then expand the Network Configuration node Right-click the Routing node, click New, and then click Rule

2 In the Welcome page, type in the name of the rule—something like Upstream Squid—then click Next

3 On the Destination Sets page, select All destinations in the Apply this rule

to drop-down list box, then click Next

4 In the Request Action dialog box, select the option to Route to a specified upstream server If you must use a dial-up connection, be sure to place a check mark in the check box for Use dial-up entry, and then click Next

5 On the Primary Routing page, you’ll see something like Figure 8.13

Figure 8.13 The Primary Routing Page

Type in the appropriate information for the name of the Server or array, the Port number and the SSL Port number to which you want the requests

routed on the Squid server If your upstream server listens on different ports, you should change them here

If you require authentication on the Squid server, be sure to configure the

account and the password by clicking the Set Account button and entering that information For Authentication, you’ll have to use Basic because the Linux

box does not support integrated Windows authentication

6 On the Backup Routing page, you can configure a path to use if the Squid

server is not available We’ll talk more about backup configuration in the Web proxy chaining discussion that follows

7 On the Cache Retrieval Configuration page, make the selection that fits your

caching requirements

8 On the Cache Content Configuration page, make the selection that fits your

requirements

9 Click Finish and the Routing Rule is complete

Configuring ISA Web Proxy Chaining

Web proxy chaining allows you to extend the benefits of the ISA server’s Web proxy cache to all members of an organization It also allows you to bring the Web proxy cache closer to users that need access to cached Web objects This makes the cache available

to users in different departments in the same organization or located in remote offices

A Web proxy chain allows ISA servers throughout an organization to take

advantage of the contents of the Web cache of other ISA servers in the organization By chaining ISA servers in this fashion, you can reduce the amount of bandwidth consumed

on a corporate backbone or on WAN links that connect various sites These WAN links can also include VPN connections

Proxy Chaining Example 1: Chaining Through a WAN

For example, suppose your main office is in Dallas You also have remote offices in

Abilene and Galveston There are 2500 computers in the main office, 1500 computers in the Galveston office, and 400 computers in the Abilene office You would like to maximize

the potential of the ISA Server Web cache for all users in your organization and improve your users’ Web experience as much as possible

Each office has a dedicated connection to the Internet The Abilene office has a dedicated 128Kbps basic rate interface (BRI) ISDN modem connection to the Galveston office, the Galveston office has a 256Kbps Frame Relay connection to the Dallas office, and the Dallas office has a 1.5Mbps T1 connection to the Internet You want all Internet Web traffic to exit and enter the main office’s link to the Internet This creates a single point of access for Web traffic in your organization, greatly simplifying your ability to monitor access and implement access control

To optimize the Web caching scheme for your organization, you can configure the smallest office (Abilene) to route Web requests to the ISA server in the Galveston office You can then configure the Galveston ISA server to route Web requests to the Dallas office The Dallas office would then route requests directly to the Internet

Note that we can also make each link in the Web proxy chain fault tolerant If any

of the dedicated links that connect the sites becomes unavailable, you can configure

backup routes that the ISA server can use to access Internet resources In this scenario,

where we are using dedicated links to connect the offices, we might want to install a second device, such as a modem, to provide a backup route for Internet access

To see what happens when we create such as chain, let’s examine what happens when someone at the Abilene office makes a request for a Web page A user on that network sends a request for the Web page, and that request is sent to the ISA server at the edge of the user’s network The Abilene ISA server checks its Web proxy cache to see

if it contains the object If it does contain the object, it returns the object to the user without generating any WAN traffic If it does not contain the object, the ISA server will route the request to the Galveston office

Once the request arrives to the Galveston ISA server, that ISA server checks its own Web proxy cache for the requested object If the object is located in its cache, it returns the object to the Abilene ISA server without generating any WAN traffic on its Frame Relay link to Dallas The Abilene ISA server then puts the object in its own cache and then returns it to the user who made the request If the object is not contained in theGalveston ISA server’s cache, the server forwards the request to the Dallas ISA server

The Dallas ISA server checks its cache If the object is contained in cache, it

returns it to the Galveston ISA server without generating any traffic on the T1 link to the Internet The Galveston ISA server then puts the object into its cache Then the

Galveston ISA server returns the object to the Abilene ISA server, which puts the object

in its cache, and then it returns the object to the host that made the initial request

If the Dallas ISA server does not contain the object in its cache, it fetches it from the Internet server and returns it along that same path, with each ISA server in the return path placing the object in its own cache before returning it

You can see in this example that a single request at the end of the chain has the potential of placing the object on all ISA servers in the chain So, if another user at any location in the network needs to access the same object, it will be on the ISA server located closest to that user This method saves bandwidth on all interfaces in the proxy chain Note that the rationale of configuring the chain with the smallest number of users

at the end of the chain reduces the probability of generating traffic on the central Internetlink at the Dallas office

Note that if any of the links between the offices fails, a backup route can be

configured on the ISA servers in the chain so that a request can still be serviced

Proxy Chaining Example 2: Chaining Within a LAN

Another way to take advantage of the benefits of Web proxy chaining is to use it in an environment that has a number of departmental or area-specific LANs that are connected

to a busy network backbone By placing an ISA server on the edge of each of the LAN segments, you can reduce the amount of traffic on the backbone as well as on the

Internet connection itself

For example, suppose you are responsible for a small college’s network One of the backbone segments connects three college dorms and the recreation center to the

Internet You would like to reduce the amount of traffic on the Internet link as well

as the amount of traffic over the network backbone, especially in light of the fact that the students like to use NetMeeting to call students in other dorms as well as in the

recreation center There is also quite a bit of audio/visual traffic coming in from the

Internet in the form of streaming media, with students often accessing the same online concert simultaneously

You can place an ISA server on the edge of each network segment that connects to the backbone and another ISA server that connects the backbone to the Internet Then you configure the segment ISA servers to route Web requests to the ISA server (or array)

on the edge of the campus network In this way, the segment ISA server cache is

searched first, and only if the object isn’t found in the cache is the request sent over the backbone to the campus ISA server or array If that ISA server has the object in cache, it returns it to the ISA server on the segment backbone

In actual practice, the ISA server at the edge of the campus network needs a

measure of fault tolerance; therefore, you would configure it as an enterprise array When you configure the segment-level ISA servers to route requests to the enterprise array, you can also configure them to take advantage of the Autoconfiguration script When the segment ISA servers use the Autoconfiguration script, they can identify which ISA server in the array will contain the cached object and directly retrieve the object for that server In addition, the script will inform the segment ISA servers when one of the array members is unavailable Therefore, there is fault tolerance as well as load balancing

in this type of routing solution

Configuring Routing for ISA Server Chains

Configuring the routing rule for ISA server chains is similar to configuration for the Squid routing rule, except this time we are able to take advantage of the Autoconfiguration script Perform the following steps to create a link in an ISA server chain

1 Open the ISA Management console, expand the Servers and Arrays node, and then expand the Network Configuration node Right-click the Routing node, click New, and then click Rule

2 On the Welcome page, type in the name of the rule—something like

Upstream ISA Server—then click Next

3 On the Destination Sets page, select All destinations in the Apply this rule

to drop-down list box, then click Next

4 In the Request Action dialog box, select the option to Route to a specified upstream server If you use a dial-up connection, be sure to place a check mark in the check box for Use dial-up entry, then click Next

5 On the Primary Routing page, type in the Server or array name The default port number is 8080 and the default SSL port is 8443 Do not change these

values unless you change the Outgoing Web Requests Listener configuration on the upstream ISA server Figure 8.14 shows these settings If the upstream ISA server is configured to require authentication for outbound Web Proxy Service

access, you must configure an account by checking the Use this account check box and clicking the Set Account button Click Next

NOTE

Remember that earlier in the chapter we were talking about configuring backup routes and how you had to change the outbound Web proxy listener to use port 80? That was because the client using the backup route was no longer a Web proxy client and was not sending requests to the backup route server’s port

8080; it was sending them to port 80 In the present case of configuring an ISA server as a member of an ISA server chain, the downstream ISA server is acting

as a Web proxy client to the upstream ISA server Therefore, it needs to send its

requests to port 8080 on the upstream ISA server’s Web Proxy Service

Figure 8.14 The Primary Routing Page

6 On the Backup Routing page (Figure 8.15), you are presented with the

following options:

· Ignore requests If the primary route is unavailable, the request will be

dropped Select this option to prevent the ISA server from trying other methods

to access the Internet if the upstream ISA server is not available

· Retrieve requests directly from specified destination If the upstream

server is not available, you can configure the ISA server to attempt to access the Web object directly If you have a dial-up entry on the computer, you can configure ISA Server to use the dial-up entry for its backup route

· Route requests to an upstream server This option allows the ISA server to

route the request to an alternate upstream proxy server in the event that the upstream ISA server for the primary route becomes unavailable Note that this option will send requests to port 8080 on the alternate ISA server, since it is still a Web proxy client When you make this selection, the next page will allow you to configure the name/address and port numbers for the upstream ISA server

Figure 8.15 The Backup Routing Page

7 Click Next

8 Select the appropriate option on the Cache Retrieval page, and click Next

9 Select the appropriate option on the Cache Content Configuration page, and click Next

10 Confirm your settings, and click Finish

Outbound PPTP Requests

ISA Server supports outbound PPTP sessions between an internal network client behind

an ISA server and a PPTP server located on an external network This is a new feature, something you could not do with Proxy Server 2.0 However, there is a limitation to this

feature It is available only to SecureNAT clients It will not work if the computer is set up

as a firewall client only In addition, remember that although ISA supports PPTP clients behind the firewall, it does not support L2TP/IPSec clients This is due to issues with address translation and IPSec security negotiation

To allow PPTP through the ISA server, perform the following steps:

1 Open the ISA Management console, expand Servers and Arrays, and then expand Access Policy Right-click the IP Packet Filters node, and click

Properties

2 Click the PPTP tab You will see the screen that appears in Figure 8.16

Figure 8.16 The PPTP Tab in the Packet Filters Properties Dialog Box

3 Place a check mark in the check box for PPTP through ISA firewall Click OK,

and the clients will now be able to access PPTP VPN servers through the ISA server

After enabling PPTP through the firewall, a new IP packet filter is created You can

click the IP Packet Filters node in the left pane and find the SecureNAT PPTP packet filter in the right pane This packet filter opens up a predefined PPTP call filter The PPTP

call filter allows IP Protocol Number 47 (for GRE packets) to move outbound and inbound through the external interface of the ISA server

This filter is available to all SecureNAT clients on your internal network and allows

calls to any PPTP VPN server However, one of the big problems with allowing outbound PPTP is that you cannot control access to what user or group, or even what machine, has access to outbound PPTP This is because PPTP is not a TCP- or UDP-based protocol Access controls can be placed only on protocols that use TCP or UDP

SECURITY ALERT!

It is important to reiterate this point: You cannot exert any outbound access control over PPTP communications leaving the network if you enable the PPTP filter on the ISA server

We investigate packet filters and how to configure them in more detail in Chapter

9

The Local Address Table

The ISA server uses the local address table (LAT) to define the IP addresses that are

internal and those that are external Another way of thinking about the LAT is that it defines what networks are trusted and what networks are not trusted Trusted network clients can be contacted directly Hosts on untrusted networks must be contacted throughthe ISA server, and access rules will be applied to those requests

One thing that the LAT does not allow you to do is configure what might be called

an internal “DMZ” network where the hosts are located on the internal network In such

an internal DMZ, the hosts are located on the internal network but are treated as untrusted hosts that must be accessed through the ISA server’s rules engine With ISA Server, you must configure a DMZ or perimeter network segment as an untrusted

network and then control access as you would for any other external network resource

It is the Firewall Service that uses the LAT to make decisions regarding what is and what is not a trusted network Firewall clients download a copy of the LAT on a periodic basis—every six hours, by default—and use the LAT entries to assess what requests should be sent to the ISA server and what requests should be sent directly to an internal computer on the local network If the IP address of the destination host does not match

an IP address on the LAT, the request is sent to the Firewall Service on the ISA server Because of the LAT, you do not need to configure a default gateway on your firewall clientcomputers

SecureNAT clients do not download a copy of the LAT This makes sense when you realize that a SecureNAT client is configured with a default gateway that routes requests

to remote networks to the internal interface of the ISA server If the SecureNAT client needs to contact a computer on the internal network, it does not need to check the LAT, because routing decisions are made by intervening routers rather than by the client itself

Web proxy clients also do not download a copy of the LAT; they are configured to

send all HTTP requests to a particular ISA server Because Web proxy clients are

preconfigured to send their requests to a specific server, they do not need to make

routing decisions, because the ISA server makes those decisions for them An exception

to this rule occurs when a name without “dots” is typed in for the server in the URL In this case, the Web proxy client treats the request as local and does not send it to the Web Proxy Service on the ISA server Note that you can also configure the browser to treat “dotted” addresses as internal

Configuring the LAT

The LAT can be configured during ISA Server setup or after ISA Server setup has been completed It is a best practice to configure the LAT during setup and make configuration changes only after setup is complete

You should always configure a meaningful and accurate routing table before

installing ISA Server and creating the LAT The ISA server must have a routing table that reflects the routed infrastructure of your internal network The machine must know how

to reach each network ID on your internal network When a client from network ID

192.168.15.0/24 sends a request to the internal interface of the ISA server on network

ID 192.168.1.0/24, the ISA server must know how to return the answer it receives from the Internet server to the requesting client This can be accomplished only by configuring

a correct routing table

An incorrectly configured LAT will prevent ISA clients from being able to access Internet resources and could create a security risk If an external address is inadvertently included in the LAT, any requests coming from such a host will be considered as arriving from a trusted network and will not be exposed to the same scrutiny as requests from an external network client

If you haven’t configured your LAT during setup or if you would like to redefine your LAT, perform the following steps:

1 Open the ISA Management console, expand Servers and Arrays, and

expand the Network Configuration node in the left pane Right-click the Local Address Table (LAT) node, and click the Construct LAT command The Construct LAT dialog box appears (Figure 8.17)

Figure 8.17 The Construct LAT Dialog Box

You are presented with the following options:

· Add the following private ranges: 10.x.x.x, 192.168.x.x,

172.16.x.x-172.31.x.x and 169.254.x.x This option automatically adds to the LAT all

addresses contained within the private network ID address space Although this

is convenient, you might want to avoid using this option One reason you might not want to include all private network IDs on the LAT is that a network

backbone might be located on a private network ID When you connect ISA servers at the edge of network segments that also have privates network IDs, both the backbone and the departmental/local segment will seem to the ISA server as interfaces on an internal, and therefore trusted, network This would undo any security plans you have in mind in terms of access control for each segment with a border ISA server An even more compelling reason applies when you connect to an extranet through a VPN You do not want the private network ID of the remote network in your LAT

· Add address ranges based on the selected computer’s Windows 2000 routing table This is the preferred method for configuring the LAT ISA Server

will examine the routing table on the ISA server and then automatically create the LAT based on those entries This is the most reliable and least error-prone method of configuring the LAT However, remember to include private network IDs for hosts that might connect to your network through a VPN connection in a gateway-to-gateway setup You will need to include the private network ID address range(s) that will be used by those on the networks connected to yours

in the VPN

2 The Select computer drop-down list box allows you to select which computer’s

routing table you want to use in the construction of the LAT Remember, in an array, all the array members share the same LAT Each server should have the same routing table configuration; therefore, you could choose any server in the array

2 The Select the address ranges that are associated with the following internal network adapters selection box allows you to choose the adapter

address range you would like to include in the LAT If your routing table is configured correctly it should not make any difference, since there will already

be an entry for that adapter’s network ID Although this address is included in

the routing table, you must make a selection or the OK button will not become available After you make your choices and click OK, this fact is confirmed in

the following dialog box (Figure 8.18) As this dialog box states, the LAT is based on the routing table because we made that choice All other choices are superfluous

Figure 8.18 Confirmation Dialog Box After Constructing the LAT

Before leaving this subject, let’s take a look at how to build a routing table for the ISA Server

Building the Routing Table

ISA Server uses the routing table to assess where to send packets based on their

destination network IDs The machine looks at the header for the destination IP address and then checks to see if it has a route for that address There must be an established route for each network ID to which the internal interface needs to send packets, because the internal interface is not configured with a default gateway address Therefore, the ISAserver has only the routing table to assist it to get the packet to the internal address

NOTE

The reason that you cannot configure the internal interface with a default

gateway is that routers, including the Windows 2000 router, support a single gateway address for network ID 0.0.0.0 Since you must have a default gateway

on the external interface to send packets to a router that knows how to route Internet-bound packets, you do not have the option, nor do you need one, of setting a default gateway on another interface For this reason, you must

configure a routing table so that packets can be intelligently routed to network IDs on your internal network

While you can use the Routing and Remote Access console’s GUI interface to

construct a routing table, you might not want or need to enable RRAS In our opinion, it

is best if you construct the routing table from the command line This obviates the need

to enable RRAS Let’s use a simple three-segment internal network as an example A single ISA server is configured with an ISDN 128Kbps BRI terminal adapter for its

external interface and an Ethernet 10/100 connection for its internal interface The

internal interface’s IP address is 192.168.1.1 Two dual-homed Windows 2000 servers act

as routers on the internal network Router1 has these IP addresses:

to network ID 192.168.1.0/24, because that network is directly connected to the internal interface

To add a new route, use the following syntax:

route add [destination network ID] MASK [destination network subnet mask]

[gateway address] METRIC [metric value] IF [interface number]

Most of these comments are self-explanatory, but you might not be acquainted

with the IF entry The IF, or Interface Number, allows you to control the interface a

particular route should use to send the packet This control is helpful if you do not want the router to make its own determination of the best route to take and could slightly increase performance In our example of dual-homed machines, there’s no compelling reason to use this entry

To allow our ISA server to route to network ID 192.168.9.0/24, we would enter thefollowing at the command line:

route add 192.168.9.0 MASK 255.255.255.0 192.168.1.250

and then press Enter After you press Enter, you will be returned to the command

prompt and will not be informed that the route is correct However, you will receive an error message if you configure a route to an interface that is not local to the adapter forwarding the packet

To route to network ID 192.168.10.0, you would enter the following at the

command line:

route add 192.168.10.0 MASK 255.255.255.0 192.168.1.185

and press Enter To confirm the entries in the routing table, you can use the route print command

One last but important thing: These routes will work perfectly until you restart the computer After you restart, the routes will disappear because we did not use the

persistent switch To ensure that your routes survive a restart, make sure to include the

–p switch For this switch, the command begins route add –p

NOTE

Routing table entries are stored in memory unless you use the –p switch to

create a permanent route Permanent routing table entries are stored in the

registry

Configuring the Local Domain Table

The local domain table (LDT) contains a list of local domains that is downloaded by

firewall clients on a regular basis The purpose of the LDT is to help the firewall client computer assess whether it should resolve a name or allow the ISA server to resolve the name for it

UNDOCUMENTED ISA SERVER

If the LAT is stored in a file called msplat.txt, you might expect the LDT to be stored in a file called something like mspldt.txt—but you would be wrong The fact is, you won’t find that file anywhere on your hard disks The LDT entries are included in the mspclnt.ini file

For example, if we have *.tacteam.net in our local domain table, all name

resolution requests for hosts in this domain will be sent by the firewall client to a DNS server that it is configured to use in the TCP/IP Properties dialog box If the firewall client

needs to resolve another domain name, such as woodmaster.com, the firewall client

would check its local copy of the LDT, see that this is not an internal domain, and allow the ISA server to resolve the name for it

The LDT solves a problem related to using FQDNs to access resources on the

internal network For example, if we had not included the *.tacteam.net entry in the LDT

and then sent a request for exeter.tacteam.net for name resolution, the firewall client

software would assume that since the request had “dots” in it, the request must be for an external server, and therefore the ISA server would be tasked to resolve the name.However, since we made an entry in the LDT, the firewall client software lets the client computer take over the name resolution duties and allows the name resolution request to

be sent to its preferred DNS server

To configure an entry in the LDT, perform the following steps:

1 Open the ISA Management console, expand Servers and Arrays, and then expand Network Configuration Right-click the Local Domain Table node in the left pane, click the New command, and then click LDT Entry You will see

the screen that appears in Figure 8.19

Figure 8.19 The New LDT Entry Dialog Box

2 In the Name text box, type the name of a computer or include an entire

domain, using the * as a wildcard to include all the computers in the domain

Click OK to complete the entry

UNDOCUMENTED ISA SERVER

We just told you what the LDT is supposed to do However, there’s a little more

to the story From our testing, we find that when a firewall client computer is configured with a DNS server that is able to resolve Internet names, it will not use the ISA server to perform DNS Proxy at any time We have confirmed this finding using Network Monitor The only times the firewall client will use the ISA server to perform DNS Proxy occurs when the firewall client does not have a DNS server address configured in its TCP/IP settings or when the DNS server on the internal network is not able to resolve the Internet host name

Creating Secure Outbound Access Policy

Microsoft ISA Server uses rules to determine the level of access allowed for Internet resources Rules are also used to determine the level of external network client access to internal resources (through Web and server publishing rules) and resources contained on perimeter networks (through packet filters) Using the ISA Server rules, you can attain a high level of control over both inbound and outbound access

ISA Server rules involved with outbound access are grouped into access policies

There are three categories of access policy:

· Site and content rules

· Protocol rules

· IP packet filters

Site and content rules are used to determine the sites (computers or domains) that can be accessed through the ISA server They are also used to control the content that can be accessed via HTTP A schedule can be applied to these rules that will assign the day and time when the rule is in effect In order to access sites and content on the

Internet, there must be a site and content rule that allows access ISA Server includes a default site and content rule that allows access to all sites and all content at all times You must create new site and content rules and disable the default to obtain more

granular control

Protocol rules determine the protocols that are available for both inbound and outbound access Protocol rules will be used to determine outbound access, since you’ll use publishing rules to determine inbound access policy, although both take advantage of protocol definitions These rules determine the protocols and port numbers that are

available to internal users, groups, or computers In order for you to use a particular protocol to access Internet resources, a protocol rule must be in place to allow such

access

ISA Server always checks that there is both a site and content rule and a protocol

rule that allows access to a external resource before access is granted The availability of access policy rules depends on the type of ISA Server installation Table 8.1 shows the relationships

Table 8.1 Access Policies and Installation Types

* The Web protocols include HTTP, HTTPS, FTP, and Gopher

IP packet filters are used to control inbound and outbound access on the external interface of the ISA server Typically, you will not use packet filters to control access to external resources by internal network clients; instead, you will use protocol rules The advantage of using rules rather than packet filters is that protocol rules allow dynamic opening and closing of ports on the external interface

Packet filters allow you to statically open or close a port on the external interface ofthe ISA server When you deny access to particular port by using static packet filters, that port is not available, even if you wanted to use a protocol rule to allow access to it

In a sense, you could say that packet filters override configuration changes made by protocol rules Packet filters are discussed in more detail in Chapter 9

Access policies determine what, where, and when content can be accessed; other

policies determine how the content is accessed These policies include:

· Bandwidth rules

· Routing and chaining rules

Bandwidth rules allow you to shape the traffic moving through the ISA server Theyallow you to indirectly assign the amount of bandwidth available to a particular

connection type This feature takes advantage of the Windows 2000 QoS packet

scheduling service

Routing and chaining rules determine where requests will be sent for further

processing You can use these rules to control the routing of Winsock application traffic, configure proxy chains, or control the content that is cached on the ISA server

Routing and chaining rule configuration depends on the ISA server installation mode Table 8.2details the specifics

Rule Type Firewall Mode Cache Mode Integrated Mode

Protocol rules Yes Web protocols only* Yes