Publishing concepts in ISA Server 2006
Publishing_Concepts.doc
http://download.microsoft.com/download/F/E/0/FE06C50A-92F2-4E2A-9C3B-C10301634690/Publishing_Concepts.doc
Concepts:
server, publishing, ISA server, client, requests, network, Internet, HTTP, ISA server computer, Microsoft, authentication, specify, configuration, protocol, connections.Summary:
Information in this document, including URL and other Internet Web site references, is subject to change without notice.
Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.
Complying with all applicable copyright laws is the responsibility of the user.
Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document.
Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Microsoft, Active Directory, FrontPage, Visual Studio, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
You can use Microsoft® Internet Security and Acceleration (ISA) Server 2006 publishing to make content available to groups of users or to all users, typically from an Internal network or perimeter network (also known as a DMZ, demilitarized zone, or screened subnet) server.
ISA Server provides two types of publishing rules: Web publishing rules and server publishing rules.
Web publishing rules are configured to make Hypertext Transfer Protocol (HTTP) and Secure HTTP (HTTPS) content available on Web servers, such as servers running Internet Information Services (IIS).
Server publishing publishes an entire server through a specific protocol, and enables you to restrict access to specific computers or networks.
You cannot publish HTTP content using server publishing rules.
This document describes Web publishing and server publishing in ISA Server 2006.
The following sections provide information about Web publishing, server publishing, rule elements, rule order, logging requests that match a rule, and deny rules.
ISA Server uses Web publishing rules to handle issues associated with publishing Web content to the Internet, without compromising Internal network security.
Web publishing rules determine how ISA Server intercepts incoming requests for HTTP objects on an internal Web server and how ISA Server responds on behalf of the Web server.
Requests are forwarded downstream to an internal Web server, located behind the ISA Server computer.
If possible, the request is serviced from the ISA Server cache.
You can limit the portions of your servers that can be accessed.
Restricting access to specific paths and content types.
User authentication can be delegated by ISA Server, eliminating the need to reauthenticate at the Web server.
Links in Web content to internal servers are handled seamlessly.
You can select to encrypt traffic between the ISA Server computer and the Web server.
For information on configuring Web publishing rules, see "Authentication in ISA Server 2006" at the Microsoft TechNet Web site.
Requests are forwarded downstream to an internal server, located behind the ISA Server computer.
Server publishing allows virtually any computer on your Internal network to publish to the Internet.
Security is not compromised because all incoming requests and outgoing responses pass through ISA Server.
When a server is published by an ISA Server computer, the IP addresses that are published are actually the IP addresses of the ISA Server computer.
Users who request objects assume that they are communicating with the ISA Server computer---whose name or IP address they specify when requesting the object---while they are actually requesting the information from the publishing server.
This is true when the network on which the published server is located has a network address translation (NAT) relationship from the network on which the clients accessing the published server are located.
When you configure a route network relationship, the clients use the actual IP address of the published server to access it.
Server publishing is not supported when ISA Server is configured with a single network adapter.
In this configuration, ISA Server recognizes only the Internal network.
For example, Web publishing rules require a Web listener network object, while server publishing rules do not.
You can see the rule elements that are available to you by expanding the ISA Server computer node, clicking Firewall Policy, and selecting the Toolbox tab in the task pane.
This rule element type contains protocols that you can use to limit the applicability of rules.
For example, suppose your policy does not allow Dynamic Host Configuration Protocol (DHCP) requests, and as a result, you see many DHCP requests that are being denied.
The request will be accepted only if a rule specifically allows the client access to the content.
Each of the wizards is designed to provide you with the default settings that are most appropriate for specific publishing scenarios, and that provide configuration advantages, including security advantages, for that scenario.
For example, when you are creating a Microsoft Exchange Server publishing rule for publishing Exchange Web client access, and create a new listener, the default method for obtaining client credentials is HTML forms-based authentication.
You specify the type of connection ISA Server makes with the published server (HTTP or HTTPS).
You must select a server certificate to be used by the Web listener, so that the ISA Server computer can authenticate itself to the client.
For example, if the Web site you are publishing allows client requests from the Internet (External network), you should select the External network for the Web listener.
Assigning a different certificate to each IP address enables you to publish several sites over HTTPS using the same Web listener, without using a wildcard certificate.
For example, you can publish mail.contoso.com using a certificate with that name on one IP address, and team.contoso.com using a certificate with that name on a different IP address.
By default, ISA Server listens on port 80 for HTTP requests.
However, if connecting clients are expected to use a different port, you should change the port number accordingly.
You can also enable the Web listener to listen for SSL requests.
You can configure the Web listener properties to define authentication methods for Web requests.
For more information about authentication, see "Authentication in ISA Server 2006" at the Microsoft TechNet Web site.
When users access two different Web sites, such as an Outlook Web Access site and a SharePoint site, users should not have to provide the same credentials again when they click a link to open another site.
The ISA Server 2006 single sign on (SSO) feature reuses user credentials for another published server, eliminating the need to reenter credentials a second or third time.
This enhances the user experience, because users click a link that opens another Web application without having to provide their credentials.
SSO is available when HTML forms-based authentication is the selected client authentication method.
SSO between different applications requires persistent cookies, which are disabled by default.
When ISA Server 2006 receives an incoming Web request, it determines whether the request is allowed, and then routes the request to the appropriate location on the Web server as defined in the Web publishing rule.
If the rule is configured to forward the original host header, ISA Server passes the host header (for example, Host: example.microsoft.com) included in the client request to the published server.
If the rule stipulates that the original host header should not be forwarded, ISA Server substitutes the original host header in the request with the name of the server specified in the Web publishing rule.
As a result, all requests that are routed to a particular Web server are sent to the same (default) Web site on that Web server.
For alternate access mapping to work properly, your SharePoint publishing rule must be configured to forward the original host header.
This is the default configuration when using the SharePoint Publishing Wizard.
SSL bridging is used when ISA Server ends or initiates an SSL connection.
In ISA Server 2006, SSL bridging is automatically configured when the specified Web listener is configured to listen for HTTPS traffic.
SSL bridging protects against attacks that are hidden in SSL-encrypted connections.
For SSL-enabled Web applications, after receiving the client's request, ISA Server decrypts it, inspects it, and terminates the SSL connection with the client computer.
The Web publishing rules determine how ISA Server communicates the request for the object to the publishing Web server.
If the secure Web publishing rule is configured to forward the request using HTTPS, ISA Server initiates a new SSL connection with the published server.
Because the ISA Server computer is now an SSL client, it requires that the publishing Web server responds with a server-side certificate.
ISA Server 2006 can publish a group of servers hosting the same data, also known as a server farm.
Server farms are rule elements, and can be defined either while creating a rule, or through the ISA Server Toolbox.
ISA Server verifies on regular intervals that the servers that are members of the server farm are functioning.
When you protect your server farm with ISA Server, you distribute client requests between the Web servers while maintaining client affinity.
We recommend that the servers in the server farm be located on a separate network from the users, to ensure that ISA Server can properly determine when the servers are available and not available.
In many scenarios, for load balancing to be effective, affinity must be maintained between the client and the Web server that receives and responds to the client's request.
Otherwise, a series of requests from the client and responses from the server farm will be handled by different Web servers, ignoring the context of the requests.
For example, Outlook Web Access is an application that requires client affinity, because the Outlook Web Access server maintains a context for the connected client.
The need for affinity is also demonstrated in a Web shopping scenario, where a client sets up a shopping cart on a Web server.
If affinity is not maintained, at some point in the client's session, the client's requests may be directed to another Web server that is unaware of the shopping cart.
When you apply a rule to a server farm, you can also configure whether the load balancing mechanism should be cookie based or source-IP based.
We recommend that you use session affinity when possible, because it provides more reliable client affinity when a Web server is restarted.
Session affinity should be used for load balancing Outlook Web Access or Windows SharePoint Services access, both of which use Microsoft Internet Explorer®, and therefore support HTTP cookies.
IP address-based affinity must also be used in a scenario where you are load balancing remote procedure call (RPC) over HTTP Outlook access.
Note that if your Web servers use a port other than port 80, specify that port on the server farm properties Connectivity Verification tab.
ISA Server provides a Drain option allowing you to specify that a server in the farm should temporarily stop accepting new connections.
Outlook Web Access provides Web browser access to e-mail, scheduling (including group scheduling), contacts, tasks, and collaborative information stored in Exchange Storage System folders.
RPC over HTTP enables users to access e-mail with Microsoft Office Outlook 2003 over the Internet.
The user accesses the ISA Server computer, which then forwards the request to the Outlook Web Access server or RPC over HTTP proxy server according to the conditions of your mail server publishing rule.
The published server is a SecureNAT client.
Therefore, no special configuration of the published server is required after you create the server publishing rule on the ISA Server computer.
ISA Server provides built-in inbound protocol definitions for server publishing.
The address of the source is translated only if the network relationship is NAT.
If the network relationship is route, there is no address translation.
If the Web proxy is used, the server being accessed sees the ISA Server address.
When the network relationship is defined as NAT, the client connects to the ISA Server external address.
The published server receives the packet from a source address of either the client or the ISA Server internal address, depending on how you configure the publishing rule.
The default setting for server publishing rules is that the published server receives the client address.
The default setting for Web publishing rules is that the published server receives the ISA Server internal address.
When the network relationship is defined as route, the client connects directly to the server.
The published server will receive the packet from the client address.
However, for Web publishing rules (only when publishing HTTP), you can configure whether the published server should receive the ISA Server internal address.
For access rules, SMTP, DNS, and POP filtering cannot be configured.
All other built-in application filtering can be performed.
For application filters developed by third-party vendors, the vendor should indicate the support model.
However, when a single server is typically accessed by many clients, we recommend that you use publishing rules, because ISA Server will ensure that the clients are load balanced when the server is accessed.
Summarized by Copernic Summarizer
posted by Helge Olav Helgsen @ 14:26
0 comments
