Chapter 14. Protecting SharePoint with Advanced Edge Security Solutions
In This Chapter
Understanding the Forefront Edge Line of Products
Outlining the Need for the Forefront Edge Line for SharePoint Environments
Outlining the Inherent Threat in SharePoint Web Traffic
Securing SharePoint Sites with Forefront TMG 2010
Securing SharePoint Sites Using Forefront UAG
In today’s risk-fraught computing environment, any exposed service is subject to frequent attack from the Internet. This is particularly true for web services, including those offered by SharePoint 2013. Exploits using the Hypertext Transport Protocol (HTTP) that these services use are becoming very common, and it is not considered best practice to make a SharePoint server directly accessible via the Internet.
Fortunately, the productivity gains in SharePoint 2013 can still be utilized and made more accessible by securing them behind a reverse-proxy server such as Microsoft’s Forefront Threat Management Gateway (Forefront TMG) 2010 or Forefront Unified Access Gateway (Forefront UAG) 2010. These tools, part of the Forefront Edge line, allow for advanced application layer filtering of network traffic, greatly securing the overall SharePoint environment.
This chapter details the ways that SharePoint 2013 sites can be secured using the Forefront TMG 2010 and Forefront UAG 2010 products. Deployment scenarios for securing SharePoint-related services with Forefront TMG/UAG are outlined, and specific step-by-step guides are illustrated.
Note that Microsoft has started to deprecate the TMG product, but TMG functionality can still be found in Forefront UAG and administrators can still use existing supported TMG environments to secure SharePoint 2013 sites as described in this chapter.
Understanding the Forefront Edge Line of Products
The rise in the prevalence of computer viruses, threats, and exploits on the Internet has made it necessary for organizations of all shapes and sizes to reevaluate their protection strategies for edge services such as SharePoint Server. No longer is it possible to ignore or minimize these threats as the damage they can cause can cripple a company’s business functions. A solution to the increased sophistication and pervasiveness of these viruses and exploits is becoming increasingly necessary.
Corresponding with the growth of these threats has been the development of Microsoft’s Forefront Edge line of products, including Forefront TMG and Forefront UAG products from Microsoft. These products are fast becoming a business-critical component of many organizations, who are finding that many of the traditional packet-filtering firewalls and technologies don’t necessarily stand up to the modern threats of today. The Forefront Edge products provide for that higher level of application security required, particularly for tools such as SharePoint sites and other web services.
Note
Microsoft has begun the process of deprecating Forefront TMG, so environments looking at new solutions for security SharePoint should look instead at Forefront UAG. That said, existing Forefront TMG environments can still publish SharePoint 2013 sites with TMG.
Understanding the Difference Between Forefront UAG and Forefront TMG
The first important distinction that needs to be made is the difference between the two products in the Forefront Edge line. Forefront TMG is the direct replacement for the Internet Security and Acceleration (ISA) Server 2006 product and is positioned by Microsoft as the preferred product for outbound security filtering of web and other traffic. Forefront UAG, however, is a full-function Secure Sockets Layer/Virtual Private Network (SSL/VPN), and is positioned by Microsoft as the preferred solution for inbound security filtering of traffic destined for SharePoint and other internal published resources.
So, in a perfect world, SharePoint administrators would use the full Forefront UAG product for securing access to a SharePoint site. Indeed, Forefront UAG has a Forefront TMG engine within it, so there is no loss of functionality using the Forefront UAG line. Forefront TMG, however, has fewer overall features and is not a true SSL/VPN, and is primarily positioned as a forward proxy solution rather than a reverse-proxy one, which is what is needed for securing SharePoint.
That said, Forefront TMG does not lose any of its reverse proxy capabilities that it inherited from the older ISA 2006 product, so it can still be used for reverse-proxy securing of inbound SharePoint traffic. Either solution can be used for properly securing critical SharePoint traffic, and both solutions are outlined in this book. This chapter points out instances when there are differences between the two tools, but also assumes that either tool may be used.
At a minimum, it is highly recommended to use an application layer-aware security solution for inbound traffic to SharePoint sites, whether that is the Forefront Edge line or whether it is another third-party solution. Exposing a SharePoint site to direct uninspected access from the Internet is highly discouraged.
Outlining the Need for the Forefront Edge Line for SharePoint Environments
A great deal of confusion exists about the role that the Forefront Edge line can play in a SharePoint environment. Much of that confusion stems from the misconception that Forefront TMG or Forefront UAG are only proxy server products. Both Forefront Edge products are, on the contrary, fully functional firewalls, VPN servers, web caching proxies, and application reverse-proxy solutions. In addition, the Forefront Edge line addresses specific business needs to provide a secured infrastructure and improve productivity through the proper application of its built-in functionality. Determining how these features can help to improve the security and productivity of a SharePoint environment is subsequently of key importance.
In addition to the built-in functionality available within the Forefront Edge line, a whole host of third-party integration solutions provide additional levels of security and functionality. Enhanced intrusion detection support, content filtering, web surfing restriction tools, and customized application filters all extend the capabilities of the Forefront Edge line and position it as a solution to a wide variety of security needs within organizations of many sizes.
Outlining the High Cost of Security Breaches
It is rare when a week goes by without a high-profile security breach, denial-of-service (DoS) attack, exploit, virus, or worm appearing in the news. The risks inherent in modern computing have been increasing exponentially, and effective countermeasures are required in any organization that expects to do business across the Internet.
It has become impossible to turn a blind eye toward these security threats. On the contrary, even organizations that would normally not be obvious candidates for attack from the Internet must secure their services, as the vast majority of modern attacks do not focus on any one particular target, but sweep the Internet for any destination host, looking for vulnerabilities to exploit. Infection or exploitation of critical business infrastructure can be extremely costly for an organization. Many of the productivity gains in business recently have been attributed to advances in information technology functionality, including SharePoint-related gains, and the loss of this functionality can severely impact the bottom line.
In addition to productivity losses, the legal environment for businesses has changed significantly in recent years. Regulations such as Sarbanes-Oxley (SOX), Health Insurance Portability and Accountability Act (HIPAA), and Gramm-Leach-Bliley have changed the playing field by requiring a certain level of security and validation of private customer data. Organizations can now be sued or fined for substantial sums if proper security precautions are not taken to protect client data. The atmosphere surrounding these concerns provides the backdrop for the evolution and acceptance of the Forefront Edge line of products.
Outlining the Critical Role of Firewall Technology in a Modern Connected Infrastructure
It is widely understood today that valuable corporate assets such as SharePoint sites cannot be exposed to direct access to the world’s users on the Internet. In the beginning, however, the Internet was built on the concept that all connected networks could be trusted. It was not originally designed to provide robust security between networks, so security concepts needed to be developed to secure access between entities on the Internet. Special devices known as firewalls were created to block access to internal network resources for specific companies.
Originally, many organizations were not directly connected to the Internet. Often, even when a connection was created, no type of firewall was put into place because the perception was that only government or high-security organizations required protection.
With the explosion of viruses, hacking attempts, and worms that began to proliferate, organizations soon began to understand that some type of firewall solution was required to block access to specific “dangerous” TCP or UDP ports that were used by the Internet’s TCP/IP protocol. This type of firewall technology would inspect each arriving packet and accept or reject it based on the TCP or UDP port specified in the packet of information received.
Some of these firewalls were ASIC-based firewalls, which employed the use of solid-state microchips, with built-in packet-filtering technology. These firewalls, many of which are still used and deployed today, provided organizations with a quick-and-dirty way to filter Internet traffic, but did not allow for a high degree of customization because of their static nature.
The development of software-based firewalls coincided with the need for simpler management interfaces and the ability to make software changes to firewalls quickly and easily. The most popular firewall brand in organizations today, CheckPoint, falls into this category, as do other popular firewalls such as SonicWall and Cisco PIX. The Forefront Edge line was built and developed as a software-based firewall, and provides the same degree of packet-filtering technology that has become a virtual necessity on the Internet today.
More recently, holes in the capabilities of simple packet-based filtering technology has made a more sophisticated approach to filtering traffic for malicious or spurious content a necessity. The Forefront Edge line responds to these needs with the capabilities to perform application layer filtering on Internet traffic.
Understanding the Growing Need for Application Layer Filtering
Nearly all organizations with a presence on the Internet have put some type of packet-filtering firewall technology into place to protect the internal network resources from attack. These types of packet-filter firewall technologies were useful in blocking specific types of network traffic, such as vulnerabilities that utilize the RPC protocol, by simply blocking TCP and UDP ports that the RPC protocol would use. Other ports, however, were often left wide open to support certain functionality, such as the TCP 80 or 443 ports, utilized for HTTP and HTTPS web browsing and for access to SharePoint. As previously mentioned, a packet-filter firewall is only able to inspect the header of a packet, simply understanding which port the data is meant to utilize, but unable to actually read the content. A good analogy to this would be if a border guard were instructed to only allow citizens with specific passports to enter the country but had no way of inspecting their luggage for contraband or illegal substances.
The problems that are becoming more evident, however, is that the viruses, exploits, and attacks have adjusted to conform to this new landscape, and have started to realize that they can conceal the true malicious nature of their payload within the identity of an allowed port. For example, they can “piggy-back” their destructive payload over a known “good” port that is open on a packet-filter firewall. Many modern exploits, viruses, and “scumware,” such as illegal file-sharing applications, piggy-back off the TCP 80 or 443 ports, for example. Using the border guard analogy to illustrate, the smugglers realized that if they put their contraband in the luggage of a citizen from a country on the border guard’s allowed list, they could smuggle it into the country without worrying that the guard will inspect the package. These types of exploits and attacks are not uncommon, and the list of known application-level attacks continues to grow.
In the past, when an organization realized that they had been compromised through their traditional packet-filter firewall, the common knee-jerk reaction was to lock down access from the Internet in response to threats. For example, an exploit that would arrive over HTTP ports 80 or 443 might prompt an organization to completely close access to that port for a temporary or semi-permanent basis. This approach can greatly impact productivity as SharePoint access would be affected. This is especially true in a modern connected infrastructure that relies heavily on communications and collaboration with outside vendors and customers. Traditional security techniques would involve a trade-off between security and productivity. The tighter a firewall was locked down, for example, the less functional and productive an end user could be.
In direct response to the need to maintain and increase levels of productivity without compromising security, application layer “stateful inspection” capabilities were built into the Forefront Edge line that could intelligently determine whether particular web traffic is legitimate. To illustrate, the Forefront Edge line inspects a packet using TCP Port 80 to determine if it is a properly formatted HTTP request. Looking back to the analogy we have been using, the Forefront Edge line is like a border guard who not only checks the passports, but is also given an x-ray machine to check the luggage of each person crossing the border.
The more sophisticated application layer attacks become, the greater the need becomes for a security solution that can allow for a greater degree of productivity while reducing the type of risks which can exist in an environment that relies on simple packet-based filtering techniques.
Outlining the Inherent Threat in SharePoint Web Traffic
The Internet provides somewhat of a catch-22 when it comes to its goal and purpose. On one hand, the Internet is designed to allow anywhere, anytime access to information, linking systems around the world together and providing for that information to be freely exchanged. On the other hand, this type of transparency comes with a great deal of risk because it effectively means that any one system can be exposed to every connected computer, either friendly or malicious, in the world.
Often, this inherent risk of compromising systems or information through their exposure to the Internet has led to locking down access to that information with firewalls. Of course, this limits the capabilities and usefulness of a free information exchange system such as what web traffic provides. Many of the web servers need to be made available to anonymous access by the general public, which causes the dilemma, as organizations need to place that information online without putting the servers it is placed on at undue risk.
Fortunately, the Forefront Edge line provides for robust and capable tools to secure web traffic, making it available for remote access but also securing it against attack and exploit. To understand how it does this, it is first necessary to examine how web traffic can be exploited.
Understanding Web (HTTP) Exploits
It is an understatement to say that the computing world was not adequately prepared for the release of the Code Red virus. The Microsoft Internet Information Services (IIS) exploit that Code Red took advantage of was already known, and a patch was made available from Microsoft for several weeks before the release of the virus. In those days, however, less emphasis was placed on patching and updating systems on a regular basis, because it was generally believed that it was best to wait for the bugs to get worked out of the patches first.
So, what happened is that a large number of websites were completely unprepared for the huge onslaught of exploits that occurred with the Code Red virus, which sent specially formatted HTTP requests to a web server to attempt to take control of a system. For example, the following URL lists the type of exploits that were performed:
http://sharepoint.companyabc.com/scripts/..%5c../winnt/system32/cmd.exe?/c+dir+c:
This one in particular attempts to launch the command prompt on a web server. Through the proper manipulation, viruses such as Code Red found the method for taking over web servers and using them as drones to attack other web servers.
These types of web-based attacks were a wakeup call to the broader security community. It became apparent that packet-layer filter firewalls that could simply open or close a port were worthless against the threat of an exploit that packages its traffic over a legitimately allowed port such as HTTP or HTTPS.
Web-based filtering and securing, fortunately, is something that the Forefront Edge line does extremely well and offers a large number of customization options that enable administrators to have control over the traffic and security of the web server.
Securing Encrypted (SSL) Web Traffic
As the World Wide Web was maturing, organizations realized that if they encrypted the HTTP packets that were transmitted between a website and a client, it would make it nearly unreadable to anyone who would potentially intercept those packets. This led to the adoption of SSL encryption for HTTP traffic.
Of course, encrypted packets also create somewhat of a dilemma from an intrusion detection and analysis perspective because it is impossible to read the content of the packet to determine what it is trying to do. Indeed, many HTTP exploits in the wild today can be transmitted over secure SSL-encrypted channels. This poses a dangerous situation for organizations that must secure the traffic against interception but must also proactively monitor and secure their web servers against attack.
The Forefront Edge line is uniquely positioned to solve this problem, fortunately, because it includes the ability to perform end-to-end SSL bridging. By installing the SSL certificate from the SharePoint web front-end server on either the Forefront UAG or Forefront TMG servers, along with a copy of the private key, the server is able to decrypt the traffic, scan it for exploits, and then reencrypt it before sending it to the SharePoint server. Very few products on the market do this type of end-to-end encryption of the packets for this level of security other than the two Forefront Edge line products. Before Forefront UAG or Forefront TMG can secure SharePoint SSL traffic, however, an SSL certificate must be placed on the SharePoint server.
Securing SharePoint Traffic with SSL Encryption
By default, SharePoint is configured to use integrated Windows authentication. This form of authentication works fine if access to the server is over a trusted internal network, but is not feasible for access over the Internet.
Because of this limitation, a form of authentication that can be sent across the Internet must be used. This effectively limits the SharePoint server to using basic authentication, which is supported by most web browsers and devices. The problem with basic authentication, however, is that the username and password that the user sends is effectively sent in clear text and can be intercepted and stolen in transit. In addition, documents and other confidential information are transmitted in clear text, a huge security issue.
The solution to this problem is to use what is known as SSL encryption on the traffic. SSL encryption is performed using Public Key Infrastructure (PKI) certificates, which work through the principle of shared-key encryption. PKI SSL certificates are widely used on the Internet today; any website starting with an https:// uses them, and the entire online merchant community depends on the security of the system.
For SharePoint, the key is to install a certificate on the server so that the traffic between the device and the server is protected from prying eyes. There are effectively two options to this approach, as follows:
Use a third-party certificate authority: A common option for many organizations is to purchase a certificate for SharePoint from a third-party trusted certificate authority (CA), such as VeriSign, Thawte, or others. These CAs are already trusted by a vast number of devices, so no additional configuration is required. The downside to this option is that the certificates must be purchased and the organization doesn’t have as much flexibility to change certificate options.
Install and use your own CA: Another common approach is to install and configure Windows Server 2008 R2 Active Directory Certificate Services (AD CS) to create your own CA within an organization. This gives you the flexibility to create new certificates, revoke existing ones, and not have to pay immediate costs. The downside to this approach is that no browsers will trust the certificate by default, and error messages to that effect will be encountered on the devices unless the certificates are manually trusted or forced out to client domain members via Active Directory Group Policy Objects.
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 chapter, 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.
Forefront TMG can be used to secure a SharePoint implementation and 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 14.1.
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 can secure web traffic with SSL encryption from end to end. It does this by using the SharePoint server’s own certificate to reencrypt 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 reencrypted 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 chapter covers one common scenario that the 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 are not able to access internal links.
To configure the AAM in this scenario, home.companyabc.com, on a web application, follow these steps:
1. Open the SharePoint Central Administration tool.
2. Click the System Settings area, and then click the Alternate Access Mappings link in the links provided on the left of the screen.
4. Under Alternate Access Mapping Collection, select the AAM Collection that corresponds to the web application for home.companyabc.com.
5. Enter the https:// AAM needed under the Internet box, as shown in Figure 14.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.
6. 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 14.3. In this example, we choose to publish a simple single website. Click Next to continue.
5. Choose whether to require SSL from the Forefront Edge line server to the SharePoint server, as shown in Figure 14.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.
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 fully qualified domain name (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 are not 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 14.5. Leave Windows (Active Directory) selected and click Next.
16. The Single Sign-On (SSO) 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 Outlook Web App (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 Authentication 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 14.6, select that SharePoint AAM is already configured, as we configured the Alternate Access Mapping on the SharePoint server in previous steps.
FIGURE 14.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 now appears 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 <same as internal> Internal paths = /_vti_inf.html*, /_vti_bin/*, /_upresources/*, /_layouts/*, /* (as illustrated in Figure 14.7).
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 & Reports node, as shown in Figure 14.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.
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 displays 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).
Securing SharePoint Sites Using Forefront UAG
Microsoft’s Forefront UAG tool is a full-service SSL/VPN tool that can be used to publish access to multiple services, web-based or otherwise. It can be used to strictly control what users have access to and can be very granular for granting access rights, which makes it an ideal publishing solution for SharePoint 2013, because administrators can define exactly which farms a user needs to have access to.
Architecting Forefront UAG
Forefront UAG is similar to Forefront TMG; in fact, it uses a Forefront TMG engine for the creation of all its rules. You can even access the Forefront TMG console directly from a Forefront UAG server. Subsequently, the same design criteria that applied to Forefront TMG and that are listed earlier apply to Forefront UAG.
The main difference between Forefront TMG and Forefront UAG is that Forefront UAG allows for the creation of a “trunk,” which is essentially a web page that users hit first that forces them to authenticate and, when authenticated, allows them to have access to various applications through different links on that page. One user will see different applications on that page than another user, depending on their rights.
Creating a SharePoint Application within a UAG Trunk
An HTTP or (preferably) HTTPS trunk needs to be created before an application such as SharePoint can be defined. Creation of this trunk is outside the scope of this book, but more information can be found at Microsoft.com/forefront on the configuration of HTTPS trunks for Forefront UAG.
From within the trunk, shown in Figure 14.9, multiple “applications” can be created, such as one for SharePoint. To add SharePoint as an application to a trunk, follow these steps:
1. From within the trunk, such as the one shown in Figure 14.9, click Add to add a new application.
2. Click Next at the welcome screen.
3. From the Select Application dialog box, select Microsoft SharePoint Server 2010 under the type Web. (Note that there is currently no dropdown for SharePoint 2013; you must use 2010.) Click Next to continue.
4. Give the application a name, such as SharePoint Extranet Farm, and click Next to continue.
5. From the EndPoint Policies screen, select what type of policies will be enabled for the application. Custom policies can be created from within Forefront UAG that allow for restriction of what types of activities are allowed on the site. Microsoft creates default policies that can be used as well, such as Microsoft SharePoint 2013 Download. Either use the default policies or custom policies, depending on the situation, and then click Next to continue.
6. Under step 4, select to configure either one published server or multiple servers, depending on how big the SharePoint farm is. For this example, we are configuring a single SharePoint server. Click Next to continue.
7. Enter the IP address of the server, plus the public hostname that the SharePoint environment is known by. (Be sure to configure AAMs for SharePoint, such as what is illustrated earlier in this chapter under the Forefront TMG publishing scenarios.) Click Next to continue.
8. Under step 6, usually leave the SSO settings at the default, unless you have a specific need to customize them. You will need to either add an authentication server or choose one that is already established (such as an AD domain controller). After adding an authentication server, click Next to continue.
9. Select what type of link to include on the SSL/VPN page for the SharePoint application, such as what is shown in Figure 14.10. Click Next to continue.
10. Specify which set of users will be authorized to use the specific application. This gives you the opportunity to restrict who has rights to which application. After making any necessary changes, click Next to continue.
11. Click Finish when completed.
You can create different SharePoint applications for multiple farms and then direct them at different types of users. Forefront UAG can also be set to authenticate users from multiple directory sources, allowing it to act as a meta-directory gateway for multiple platforms and environments.
Summary
The capabilities of the Forefront Edge line to secure and protect SharePoint products and technologies give it capabilities not present in other firewall solutions. In addition, the Forefront Edge line’s ability to be easily deployed in the Perimeter network of existing firewalls as a dedicated security appliance further extends its capabilities and allows it to be deployed in environments of all shapes and sizes. Together, these tools allow for a higher degree of security and data integrity than would normally be possible with SharePoint 2013.
Best Practices
The following are best practices from this chapter:
Use SSL encryption to secure the traffic to and from a SharePoint server, particularly if that traffic crosses an unsecured network, such as the Internet.
Monitor Forefront TMG using the MSDE or SQL logging approaches to allow for the greatest level of monitoring functionality.
Secure any edge-facing service such as SharePoint with a reverse-proxy system such as Forefront TMG or Forefront UAG.
It is recommended to use Forefront UAG for inbound securing scenarios, but not necessarily required, as Forefront TMG also has significant reverse-proxy functionality. Because Forefront TMG is being deprecated, however, it might be necessary to deploy Forefront UAG instead for new environments.
Deploy the Forefront Edge line of products in the existing DMZ of a firewall if it is not feasible to replace existing firewall technologies.