TMG Back to Basics - Part 7: SharePoint Server Publishing

If you would like to read the other parts in this article series please go to:

Introduction

If you’re new to the TMG firewall, you might not be familiar with the term “publishing” in this context. When working with the TMG firewall, the term publishing is used to refer to the use of either reverse web proxy or reverse NAT. When publishing SharePoint, you’ll be configuring the TMG firewall to perform the reverse web proxy function.

The TMG firewall includes a wizard that makes publishing SharePoint sites very easy. The TMG firewall can publish one SharePoint server or multiple SharePoint servers, or even SharePoint web farms, with or without a load balancer. The TMG firewall’s SharePoint Publishing Wizard does a lot of configuration in the background that you don’t see in the wizard interface, which ensures that when you publish your SharePoint server, everything is set up automatically to make sure that the users can access all components of your SharePoint solution.

Since this is part of our Back to Basics series, in this article on publishing SharePoint servers we’ll focus on a very simple scenario: a public access SharePoint server that doesn’t require users to authenticate and that hosts information that is available to everyone. In this simple scenario, no authentication is required and no encryption is required. More complex scenarios can involve a variety of authentication and encryption options and we’ll address those in other future articles. But for a “back to basics” article, we’ll stick with the basics.

Setting up your SharePoint server is way beyond the basics of this article, but if you need help with that, check out the comprehensive guidance on the Microsoft TechNet site.

After your SharePoint site is set up, you can then open the TMG firewall console and click on the Firewall Policy node in the left pane of the TMG firewall console. In the Tasks Tab of the Task Pane, click the Publish SharePoint Sites link.

This brings up the Welcome to the SharePoint Publishing Rule Wizard page. Enter a name for the rule in the SharePoint publishing rule name text box. In this example, shown in Figure 1, we’ll name the rule TACTEAM SharePoint. Click Next.

Figure 1

On the Publishing Type page, you have three options:

Publish a single web site or load balancer. Use this option if you want to publish a single SharePoint server or publish multiple SharePoint servers that are located behind a load balancer.
Publish a server farm of load balanced web servers. Use this option when you want to publish a farm of SharePoint servers and take advantage of the built in web farm publishing feature included with the TMG firewall.
Publish multiple web sites. Use this option if you want to publish multiple SharePoint sites or multiple sites located behind multiple load balancers

In this example, we want to publish a single SharePoint server, so we’ll select the Publish a single web site or load balancer option, as shown in Figure 2. Click Next.

Figure 2

On the Server Connection Security page, shown in Figure 3, you have two options:

Use SSL to connect to the published web server or server farm. Use this option if you want to create a connection between the internal interface of the TMG firewall and the SharePoint server that uses SSL encryption to secure the connection.
Use non-secured connections to connect the published web server or server farm. Use this option if you want the connection between the internal interface of the TMG firewall and the SharePoint server to be unencrypted.

For this example, we’ll use the Use non-secured connections to connect to the published web server or server farm option and click Next, but note that the SSL option is more secure.

Figure 3

On the Internal Publishing Details page, which is shown in Figure 4, enter the internal name of the SharePoint site in the Internal site name text box. This is the name that internal clients use to connect to the SharePoint server on the internal network. In this example, we’ll use the name sps.tacteam.net and click Next.

Figure 4

On the Public Name Details page, shown in Figure 5, always select the This domain name (type below) option from the Accept requests for drop down list. In the Public name text box, enter the name that external users will use to access the SharePoint site. In this example, we’ll use the name spspublic.tacteam.net and click Next.

Notice in the example that I don’t use a strict split DNS infrastructure for publishing the SharePoint site. If you’ve been a fan of ISAserver.org for a while, you might know that Tom is a big fan of the Split DNS infrastructure. However, Tom will also tell you that a strict split DNS infrastructure can cause some problems with DirectAccess and I’ve seen that myself in my own DirectAccess deployment. Therefore, we’ll be using different host names to connect to the SharePoint site, based on whether the user is located on the external or internal network.

Figure 5

A Web Listener is required to accept incoming connections for published servers. You can create HTTP and HTTPS Web Listeners. In this example, we need to create an HTTP Web Listener. On the Select Web Listener page, shown in Figure 6, click the New button.

Figure 6

On the Welcome to the New Web Listener Wizard page, which is shown in Figure 7, enter a name for the Web Listener in the Web Listenername text box. In this example, we’ll name the Web Listener HTTP Listener, since it will be accepting only HTTP connections for the published SharePoint site. Click Next.

Figure 7

On the Client Connection Security page, shown in Figure 8, you have two options:

Require SSL secured connection with clients. Use this option when you want to force external clients to use SSL to connect to the external interface of the TMG firewall to reach the SharePoint site, for better security.
Do not require SSL secured connections with clients. Use this option to allow unencrypted connections to the TMG firewall’s external interface to reach the SharePoint site behind the TMG firewall.

In today’s example, since we’re keeping everything basic, we’ll select the Do not require SSL secured connections with clients and click Next.

Figure 8

On the Web Listener Addresses page, shown in Figure 9, you specify which IP addresses are used to accept connections for this Web Listener. In this example, we’ll select External and then click Select IP Addresses. Then we’ll select the specific IP addresses for which we want this Web Listener to accept connections.

Figure 9

You can see the IP address that was selected for this Web Listener in Figure 10 below. Notice that you can configure the Web Listener to listen for incoming connections on other Networks, including internal Networks. This would allow you to publish your SharePoint server to internal clients too. This is very useful in many scenarios when you want to take advantage of the TMG security benefits for access not only for external clients, but internal clients as well.

Figure 10

On the Authentication Settings page, shown in Figure 11, you can set the type of authentication you want to require to access the published SharePoint site. In this example, we’re not requiring any type of authentication, so we’ll select the No Authentication option. Click Next.

Figure 11

On the Single Sign On Settings page, as shown in Figure 12, you can configure Single Sign On to allow users to authenticate once with the TMG firewall and then access all published web sites that use this web listener. Notice that the option isn’t available at this time. The reason for this is that we’ve configured this Web Listener to not require authentication. Click Next.

Figure 12

Review the settings on the Completing the New Web Listener Wizard page and then click Finish, as shown in Figure 13.

Figure 13

On the Select Web Listener page, shown in Figure 14, click Next.

Figure 14

On the Authentication Delegation page, shown in Figure 15, you can configure the method the TMG firewall uses to authenticate the session it opens with the published sites. When authentication is required by the TMG firewall, you can configure the TMG firewall to delegate credentials so that the user doesn’t have to authenticate again with the published SharePoint site; instead, the TMG firewall forwards the credentials it has already received by the user. In this example, the users aren’t authenticating with the TMG firewall, so we’ll select the No delegation, and client cannot authenticate directly. There is also another option available that enables the user to authenticate directly with the published SharePoint site, but this is a bad idea since the session is not encrypted.

Figure 15

On the Alternate Access Mapping Configuration page, shown in Figure 16, you have two choices:

SharePoint AAM is already configured on the SharePoint server. Use this option when you have configured the AAM settings on the SharePoint site. I recommend that you always configure the AAM settings on the SharePoint site in advance of publishing the SharePoint site with the TMG firewall. While you can access some features of the SharePoint site without configuring AAM, not everything will work. For the best experience, always configure AAM and then select this option when you publish the SharePoint site.
SharePoint AAM is not yet configured.Also select this option if you are unsure if AAM is configured.I recommend that in general, you should never use this option; configure AAM first on the SharePoint site before publishing the site.

In this example we’ll select the SharePoint AMM is already configured on the SharePoint server and click Next.

Figure 16

On the User Sets page, shown in Figure 17, you can specify which users are allowed to connect to the SharePoint site. In this example we will allow anonymous access, which is the same as All Users. Click Next.

Figure 17

Review the settings on the Completing the New SharePoint Publishing Rule Wizard page, shown in Figure 18, and then click Finish.

Figure 18

Summary

In this “back to basics” article, we reviewed the SharePoint publishing wizard and to run the wizard in a very simple SharePoint publishing scenario where anonymous access is allowed and no encryption is required. In a future article, we’ll publish a SharePoint site that requires users to authenticate with the TMG firewall and have the TMG firewall delegate credentials to the published site. We’ll also discuss issues related to SSL bridging, and things you want to consider regarding SSL bridging. See you then! –Deb.

If you would like to read the other parts in this article series please go to: