Best practices for extranet environments (SharePoint Foundation 2010)
Applies to: SharePoint Foundation 2010
This article describes planning and design recommendations for extranet environments based on SharePoint Foundation in which users outside the internal network are given access to sites. This article is one of a series of Best Practices articles for Microsoft SharePoint Foundation 2010.
1. Get started with the Extranet Topologies for SharePoint 2010 Products model
The Extranet Topologies for SharePoint 2010 Products model illustrates the specific extranet topologies that have been tested with SharePoint 2010 Products. It also provides a comparison of Internet Security and Acceleration (ISA) Server, Forefront Threat Management Gateway (TMG), and Forefront Unified Access Gateway (UAG) when used as a firewall or gateway product with SharePoint 2010 Products.
Extranet Topologies for SharePoint 2010 Products
Click the image to zoom into the Extranet Topologies for SharePoint 2010 Products model
Download the Extranet Topologies for SharePoint 2010 Products model (https://go.microsoft.com/fwlink/p/?LinkId=219527)
2. Choose the appropriate server license
The license or combination of licenses for servers depends on several factors. Companies that use SharePoint Foundation 2010 have to be properly licensed for Windows Server 2008.
3. Leverage multiple authentication mechanisms
Do not try to standardize all users to a single authentication mechanism. Use the authentication mechanism that gives the best experience for each user audience. For example, using SAML claims-based authentication for partners enables these users to use one set of credentials. Take advantage of the flexibility that SharePoint Foundation provides for configuring authentication, rather than deploying a single authentication mechanism to everyone in an organization.
For an example of a design that utilizes multiple authentication mechanisms, see Design sample: collaboration sites (SharePoint Foundation 2010).
4. Maintain consistency in user authentication for users
Ensure that users can use the same account and credentials to log on to sites whether they are inside or outside the internal network. This is important because if users connect to sites through two different authentication providers, SharePoint Foundation creates two different accounts and profiles for each user.
If you use Windows authentication internally, there are at least two options to ensure that users can log on with the same account internally and externally:
Use forms-based authentication on the firewall or gateway product to collect Windows credentials that are forwarded to the SharePoint farm. This works in environments that use classic-mode authentication in which forms-based authentication for SharePoint sites is not supported.
Using Secure Sockets Layer (SSL) to implement only one URL that can be used both internally and externally. In other words, employees use the same zone that is configured for SSL regardless of where they are located.
5. Configure zones identically across Web applications
In an extranet environment, the design of zones is critical. Ensure that the configuration of zones meets the following requirements:
Configure zones across multiple Web applications to mirror each other. The configuration of authentication, zones, and users who are assigned to zones should be the same. However, the policies that are associated with zones can differ across Web applications. For example, ensure that the intranet zone is used for the same employees across all Web applications. In other words, do not configure the intranet zone for internal employees in one Web application and remote employees in another Web application.
Configure alternate access mappings appropriately and accurately for each zone and each resource. Alternate access mappings are automatically created when you create the zone. However, SharePoint Foundation can be configured to crawl content in external resources, such as a file share. You must use alternate access mappings to manually create links for each zone to these external resources.
6. Take advantage of a reverse proxy server
Protect your environment from direct user requests by using a reverse proxy server, where request inspection rules can be applied to each request. A reverse proxy can prevent information disclosure about the configuration of an internal network, and it can be used to securely terminate client SSL sessions to avoid SSL overhead on the Web servers.
Forefront Unified Access Gateway (UAG) is a reverse-proxy server that provides many capabilities when you combine it with SharePoint Foundation in extranet environments. For more information, see the following resources:
7. Configure cross-firewall access and settings for mobile devices
A cross-firewall access zone is used to generate external URLS for mobile alert messages. It also enables users to click the E-mail a link button on the ribbon to send an externally accessible URL. Some configuration is necessary to ensure that SharePoint sites are accessible for mobile devices, such as Windows Phone 7, when the devices are used outside the corporate firewall.
For more information, see the following articles:
8. Configure the People Picker for multiple domains
Because extranet environments can span multiple domains, be sure to configure the People Picker to return users, groups, and claims from the intended domains.
For more information, see the following resources:
9. Configure antivirus settings
SharePoint Foundation includes an antivirus scanner that you can configure by using either Central Administration or by using the stsadm command-line tool.
10. Configure DNS for split back-to-back topologies
If Web servers are split between the internal network and the perimeter network, ensure that DNS is configured with the appropriate records in each network zone to direct traffic to the intended Web servers.
For more information about configuring DNS, see “Zones and URLs” in Design sample: collaboration sites (SharePoint Foundation 2010).
The SharePoint Server 2010 Content Publishing team thanks the following contributors to this article:
Ali Mazaheri, Microsoft Consulting Services
Bryan Porter, Microsoft Consulting Services
Steve Walker, Microsoft SharePoint Customer Engineering
Tajeshwar Singh, Microsoft Consulting Services