TMG Web publishing for SharePoint HTTPS, No Certificate Usage On TMG

This question came up with a client this morning, which is the first time I have had to answer it but it’s a very straightforward issue.

What if one is trying to use TMG to publish a SharePoint environment for both HTTP and HTTP access, while the certificate is appropriately setup in the SharePoint server it is not desirable to have the web publishing rule bound to the certificate, i.e. certificate stuff should be handled by the SharePoint environment. So, breaking the question down even more, they wanted to publish the HTTPS SharePoint instance WITHOUT using the certificate in the TMG instance.

This obviously is not a supported route, because logically it doesn’t make a ton of sense. One can’t use a HTTP web publishing rule without having the appropriate certificate accessibly and appropriately in place, and clearly is not a TMG limitation because it is the same requirement for ISA and Proxy Server stuff.


First Steps in Implementing ISA Server With SharePoint

* This article was written in the context of Internet Security and Acceleration (ISA) 2006, a technology now considered deprecated with the introduction of Forefront Threat Management Gateway (TMG). Variations may exist. *

First Steps in Implementing ISA Server With SharePoint
After the initial installation of ISA server, securely publishing your SharePoint portal is a fairly straightforward process that can be facilitated by either a network or SharePoint administrator. Within ISA server 2004, this process typically required setting up the appropriate listeners and web publishing rules so that the proper resources can be hit by the appropriate enterprise users. However, this process is streamlined with built in publishing mechanisms within ISA server allowing a flexible approach to how an enterprise will securely publish a SharePoint machine or arbitrary SharePoint resources.
The first step in implementing a ISA publishing architecture for SharePoint is to open the initial ISA management interface.
Step 1 — Open the ISA Administration Interface
Firstly, you must directly interact with the ISA server by logging onto the ISA Server machine either directly, through MSTSC, RDC, or other remote software such as DameWare, Tilovi, or others.
Start -> All Programs -> Microsoft ISA Server -> ISA Server Management.
Step 2 Enter Into Your ISA Firewall Policy
On the ISA machine, once you have the interface open, you must open the firewall policy dialog.In the ISA interface -> Expand Arrays -> Expand the Server Network / Domain -> Select the Firewall Policy
Step 3 Enter Into the SharePoint Publishing Dialog
Select Tasks (should open the Firewall Policy Tasks) -> Select Publish SharePoint sites (the third of the steps provided within the firewall policy dialog).
Step 4 Provide Basic SharePoint Server Information
Once you start the Publish SharePoint Sites wizard, you will be asked to provide some basic information regarding the publishing that you are going to setup. On the first set o dialogs, enter a common name for the publishing rule, such as SharePoint Sites.
Step 5 Select a Publishing Type
Depending on your installation, you will be asked to provide a publishing type which can vary heavily depending on organization by organization, the two within SharePoint are single server or web farms. You can publish multiple SharePoint site collections on different virtual servers, or a single site collection on multiple load balanced servers. The three options that you will receive are:
  • Publish a single web site or an external load balancer
  • Publish a server farm of load balanced web servers
  • Publish multiple websites 
Step 6 Select Your Internal Publishing Rules
The next step after finishing how the network publishing configuration will take place within your SharePoint environment, the next step will be how users will access it both internally and externally. The next dialog that will appear is the internal publishing details dialog, which will ask you to firstly specify the internal site name. This is typically something easy to remember that maintains a corporate DNS strategy, such as or If you are going to use SSL internally to connect to your SharePoint site, there is check box below this entry where you should specify that it is going to be used, saying ISA Server will use SSL to connect to the SharePoint site. This is required if you are going to use SSL bridging, which is recommended configuration if you are going to maintain a secure deployment. You will be able to see your site address in the grayed out box below, ensure that this address is correct.
Step 7 Select How Users Will Access Your Site Externally
The next dialog that you will see is Public Name Details, and depending on how you desire your users to access the portal, can vary. Within most organizations, it is common that this will take the form of the same site address that is used internally, or, since it is desired to maintain conformity of access and not confusing to most users. You should enter this address after you select from the dialog drop down for accept requests for. In this drop-down, select the domain name.
Step 8 Set Up The Web Listener For the SharePoint Site 
The next dialog that you will see is the web listener dialog, where you should select the HTTP selection, since this is setting up mechanisms where ISA server will facilitate listening for varying web requests. You can also edit existing web listeners, or add a new web listeners as they exist within your ISA environment.
Step 9 Setting up the Authentication
Following, you will have to setup authentication types on the Authentication Delegation page. This will not effect the authentication that you have setup for your portal, there is no direct interaction where ISA will manipulate previous settings on your SharePoint environment. This is to setup a handshaking between the server systems. On this screen, you are going to select Negotiate (Kerberos/NTLM), since these are the two authentication types that are available within your SharePoint portal. There are a variety o other options, including
  • No Delegation allow end-to-end authentication
  • Basic authentication
  • NTLM authentication
  • No Delegation do not allow end-to-end authentication
  • Kerberos Constrained Delegation
It is feasible to setup custom Authentication delegation because how client credentials are delegated will vary from organization to organization. However, within most environments, Kerberos/NTLM is the most common when publishing SharePoint assets.
Step 10 Setting up User Sets
Most times, this dialog is not necessary for a basic SharePoint setup, therefore, simply select next.
Step 11 Completing the SharePoint Publishing Wizard
Confirm all the settings that you have made, by selecting the finish dialog which will complete the wizard. Depending on the complexity o your environment, there might be additional prompts that are required to fill in information, however for general SharePoint publishing these are the only steps that you need in order to complete the publishing of your SharePoint assets.

What is ISA server, and what does it have to do with SharePoint?


* This article was written in the context of Internet Security and Acceleration (ISA) 2006, a technology now considered deprecated with the introduction of Forefront Threat Management Gateway (TMG). Variations may exist. *

The Several Hat of the SharePoint Administrator


Often times, one person is tasked within an organization to be responsible for several platforms. If you have MOSS 2007, you also might have a range of other sister server platforms such as EPM, DPM, LCS, MIIS, or a variety of supplementary Microsoft platforms. The one server that is characteristically common within an external, as well as internal, facing SharePoint deployment is ISA server 2006 for its inherent security routines and web caching solutions, along with several other security options that can be typically of interest to SharePoint administrators such as honey pots and intrusion detection systems.
What is ISA server 2006?
ISA Server 2006 plays a very vital role with your enterprise, particularly when leveraging its security framework with your communications and collaborations platform since business critical data and enterprise processes will eventually be housed there. In relation to SharePoint, the main feature that we are looking to implement will be secure application publishing, in the current circumstance, MOSS 2007 (or SharePoint 2003 if currently not planning on an upgrade). It is important to realize that ISA has several other purposes and applications within an enterprise, however since the context of this site is SharePoint security, the main focus will be on leveraging ISA to securely use a SharePoint framework.
Mitigating Risks Leveraging ISA Server 2006 in Regards To MOSS (SharePoint 2007)
As part of any integrated security planning and implementation, it is necessary to take certain precautions to mitigate several risks to protect your corporate network. Implementing SharePoint within your environment can have several implications, depending on the context of what features an organization seeks to gain out of a SharePoint rollout. However, it is clear that several legacy business processes when it becomes a de facto standard within an organization will be placed moved from paper to electronic, streamlining them, but also placing them in a container with more points of access for an attacker to take advantage of. Bring processes out of the physical realm a majority of the times will cause more visibility into them, therefore bringing other points of access for an attacker to expose. This becomes increasingly important if you have any type of compliance or regulatory issues that will effect your business operations, SOX and HIPPA being the most common in relation to SharePoint and because SharePoint is so common within the healthcare field. This by no means implies that there aren’t other regulations to consider when implementing SharePoint, specifically within governmental and financial fields (such as consideration of the US Patriot Act), all of which should be examined prior to the rollout to ensure complete compliance upon initialization of the implementation.
Protecting Against Exposure in Regards to MOSS Mobility Controls
Because of the built in mobility controls with SharePoint, this risk becomes even greater since it will allow you to expose your portal at a more granular and prevalent level (those directories that exist within /m), carrying its own application richness nevertheless its own implications. Combining this valuable mobile functionality with the probability with a new external (or internal portal that may face attacks) facing functionality leveraging the numerous new SharePoint authentication controls (authentication in MOSS has more internet style controls), there is a higher possibility that an attacker will try to take over your portal.
Why Even Attack SharePoint? 
So why is SharePoint a lucrative attack point for a person with malicious intent to gain access into, and possible corrupt. There are two main points of interest from an attacker standpoint in relation to SharePoint. Since SharePoint plays the role of an information repository, an attacker could potentially desire to gain business information for a multitude of arbitrary reasons. This could range from a lot of different points of interest, from blackmailing a company to gain this information back to a secondary company getting a competitive advantage onto another company. The second main reason is corporate espionage, taking down SharePoint, on a large scale could cause business interruptions, massive loss of data, or a platform to attack other sister server systems that might house the same type of sensitive information. For example, with the archiving agent with Live Communication Server it is feasible that once an attack gains a point of entry within the SharePoint environment that they may also have access to these archived records, which could expose a business further, or have an employee possibly covering their tracks from past malicious intent.
What Are the Benefits of Implementing ISA server with SharePoint?
  1. Enabling and monitoring access to SharePoint
  2. Implementing cryptographic solutions
  3. Leveraging Web Farms and Load Balancing
  4. Providing Secure and Fluid External Access to your SharePoint Portal
  5. Implementing Several Types of Access Such As Smart Cards and Biometrics
  6. Track User Traffic
  7. Implement Plug-ins such as Intrusion Detection, Honey pots, and Other Functionality
What are the benefits of leveraging ISA server 2006 with SharePoint 2003 or MOSS (SharePoint 2007)? There are several, in regards to SharePoint there are clear hooks that exist between SharePoint and ISA that allow you to face your portal in a variety of fashions depending on your corporate need. One of the largest problems when leveraging ISA server 2004 was that although the process of setting up listeners and routing was straightforward, SharePoint implementations were never very generic and varied to heavily for a standardized process, however with ISA server 2006, publishing your communications and collaborations network including exchange and ISA server are extremely simple.  The second largest problem was setting up a secure implementation that leveraged a certain level of cryptographic methods, most notably SSL. However, as attacks become more sophisticated, it becomes possibly to implement cryptographic cloaking which can overcome packet inspection at the firewall level, compromising communications. However, ISA server with advanced SSL bridging allows an administrator to further protect a network while maintaining stateful packet inspection. Thirdly, SharePoint implementations often take advantage of sophisticated farming solutions that can exist in the amount of n servers, Web Publishing Load Balancing can make this easier to execute with a SharePoint environment. Fourthly, facing a SharePoint portal externally for 24×7 employee access is fairly common since it becomes a platform to build virtual teams with throughout the enterprise. This poses a multitude of problems, including but not limited to several windows of access (multiple logins) and pass-through link translation from multiple levels. ISA provides mechanisms to solve all of this, to ensure constant and fluid access to your SharePoint Portal at all times. Fifthly, providing mechanisms for several types of access, such as those with Smart Cards, is necessary within several organizations, particularly those within the governmental sector. ISA helps to translate these authentication types into your portal so that the facilities exist so that there are adaptable ways to authenticate to the portal. Sixthly, maintaining inspection and providing mechanisms to properly troubleshoot ISA, and authentication to your portal related problems, usually requiring using tools such as the SSL diagnostic tools or other third party products. ISA provides interfaces to your requested and responded packets so that you can properly implement and repair any issues that may arise within your network related to your security and web caching solution so that you can ensure that your portal is always secure, yet available. Seventhly, and lastly, ISA provides mechanisms to monitor and report on traffic within your SharePoint portal so that as a SharePoint administrator at all times you can watch traffic footprints and report on any problems as they may arise. These ISA interfaces are not technically difficult to invoke and massage to gain insight to certain activities, ensuring security of your portal at all times and providing faculties by which a SharePoint administrator can report on portal activities.
Maintaining Stateful Packet Inspection
One of the largest security mechanisms used with corporate network security in regards to publishing SharePoint servers is packet inspection through HTTP protocols, it is pretty default or is hopefully part of the current network configuration. This is related to the firewall level, and therefore is not typically aware of malicious activity at the application level, so therefore is indifferent to any type of attacks that would happen against your SharePoint environment at that particular level. The main feature that we need is stateful packet inspection that will promote application layer filtering mechanisms since this will make our security configuration more aware of our communications and collaborations platforms.