Export (0) Print
Expand All

Plan security hardening for extranet environments (SharePoint Server 2010)

Published: November 1, 2011

This article describes the security hardening requirements for an extranet environment in which a server running Microsoft SharePoint Server 2010 is placed inside a perimeter network and content is available from the Internet or from the corporate network.

Although the hardening guidance was written for a back-to-back perimeter network topology, much of the information in this article can be applied to many different extranet configurations.

In this article:

For additional information about supported extranet topologies and security hardening, see the following articles:

Extranet hardening planning tool

The following planning tool is available for use with this article: Extranet hardening planning tool: back-to-back perimeter (SharePoint Server 2010) (http://go.microsoft.com/fwlink/p/?LinkId=231272). Based on the back-to-back perimeter topology, this tool articulates the port requirements for each of the network firewalls, and each of the routers or firewalls within the perimeter network. This tool is an editable Microsoft Visio 2010 file that you can revise for your environment. For example, you can modify the tool in the following ways:

  • Add your custom port numbers, where applicable.

  • Indicate which ports you will use when a choice of protocols or ports is provided.

  • Indicate the specific ports that are used for database communication in your environment.

  • Add or remove requirements for ports based on one or more of the following criteria:

    • Whether you are configuring e-mail integration.

    • The layer on which you deploy the query role.

    • Whether you are configuring a domain trust relationship between the perimeter domain and the corporate domain.

note Note:

If you would like to see additional planning tools for other supported extranet topologies, submit a comment on this article to let us know.

Network topology

The following back-to-back perimeter network topology diagram shows an example implementation and illustrates the server and client roles across an extranet environment. The purpose of the diagram is to articulate each of the possible roles and their relationship to the overall environment. The routers in the diagram can be exchanged for firewalls.

Extranet Topology Diagram

Some TCP/IP ports that various services use in this network topology cannot be changed, but ports for a few of the services can be modified. For example: the server running SQL Server in this network topology uses TCP port 1433 by default, but this can be customized. Because many port numbers that are used by these services are published by the Internet Assigned Numbers Authority (IANA), it is a good security hardening practice to change the default port to a custom port and block the default port.

When you choose custom ports for services, you should choose ports in the 1025 through 65535 range because ports from 1 through 1024 are reserved for use by system services. We recommend that you choose a port that is not in the ephemeral port range, which is used by the operating system for dynamic port assignments. The ephemeral port range includes ports 49152 through 65535 for Windows Server 2008.

For more information about the Windows TCP/IP ephemeral port range, see the following Microsoft Knowledgebase article:

929851: The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=186949)

Domain trust relationships

The requirement for a domain trust relationship depends on how the server farm is configured. This section discusses two possible configurations.

Server farm resides in the perimeter network

The perimeter network requires its own Active Directory Domain Services (AD DS) infrastructure and domain. Typically, the perimeter domain and the corporate domain are not configured to trust each other. However, to authenticate intranet users and remote employees who are using their domain credentials (Windows authentication), you must configure a one-way trust relationship in which the perimeter domain trusts the corporate domain. Claims-based authentication and forms-based authentication do not require a domain trust relationship.

Server farm is split between the perimeter network and the corporate network

If the server farm is split between the perimeter network and the corporate network and the database servers reside inside the corporate network, a domain trust relationship is required if Windows accounts are used. In this scenario, the perimeter network must trust the corporate network. If SQL Server authentication is used, a domain trust relationship is not required. The following table summarizes the differences between these two approaches.

Windows authentication SQL Server authentication

Description

Corporate domain accounts are used for all SharePoint Server 2010 service and administration accounts, including application pool accounts.

A one-way trust relationship, in which the perimeter network trusts the corporate network, is required.

SharePoint Server 2010 accounts are configured in the following ways:

  • SQL Server authentication is used for every database that is created.

  • All other administration and service accounts are created as domain accounts in the perimeter network.

  • Web servers and application servers are joined to the perimeter network.

A trust relationship is not required but can be configured to support client authentication against an internal domain controller.

note Note:

If the application servers reside in the corporate domain, a one-way trust relationship, in which the perimeter network trusts the corporate network, is required.

Setup

Setup includes the following processes:

  • SharePoint Server 2010 administration and service accounts are created in the corporate domain.

  • Web servers and application servers are joined to the perimeter network.

  • A trust relationship is established in which the perimeter domain trusts the corporate domain.

Setup includes the following processes:

  • All database accounts must be created as SQL Server login accounts in Microsoft SQL Server 2005 or Microsoft SQL Server 2008 Management Studio. These accounts must be created before the creation of any SharePoint Server 2010 databases, including the configuration database and the SharePoint_AdminContent database.

  • You must use the Psconfig command-line tool to create the configuration database and the SharePoint_AdminContent database. You cannot use the SharePoint 2010 Products Configuration Wizard to create these databases. In addition to using the -user and -password parameters to specify the server farm account, you must use the -dbuser and -dbpassword parameters to specify SQL Server authentication accounts.

  • You can create additional content databases in Central Administration by selecting the SQL authentication option. However, you must first create the SQL Server login accounts in Microsoft SQL Server 2005 or Microsoft SQL Server 2008 Management Studio.

  • Secure all communication with the database servers using Secure Sockets Layer (SSL).

  • Ensure that ports used for communication with SQL Server remain open between the perimeter network and the corporate network.

Additional information

The one-way trust relationship allows the Web servers and application servers that are joined to the extranet domain to resolve accounts that are in the corporate domain.

  • SQL Server login accounts are encrypted in the registry of the Web servers and application servers.

  • The server farm account is not used to access the configuration database and the SharePoint_AdminContent database. The corresponding SQL Server login accounts are used instead.

The information in the preceding table makes the following assumptions:

  • Both the Web servers and the application servers reside in the perimeter network.

  • All accounts are created with the least privileges necessary, including the following recommendations:

    • Separate accounts are created for all administrative and service accounts.

    • No account is a member of the Administrators group on any computer, including the server computer that hosts SQL Server.

If you are using SQL Server authentication, the following SQL Server logins must be created with the following permissions:

  • SQL Server login for the account that is used to run the Psconfig command-line tool   The account must be a member of the following SQL Server roles: dbcreator and securityadmin. The account must be a member of the Administrators group on each server on which Setup is run (not the database server).

  • SQL Server login for the server farm account   This login is used to create the configuration database and the SharePoint_AdminContent database. The login must include the dbcreator role. The login does not need to be a member of the securityadmin role. The login must be created by using SQL Server authentication. Configure the server farm account to use SQL Server authentication with the password that is specified when you create the SQL Server login for the server farm account login.

  • SQL Server login for the server farm account login for all other databases   The login must be created using SQL Server authentication. The login must be a member of the following SQL Server login for the server farm account roles: dbcreator and securityadmin.

For more information about SharePoint Server 2010 accounts, see Plan for administrative and service accounts (SharePoint Server 2010).

For more information about how to use the Psconfig command-line tool to create databases, see Psconfig command-line reference (SharePoint Server 2010).

Communication with server-farm roles

When configuring an extranet environment, it is important to understand how the various server roles communicate within the server farm.

Communication between server roles

The following figure illustrates the communication channels within a server farm. The table directly after the figure indicates the ports and protocols that are represented in the figure. The black arrows indicate which server role initiates communication. For example, the Excel Calculation Services role initiates communication with the database server. The database server does not initiate communication with the Excel Calculation Services role. This is important to know when configuring inbound and outbound communication on a firewall.

Inter-farm communication in SharePoint Server 2010

Callout Ports and protocols

1

Client access (including Information Rights Management (IRM) and search queries); one or more of the following:

  • TCP port 80

  • TCP port 443 (SSL)

  • Custom ports

2

The crawl component processes crawls of content resources, and propagates the resulting index fragment files to query components:

  • TCP Port 32845 (SML/Named Pipes)

3

Windows Communication Foundation (WCF):

  • TCP port 32843

  • TCP port 32844 (SSL)

4

Database communication:

On the Query Server, the query processor (also known as the Search Query and Settings Service) communicates with the following two databases in SQL Server:

  • Search Administration database

  • Property database types

On the Crawl Server, each crawl component is attached to a crawl database in SQL Server. The crawl component adds information such as content resource location and crawl schedules to its associated crawl database.

  • TCP/SSL port 1433 (default) for default instance (customizable)

  • TCP/SSL random port for named instances (customizable)

5

Search crawling —The crawl component on the Crawl Server processes crawls of content resources. Depending on how authentication is configured, SharePoint sites might be extended with an additional zone or Internet Information Services (IIS) site to ensure that the index component can access content; this configuration can result in custom ports.

  • TCP 80

  • TCP 443 (SSL)

  • Custom ports

6

Secure Store Service — The Secure Store Service is an authorization service that runs on an application server. The Secure Store Service provides a database that is used to store credentials. These credentials, which usually consist of a user identity and password, can also contain other fields that you define. For example, Microsoft SharePoint Server 2010 can use the secure store database to store and retrieve credentials for access to external data sources. The Secure Store Service provides support for storing multiple sets of credentials for multiple back-end systems.

For Excel Services, the Secure Store Service can be used to provide access to external data sources in published workbooks. This can be used as a substitute to passing a user’s credentials to the data source, a process which often requires configuring Kerberos delegation. Excel Services requires the Secure Store Service if you want to configure an unattended service account for data authentication.

Like all services that are shared across a SharePoint Server 2010 farm, the Secure Store Service requires the following ports:

  • TCP port 32843

  • TCP port 32844 (SSL)

For more information about the Secure Store Service, see Plan the Secure Store Service (SharePoint Server 2010).

For more information about how to share a service across a SharePoint Server 2010 farm, see Share service applications across farms (SharePoint Server 2010).

In the search architecture of SharePoint Server 2010, query requests are sent from the Search Proxy on the Web server to one instance of the Query Processor (also known as the Search Query and Site Settings service) that is running on each Query Server. The Query Processor queries a Query Component from each partition of the search index. The Query Component determines the best results from its index, and returns those items. Although logical components of search in SharePoint Server 2010 can exist on various physical servers, communication from Search Proxy to the Query Processor is done through Windows Communication Foundation (WCF). Communication from the Query Processor to Query Components is done through the Server Message Block (SMB) protocol and named pipes.

Search Query System Logical Architecture

Communication between the Central Administration site and server roles

This section details the port and protocol requirements for communication between an administrator workstation and server roles within the farm. The Central Administration site can be installed on any Web server or application server. Configuration changes that are made through the Central Administration site are communicated to the configuration database. Other server roles in the farm accept configuration changes that are registered in the configuration database during their polling cycles. Consequently, the Central Administration site does not introduce any new communication requirements to other server roles in the server farm.

The following figure illustrates the communication channels from an administrator workstation to the administrative sites and the configuration database.

Administrative Site Communication

The following table describes the ports and protocols that are illustrated in the preceding figure.

Callout Ports and protocols

A

Central Administration site — One or more of the following:

  • TCP 80

  • TCP 443 (SSL)

  • Custom ports

    note Note:

    Management of all shared service applications are performed in the Central administration site.

B

Database communication:

  • TCP/SSL port 1433 (default) for default instance (customizable)

  • TCP/SSL random port for named instances (customizable)

Communication with infrastructure server roles

When configuring an extranet environment, it is important to understand how the various server roles communicate within infrastructure server computers.

Active Directory Domain Services domain controller

The following table lists the port requirements for inbound connections from each server role to an Active Directory Domain Services domain controller.

Item Web Server Query Server Excel Calculation Services Database Server

TCP/UDP 445 (Directory Services)

X

X

X

X

TCP/UDP 88 (Kerberos authentication)

X

X

X

X

TCP/UDP 389 by default (Lightweight Directory Access Protocol [LDAP])

X1

X1

TCP 636 by default (LDAP over TLS/SSL [LDAPS])

X1

X1

1LDAP/LDAPS ports are required for server roles based on the following conditions:

  • Web servers   Use LDAP/LDAPS ports if LDAP authentication is configured.

  • Query server   Role requires LDAP/LDAPS ports for importing profiles from the domain controllers that are configured as profile import sources, wherever these reside.

SQL Server

The following table lists the port requirements for inbound connections from each server role to a server running SQL Server. Most database connections are on TCP port 1433 by default for the default instance, but this is customizable. (Because TCP port 1433 is a well-known port for accessing a SQL Server, you could configure your server running SQL Server to listen on a different port and block port 1433.) For named instances, you can choose a random port.

Item Web Server Query Server Crawl Server

TCP/UDP 1433 (default) for the default instance (customizable)

X

X

X

TCP/UDP on a custom port for named instances

X

X

X

For more information about security hardening for SQL Server, see Harden SQL Server for SharePoint environments (SharePoint Server 2010).

DNS server

The following table lists the port requirements for inbound connections from each server role to a Domain Name System (DNS) server. In many extranet environments, one server computer hosts both the Active Directory Domain Services domain controller and the DNS server.

Item Web Server Query Server Crawl Server Database Server

TCP/UDP 53

X

X

X

X

SMTP service

E-mail integration requires the use of the Simple Mail Transport Protocol (SMTP) service using TCP port 25 on at least one of the front-end Web servers in the server farm. The SMTP service is required for incoming e-mail (inbound connections). For outgoing e-mail, you can either use the SMTP service or route outgoing e-mail through a dedicated e-mail server in your organization, such as a computer running Microsoft Exchange Server.

Item Web Server Query Server Excel Calculation Services Database Server

TCP port 25

X

Requirements to support document conversions

If you are using document converters on the server, the following services must be installed and started on an application server:

  • Document Conversions Launcher Service

  • Document Conversions Load Balancer Service

You can install these services on the same application server or on separate application servers, depending on the topology that best suits your needs. These services can also be installed on one or more Web servers, if needed. If these services are installed on separate servers, communication between these separate servers must enable these services to communicate with each other.

The following table lists the port and protocol requirements for these services. These requirements do not apply to server roles in the farm that do not have these services installed.

Service Requirement

Document Conversions Launcher Service

TCP port 8082 (default), customizable for either TCP or SSL

Document Conversions Load Balancer Service

TCP port 8093 (default), customizable for either TCP or SSL

For information about how to configure these services in a server farm, see Configure Document Conversions Load Balancer and Launcher Services (SharePoint Server 2010).

Communication between network domains

Active Directory communication

To use Active Directory Domain Services to support authentication between domains when a domain controller is inside the corporate network requires at least a one-way trust relationship in which the perimeter network trusts the corporate network.

In the example illustrated in the first figure in this article, the following ports are required as inbound connections to Network Firewall B to support a one-way trust relationship:

Service Ports and protocols

Remote Procedure Call (RPC)

TCP/UDP 135

Lightweight Directory Access Protocol (LDAP)

TCP/UDP 389 by default (customizable)

LDAP over TLS/SSL (LDAPS)

TCP 636 by default (customizable)

Microsoft Global Catalog (MSFT-GC)

TCP 3268

Microsoft Global Catalog over TLS/SSL (MSFT-GC-SSL)

TCP 3269

Domain Name Service (DNS)

TCP/UDP 53

Kerberos

TCP/UDP 88

Microsoft Directory Services (Microsoft-DS)

TCP/UDP 445

Kerberos Administration (Kerberos-Adm)

TCP/UDP 749

Kerberos Version 4 (Kerberos-IV)

TCP port 750

When configuring Firewall B (or an alternate device between the perimeter network and the corporate network), the network relationship must be defined as routed. Do not define the network relationship as Network Address Translation (NAT).

For more information about security hardening requirements related to trust relationships, see the following resources:

note Note:

The Microsoft Windows Internet Name Service (WINS) and NETBIOS Name Service are not required for Active Directory communication, nor are they required for SharePoint Server 2010. Therefore, you do not need to open TCP/UDP ports 137 and 1512 on your firewall server unless there is a separate need for those services to be available.

Hardening for content publishing

Content publishing requires one-way communication between the Central Administration site on the source server farm and the Central Administration site on the destination server farm. Hardening requirements are:

  • Port number that is used for the Central Administration site on the destination server farm.

  • TCP 80 or 443 outbound from the source farm (for SOAP and HTTP Post).

When you configure content deployment on the source farm, you specify the account to use to authenticate with the destination farm. A trust relationship between domains is not required to publish content from one domain to the other. However, there are the following two account options for deploying content — one of which does require a domain trust relationship:

  • If the application pool account of the source farm has permissions to Central Administration on the destination farm, select the Use application pool account option. This requires a one-way trust relationship in which the domain of the destination farm trusts the domain of the source farm.

  • You can specify an account manually rather than using the source application pool account. In this case, the account does not have to exist in the network domain of the source farm. Typically, the account is unique to the destination farm. The account can authenticate using Integrated Windows authentication or Basic authentication.

Connections to external servers

Several features of SharePoint Server 2010 can be configured to access data that resides on server computers outside the server farm. If you configure access to data on external server computers, ensure that you enable communication between the appropriate computers. In most cases, the ports, protocols, and services that are used depend on the external resource. For example:

  • Connections to file shares use the File and Printer Sharing service.

  • Connections to external SQL Server databases use the default or customized ports for SQL Server communication.

  • Connections to Oracle typically use OLE DB.

  • Connections to Web services use both HTTP and HTTPS.

  • Connections to a Secure Token Service (STS) for claims-based authentication use HTTPS.

The following table lists features that can be configured to access data that resides on servers outside the server farm.

Feature Description

Content crawling

You can configure crawl rules to crawl data that resides on external resources, including Web sites, file shares, Exchange public folders, and business data applications. When crawling external data sources, the crawl server communicates directly with these external resources.

For more information, see Plan for crawling and federation (Search Server 2010).

Receiving Microsoft Excel workbooks

If Excel Services workbooks connect to any external data sources (for example, Analysis Services and SQL Server), appropriate TCP/IP ports need to be opened for connecting to these external data sources. For more information, see Plan Excel Services data sources and external connections (SharePoint Server 2010).

Microsoft Business Connectivity Services

Microsoft Business Connectivity Services in Microsoft SharePoint Server 2010 provide a method of connecting SharePoint solutions to external data. We recommend to use Secure Sockets Layer or Internet Protocol Security (IPSec) between servers running Microsoft SharePoint Server 2010 and external systems. An exception is that you cannot use SSL when transmitting messages to external systems using the SOAP 1.1 protocol or when connecting to a SQL Server database. However, in those cases you can use IPSec to protect the data exchange.

For more information, seeBusiness Connectivity Services security overview (SharePoint Server 2010).

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft