SharePoint Knowledge Base

SharePoint works very well as an intranet and it also can work well as an extranet or business-to-business portal. Getting the securely published is the topic of this post. Designing extranets typically requires thoughtful consideration of information architecture in regard to security. This post reviews several common scenarios.

• Perimeter or edge firewall
• Back-to-back perimeter
• Split back-to-back

Supported authentication methods

SharePoint Server 2010 supports authentication methods that were included in previous versions and also introduces token-based authentication that is based on Security Assertion Markup Language (SAML) as an option. The following table lists the supported authentication methods.

Authentication modes — classic or claims-based

SharePoint Server 2010 introduces claims-based authentication, which is built on Windows Identity Foundation (WIF). You can use any of the supported authentication methods with claims-based authentication; or you can use classic-mode authentication, which supports Windows authentication.

Claims-based authentication is built on WIF, which is a set of .NET Framework classes that are used to implement claims-based identity. Claims-based authentication relies on standards such as WS-Federation, WS-Trust, and protocols such as SAML.

Topology: Perimeter or Edge Firewall

In edge topology, a single network firewall stands between external users and internal SharePoint sites. It has the advantage of using a single Active Directory environment for internal and external users, which simplifies maintenance and administration. To secure traffic via TLS, you configure the firewall to also act as a reverse proxy. The concept of an integrated reverse proxy such as ISA or TMG Server is vital for securing Internet-facing sites, because the reverse proxy intercepts incoming requests, can authenticate external users, decrypts TLS traffic, inspects it according to firewall rules, and forwards requests to front-end servers. Public URLs may differ from internal URLs, so the reverse proxy must have a means to perform link translation to convert external URLs into internal URLs. UAG Server provides additional security capabilities, such as end-point, health-based authorization through an access policy based on user identity and client computer health, and the ability to translate links for internal SharePoint URLs when using Outlook Web Access By using a set of configurable rules, the proxy server verifies that the requested URLs are allowed based on the zone from which the request originated. The requested URLs are then translated into internal URLs.

Advantages

• The simplest solution that requires the least amount of hardware and configuration.
• The entire server farm is located within the corporate network.
• There is a single point of data:
• Data is located within the trusted network.
• Data maintenance occurs in one place.
• A single farm is used for both internal and external requests; this ensures that all authorized users view the same content.
• Internal user requests are not passed through a proxy server.
• UAG pre-authenticates users.

Disadvantage

This configuration results in a single firewall that separates the corporate internal network from the Internet.

Topology: Back-to-Back Perimeter

• A back-to-back perimeter topology isolates the server farm in a separate perimeter network.
• All hardware and data reside in the perimeter network.
• The server farm roles and network infrastructure servers can be separated across multiple layers. Combining the network layers can reduce the complexity and cost.
• Each layer can be separated by additional routers or firewalls to ensure that only requests from specific layers are allowed.
• Requests from the internal network can be directed through the internal-facing ISA/TMG server or routed through the public interface of the perimeter network.

You are not limited to just two firewalls in a back-to-back topology. You can implement additional layers separated by firewalls or routers to further separate the SharePoint roles. For example, you could use a three-layer approach, putting each layer in a DMZ, where front-end servers are first, followed by application, database and search/index server, and concluded by Active Directory/DNS servers. You can also customize a back-to-back topology to include an internal staging environment in a separate farm and publish it to the farm in the perimeter network.

Advantages

Content is isolated to a single farm on the extranet, simplifying sharing and maintenance of content across the intranet and the extranet.

• External user access is isolated to the perimeter network.
• If the extranet is compromised, damage is potentially limited to the affected layer or to the perimeter network.

Disadvantage

• Requires additional network infrastructure and configuration.
  

Topology: Split Back-to-Back

In keeping with the approach of using security layers in the topology, front-end servers reside in the perimeter network and the back-end servers running SQL Server reside in the internal network. The remaining roles, such as index, search, and central administration, can be in either network. This topology splits the farm between the perimeter and corporate networks. The computers running Microsoft SQL Server® database software are hosted inside the corporate network. Web servers are located in the perimeter network. The application server computers can be hosted in either the perimeter network or the corporate network.

If the server farm is split between the perimeter network and the corporate network, a domain trust relationship is required. There are two AD domains for the Intranet and extranet - say DOMAIN and DOMAINEXT. DOMAINEXT is in the perimeter network. Servers in the perimeter (DMZ) network are joined to this domain. In this scenario, the perimeter domain must trust the corporate domain. DOMAINEXT trusts DOMAIN with a 1-way trust.

You set up the farm as you typically would internally within DOMAIN. You then join a WFE in the perimeter network to the farm. Since this WFE is joined to a domain that trusts the internal domain, it can use the same service accounts, etc. However, if someone hacks the WFE and gains access to the extranet domain, they can't do anything to the internal domain as DOMAIN does not trust DOMAINEXT.

The only scenario in which a domain trust is not required is if the Web and application servers are in the perimeter network, the database servers are in the corporate network, and SQL authentication is used. However, if the Web and application servers are split between the networks and SQL authentication is used, a trust relationship is required.

Advantages

• Computers running SQL Server are not hosted inside the perimeter network.
• Farm components within both the corporate network and the perimeter network can share the same databases.
• Content can be isolated to a single farm inside the corporate network, which simplifies sharing and maintaining content across the corporate network and the perimeter network.

Disadvantages

• The complexity of the solution is greatly increased.
• Intruders who compromise perimeter network resources might gain access to farm content stored in the corporate network by using the server farm accounts.
• Inter-farm communication is split across two domains.

Requirements

• One-way trust between extranet AD and intranet AD
• Open Firewall Ports
  • WFE / Service application communication - Port 32843
  • SQL: TCP/TDS: 1433, 1434; Analysis service TCP: 2394
  • WINs: name service 137, Browser: 138, Session: 139
  • Search propagation requires file and printer sharing either via SMB 445 or NetBT Ports 137, 138, 139
  • SMTP - Port 25
  • Authentication – LDAP: 389, Kerberos: 88
  • Sandboxed solutions (if used) - Port 32846
  • User Profile Sync should be configured within intranet as access to AD is required and used ports 53, 389, 5725

Topology: Split Back-to-Back

About this diagram:

• Application servers are hosted inside the perimeter network. This option is illustrated by servers inside the dashed line.
• Application servers can optionally be deployed inside the corporate network, with the database servers. This option is illustrated by the servers inside the gray box with the dashed line.
• To optimize search performance and crawling, place the application servers inside the corporate network with the database servers. You can also add the Web server role to the index server inside the corporate network and configure this Web server for dedicated use by the index server for content crawling.

We love helping with SharePoint and it's all we do so feel free to contact us!

Mention this post and we'll send you a white paper about how to best utilize SharePoint!