Planning for SharePoint Publishing with TMG


Planning is the step that is most often left out of TMG publishing scenarios. It’s easy to see why that’s the case; it’s so easy to publish services with TMG firewall that the deployment sometimes seems to run itself. However, there is no substitute for smart planning before you publish any service. That’s especially the case when you’re publishing SharePoint servers.

Before publishing SharePoint, you need to consider many aspects of the deployment. In this article, we’re going to focus on the security, authentication and Alternate Access Mapping (AAM) areas. Security is our overarching concern so security considerations should be the first issues we tackle when publishing SharePoint servers.

Access considerations

Some security considerations depend on the type of authentication that is being used to either pre-authenticate the request made to the destination web server or when delegation of authentication is used when TMG forwards the request to the published SharePoint Server. Authentication requirements need to be considered because authentication mismatches can cause users to be unable to authenticate access to the destination SharePoint server.

Most SharePoint administrators are going to want to implement the most restrictive access possible to their published servers in order to reduce the threat of unauthenticated users compromising the network. That’s just a basic best security practice. Key areas that need to be planned around security include:

  • Access based on source networks and IP addresses
  • Access to only encrypted traffic (HTTPS/SSL) or both encrypted and unencrypted traffic, depending on the type and security classification of the data
  • Allowing caching of responses
  • Access based on Time of Day and Day of Week
  • Access based on Active Directory User Groups

Even though most of these considerations are pretty generic, they are important because each area would determine how the rule would finally be configured.

The point of publishing a web service is to allow external users to have access to the server so that they can utilize the published service when off the company premises. The most common deployment scenario allows access to users over the Internet. When you create a SharePoint web publishing rule, the default option is to allow access from “Anywhere” to the listener that is listening for the requests. However, you can set up address ranges or specific IP addresses to only allow access from that address range or IP address.

Encryption considerations

How you handle encryption is one of the most important security considerations when publishing any web service to the Internet or to another non-trusted network. Most admins will choose to encrypt all incoming and outgoing traffic from and to the Internet, using public key cryptography based on digital certificates. A web listener that has a certificate bound to it can be used to restrict access to only HTTPS traffic.

The TMG firewall can then forward the traffic using HTTP (instead of having to use HTTPS) to the destination SharePoint Server or it can send it over HTTPS depending on how the SharePoint is configured on the corporate network. Note that when you forward the traffic as HTTP instead of HTTPS, the TMG firewall can provide Secure Socket Layer (SSL) packet inspection by doing SSL bridging. SSL bridging protects against attacks that are hidden in SSL-encrypted connections.

For SSL-enabled Web applications such as SharePoint, the TMG firewall can decrypt the connection from the client and inspect it. Web publishing rules will determine how the TMG firewall will forward the request for the object to the published SharePoint server. If the secure Web publishing rule is configured to forward the request using SSL (HTTPS), then TMG will initiate a new SSL connection with the published server. Because the TMG firewall is the SSL client in this scenario, it requires that the published Web server respond with a server-side certificate.

An important thing to keep in mind when choosing a certificate is that the certificate needs to have a private key and its Common Name (CN) or one of its Subject Alternate Names (SANs) will need to be the same as the public URL. This is one of the most common mistakes that is made by admins in publishing their SharePoint servers. The certificate should also have a private key and should be trusted up to the Root Certification Authority.

For more information about certificate requirements please read this technet article.

Content caching considerations

Content caching enables the TMG firewall to cache Web content and to respond to user requests from the cache instead of making a request across the Internet to the destination web server. This increases response performance for clients. Caching also reduces the amount of traffic that is exchanged between the TMG firewall and the published SharePoint server, because requests for URLs that are found in the TMG firewall’s cache will be forwarded to the client from the TMG firewall’s cache and therefore this saves you the round trip to the published server and back. In addition to reducing the amount of traffic, you will also reduce the processing requirements on the web server, as the TMG firewall handles the processing overhead for requests that are serviced by the cache.

Time-based access restrictions

Depending on the usage scenario, some administrators may want to restrict access based on the time of day and/or the day of the week. This can help to reduce bandwidth usage by, for example, allowing access only during business hours and restricting or blocking access during non-business hours. This can be done by using the built-in scheduling that comes with the TMG firewall right out of the box or you can create custom schedules and allow and deny access in the SharePoint publishing rule, based on those schedules.

Authentication considerations

The TMG firewall can pre-authenticate a request before even forwarding it to the SharePoint server. This prevents unauthenticated connections from getting to the SharePoint server. If the user can not be successfully authenticated, then the user will never get close to the SharePoint server as the connection is dropped at the TMG firewall. You can configure the TMG firewall to allow all authenticated requests for any user in the Active Directory or you can restrict access based on user group membership, so that only the users belonging to a particular group or groups are allowed access to the published server.

The TMG firewall supports a number of authentication protocols and methods, which can be used to pre-authenticate requests at the firewall and then either allow the client to authenticate against the SharePoint server directly or use the credentials collected in the pre-authentication process and delegate them to the SharePoint server to provide a single sign-on experience to the client. In general, it’s best to have the firewall do the pre-authentication, so that unauthenticated users will never get to the published SharePoint server.

The types of client authentication supported by the TMG firewall include:

  • No Authentication
  • Forms Based Authentication
  • HTTP Authentication (received in HTTP header)
  • Client certificate Authentication

The TMG firewall can validate client credentials passed on using the above formats by leveraging the following providers and protocols:

  • No Authentication (allows the Internal published server to handle authentication instead of having the firewall pre-authenticate the connection)
  • Windows Active Directory
  • Active Directory over LDAP protocol (uses LDAP instead of NTLM, but LDAP connections can only be made to a domain controller)
  • RADIUS one-time password (RADIUS OTP)
  • SecurID

The most popular authentication method supported by the TMG firewall is Forms Based Authentication (FBA). When you enable Forms-based authentication, the TMG firewall will present a Web page on which the user is prompted to enter a username and password. Then the TMG firewall can authenticate against the Active Directory (when the firewall is joined to the domain) or the Active Directory over LDAP protocol (when the TMG firewall is not configured as a domain member). Once authentication has been completed, the TMG firewall can then forward the credentials to the SharePoint Server so that the user will not be prompted a second time for the username and password.

It’s important to keep in mind that when choosing a type of authentication to use to authenticate external users, that if the TMG firewall is set to delegate the user’s credentials to the published SharePoint server, then the authentication delegation method should be the same as the authentication type used on SharePoint server. The delegation method will vary, depending on the client authentication method that you configure on the TMG firewall. In some scenarios, only certain combinations can be used together. Therefore, it is important that you plan for which client authentication method should be on the TMG firewall so that there will be no mismatch between the delegation method and the authentication type used by the SharePoint server.

To find out more about different Authentication Methods that are available with the TMG firewall and valid Authentication Delegation combinations, see this technet article.

Alternate Access Mapping

Windows SharePoint Services relies on absolute hyperlinks. A Uniform Resource Locator (URL) correction method, such as the TMG’s firewall’s link translation capability, cannot provide a complete solution for disambiguating the absolute links that are delivered to Internet clients making requests to a SharePoint server located on the corporate network.

The solution to this problem is Alternate Access Mapping (AAM). The goal of AAM is to create dynamic links for requests that are forwarded by the reverse proxy to serve to the requesting client, while maintaining a proper mapping of which links should be returned to an internal user vs. an external user.

It’s all too common for admins to confuse link translation with AAM and therefore they might not consider AAM to be important. Link Translation and AAM are never used together by the TMG firewall in a SharePoint publishing scenario. When you configure SharePoint publishing, you will be prompted to choose whether AAM is configured on the SharePoint server or not. If you say that AAM is not configured, then TMG sets up link translation mappings for that rule. If you tell the wizard that AAM is set up correctly, then there is no link translation mapping for that rule. However, no link translation feature from any reverse proxy server, including TMG, is sufficient to fix all SharePoint links to be accessed publicly, and therefore you should always configure AAM on the SharePoint server itself and not depend on the TMG firewall’s link translation capabilities.

The reason for this is that SharePoint dynamically embeds its URLs in many places and uses a number of encoding methods that cannot be manipulated by the TMG firewall’s reverse proxy link translation feature. In addition, SharePoint uses URLs that do not go through reverse proxy web publishing rules. One example of this would be e-mail alerts. You must use AAM to ensure that the links in the e-mail alerts will include the correct URLs so that they can be accessed from outside the corporate network.

For more information about SharePoint AAMs please see this technet article.


In this article, we took a look at some of the planning considerations for publishing SharePoint servers with TMG. Security, authentication, authorization, caching and link translation/AAM are all important issues when it comes to publishing SharePoint servers. Always plan accordingly before you begin the SharePoint publishing process. Thanks! –Deb.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top