Implementing and Validating SharePoint 2010 Security : Using IPsec for Internal SharePoint Encryption

3/6/2011 3:02:52 PM
IPsec, mentioned briefly in previous sections, is essentially a mechanism for establishing end-to-end encryption of all data packets sent between computers. IPsec operates at Layer 3 of the OSI model and uses encrypted packets for all traffic between members.

IPsec is often considered to be one of the best ways to secure the traffic generated in an environment and is useful for securing all SharePoint farm servers in high-risk Internet access scenarios and also in private network configurations for an enhanced layer of security. Without a technology such as IPsec, communications between farm members can be intercepted and their contents easily defined.

Reviewing the IPsec Principle

The basic principle of IPsec is this: All traffic between clients, whether initiated by applications, the operating system, services, and so on, is entirely encrypted by IPsec, which then puts its own header on each packet and sends the packets to the destination server to be decrypted. Because every piece of data is encrypted, this prevents electronic eavesdropping, or listening in on a network in an attempt to gain unauthorized access to data.

Several functional IPsec deployments are available, and some of the more promising ones are actually built in to the network interface cards (NICs) of each computer, performing encryption and decryption without the operating system knowing what is going on. Aside from these alternatives, Windows Server includes a robust IPsec implementation by default, which can be configured to use a PKI certificate network or the built-in Kerberos authentication provided by Active Directory on Windows Server.

Detailing Key IPsec Functionality

IPsec in Windows Server provides for the following key functionality that, when combined, provides for one of the most secure solutions available for client/server encryption:

  • Data privacy— All information sent from one SharePoint machine to another is thoroughly encrypted by such algorithms as 3DES, which effectively prevent the unauthorized viewing of sensitive data.

  • Data integrity— The integrity of IPsec packets is enforced through ESP headers, which verify that the information contained within an IPsec packet has not been tampered with.

  • Antireplay capability— IPsec prevents streams of captured packets from being re-sent, known as a “replay” attack, blocking such methods of obtaining unauthorized access to a system by mimicking a valid user’s response to server requests.

  • Per-packet authenticity— IPsec utilizes certificates or Kerberos authentication to ensure that the sender of an IPsec packet is actually an authorized user.

  • NAT transversal— The Windows Server implementation of IPsec now allows for IPsec to be routed through current Network Address Translation (NAT) implementations, a concept defined more thoroughly in the following sections.

  • Diffie-Hellman 2048-bit key support— Nearly unbreakable Diffie-Hellman 2048-bit key lengths are supported in the Windows Server IPsec implementation, essentially ensuring that the IPsec key cannot be cracked.

Setting Up the Monitoring Environment for IPsec Communications

IPsec is built in to all Windows Server machines and is also available for client systems. It is a straightforward process to install and configure IPsec between SharePoint servers and should be considered as a way to further implement additional security in a SharePoint environment.


IPsec is highly recommended, although there is a performance penalty. Assume an approximately 10 percent overhead to use IPsec on network communications. That said, it is extremely easy to configure and highly useful for providing for transport-level security of data between SharePoint farm servers. Transport-level security from clients to web servers should always take the form of Secure Sockets Layer (SSL) certificate encryption.

The procedure outlined in the following sections illustrates the setup of a simple IPsec policy between a SharePoint web role server and a SQL database server holding SharePoint databases. In this example, the SharePoint server is SP1, and the SQL DB server is SQL1. The OS on both servers is Windows Server 2008 R2.

To view the current status of any IPsec policies, including the ones that will be created in this procedure, the IPsec Security Monitor MMC snap-in on SP1 needs to be opened. The MMC snap-in can be installed and configured by following these steps:

Choose Start, Run and type mmc into the Run dialog box. Click OK when complete.

In MMC, choose File, Add/Remove Snap-in.

Scroll down and select IP Security Policy Management and click Add.

Select Local Computer and click OK.

Scroll down and select IP Security Monitor; then click the Add button, followed by the OK button.

Both the IP Security Policies and the IP Security Monitor MMC snap-in should now be visible, as shown in Figure 1. Click OK.

Figure 1. Configuring monitoring of IPsec transport-layer security between SharePoint servers.

In MMC, expand to Console Root\IP Security Monitor\SP1.

Right-click SP1 and choose Properties.

Change the autorefresh setting from 45 seconds to 5 seconds or less. Click OK when finished. You can then use the MMC IP Security Monitor console to view IPsec data.

Establishing an IPsec Policy on the SharePoint Server

Default IPsec policies must be enabled on any server in the SharePoint farm that will need to communicate over IPsec. To enable a simple IPsec policy that uses Active Directory Kerberos (as opposed to certificates-based IPsec), do the following on each server:

From the MMC Console setup in the previous step, right-click IP Security Policies, and then click Create IP Security Policy.

Click Next at the Welcome Wizard.

Give a name to the IP security policy, such as SharePoint IP Security Policy, and click Next to continue.

Do not check the box to activate the default response rule, but do click Next to continue. The default response rule is only used for down-level systems.

Leave the Edit Properties check box marked and click the Finish button.

In the Security Rules dialog box, click Add.

Click Next to continue.

At the Tunnel Endpoint dialog box, shown in Figure 2, choose that the rule does not specify a tunnel, and click Next to continue.

Figure 2. Creating an IP security policy.

From the Network Type dialog box, choose All Network Connections and click Next to continue.

In the IP Filter List dialog box, click Add to add an IP filter.

Give a name to the IP filter, and then click Add.

Click Next at the Welcome Wizard.

Leave the Mirrored check box intact and click Next to continue.

For Source Address, leave the default at Any IP Address and click Next.

For Destination Address, leave the default at Any IP Address and click Next.

For Protocol, leave the default at Any, shown in Figure 3, and click Next.

Figure 3. Creating an IP filter list.

Click Finish at the Completion Wizard for the IP filter.

Tick the circle for the filter list just created, and then click Next to continue.

Under Filter Action, click Add to create a filter action.

At the Welcome Wizard, click Next to continue.

Enter a name and description for the filter action and click Next.

Choose Negotiate Security, shown in Figure 4, and click Next to continue.

Figure 4. Selecting authentication type.

Select Do Not Allow Unsecured Communication and click Next to continue. Note that if you have servers that do not support IPsec, you may have to choose the less-secure option to allow unsecured communications in some cases.

In the IP Traffic Security dialog box, choose the security method of Integrity and Encryption and click Next to continue.

Click Finish.

Tick the circle for the filter action just created, as shown in Figure 5, and click Next to continue.

Figure 5. Selecting a filter action.

Select Kerberos v5 authentication and click Next to continue.

Click Finish to complete the wizard.

The Security Policy Settings should look similar to what is shown in Figure 6. Click OK to close the dialog box.

Figure 6. Finalizing security policy settings.

From within the IP Security Policies MMC Snap-in, choose the SharePoint security policy just created, right-click it, and choose Assign.

Repeat on additional SharePoint servers.

Verifying IPsec Functionality in Event Viewer

After the local IPsec policies are enabled on both SQL1 and SP1, IPsec communications can take place. To test this, either ping the server from the client desktop or perform other network tests, such as accessing SP1’s SharePoint site.

A quick look at the IP Security Monitor that was established in MMC on SP1 shows that IPsec traffic has been initialized and is logging itself. Traffic statistics, such as those shown in Figure 7, should subsequently be shown. All communications between the SharePoint farm members are now highly encrypted and secured.

Figure 7. Viewing IPsec statistics.

These default IPsec policies are useful in establishing ad hoc IPsec between SharePoint clients on a network but are limited in their scope. Enterprise-wide IPsec policies can be accomplished through the use of group policies, but proper planning of an enterprise IPsec implementation is necessary to effectively secure an entire environment using custom IPsec policies.

  •  Examining Integration Points Between SharePoint and Public Key Infrastructure
  •  Getting the Most Out of the Microsoft Outlook Client : Deploying Outlook 2007
  •  Getting the Most Out of the Microsoft Outlook Client : Implementing Outlook Anywhere
  •  Getting the Most Out of the Microsoft Outlook Client : Security Enhancements in Outlook 2007
  •  Getting the Most Out of the Microsoft Outlook Client : Highlighted Features in Outlook 2007
  •  Sharepoint 2010 : Deploying Transport-Level Security for SharePoint
  •  sharepoint 2010 : Verifying Security Using the Microsoft Baseline Security Analyzer
  •  sharepoint 2010 : Utilizing Security Templates to Secure a SharePoint Server
  •  Integrating Office Communications Server 2007 in an Exchange Server 2010 Environment : Web Conferencing
  •  Integrating Office Communications Server 2007 in an Exchange Server 2010 Environment : Installing and Using the Communicator 2007 Client
  •  Integrating Office Communications Server 2007 in an Exchange Server 2010 Environment : Exploring Office Communications Server Tools and Concepts
  •  SharePoint 2010 : Securing SharePoint’s SQL Server Installation
  •  SharePoint 2010 : Physically Securing SharePoint Servers
  •  SharePoint 2010 : Identifying Isolation Approaches to SharePoint Security
  •  Exchange Server 2010 : Installing OCS 2007 R2 (part 5) - Starting the OCS Services on the Server & Validating Server Functionality
  •  Exchange Server 2010 : Installing OCS 2007 R2 (part 4) - Configuring the Server & Configuring Certificates for OCS
  •  Exchange Server 2010 : Installing OCS 2007 R2 (part 3) - Configuring Prerequisites & Deploying an OCS 2007 Server
  •  Exchange Server 2010 : Installing OCS 2007 R2 (part 2) - Prepping the Domain & Delegating Setup and Administrative Privileges
  •  Exchange Server 2010 : Installing OCS 2007 R2 (part 1) - Extending the Active Directory (AD) Schema & Preparing the AD Forest
  •  Integrating Office Communications Server 2007 in an Exchange Server 2010 Environment - Understanding Microsoft’s Unified Communications Strategy
    Top 10
    Nikon 1 J2 With Stylish Design And Dependable Image And Video Quality
    Canon Powershot D20 - Super-Durable Waterproof Camera
    Fujifilm Finepix F800EXR – Another Excellent EXR
    Sony NEX-6 – The Best Compact Camera
    Teufel Cubycon 2 – An Excellent All-In-One For Films
    Dell S2740L - A Beautifully Crafted 27-inch IPS Monitor
    Philips 55PFL6007T With Fantastic Picture Quality
    Philips Gioco 278G4 – An Excellent 27-inch Screen
    Sony VPL-HW50ES – Sony’s Best Home Cinema Projector
    Windows Vista : Installing and Running Applications - Launching Applications
    Most View
    Bamboo Splash - Powerful Specs And Friendly Interface
    Powered By Windows (Part 2) - Toshiba Satellite U840 Series, Philips E248C3 MODA Lightframe Monitor & HP Envy Spectre 14
    MSI X79A-GD65 8D - Power without the Cost
    Canon EOS M With Wonderful Touchscreen Interface (Part 1)
    Windows Server 2003 : Building an Active Directory Structure (part 1) - The First Domain
    Personalize Your iPhone Case
    Speed ​​up browsing with a faster DNS
    Using and Configuring Public Folder Sharing
    Extending the Real-Time Communications Functionality of Exchange Server 2007 : Installing OCS 2007 (part 1)
    Google, privacy & you (Part 1)
    iPhone Application Development : Making Multivalue Choices with Pickers - Understanding Pickers
    Microsoft Surface With Windows RT - Truly A Unique Tablet
    Network Configuration & Troubleshooting (Part 1)
    Panasonic Lumix GH3 – The Fastest Touchscreen-Camera (Part 2)
    Programming Microsoft SQL Server 2005 : FOR XML Commands (part 3) - OPENXML Enhancements in SQL Server 2005
    Exchange Server 2010 : Track Exchange Performance (part 2) - Test the Performance Limitations in a Lab
    Extra Network Hardware Round-Up (Part 2) - NAS Drives, Media Center Extenders & Games Consoles
    Windows Server 2003 : Planning a Host Name Resolution Strategy - Understanding Name Resolution Requirements
    Google’s Data Liberation Front (Part 2)
    Datacolor SpyderLensCal (Part 1)