Recomendados
Mais conteúdo relacionado
Semelhante a 50357 a enu-module03
Semelhante a 50357 a enu-module03 (20)
Mais de Bố Su
Último
Último (20)
50357 a enu-module03
- 1. Module 3: Remote Access Gateway © 2009, Microsoft. All rights reserved. All other trademarks are the property of their respective owners.
- 2. Module Overview Remote Access Gateway overview Server publishing Web publishing Virtual Private Networking (VPN) connectivity
- 3. Lesson 1 – Remote Access Gateway Overview
- 4. Remote Access Connectivity Options Forefront TMG 2010 Connectivity Example Method Goal Usage Scenario Non-HTTP server Connectivity to specific Access to internal e-mail Publishing internal non-HTTP servers (SMTP) server Web server publishing Connectivity to internal Access to Outlook Web Web servers application Virtual Private Network Full connectivity to the Access for employees corporate network connecting from home or at a customer site
- 5. Forefront TMG 2010 vs. Forefront™ Unified Access Gateway (UAG) Product Positioning Forefront TMG 2010 Enables users to safely and productively use the Internet without worrying about malware and other threats Forefront UAG Comprehensive, secure remote access to corporate resources Forefront UAG is the preferred solution for providing remote access Forefront TMG 2010 still provides support for remote access features, but not the recommended solution
- 6. Lesson 2 – Non-HTTP Server Publishing
- 7. Non-HTTP Server Publishing Allows map requests for non-Web servers in one of the TMG 2010 networks Clients can be either on the Internet or on a different internal network Can be used to publish most TCP and UDP protocol Behavior depends on whether non-Web server is behind a NAT relationship or not If behind NAT, clients will then connect to an IP address belonging to Forefront TMG If behind a route relationship, TMG 2010 listens for requests on the IP address of the non-Web server The published server should be configured as a SecureNAT client with a default gateway pointing to TMG 2010
- 8. Sample Server Publishing Scenario DNS Server Publishing 192.168.0.100 DG: 192.168.0.3 ` DNS Server 203.16.4.1 10.0.0.3 192.168.0.3 192.168.0.254 TMG 1. DNS request 203.16.4.1 > 10.0.0.3 2. Check rule match 192.168.0.101 DG: 192.168.0.254 FTP Server
- 9. Check Publishing Rule Match 9
- 10. Sample Server Publishing Scenario DNS Server Publishing 192.168.0.100 DG: 192.168.0.3 ` DNS Server 203.16.4.1 10.0.0.3 192.168.0.3 192.168.0.254 TMG 1. DNS request 203.16.4.1 > 10.0.0.3 2. Check rule match 192.168.0.101 DG: 192.168.0.254 3. Rule matched FTP Server 4. Check rule action
- 11. Check Rule Action 11
- 12. Sample Server Publishing Scenario DNS Server Publishing 192.168.0.100 DG: 192.168.0.3 ` DNS Server 203.16.4.1 1. DNS request 10.0.0.3 203.16.4.1 > 10.0.0.3 192.168.0.3 192.168.0.254 2. Check rule match TMG 3. Rule matched 4. Check rule action 192.168.0.101 5. Action is allow DG: 192.168.0.254 FTP Server 6. Evaluate filters
- 13. Evaluate Network Inspection System (NIS) Filters 13
- 14. Evaluate Application Filters 14
- 15. Sample Server Publishing Scenario DNS Server Publishing 1. DNS request 203.16.4.1 > 10.0.0.3 2. Check rule match 192.168.0.100 DG: 192.168.0.3 3. Rule matched ` 4. Check rule action DNS Server 203.16.4.1 5. Action is allow 6. Evaluate filters 10.0.0.3 192.168.0.254 7. Request OK 192.168.0.3 TMG 8. Forward request 203.16.4.1 > 192.168.0.100 9. Server response 192.168.0.101 DG: 192.168.0.254 192.168.0.100 > 203.16.4.1 FTP Server
- 16. Sample Server Publishing Scenario FTP Server Publishing 1. FTP request 192.168.0.100 DG: 192.168.0.3 203.16.4.1 > 10.0.0.3 ` 2. Check rule match DNS Server 3. Rule matched 203.16.4.1 4. Check rule action 10.0.0.3 5. Action is allow 192.168.0.3 192.168.0.254 TMG 6. Evaluate filters 7. Request OK 8. Forward request to FTP 192.168.0.101 DG: 192.168.0.254 192.168.0.3 > 192.168.0.101 FTP Server 9. FTP server response 192.168.0.101 > 192.168.0.3 10. TMG response 10.0.0.3 > 203.16.4.1
- 17. Server Publishing Wizards Available from Firewall Policy Tasks Publish common non-Web protocols Publish mail (SMTP) servers
- 18. Non-HTTP Server Publishing Things to consider when planning Server Publishing No authentication support Access restriction by network elements only Networks, subnets, or IP addresses No support in single adapter configuration Client source IP address preserved Behavior can be changed using rule setting Application Layer Filter and NIS signature coverage SMTP, POP3, DNS, etc. 18
- 19. Lesson 3 – Web Publishing
- 20. Web Publishing Provides secure access to Web content to users from the Internet Web content may be either on internal networks on in a DMZ Supports HTTP and HTTPS connections Forefront TMG 2010 Web Publishing features: Mapping requests to specific internal paths in specific servers Allows authentication and authorization of users at TMG level Allow delegation of user credentials after TMG authentication Caching of the published content (reverse caching) Inspection of incoming HTTPS requests using SSL bridging Load balancing of client requests among Web servers in a server farm
- 21. Accessing Web Resources OWA RPC/HTTP(S) HTTPS ActiveSync Exchange Server HTTPS HTTP ` HTTP HTTPS Web Internet Server HTTP SharePoint Server Forefront TMG 2010 can publish multiple internal Web servers, using multiple external IP addresses and protocols
- 22. Configuring 1. Define web listeners IP addresses and ports that will listen for Web requests Authentication method used (client to TMG 2010) Server certificates and SSL options Number of client connections allowed 2. Create other rule elements Source addresses Web farms User sets Schedules 3. Run appropriate wizard 22
- 24. Configuring Web Listeners Assigning Certificate to Web Listener Showing Invalid Certificates Private Key not Installed Certificate Missing
- 25. Securing SSL Traffic SSL Bridging: 1. Client on Internet encrypts communications 2. TMG 2010 decrypts and inspects traffic 3. TMG 2010 sends allowed traffic to published server, re-encrypting it if required
- 26. Authentication Process 1. Client credentials received 2&3. Credentials validated 4. Credentials delegated to internal server 5. Server send response 6. Response forwarded to client
- 27. Configuring Web Listeners Client Authentication Methods Authentication Providers: Credential Types: Credential Types: AuthenticationPassword Basic Username and Password Username and Username and Passcode Active Directory Username and Passcode Providers: LDAP Username, Password and Active Directory only RADIUS Passcode Fallback to: Providers: Authentication Providers: Digest Authentication BasicActiveDirectory only Active Directory Active Directory Digest server Integrated LDAP server LDAP Integrated Directory only RADIUS Active RADIUS RADIUS OTP RADIUS OTP RSA SecurID RSA SecurID Fallback to Basic Fallback to Basic Password Management Password Management
- 28. Authentication Delegation Authentication Methods None – client cannot authenticate directly None – client can authenticate directly Basic authentication NTLM authentication Negotiate Kerberos/NTLM Kerberos Constrained Delegation SPN required for Kerberos Forefront TMG 2010 needs to be in the same domain as the published server
- 29. Authentication Delegation Authentication Methods x Delegation Support Matrix Authentication Authentication Method Provider Delegation Method Basic Active Directory Basic Forms-based LDAP NTLM Authentication (password RADIUS Negotiate (Kerberos/NTLM) only) Kerberos Constrained Delegation Forms-based SecurID SecurID Authentication (passcode RADIUS OTP Kerberos Constrained Delegation only) Forms-based SecurID SecurID Authentication (password RADIUS OTP Basic & passcode) NTLM Negotiate (Kerberos/NTLM) Digest Active Directory® Kerberos Constrained Delegation Integrated Client Certificate None, client can authenticate directly and None, client cannot authenticate directly options apply to all methods
- 30. Single Sign On Sample Scenario – Two Published Web Sites requiring AuthN With Single Signon Without Single Signon: 1. User Prompted for authentication 2. User Clicks Link to SharePoint 3. User NOT Prompted for authentication Prompted for authentication again Exchange.Company.Com FBA ` SharePoint.Company.Com 30
- 31. Configuring Web Listeners Single Signon
- 32. Web Publishing Wizards Publish Web sites Publish SharePoint sites Publish Exchange Web client access Outlook® Web Access Outlook® Anywhere Exchange ActiveSync® Outlook® Mobile Access Microsoft® Exchange Server® 2003
- 33. Web Farms Distributes requests evenly among available Web servers Detect offline servers and implement consistent failover Allow the draining, removal, and addition of servers without disrupting current connections Methods for monitoring connectivity include HTTP GET, PING request, or TCP connection to a given port Supports IP or cookie-based affinity
- 35. Web Publishing Rules Define membership to user group Across different authentication namespaces Used for authorization at Forefront TMG 2010 level
- 36. Web Publishing Rules Configure Web rule schedule Define access hours for accessing the Web site Configure link translation Translates internal names in links to public names of the Web sites
- 37. Lesson 4 – Virtual Private Networking (VPN) Connectivity
- 38. Forefront TMG Virtual Private Networking (VPN) TMG 2010 supports two types of VPNs: Remote Access VPN Site-to-site VPN TMG 2010 implements Windows Server® 2008 VPN technology Implements support for Secure Socket Tunneling Protocol (SSTP) Implements support for Network Access Protection (NAP)
- 39. Secure Socket Tunneling Protocol (SSTP) New SSL-based VPN protocol HTTP with SSL session (TCP 443) between VPN clients and servers to exchange encapsulated IPv4 or IPv6 packets Support for unauthenticated Web proxies Support for Network Access Protection (NAP) Client support in Windows Vista® SP1 No plans to backport SSTP to previous versions
- 40. Network Access Protection (NAP) Windows Policy Validation and Enforcement Platform Policy Determines whether the computers are compliant with the company’s Validation security policy. Compliant computers are deemed healthy. Network Restricts network access to computers based on their health. Restriction Provides necessary updates to allow the computer to get healthy. Remediation Once healthy, the network restrictions are removed. Ongoing Changes to the company’s security policy or to the computers’ health Compliance may dynamically result in network restrictions.
- 41. NAP Support in Forefront TMG 2010 Enforces compliance and provides remediation for clients connecting remotely through Remote Access VPN Supports all VPN protocols, including SSTP Different solution than the Remote Access Quarantine Services (RQS) supported in ISA Server 2006 NAP validates health status of the remote client at connection time VPN network access limitation is done through IP packet filters applied to the VPN connection Access limited to resources on the restricted network
- 42. NAP with Forefront TMG Walkthrough Restricted Network Corporate Network Remediation Servers System Health Servers Unhealthy SHA performs remediation against remediation servers Ongoing policy updates to Network Here is the fix you need. Policy Server VPN QEC passes SoH VPN QEC queries NAPAgent collects Responses back to new SoH and for SOHs NAPAgent passes NAPAgent to VPN QEC PEAP messages EAP VPN Session Request PEAP messages Can I pleaseHere is my SOH the network? have access to EAP - Response/Identity Here is my SOH EAP - Request/Identify RADIUS Access-Accept PEAPEAP - Request/Identify PEAP Message Message EAP – Request/Start – Send SOH State: – Request/Start – Send SOH EAP Quarantine State: Full Access Forefront TMG According to policy, the client is Client SOH Responses SOH Responses 2010 not up to date. Quarantine client. up to date. Restrict client to – no filters Grant access 10.10.10.0/24 Network Policy Server
- 43. NAP Components Platform Components Enforcement Components Health Components System Health Agents (SHA) = Declare = health status, coordinates between SHA and QEC. Quarantine Agent (QA) Clients (QEC) health (patch state, virus signature, system configuration, Quarantine Enforcement= Reports client Negotiate access with network access device(s); etc.). VPN, 1X, IPSec QECs. DHCP, System Health Validators= Restricts networknetworkto madebased on what SHV certifies. Network Access Devices = Provide client’s access access by health agents. Quarantine Server (QS) (SHV) = Certify declarations healthy endpoints. System Registration Authority = Issues certificates to clients that componentschecks. client. Health Health Servers = Define health requirements for system pass health on the Remediation Servers = Install necessary patches, configurations, applications. Bring clients to healthy state. Remediation Servers System Health Servers Updates Health policy Client Health Network Network Statements Access Requests Policy SHA<n> Server Health Result Quarantine SHV<n> Agent QEC QEC Quarantine Server Network Access Device 1 2 (Forefront TMG 2010)
- 44. Comparing NAP to RQS/RQC Remote Access Quarantine Service (RQS) and Remote Access Quarantine Client (RQC) Supports all versions of Windows® Requires configuration of scripts for policy evaluation and remediation Requires the use of Connection Manager Supports only remote access (VPN or dial up) connections Network Access Protection (NAP) Supports Microsoft Windows XP® Service Pack 3 or newer operating systems Requires System Health Agents (SHAs) for policy evaluation and remediation Supports any kind of network connection, with no requirements for Connection Manager usage Both methods are supported by Forefront TMG 2010
- 45. Configuring Forefront TMG with NAP 1. Install Windows Server® 2008 or Windows Server® 2008 R2 Network Policy Server (NPS) role Preferably in a separate server from Forefront TMG 2010 2. Configure Forefront TMG 2010 as a RADIUS client 3. Configure remote access policies at NPS server Configure System Health Validators (SHVs) and health policies Create network policies Create connection request policies Define remediation servers 4. Configure NAP clients Enable NAP service and EAP quarantine agent Configure SHAs
- 46. Questions
- 47. Lab 3: Remote Access Gateway Lab In this lab, you will: Use Web Publishing to publish Exchange Web Services Lab 3 - Exercise 6 Estimated completion time: 45 min
- 48. © 2009 Microsoft Corporation. All rights reserved. Microsoft, Forefront, Windows and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
Notas do Editor
- Forefront TMG 2010 uses server publishing rules to map requests for non-Web servers located in a Forefront TMG 2010 network from clients located in other networks. Clients can be external clients located on the Internet or internal clients located on a different internal network. When the network on which the published server is located has a NAT relationship with the network from which client requests are located, server publishing works as follows:The IP address published by the server-published rule belongs to Forefront TMG. Clients make a request for the published resource to the client-facing adapter on the Forefront TMG server and not directly to the internal server.By default, the client source address sent to the published server is that of client. You can change this setting to specify that the source address sent to the published server is that of the Forefront TMG server.When the network on which the published server is located has a route relationship with the network from which client requests are located, server publishing works as follows:Forefront TMG listens for requests on the IP address of the published server.Clients make a request to the IP address of the internal server.Server publishing rules display the following characteristics:Server publishing can be used to publish most TCP and UDP protocols.The published server should be configured as a SecureNAT client with a default gateway pointing to Forefront TMG 2010.You cannot authenticate user requests for server publishing rules.You can use IP address control to specify who can access published resources.A server publishing rule can only publish a single server and protocolIn some circumstances you may want to consider using server publishing rules instead of access rules for internal client requests. For example, if you want to allow internal clients to access a non-Web server located in a perimeter network. For a comparison of using server publishing rules or access rules, see the Microsoft TechNet article About network relationships and firewall policy (http://technet.microsoft.com/en-us/library/cc995201.aspx).
- For non-HTTP requests, Forefront TMG 2010 checks network rules, and then checks publishing rules to determine if requests are allowed.Overriding default ports Server publishing configures Forefront TMG 2010 to listen on a specific port and forward requests to a published server. You can configure the following port properties:Specify the port on which should listen for requests for request. If you publish on a port other than the default port, Forefront TMG 2010 receives client requests for the published service on the nonstandard port, and then forwards requests to the designated port on the published server. For example, a server publishing rule may specify that client requests for FTP services connect through port 22 on the Forefront TMG 2010 computer before being redirected to the default port 21 on the published server.
- When using server publishing rules, Forefront TMG 2010 forwards the traffic as it does for access rules, but it uses application filters directly. For example, the Single Mail Transfer Protocol (SMTP) filter is not used for SMTP traffic handled by an access rule, but it is used with traffic handled by a server publishing rule.In server publishing rules, the client in the destination network makes a connection to the Forefront TMG IP address on which the publishing rule is listening for requests. When Forefront TMG 2010 forwards the traffic to the published server, it replaces the Forefront TMG IP address with the IP address of the internal server that it is publishing, but it does not modify the source IP address. Note that in a NAT relationship, server publishing rules can only access the network specified as the destination network. In addition, because server publishing across networks with NAT leaves the source IP address intact when forwarding traffic to the published server, the published server must use the Forefront TMG 2010 computer as the last hop in the routing structure to the destination network. If this is not possible, configure server publishing rules to use the setting Requests appear to come from the Forefront TMG computer. This causes Forefront TMG 2010 to perform full NAT on the traffic handled by the rule.
- Forefront TMG Web publishing makes Web content securely available to groups of users or to all users who send requests to your organization from the Internet. The Web content requested is typically stored on Web servers in the Internal network or in a perimeter network (also known as a screened subnet or a demilitarized zone (DMZ)).With Web publishing rules, you can allow or deny requests based on defined access policies. You can restrict access to specified users, computers, or networks, require user authentication, and inspect the traffic. Content caching enables Forefront TMG 2010 to cache Web content and to respond to user requests from the cache without forwarding the requests downstream to the published Web server. This type of content caching is called reverse caching. Web publishing rules have many features that determine how client Web requests are passed to the published Web servers, including the following:Mapping requests to specific internal paths to limit the portions of your Web servers that can be accessed.Delegation of user credentials for authenticating Forefront TMG to the Web server after authentication by Forefront TMG 2010, without requiring users to supply their credentials for a second time.Link translation for replacing internal host names and paths in Web content with public names and external paths.Secure Sockets Layer (SSL) bridging, which enables Forefront TMG to inspect incoming HTTPS requests and then forward them to the Web server over an encrypted SSL channel.Load balancing of client requests among the Web servers in a server farm, with maintenance of client affinity for increased availability and improved performance.
- When you create a Web publishing rule, you specify a Web listener to be used when applying the rule. The Web listener properties determine:Which Internet Protocol (IP) addresses and ports on the specified networks will listen for Web requests. Which authentication method will be usedwhen authentication is required. Number of client connections that are allowed. The Web listener is used to:Indicate the IP address and port to which a client makes a connection. Enable TMG 2010 to pre-authenticate the connection. Web listeners can be used by more than one Web publishing rule.
- The Web listener network, or networks, that you select depends on which network clients will use to connect to the published Web server. For example, if the Web site you are publishing allows client requests from the Internet (the external network), you should select the External network for the Web listener. By selecting the External network, you are selecting the IP addresses on the Forefront TMG 2010 computer that are associated with the external network adapter. If you do not limit the IP addresses, all IP addresses associated with the selected network adapter will be included in the listener configuration.Web listeners are used by a Web publishing rule. The rule specifies source network objects in addition to specifying a Web listener. The network objects specified as sources in the Web publishing rule must include the networks selected for the Web listener. Publishing multiple SSL Web sites on selected IP addresses You can specify that a Web listener will listen on one or more specific IP addresses. When you do so for an HTTPS Web listener, you can choose to assign a single certificate to all of the IP addresses, or to assign a different certificate to each IP address. Assigning a different certificate to each IP address enables you to publish several sites over HTTPS by using the same Web listener, without using a wildcard certificate. For example, you can publish mail.contoso.com by using a certificate with that name on one IP address, and team.contoso.com by using a certificate with that name on a different IP address.Alternatively, you can publish multiple Secure Sockets Layer (SSL) Web sites by using a single Web listener and a wildcard certificate. For instructions for implementing this scenario, see the Microsoft TechNet article Using wildcard certificates (http://technet.microsoft.com/en-us/library/cc441561.aspx).By using the same listener for several sites, you can take advantage of the Forefront TMG 2010 single sign-on (SS0) feature, which requires a common Web listener for all of the SSO sites.Authentication You can create Web publishing rules that allow or deny access to a set of computers or to a group of users. If the rule applies specifically to users, Forefront TMG 2010 checks the incoming Web request properties to determine how the user will be authenticated. For example, a Web publishing rule might allow access only to specific users. Forefront TMG 2010 will authenticate the user requesting the object, to determine whether the Web publishing rule allows the requesting user access. The user must authenticate, using one of the authentication methods specified for the incoming Web requests.Forefront TMG provides a secure, encrypted logon environment for browsers that support Microsoft Windows NT® Challenge/Response authentication, and for other browsers that use Basic authentication. Authentication methods can be set for all IP addresses on the server, or separately for each IP address.Single sign-on (SSO) enables your users to move safely from one application to another, without having to reauthenticate. SSO is configured on the Single Sign On Settings page of the New Web Listener Wizard, and is available for HTML forms-based authentication.For more information about authentication in Forefront TMG, see the Microsoft TechNet article Overview of client authentication (http://technet.microsoft.com/en-us/library/cc995161.aspx).Limiting concurrent connections By limiting the number of client connections allowed simultaneously to the Forefront TMG 2010 computer, you can prevent attacks that may overwhelm the system's resources. This is particularly useful when publishing servers.
- Single sign-on (SSO) enables users to authenticate once to Microsoft Forefront Threat Management Gateway and then, without reauthenticating, access all of the Web sites with the same domain suffix that Forefront TMG 2010 publishes on a specific Web listener. Web sites can include Microsoft® Outlook® Web Access and Microsoft® SharePoint® Server sites, as well as standard Internet Information Services (IIS) Web sites.A typical example of SSO is a user who logs on to Outlook Web Access by providing credentials on a form. In one of the e-mail messages that the user receives, there is a link to a document that is stored on a SharePoint server. The user clicks the link, and the document opens without an additional request for authentication. This example relies on the use of persistent cookies.Security notes As long as a user's browser process is still running, that user is logged on. For example, a user logs on to Outlook Web Access. From the Microsoft Internet Explorer menu, the user opens a new browser window and then navigates to another site. Closing the Outlook Web Access window does not end the session, and the user is still logged on.When enabling SSO, be sure to provide a restrictive SSO domain. Providing an inclusive domain, such as .co.uk, allows the Web browser to send the Forefront TMG SSO cookie to any Web site in that domain, creating a possible security risk.In a scenario where you create a Web listener that uses forms-based authentication with RSA SecurID validation and you enable Collect additional delegation credentials in the form, Forefront TMG 2010 does not verify whether a user enters the same or a different name for the additional credentials.Note: There is no support for SSO between different Web listeners. SSO is supported for published Web sites whose host names have the same DNS suffix after the first dot. For example, you can configure SSO when publishing mail.fabrikam.com and team.fabrikam.com by specifying .fabrikam.com as the SSO domain. However, you cannot configure SSO for mail.fabrikam.com and mail.contoso.com. In addition, a DNS suffix specified as an SSO domain must consist of at least two segments separated by an embedded dot. For example, .fabrikam.com and .portal.fabrikam.com are valid SSO domains, but .com is not a valid SSO domain.
- Server farm load balancing enables administrators of Microsoft Forefront Threat Management Gateway to publish a farm of Web servers that perform the same role or host the same content to do the following:Implement load balancing to distribute requests evenly among available Web servers.Detect offline servers and implement consistent failover.Allow the draining, removal, and addition of servers without disrupting current connections.Although you can publish a hardware load balancing device to balance traffic to Web servers, Forefront TMG 2010 server farm load balancing provides a number of advantages.Hardware load balancing devices may use source IP addresses to balance requests, and this may not be viable when balancing requests from clients situated behind network address translation (NAT) devices. For Web publishing requests, if Forefront TMG 2010 is not configured to forward the original client IP address to the published server, the source IP address for requests will be that of the Forefront TMG 2010 computer.Although one solution to the source IP address issue is to configure Forefront TMG 2010 to forward the original client IP address, this may be difficult to scale. It requires the Forefront TMG 2010 computer to be configured as the default gateway on published servers, so that the published server directs responses to the Internet to the Forefront TMG 2010 computer.The server farm load balancing feature eliminates the need to purchase a load balancing hardware device, thus saving costs. Creating server farms Forefront TMG allows you to group Web servers that share the following characteristics:All servers in the farm contain the same information, for example, mirrored servers.All servers in the farm perform the same function, for example, published Microsoft Outlook Web Access servers.Web servers are grouped into a farm by creating a server farm. Forefront TMG treats all the Web servers in the farm as a single entity. When you create a server farm, you specify the following:The computer names or IP addresses of the Web servers to be included in the farm. Computer names must be resolvable to IP addresses.A method for monitoring connectivity to each server in the farm. The possible methods include sending an HTTP GET request, a PING request, or a request to establish a TCP connection to a specific port. Based on the method you choose, Forefront TMG 2010 automatically creates a connectivity verifier for testing connectivity to all the servers in the farm. A connectivity verification request is sent every 30 seconds to each farm member, and the response time is compared with a default time-out response threshold of 5,000 milliseconds. Forefront TMG 2010 uses the response to determine the state of servers in the farm. Note the following limitations when you select sending an HTTP GET request as the connectivity verification method for server farm monitoring:Sending HTTP GET requests is supported only for servers whose names do not contain non-English characters.The host name in the URL that you specify should be an asterisk (*). Forefront TMG 2010 will replace the asterisk with the name of each server in the farm. For example, if you have a farm with the servers A and B, and you specify http://*/status.htm as the URL, Forefront TMG will use the URLs http://A/status.htm and http://B/status.htm for checking connectivity.In most cases, you must enable the Allow HTTP/HTTPS Requests from Forefront TMG to Selected Servers for Connectivity Verifiers system policy rule. However, if you specify a non-standard port in the URL (for example, http://*:88/status.htm), the predefined system policy rule cannot be used. Instead, you must create a custom access rule to allow HTTP and HTTPS traffic from Forefront TMG to the server farm on the custom port.When you select sending an HTTP GET request as the connectivity verification method, you can specify a custom Host header to be included in the connectivity verification request. This is useful if a Web application published by the server farm requires a specific Host header.After creating the server farm using the New Server Farm Wizard, you can configure the following additional properties on the property pages of the server farm:Modify the time-out response threshold of the connectivity verifier. By default, Forefront TMG 2010 sets the time-out response threshold to 5,000 milliseconds.For monitoring purposes, you can specify that an alert should be triggered if a response is not received within the time period specified.Load balancing and client affinity Forefront TMG can use session affinity (cookie-based load balancing) or IP address affinity (source IP address-based load balancing) to implement the load balancing algorithm.Session affinitySession affinity uses a cookie to identify the client and to maintain its affinity with a specific Web server. This function requires a browser that can accept HTTP cookies. Cookies are supported by all HTTP 1.1-compliant browsers and by some versions of HTTP 1.0 browsers. Session affinity is maintained until the browser is closed on the client computer.The aim of session affinity is to evenly disperse client sessions (where a session is a number of consecutive Web requests that share the same TCP connection) among farm members. Session affinity does not support an uneven distribution of requests (for example, 50 percent of traffic to Server 1 in the farm, 20 percent of traffic to Server 2, and so on). Instead, session affinity uses a round-robin mechanism to ensure that browser sessions with a Web application serviced by a server farm are distributed evenly among farm members that are online.When session affinity is used, if a Web server, such as Web Server 1, goes out of service, the clients that are associated with it will be directed by Forefront TMG 2010 to another server, such as Web Server 2. The context of the Web session is lost when this happens. When Web Server 1 becomes available again, client affinity is maintained with Web Server 2 until the session ends. All replies to HTTP requests originating from a client browser session are sent to the original client. We recommend that you use session affinity when possible, because it provides more reliable client affinity when a Web server is restarted. This is sometimes referred to as client stickiness. Stickiness is ensured using a cookie inserted by Forefront TMG in the response to client requests. The cookie is sent by the client’s browser in further requests and indicates the server in the farm to which Forefront TMG should connect.Session affinity is suited to publishing Outlook Web Access servers and SharePoint sites. It is not useful in Exchange RPC-over-HTTP publishing, where the client application is an instance of Outlook rather than a Web browser, and it cannot handle cookies.IP address affinityWith IP address affinity, when Forefront TMG receives a request, it determines which Web server in the farm should handle it, based on the client's IP address. Every request from that IP address will be sent to the same Web server, so affinity is maintained.The aim of IP address affinity is to evenly disperse requests from different IP addresses among farm members. The even spread is preserved during failover. For failover, servers that are not responding are detected, and the load is distributed among available servers. Forefront TMG 2010 administrators can remove a server from a farm in a two-step process without disconnecting existing client requests.When IP address-based affinity is used, if a Web server goes out of service, the clients that are associated with it will be directed by Forefront TMG 2010 to another server. The context of the Web session is lost when this happens. Similarly, when that Web server is restarted, requests from those clients are directed to the original Web server, and the context is lost again.IP address-based affinity has an advantage over session affinity in that it supports clients that are not fully compliant with HTTP 1.1 (clients that do not support HTTP cookies), such as some mobile devices. IP address affinity should not be used when remote clients are located behind a NAT device, or if Forefront TMG 2010 functions as an upstream server, and sees only the IP address of the downstream Forefront TMG 2010 computer. In this case, you should use session affinity only.IP address affinity is particularly useful in an Exchange RPC-over-HTTP scenario, where session affinity cannot be used because cookies are not supported by the Outlook client application.
- Web pages returned from a Web server published by a Forefront TMG 2010 Web publishing rule may include links containing internal names of computers or Web sites and internal paths to Web content. Because external clients cannot resolve these internal names, these links are broken unless the internal names are replaced with the public names of published Web sites. Forefront TMG 2010 includes a built-in Web filter named Link Translation Filter, which uses mappings to translate internal names in links on Web pages to publicly resolvable names. Each mapping translates an internal URL (or part of a URL) to a public equivalent. For example, a mapping can translate the internal URL http://team to the public URL https://www.team.contoso.com for external users. Link translation mappings are stored in tables called link translation dictionaries.When link translation is enabled for a Web publishing rule, a default link translation dictionary is automatically created for each public name of the rule that does not contain a wildcard character (*).Forefront TMG 2010 includes link translation support for all published Web content, including support for Web publishing rules that publish servers running Microsoft Exchange Server and Microsoft Office SharePoint Server. Link translation is not applied to rules that publish FTP servers over HTTP.Types of mappings When link translation is enabled for a Web publishing rule, links in content sent from the published Web site to a client are translated according to the following mappings, which are stored in the effective link translation dictionary for the rule:Implicit mappings of the rule – These mappings are added automatically and map the internal name (or IP address) of the server published by the Web publishing rule to the public name (or IP address) of the Web site, or if there are multiple public names, to one of its public names. Local mappings – The user creates these mappings for the rule, and they map a string containing an internal host name to a string containing a publicly resolvable host name. The string to be translated must contain at least four characters. A local mapping can override an implicit mapping of the rule. Local mappings are not added automatically to the effective link translation dictionaries of other rules.Implicit mappings of other rules – These mappings are automatically added to the effective link translation dictionary of every Web publishing rule that is defined and enabled and has link translation enabled on the Forefront TMG computer. These mappings are derived from the implicit mappings defined in each Web publishing rule on the Forefront TMG computer. Global mappings – The user creates these mappings for the Forefront TMG computer, and they apply to all Web publishing rules in the Forefront TMG 2010 computer. These mappings override conflicting implicit mappings of other rules. Adding local mappingsLocal mappings can be defined for a Web publishing rule on the Locally Defined Mappings page. To open this page, on the Properties page for the rule, on the Link Translations tab, click Configure. To create a local mapping, you need to specify a string containing the internal name (or IP address) of a Web site or host and a string containing the publicly resolvable name to which the internal name should be translated. The translated name is typically the public name that can be accessed by external clients, such as the fully qualified domain name (FQDN) or IP address of the Forefront TMG 2010 computer. Note that in the same rule, you cannot define more than one local mapping for a string to be translated. Adding global mappingsGlobal mappings can be defined on the Global Mappings tab of the Link Translation properties. To create a global mapping, you need to specify an internal URL and the public URL to which the internal URL should be translated. The internal URL typically contains the name (or IP address) of an internal Web site or host. The translated URL is typically the public name that can be accessed by external clients, such as the FQDN or IP address of the Forefront TMG 2010 computer. The URLs specified in user-defined global mappings must begin with a valid protocol (http:// or https://).
- Virtual private network (VPN) technology enables cost-effective, secure, remote access to private networks. With a VPN, you can extend your private network across a shared or public network, such as the Internet, in a manner that emulates a point-to-point private link. By using the Forefront TMG computer as the VPN server, you benefit by protecting your corporate network from malicious VPN connections. Because the VPN server is integrated into the firewall functionality, VPN users are subject to the Forefront TMG firewall policy.About Forefront TMG VPNsForefront TMG 2010 supports two types of VPNs: Remote access VPN – Provides roaming users with secure remote access to the internal networkSite-to-site VPN – Enables quick connectivity between sites, for example between a main office and its branch offices. Note: All VPN connections to Forefront TMG are logged to the Firewall log, so that you can monitor them. Forefront TMG implements Windows Server VPN technology. For a description, see What Is VPN? (http://go.microsoft.com/fwlink/?LinkId=160092). When reading this content, keep in mind the functional differences between Windows Server 2003 and later versions of Windows as documented in What's New in Routing and Remote Access in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=160094).
- Network Access Protection (NAP) consists of several components and architecture models that work in conjunction to provide security for the network. The infrastructure of NAP supports the different servers required to validate, remediate and provide health certificates. The enforcement methods used by NAP (802.1x, DHCP, VPN, NPS RADIUS and IPSec) provide flexibility in determining the appropriate method for securing client access to your network.
- NAP Support in TMG 2010 allows you to define levels of network access based on a client’s identity, the groups to which the client belongs, and the degree to which the client complies with corporate governance policy. If a client is not compliant, NAP provides a mechanism for automatically bringing the client into compliance (a process known as remediation), and then dynamically increases its level of network access.
- Remote Access Quarantine Service (RQS) and Remote Access Quarantine Client (RQC).
- Used in combination with Forefront TMG 2010, NAP can enforce a health policy when client computers attempt to connect to the network by using a VPN connection. VPN enforcement provides strong limited network access for all computers accessing the network through a VPN connection. Configuring NAP on the NPS includes the following tasks:Installing the NPS roleSetting Forefront TMG as a RADIUS clientCreating system health validators and policiesCreating network policiesCreating connection request policiesEnabling the NAP service on NAP-capable client computers