Securing SharePoint Sites with Forefront TMG 2010

SharePoint sites comprise one of the more common types of content that are secured by the Forefront Edge line. This stems from the critical need to provide remote document management while at the same time securing that access. Although Forefront UAG is the preferred solution for reverse proxy of a SharePoint environment, the Forefront TMG product is also a highly capable product that allows for reverse proxy functionality. Both products are covered in this article, but this section illustrates the creation of a Forefront TMG publishing rule for a SharePoint site for clients with an investment in Forefront TMG but without a Forefront UAG environment.

Note

Organizations with legacy ISA Server 2006 can still use it to secure inbound traffic to SharePoint 2010 because it is still a supported product. The steps to secure a SharePoint site with ISA 2006 are nearly identical to the steps used with Forefront TMG. Just follow the same instructions listed here or refer to SharePoint 2007 Unleashed, which describes the process of ISA Server 2006.

Forefront TMG can be used to secure a SharePoint implementation can be deployed in multiple scenarios, such as an edge firewall, an inline firewall, or a dedicated reverse-proxy server. In all these scenarios, Forefront TMG secures SharePoint traffic by “pretending” to be the SharePoint server itself, scanning the traffic that is destined for the SharePoint server for exploits, and then repackaging that traffic and sending it on, such as what is illustrated in Figure 1.

Figure 1. Conceptualizing the process of securing a SharePoint site using Forefront TMG.

Forefront TMG performs this type of securing through a SharePoint site publishing rule, which automatically sets up and configures a listener on the Forefront TMG server. A listener is a Forefront TMG component that listens to specifically defined IP traffic and processes that traffic for the requesting client as if it were the actual server itself. For example, a SharePoint listener on Forefront TMG would respond to SharePoint HTTP/HTTPS requests made to it by scanning them for exploits and then repackaging them and forwarding them on to the SharePoint server itself. Using listeners, the client cannot tell the difference between the Forefront TMG server and the SharePoint server itself.

Forefront TMG is also one of the few products, along with Forefront UAG, that has the capability to secure web traffic with SSL encryption from end to end. It does this by using the SharePoint server’s own certificate to re-encrypt the traffic before sending it on its way. This also allows for the “black box” of SSL traffic to be examined for exploits and viruses at the application layer, and then re-encrypted to reduce the chance of unauthorized viewing of the traffic. Without the capability to scan this SSL traffic, exploits bound for a SharePoint server could simply hide themselves in the encrypted traffic and pass right through traditional firewalls.

This article covers one common scenario that Forefront TMG server is used for: securing a SharePoint site collection (in this example, home.companyabc.com) using Forefront TMG. The steps outlined here describe this particular scenario, although Forefront TMG can also be used for multiple other securing scenarios as necessary.

Configuring the Alternate Access Mapping Setting for the External URL

Before external access can be granted to a site, an alternate access mapping (AAM) must be established for the particular web application. An AAM is a host header value (such as https://portal.companyabc.com, http://server4, https://home.companyabc.com, and so on) that must be consistently applied to the site across all links. If it is not put into place, external clients will not be able to access internal links.

To configure the AAM in this scenario, home.companyabc.com, on a web application, perform the following steps:

1.	Open the SharePoint Central Admin Tool.
2.	Click the System Settings link in the links provided on the left of the screen.
3.	Under Farm Management, click the Configure Alternate Access Mappings link.
4.	Click Edit Public URLs.
5.	Under Alternate Access Mapping Collection, select the AAM Collection that corresponds to the web application for home.companyabc.com.
6.	Enter the https:// AAM needed under the Internet box, as shown in Figure 2. In this example, we enter https://home.companyabc.com. If the web application will be addressed by other names, enter all possible names here. Click Save. Figure 2. Creating an alternate access mapping for external published use.
7.	Review the AAMs listed on the page for accuracy, and then close the SharePoint Central Admin tool.   Creating a SharePoint Publishing Rule Using Forefront TMG After an SSL Certificate from the SharePoint server has been installed onto the Forefront TMG server, the actual Forefront TMG SharePoint publishing rule can be generated to secure SharePoint via the following procedure: Note The procedure outlined here illustrates the Forefront Edge line SharePoint publishing rule that uses forms-based authentication (FBA) for the site, which allows for a landing page to be generated on the Forefront Edge line to pre-authenticate user connections to SharePoint. 1. From the Forefront TMG console, click once on the Firewall Policy node from the console tree. 2. Click the link in the Tasks tab of the Tasks pane labeled Publish SharePoint Sites. 3. Enter a descriptive name for the publishing rule, such as SharePoint Publishing Rule. 4. Select whether to publish a single website, multiple websites, or a farm of load-balanced servers, as illustrated in Figure 3. In this example, we choose to publish a simple single website. Click Next to continue. Figure 3. Creating a Forefront TMG publishing rule for SharePoint sites. 5. Choose whether to require SSL from the Forefront Edge line server to the SharePoint server, as shown in Figure 4. It is recommended to provide end-to-end SSL support for the Forefront Edge line, although it will require a copy of the SSL certificate with the private key exported to the TMG server for this to be set up properly. Click Next to continue. Figure 4. Configuring SSL for publishing rule. 6. In the Internal Publishing Details dialog box, enter the site name that internal users use to access the SharePoint server. Examine the options to connect to an IP address or computer name; this gives additional flexibility to the rule. Click Next to continue. 7. Under the subsequent dialog box, enter to accept requests for This Domain Name (type below): and enter the FQDN of the server, such as home.companyabc.com. This will restrict the rule to requests that are destined for the proper FQDN. Click Next to continue. 8. Under Web Listener, click New. 9. At the start of the Web Listener Wizard, enter a descriptive name for the listener, such as SharePoint HTTP/HTTPS Listener, and click Next to continue. 10. Again, a prompt is given to choose between SSL and non-SSL. This prompt refers to the traffic between client and SharePoint, which should always be SSL whenever possible. Click Next to continue. 11. Under Web Listener IP addresses, select the External network and leave it at All IP Addresses. Click Next to continue. 12. Under Listener SSL Certificates (if creating an SSL-based rule; if not, you will not be prompted for this), click Select Certificate. 13. Select the previously installed certificate (if using SSL) and click the Select button. 14. Click Next to continue. 15. For the type of authentication, choose HTML Form Authentication, as shown in Figure 5. Leave Windows (Active Directory) selected and click Next. Figure 5. Selecting to use forms-based authentication for a Forefront TMG publishing rule. 16. The Single Sign On Settings dialog box is powerful; it allows all authentication traffic through a single listener to be processed only once. After the user has authenticated, he can access any other service, be it an Exchange OWA server, web server, or other web-based service that uses the same domain name for credentials. In this example, we enter .companyabc.com into the SSO domain name. Click Next to continue. 17. Click Finish to end the Web Listener Wizard. 18. Click Next after the new listener is displayed in the Web Listener dialog box. 19. Under Authentication Delegation, choose Basic from the drop-down box. Basic is used if SSL is the transport mechanism chosen. If using HTTP only, it is recommended to use NTLM authentication to avoid the passwords being sent in clear text. Click Next to continue. 20. At the Alternate Access Mapping Configuration dialog box, shown in Figure 6, select that SharePoint AAM is already configured, as we configured the Alternate Access Mapping on the SharePoint server in previous steps. Figure 6. Creating a Forefront TMG publishing rule for a SharePoint site with AAM already configured. 21. Under User Sets, leave All Authenticated Users selected. In stricter scenarios, only specific AD groups can be granted rights to SharePoint using this dialog box. In this example, the default setting is sufficient. Click Next to continue. 22. Click Finish to end the wizard. 23. Click Apply in the details pane, and then complete the change management options and click Apply again. 24. Click OK when finished to commit the changes. The rule will now appear in the details pane of the Forefront TMG server. Double-clicking the rule brings up the settings. Tabs can be used to navigate around the different rule settings. The rule itself can be configured with additional settings based on the configuration desired. For example, the following rule information is used to configure our basic FBA web publishing rule for SharePoint: General tab— Name—SharePoint; Enabled = checked. Action tab— Action to take = Allow; Log requests matching this rule = checked. From tab— This rule applies to traffic from these sources = Anywhere. To tab— This rule applies to this published site = home.companyabc.com; Computer name or IP address = 10.10.10.105 (internal IP address of SharePoint server). Forward the original host header instead of the actual one (specified in the Internal Site Name field) = checked; Specify how the firewall proxies requests to the published server = Requests appear to come from the Forefront TMG computer. Traffic tab— This rule applies to traffic of the following protocols = HTTPS. Listener tab, Properties button— Networks tab = External, All IP addresses; Connections tab – Enabled HTTP connections on port 80, Enable SSL connections on port 443; HTTP to HTTPS Redirection = Redirect authenticated traffic from HTTP to HTTPS; Forms tab = Allow users to change their passwords, Remind users that their password will expire in this number of days = 15; SSO tab = Enable Single Sign On, SSO Domains = .companyabc.com. Public Name tab— This rule applies to requests for the following websites = home.companyabc.com. Paths tab— External paths = All are set to Figure 7

).

Figure 7. Viewing the tabs on a newly created SharePoint site publishing rule.

Authentication Delegation tab— Method used by the Forefront Edge line to authenticate to the published web server = Basic authentication.

Application Settings tab— Use customized HTML forms instead of the default = unchecked.

Bridging tab— Redirect requests to SSL port = 443.

Users tab— This rule applies to requests from the following user sets = All Authenticated Users.

Schedule tab— Schedule = Always.

Link Translation tab— Apply link translation to this rule = checked.

Different rules require different settings, but the settings outlined in this example are some of the more common and secure ones used to set up this scenario.

Monitoring Forefront TMG Using the Logging Feature

One of the most powerful troubleshooting tools at the disposal of SharePoint and Forefront TMG administrators is the logging mechanism, which gives live or archived views of the logs on a Forefront TMG computer and allows for quick and easy searching and indexing of Forefront TMG log information, including every packet of data that hits the Forefront TMG computer.

Note

Many of the advanced features of the Forefront Edge line logging are available only when using MSDE or SQL databases for the storage of the logs.

The Forefront TMG logs are accessible via the Logging tab in the details pane of the Logs and Reports node, as shown in Figure 8. They enable administrators to watch, in real time, what is happening to the Forefront TMG server, whether it is denying connections, for example, and what rule is being applied for each allow or deny statement.

Figure 8. Examining Forefront TMG logging.

The logs include pertinent information on each packet of data, including the following key characteristics:

• Log Time— The exact time the packet was processed.
• Destination IP— The destination IP address of the packet.
• Destination Port— The destination TCP/IP port, such as port 80 for HTTP traffic.
• Protocol— The specific protocol that the packet utilized, such as HTTP, LDAP, RPC, or others.
• Action— What type of action the Forefront Edge line took on the traffic, such as initiating the connection or denying it.
• Rule— Which particular firewall policy rule applied to the traffic.
• Client IP— The IP address of the client that sent the packet.
• Client Username— The username of the requesting client. Note that this is populated only if using the firewall client.
• Source Network— The source network that the packet came from.
• Destination Network— The network where the destination of the packet is located.
• HTTP Method— This column displays the type of HTTP method used, such as GET or POST.
• URL— If HTTP is used, this column will display the exact URL that was requested.

By searching through the logs for specific criteria in these columns, such as all packets sent by a specific IP address, or all URLs that match http://home.companyabc.com, advanced troubleshooting and monitoring is simplified.

Note

It cannot be stressed enough that this logging mechanism is quite literally the best tool for troubleshooting Forefront TMG access. For example, it can be used to tell whether traffic from clients is even hitting the Forefront TMG server, and if it is, what is happening to it (denied, accepted, and so forth).