Tài liệu MCSE ISA Server 2000- P14 pptx

S
TUDY STRATEGIES
. For each Enterprise policy assignment, develop
policy elements and access policies, and then
test them.
. When things don’t work as expected, determine
why, and test your assumption to prove it
works.
. There is no substitute for hands-on experience
here. You must install at least two Enterprise
ISA Servers in an array.
. Try different approaches by creating different
types of Enterprise policies and assigning them
one at a time to your array.
16 mcse CH12 6/5/01 12:10 PM Page 363
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
364 Part III CONFIGURING, MANAGING, AND TROUBLESHOOTING POLICIES AND RULES
INTRODUCTION
The Enterprise edition of ISA Server, when integrated in an Active
Directory domain, affords new vistas of centralized control and
management. You may be well versed in how to create and trou-
bleshoot ISA Server Internet access and be tempted to quickly scan
this information. Don’t! Some familiar tasks are restricted, or can
only take place at the Enterprise level. Many capabilities are depen-
dent on the Enterprise policy applied to the array, so learning the
hows and wheres in one array, might not transfer to another array
you’ll visit. Your time will be well spent here, as you need to have a
framework on which to hang your hands-on knowledge. Be sure to
spend time implementing access policy in an array environment.
Organizing your knowledge consists of:
á Determining Where to Do It: An Access Policy Functional

Framework
á Determining Who Can Do It: An Access Policy Permissions
Framework
á Applying Access Policy: An Access Policy Strategy for the
Enterprise
á Troubleshooting Access Problems
DETERMINING WHERE TO DO IT:
AN ACCESS POLICY FUNCTIONAL
FRAMEWORK
The first indication that the rules for access policy creation have
changed is the change to the ISA Server management console inter-
face. Figure 12.1 (Enterprise Edition) and Figure 12.2 (Standard edi-
tion) illustrate that difference. The Enterprise edition makes
available the creation of enterprise level:
á Site and Content Rules
á Protocol Rules
á Some Policy Elements
16 mcse CH12 6/5/01 12:10 PM Page 364
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 12 ACCESS CONTROL IN THE ENTERPRISE 365
FIGURE 12.1
Enterprise location of rules and
policy elements.
FIGURE 12.2
Standard edition location of rules and policy
elements.
In the Standard edition, it’s pretty straightforward: You create all
access rules and policy elements right in one place. In the Enterprise
edition, there are two possible places to create policy elements and
rules: at the enterprise policy location, and/or the array. Also, the

type of policy applied to the array controls whether you can create
any of them. Depending on this policy, some things must be created
at the enterprise level, some at the array level, and some at both.
16 mcse CH12 6/5/01 12:11 PM Page 365
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
366 Part III CONFIGURING, MANAGING, AND TROUBLESHOOTING POLICIES AND RULES
Additionally, some items, such as publishing rules and dial-up
entries, can only be created at the server level. Understanding what
can be created, and where, is a matter of applying the meaning of
the policy to the availability of the object. Table 12.1 lists rules and
policy elements and defines where they can be created according to
policy scope. The policy names used in the table can be cross-
referenced to the policy choices in the following list:
á Array Only: Use array policy only
á Enterprise Only: Use this enterprise policy
á Enterprise with Restrictive Array: Allow array-level access
policy rules that restrict enterprise policy
á Allow Publishing: Allow publishing rules
TABLE 12.1
ACCESS POLICY F UNCTIONAL F RAMEWORK
Access Policy Type of Policy Create at Create at Array
or Policy Enterprise
Element
Site and Array Only No Yes
Content Rules Enterprise Only Yes No
Enterprise with Yes Yes (deny only)
Restrictive Array
Protocol Rules Array Only Yes Yes
Enterprise Only Yes No
Enterprise with Yes Yes (deny only)

Restrictive Array
Schedules All Choices Yes Yes
Bandwidth Array Only No Yes
Priorities Enterprise Only
Enterprise with
Restrictive Array
Destination Sets Array Only Yes Yes
Enterprise Only
Enterprise with
Restrictive Array
TIP
Which Policy Is Effective? To
locate the policy that impacts the server,
find the server’s array in the ISA Server
Management Console. Right-click on the
array object and select Properties. The
Policies page lists and defines the policy
assigned to this array (see Figure 12.4).
EXAM
FIGURE 12.3
When packet filtering is forced at Enterprise
level the choice is grayed out on server.
16 mcse CH12 6/5/01 12:11 PM Page 366
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 12 ACCESS CONTROL IN THE ENTERPRISE 367
Access Policy Type of Policy Create at Create at Array
or Policy Enterprise
Element
Client Address Sets Array Only Yes Yes
Enterprise Only

Enterprise with
Restrictive Array
Protocol Definitions Array Only Yes Yes
Enterprise Only
Enterprise with
Restrictive Array
Content Groups Array Only Yes Yes
Enterprise Only
Enterprise with
Restrictive Array
Dial-up Entries Array Only No Yes*
Enterprise Only
Enterprise with
Restrictive Array
Routing Rules Array Only
Enterprise Only
Enterprise with
Restrictive Array
Publishing Rules Array Only No No
Enterprise Only
Enterprise with
Restrictive Array
Allow Publishing No Yes*
Packet Filters Array Only No if “forced on Yes, if this is
Enterprise Only array.” unchecked.
Enterprise with
Restrictive Array No if “forced on Yes
array.” (see Figures
12.3, 12.4, and 12.5)
* Strictly speaking, publishing rules and dial-up entries are created for a server, not

for array as a whole, but the “Allow Publishing Rules” distinction allows creating
publishing rules at any server in the array.
FIGURE 12.4
Packet filtering controlled at array level—policy.
FIGURE 12.5
The capability to set packeting filtering is now
available.
16 mcse CH12 6/5/01 12:11 PM Page 367
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
368 Part III CONFIGURING, MANAGING, AND TROUBLESHOOTING POLICIES AND RULES
DETERMINING W
HO CAN DO IT: AN
ACCESS P
OLICY PERMISSIONS
FRAMEWORK
The purpose behind this elaborate framework is twofold:
á Provide for centralized control and management of multiple
ISA Servers.
á Allow delegation of array-level policy.
Centralized control is obtained by assigning a policy to each array
that meets the needs of the enterprise. Decentralized IT functions
are met by the choice User Array Level Policy Only. Centralized IT
functions are given all-powerful control by Use This Enterprise
Policy. Arrays that need more restrictive polices can do so with Allow
Array-Level Access Policy Rules That Restrict Enterprise Policy. A
combination of enterprise and array management polices can be ful-
filled by creating multiple arrays and assigning different enterprise
policies.
The second issue in an enterprise model is the capability to assign
administrative chores in a manner that provides the power to do

what is necessary and allowed, without being able to overstep the
boundaries. This can be obtained in a straightforward manner
through the standard permission set at the enterprise and array level,
or by creating custom groups and applying administrative permis-
sions at the level desired.
In the default implementation of ISA Server Enterprise edition, only
the Enterprise Admins group has full control. If a Domain Admin
attempts to write enterprise policies (policy elements and rules), she
will be denied access at the enterprise level (see Figure 12.6 and
Figure 12.7). At the array level, the local computer Administrator,
Domain Admins, and Enterprise Admins have full control. Keep in
mind that before a Domain Admin can create an access rule, the
capability to create rules at the array level must be specified in the
policy.
FIGURE 12.6
Domain admins can’t write enterprise policy ele-
ments.
FIGURE 12.7
Domain admins can’t write enterprise rules.
16 mcse CH12 6/5/01 12:11 PM Page 368
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 12 ACCESS CONTROL IN THE ENTERPRISE 369
APPLYING A
CCESS POLICY:
A
N ACCESS
POLICY STRATEGY
FOR THE
ENTERPRISE
The actual act of creating policy elements and rules to manage

Internet access varies little from that described previously. The dif-
ference in an Enterprise deployment is not in the “how to” but in
the “where” and “who”. While the previous sections of this chapter
detailed the overall rules which determine the where and who, this
section presents some rule and element specifics and describe a strat-
egy to take advantage of the strengths of each policy type.
Specifically, it will look at:
á Creating Policy Elements
á Creating Rules
á Putting Together a Implementation Plan
Creating Policy Elements
Create new policy elements. Elements include schedules,
bandwidth priorities, destination sets, client address sets,
protocol definitions, and content groups.
To create policy elements, follow the same general instructions
described in the Step by Step sections detailed in Chapter 5,
“Outbound Internet Access.” To determine where to create them,
you must both consider where they will be used and where they can
be created. Remember that enterprise level rules can only use policy
elements created at the enterprise level, while array level rules (if
allowed) can use enterprise and policy elements. An example of this
is displayed in Figures 12.8 and 12.9. The “Enterprise Morning”
schedule was created at the enterprise level, and the “Array Evenings”
schedule was created as the array level. Both captures were taken
during a Site and Content Rule wizard schedule choice. (Figure 12.8
at the enterprise level, and Figure 12.9 at the array level).
This arrangement makes sense. Array level policy elements are prob-
ably only relevant at the array level. If they are required at more than
one array, then they can be created at the enterprise level.
FIGURE 12.8

Only enterprise policy elements are available for
enterprise rules.
FIGURE 12.9
Enterprise and array level policy elements are
available at the array.
16 mcse CH12 6/5/01 12:11 PM Page 369
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
370 Part III CONFIGURING, MANAGING, AND TROUBLESHOOTING POLICIES AND RULES
Remember, policy elements in themselves do not allow or restrict
access, they merely form the building blocks that can be used in
rules that do.
Two policy elements can only be created at the array level: band-
width priorities and dial-up entries. Dial-up entries are specific to
the server on which the modem is installed, so there is no need for
an enterprise level policy. Bandwidth priorities are only used in cre-
ating bandwidth rules. Bandwidth rules are only created at the array
level.
Creating Rules
Create and configure access control and bandwidth
policies.
á Create and configure sites and content rules to restrict Internet
access.
á Create and configure protocol rules to manage Internet access.
á Create and configure routing rules to restrict Internet access.
á Create and configure bandwidth rules to control bandwidth
usage.
To create site and content, protocol, bandwidth, and routing rules,
follow the instructions in the Step-by-Step sections detailed in
Chapter 5. To determine why you might want to create them in a
specific , consider the section, “Putting Together an Implementation

Plan” later in this chapter. You should also keep in mind that the
capability to create site and content rules and protocol rules at the
array level is only allowed in two cases:
á If the “Use array policy only” policy applies, rules can be either
“allow” or “deny” access rules. (In the Kansas City array, this is
the policy; see Figure 12.10).
á If the “Use custom enterprise policy settings” policy applies,
rules can only be “deny” rules. (This is the policy in the Grain
Valley arrays; see Figure 12.11).
FIGURE 12.10
Kansas City policy—allow or deny access.
16 mcse CH12 6/5/01 12:11 PM Page 370
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 12 ACCESS CONTROL IN THE ENTERPRISE 371
Bandwidth rules are created at the array level and this can only be
done if array policies are allowed. Routing rules are also created at
the array level, and only if publishing rules are allowed when speci-
fied by enterprise policy, or array level rules are allowed.
Putting Together an Implementation
Plan
If you are an administrator who has inherited policies configured by
others, then you may be limited to following the rules as they are
set. However, if you are the one architecting the implementation of
ISA Server policies in your enterprise then you need to combine
your knowledge of the policy types that are available and the needs
and requirements for access control in your environment. Here are
some helpful hints on how to design a structure that’s right for you.
1. If your IT administration is decentralized, then create a policy
that specifies “Use array policy only.” Arrange ISA Servers in
arrays that represent locations that manage their own IT

function.
2. If your IT administration is highly centralized, create a policy
that uses enterprise policy.
3. If you need to diversify your policies and allow the capability
to restrict enterprise policies in some or all arrays, use the fea-
ture to “Allow array level access policy rules that restrict enter-
prise policy.”
4. If an array needs to use Web and server publishing rules, open
that possibility by checking “Allow publishing policy.”
5. Design backward. Now that you know what’s possible, what
does your environment need? Do local administrators need to
create restrictive site and content rules, or all types of rules?
Do you have multiple areas to manage and are they all differ-
ent? Break it down even further: Do users at some locations
have different needs than users at other locations? Determine
the need for an array based on your knowledge or user needs,
management policy, and administrative delegation. The easiest
way to get a grip on large diverse environments is to plot the
requirements first, then determine which policy model fits
your requirements.
FIGURE 12.11
Grain Valley policy—deny access only.
16 mcse CH12 6/5/01 12:11 PM Page 371
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
372 Part III CONFIGURING, MANAGING, AND TROUBLESHOOTING POLICIES AND RULES
TROUBLESHOOTING
ACCESS
PROBLEMS
Troubleshoot access problems.
á Troubleshoot user-based access problems

á Troubleshoot packet-based access problems
When information can’t flow where it is supposed to, or rules and
procedures can be thwarted to give unrestricted access where it is not
allowed, there is a problem. In either case you need to determine the
reason for the problem and correct it. Although many configuration
elements that need to be checked, you can often reduce the time this
takes by:
á Examining logs for specific information on ports, protocols,
source, and destination information.
á Investigating configurations in the order in which rules are
processed.
á Identifying the problem as being user- or packet-related.
Although the logs are an excellent source of information on the traf-
fic denied access, they primarily provide information that tells you
that a request was blocked. They can be helpful in identifying that
the request reached the ISA Server, however, and should be a point
of reference during troubleshooting. Information on understanding
the logs and how they may be used to assist in troubleshooting
access can be found in Chapter 15, “Monitoring Network Security
and Usage.”
Investigation Via Rule Processing
Order
When a client makes a request, rules are processed in the following
order:
1. Protocol rule
2. Site and content
3. Packet filter
16 mcse CH12 6/5/01 12:11 PM Page 372
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 12 ACCESS CONTROL IN THE ENTERPRISE 373

4. Routing rule (if client is Web proxy)
5. Firewall chaining (if client is SecureNAT or Firewall)
Keep in mind, however, that the presence of a deny rule anywhere
along the path will result in a denial. To troubleshoot access, look
for these items in the following order:
1. By default, all protocols are blocked. Check protocol rules to
determine if a rule exists that would allow access and to be
sure there is no protocol rule that would deny access.
2. If Step 1 does not identify the problem, check Site and
Content Filters to make sure the site is not blocked, the time
of the request is not the issue, and the user and computer used
are not blocked.
3. If the problem is still not resolved, check packet filters. While
packet filters are usually used to allow or block access of
inbound requests, they can be configured to block outbound
requests. Make sure that no blocking packet-filter exists.
4. Finally, determine the type of client being used. If the client is
a Web proxy client, then examine routing rules. If the client is
a SecureNAT or Firewall client, then examine Firewall chain-
ing rules.
Identifying the Problem as Being User-
or Packet-Based
Identifying problems as being user-based or packet-based can go a
long way to reducing the time it takes to troubleshoot the problem.
For example, if you can determine that the request uses a particular
protocol, say, SMTP and your ISA Server has not been configured
to allow SMTP to pass, then you know immediately why the request
was unsuccessful. You can then determine if SMTP should be
allowed to pass, for whom when, and take the appropriate action. In
another case, if you know that other users are successful in using a

particular protocol, or in accessing a particular site, then you can
probably assume that the cause of the problem is user-related and
narrow your investigation to those rules that stipulate user-related
information.
16 mcse CH12 6/5/01 12:11 PM Page 373
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
374 Part III CONFIGURING, MANAGING, AND TROUBLESHOOTING POLICIES AND RULES
Troubleshooting User-Based Access
Problems
Many specific user-based access problems and troubleshooting tech-
niques are covered in section, “Troubleshooting Client Access
Problems,” in Chapter 5. More information on specific client-related
issues having to do with the way clients are treated, and the client
configuration are covered in Part IV, “Deploying, Configuring, and
Troubleshooting the Client Computer”. In summary, troubleshoot-
ing user-based access problems involves resolving the following
issues:
á If the client is a Web proxy client, is the Web browser appro-
priately configured? (Are other sites accessible?)
á If the client is a firewall client, is the client configuration
correct?
á Is there a site and content rule that allows the user access?
á Is there any site and content rule that denies the user access?
á Have both enterprise and array level site and content rules
been reviewed?
á For SecureNAT and firewall clients, is the HTTP redirector
filter enabled?
á If client is a SecureNAT client, remember that a rule that is
defined to apply to all IP protocols will only apply to all
“defined protocols.”

á If authentication is required, can the client process authentica-
tion successfully?
Troubleshooting Packet-Based Access
Problems
To troubleshoot packet-based access problems, you must examine
the following areas that control access:
á Installation mode
á Protocol rules
á Packet filters
TIP
When Is All Not All? In caching
mode protocol rules, even though you
might select “all protocols,” only HTTP,
HTTPS, Gopher, and FTP are selected.
EXAM
16 mcse CH12 6/5/01 12:11 PM Page 374
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 12 ACCESS CONTROL IN THE ENTERPRISE 375
á Protocol definitions
á Application filters
It is important to realize the installation mode of the ISA Server.
Installing the ISA Server in firewall or integrated mode expands pos-
sibilities for client access as well as your opportunities for trou-
bleshooting failed access. Installing ISA Server in caching mode
restricts client access in the following ways:
á Protocol rules only apply to HTTP, HTTPS, Gopher, and
FTP.
á Packet filter properties cannot be configured in caching mode.
á Firewall clients are not supported in cache mode.
This effectively limits client access only via HTTP, HTTPS,

Gopher, and FTP. If a client attempts to use other protocols, then
the answer is clear: This type of access is not allowed.
If ISA Server is installed in firewall or integrated mode, you will
need to look closely at protocol rules, and packet and application
filters. Be sure to check array level and enterprise level policies.
Follow this approach:
1. Is there a protocol rule that denies access? End of story.
2. Is there a protocol rule that allows access? Either way,
continue.
3. Is there a packet filter that denies access? End of story.
4. Is there a packet filter that allows access? Either way, continue.
5. Is there an application filter enabled which denies access?
End of story.
6. Is there an application filter enabled which allows access?
16 mcse CH12 6/5/01 12:11 PM Page 375
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
376 Part III CONFIGURING, MANAGING, AND TROUBLESHOOTING POLICIES AND RULES
Understanding ISA Server access policies in an enter-
prise can be a daunting challenge. There maybe several
levels of policy to design, or if already implemented—to
understand. Enterprise level access policy is established
by Enterprise Admins and assigned to arrays that are
managed by Domain Administrators. Protocol rules and
site and content rules can be created at both levels, if
enterprise policy dictates, or may be restricted to only
one. Within an enterprise, all three scenarios may exist.
This chapter has concentrated on the “where” and “by
whom,” instead of the “how to.”
Finally, troubleshooting client access must involve inves-
tigation of access policy at both levels and concern itself

with packet-based and user-based issues.
CHAPTER SUMMARY
16 mcse CH12 6/5/01 12:11 PM Page 376
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 12 ACCESS CONTROL IN THE ENTERPRISE 377
A PPLY YOUR K NOWLEDGE
Answers to Exercise Questions
2. Allow and deny in array policy.
3. Allow and deny in array policy. Yes.
4. Yes.
5. Yes. No.
6. No. No. No. Yes.
Review Questions
1. John is a Domain Admin. Sally is an Enterprise
Admin. Figure 12.12 displays the Policy on the
ISAArray2 array. Can Sally prevent John from
disabling packet filters?
2. John is a Domain Admin. Sally is an Enterprise
Admin. Figure 12.13 displays the Policy on the
ISAArray3 array. Can John create a site and con-
tent rule to prevent Domain Users from accessing
Ubid.com?
3. John is a Domain Admin. Sally is an Enterprise
Admin. Figure 12.14 displays the Policy on the
ISAArray3 array. Can Sally write a protocol rule
that allows passage of telnet traffic?
4. When would it be advantageous to allow array
level administration of packet-filters?
5. Why are publishing rules created at the server
level?

Exercises
12.1 Examining Access Policy in a Tiered
Enterprise
The best way to understand the diversity available in a
tiered enterprise is to write new policy elements and
rules in different policy implementations.
Estimated Time: 25 minutes
1. Continue working with the arrays established in
Chapter 11, Exercise 11.1. Select the array that
specifies “array only” access policy.
2. As Enterprise Admin, write new policy elements,
protocol rules, and site and content rules. Where
did you write them?
3. As Domain Admin, write new policy elements,
protocol rules, and site and content rules. Where
did you write them? Can you write both allow
and deny rules?
4. Select the array that does not have packet filter-
ing forced. As Domain Admin, can you enable
and disable packet filtering?
5. Select an array that forces packet filtering. As
Enterprise Admin, can you enable and disable
packet filtering on the array? As Domain Admin,
can you?
6. Log on as Domain Admin. Select the “enterprise
only” policy array. Can you write allow rules?
Can you write deny rules? Select the “enterprise
and array policy” array. Can you write allow
rules? Can you write deny rules?
16 mcse CH12 6/5/01 12:11 PM Page 377

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
378 Part III CONFIGURING, MANAGING, AND TROUBLESHOOTING POLICIES AND RULES
A PPLY YOUR K NOWLEDGE
FIGURE 12.12
Question 1.
FIGURE 12.13
Question 2.
Exam Questions
1. John is configuring ISAArray2. This array is
installed in HomeDomain2. His enterprise
encompasses multiple domains and arrays. He
needs to prevent HomeDomain2 Users from
using IRC chat but not restrict users for other
domains. He should
A. Create an enterprise level client address set
that includes the HomeDomain2 users. Write
a site and content rule at the enterprise level
blocking this client address set from using
IRC.
B. Create an array level client address set that
includes the HomeDomain2 users. Write a
site and content rule at the array level block-
ing access to IRC for this client address set.
FIGURE 12.14
Question 3.
16 mcse CH12 6/5/01 12:11 PM Page 378
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 12 ACCESS CONTROL IN THE ENTERPRISE 379
A PPLY YOUR K NOWLEDGE
Answers to Review Questions

1. No. Because packet filtering is not forced on the
array, the Domain Admin, John, can manage
packet filtering. See the section, “Determining
Where to Do It: An Access Policy Functional
Framework.”
2. Yes. In this policy restrictive array rules can be
written. See the section, “Determining Where to
Do It: An Access Policy Functional Framework.”
3. Yes. Even though Sally is an Enterprise Admin
and policy is managed entirely by array, the
Enterprise Admin can create policies at this level.
See the section, “Determining Who Can Do It:
An Access Policy Permissions Framework.”
4. When there are widely varying needs for packet
filters. See the section, “Applying Access Policy:
An Access Policy Strategy for the Enterprise.”
5. Publishing rules are created at the server level
because of the need to control which servers in
the array will allow access to a Web site behind
the array. See the section, “Determining Where
to Do It: An Access Policy Functional
Framework.”
Answers to Exam Questions
1. C. Protocol rules block or allow protocol use.
This should be done at the array level because
there is a stated requirement for not blocking all
users in all domains. See the section,
”Determining Where to Do It: An Access Policy
Functional Framework.”
2. C. Dial-up entries are created at the server level.

The modems exist at that level. See the section,
“Determining Where to Do It: An Access Policy
Functional Framework.”
C. Create an array level protocol rule that blocks
the use of IRC by HomeDomain2 Users.
D. Create an enterprise level protocol rule that
blocks the use of IRC by HomeDomain2
Users.
2. Jan wants to provide backup routes for ISA
Servers in ISAArray3. He installs modems in
these servers and arranges for dial-up access to
the Internet. Then he
A. Creates dial-up entries in the enterprise policy.
B. Creates dial-up entries in the array policy.
C. Creates dial-up entries at each server in the
array.
D. Creates dial-up connections at each server in
the array.
3. Users are having trouble connecting to the com-
pany Web site that resides on the ISA Server. You
examine the ISA Server interface and find the
following: Packet filtering is enabled. An array
rule has been set up to allow traffic inbound to
this server on port 80. Automatic discovery has
been enabled. A blocking rule has been set to
block FTP and HTTPS. To correct the situation
and allow users to access the Web server you
(Select all that apply.)
A. Delete the blocking filter for HTTPS.
B. Delete the blocking filter for FTP.

C. Disable automatic discovery.
D. Set automatic discovery to listen on port
8080.
16 mcse CH12 6/5/01 12:11 PM Page 379
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
380 Part III CONFIGURING, MANAGING, AND TROUBLESHOOTING POLICIES AND RULES
A PPLY YOUR K NOWLEDGE
3. C, D. By default, automatic discovery listens at
port 80. Automatic discovery could also be
changed to listen at a different port. If a Web
server resides on an ISA Server, this will cause a
problem. HTTPS and FTP have nothing to do
with whether users can reach a Web site unless
that Web site requires SSL (HTTPS) or they are
attempting FTP access. See the section,
“Determining Where to Do It: An Access Policy
Functional Framework.”
1. “Configuring Protocol Definitions,” ISA
Server Help.
2. Deployment of ISA Server at Microsoft, paper
at
/>info/itgdeploy.htm
.
Suggested Readings and Resources
16 mcse CH12 6/5/01 12:11 PM Page 380
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
IV
DEPLOYING,CONFIGURING, AND
TROUBLESHOOTING THE CLIENT
COMPUTER

13 Planning and Deploying Clients
14 Installing and Configuring Client Options
PART
17 mcse Pt 4 6/5/01 12:11 PM Page 381
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
17 mcse Pt 4 6/5/01 12:11 PM Page 382
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
O
BJECTIVES
13
CHAPTER
Planning and
Deploying Clients
This chapter covers the following Microsoft-specified
objectives for the Deploying, Configuring, and
Troubleshooting the Client Computer section of the
Installing, Configuring, and Administering Microsoft
Internet Security and Acceleration (ISA) Server 2000
exam:
Plan the deployment of client computers to
use ISA Server services. Considerations
include client authentication, client operating
system, network topology, cost, complexity,
and client function.
. To deploy any new system in the most cost-efficient
and least-disruptive fashion requires careful plan-
ning. Knowing how to configure and install clients
is only a small part of the total picture. Of what
good is knowledge of how to install the firewall
client if it is determined that this client will not be

used in the network? Of what use is the “least
cost/least complexity” dogma, if no one knows the
potential advantages of deploying clients that
require more time and effort to deploy?
. Client choices can also impact network infrastruc-
ture design. If services required by clients are not in
place, more changes to the current network infra-
structure might have to be made. You must know
the current status, as well as client requirements
and plan needed changes so that the process is the
least disruptive possible.
18 mcse CH13 6/5/01 12:12 PM Page 383
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
S
TUDY STRATEGIES
O
UTLINE
Introduction 385
Considering Current Infrastructure
Issues 385
Introducing ISA Server Client Types 386
SecureNAT Client 386
Web Proxy Client 387
Firewall Client 388
Using Multiple Clients on a Single
Computer 389
Migrating Proxy 2.0 Clients 389
Considering Cost and Complexity 390
Considering Authentication Issues 390
Client Requirements 391

Knowledge Requirements 391
Infrastructure Changes 391
Assessing General Client Needs 392
Evaluating Network Infrastructure Changes 393
Chapter Summary 394
Apply Your Knowledge 395
Exercises 395
Review Questions 395
Exam Questions 395
Answers to Review Questions 396
Answers to Exam Questions 397
. Get firmly entrenched in your mind the differ-
ence between client types.
. Learn the relationship between requiring
authentication of all users, the use of user
groups to control access, and the client type.
. Study each client type separately, and the
impact of a single computer becoming more
than one client type at a time.
18 mcse CH13 6/5/01 12:12 PM Page 384
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 13 PLANNING AND DEPLOYING CLIENTS 385
INTRODUCTION
Plan the deployment of client computers to use ISA Server
services. Considerations include client authentication,
client operating system, network topology, cost, complex-
ity, and client function.
Allowed access to the Internet should be transparent to users. That
is, in visiting nonrestricted Web sites, using email, or a other non-
prohibited services across the Internet, no user should be aware that

a firewall or caching server sits between him and the actual source.
On the other hand, you should be able to configure the firewall to
successfully block and allow access as dictated by policy, and these
rules should operate as expected. This is possible with ISA Server
but its implementation is dependent on understanding the client
types and how rules affect them. To plan the deployment of clients,
you must spend time:
á Considering current infrastructure issues
á Considering cost and complexity
This chapter discusses issues pertinent to planning client deploy-
ment, including network infrastructure changes and configuration.
Detailed client, ISA Server and network infrastructure configuration
is covered in Chapter 14, “Installing and Configuring Client
Options.”
CONSIDERING CURRENT
INFRASTRUCTURE ISSUES
Before deciding what systems should be implemented as which type
of ISA Server client, you should take the time to understand the
client types, determine the appropriate options available to each cur-
rent client system, and determine the network infrastructure changes
that might have to be made. To do so consider:
á ISA Server client types
á Using multiple clients on a single computer
á Proxy 2.0 client migration
18 mcse CH13 6/5/01 12:12 PM Page 385
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
386 Part IV DEPLOYING, CONFIGURING, AND TROUBLESHOOTING THE CLIENT COMPUTER
Introducing ISA Server Client Types
The first step in planning deployment of client types is to match ISA
Server client capabilities with your user requirements and policy dic-

tates. The second step is to match ISA Server client availability with
your client operating systems. Where these two matching decisions
cannot be both resolved, that is, where you’d like to use a particular
ISA Server client but you can’t with the current client OS, you must
make a decision regarding accepting less functionality, or upgrading
or changing the client OS.
There are three ISA Server client types:
á SecureNAT client
á Web proxy client
á Firewall client
Table 13.1 summarizes the ISA Server client types.
SecureNAT Client
Every client computer on the internal network that does not have
the firewall client installed and can access the Internet through the
ISA Server is a SecureNAT client. This includes servers that are pub-
lished through ISA Server publishing rules. SecureNAT clients are
not supported in Caching mode. Although the SecureNAT client
does not allow for user-level authentication, many of the benefits
afforded to Firewall and Web proxy clients are also available to
them. Specifically,
á HTTP requests are cached affording faster retrieval and effi-
cient use of Internet access.
á Most access control features. HTTP requests are passed to the
Web proxy service for site and content rule application.
á ISA Server Applications filters can be used to access complex
protocols.
NOTE
NAT Versus SecureNAT The name
SecureNAT was chosen because it extends
Windows 2000 NAT by enforcing ISA Server

policies. SecureNAT hooks into the Windows
2000 NAT service.
18 mcse CH13 6/5/01 12:12 PM Page 386
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 13 PLANNING AND DEPLOYING CLIENTS 387
Changes to the network infrastructure to support SecureNAT clients
are minimal. You must ensure that all requests for Internet access
from the client are routed to the internal network interface of the
ISA Server. This might mean router changes, or changes to the client
network configuration.
Web Proxy Client
Potential Web proxy clients are those that run Web access applica-
tions, such as a Web browser, that can be directed to a proxy server.
There are no special network infrastructure changes due to the use
of Web proxy clients. However, several techniques can be used to
reduce the efforts necessary to configure Web proxy clients.
Configuration can be done by:
á Visiting clients and manually modifying browser
configuration.
á Using ISA Server Management to set automatic configuration
for firewall clients (the Web proxy configuration is down-
loaded during installation of firewall client software).
á Using Group Policy I.E. settings to manage Web proxy
configuration.
TABLE 13.1
DISTINGUISHING C LIENT T YPES
Client Type Client Configuration Protocols That Can Client OS Required Requirements ISA Server Mode
Necessary Be Used to Access
Internet Resources
SecureNAT Possible—client Requires ISA Server Any TCP/IP; Firewall,

default gateway application filters Internet requests Integrated
set to ISA Server are routed to
internal interface ISA Server;
Web proxy Configure browser HTTP, HTTPS, Most any Web application can Caching,
FTP, Gopher be configured to use Integrated
proxy
Firewall Install client Winsock applications Win32 Configuration file Firewall,
Integrated
18 mcse CH13 6/5/01 12:12 PM Page 387
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.