Share via

Plan security for an external anonymous access environment (Office SharePoint Server)

  • Article

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-11-14

In this article:

  • Protect back-end servers

  • Configure anonymous access

  • Secure the Central Administration site

  • Secure content deployment by using SSL

  • Disable incoming e-mail

  • Use lockdown mode

  • Secure design checklist

  • Plan security hardening for server roles

  • Plan secure configurations for Office SharePoint Server features

Security guidance for an external anonymous access environment is targeted to allow anonymous access to content while protecting back-end servers in the farm from direct user access or malicious actions targeted through front-end Web servers. In an environment where multiple farms might be deployed to support authoring, staging, and publishing, the guidance for this environment is intended for the published farm (the farm that is anonymously accessed by users).

There are several unique recommendations for an external anonymous access environment. Some of these recommendations might not be practical for all solutions.

Protect back-end servers

Hosting sites for anonymous use requires Internet-facing servers. You can limit the exposure to traffic from the Internet by protecting back-end servers, including the index server and other application server roles and servers that host databases:

  • Protecting database servers   At a minimum, place a firewall between front-end Web servers and servers that host databases. Some environments dictate that database servers be hosted in an internal network instead of directly in an extranet environment.

  • Protect application servers   At a minimum, protect application servers by requiring Internet Protocol security (IPsec) to secure communication between server farm computers. Additionally, you can place application servers behind the firewall used to protect database servers. Or, you can introduce an additional firewall between front-end Web servers and application servers.

  • Protect the index role   The index component communicates through a front-end Web server to crawl content in sites. To protect this communication channel, consider configuring a dedicated front-end Web server for use by one or more index servers. This isolates crawling communication to a front-end Web server that is not accessible to users. Additionally, configure Internet Information Services (IIS) to restrict SiteData.asmx (the crawler SOAP service) to allow only the index server (or other crawlers) to access it. Providing a front-end Web server dedicated to content crawling also improves performance by reducing the load on the main front-end Web servers, thereby improving the user experience.

Configure anonymous access

For content to be available for anonymous access, the following must be configured:

  • The site or site collection must be configured to allow anonymous access.

  • At least one zone in the Web application must be configured to allow anonymous access.

Enable anonymous access only for Web applications that require unauthenticated access. If you want to use authentication for personalization, implement forms authentication by using a simple database authentication provider.

Secure the Central Administration site

Because external users have access to the network zone, it is important to secure the Central Administration site to block external access and secure internal access:

  • Ensure that the Central Administration site is not hosted on a front-end Web server.

  • Block external access to the Central Administration site. This can be achieved by placing a firewall between front-end Web servers and the server that hosts the Central Administration site.

  • Configure the Central Administration site by using Secure Sockets Layer (SSL). This ensures that communication from the internal network to the Central Administration site is secured.

Secure content deployment

If you are not using the content deployment feature, disable the server farm from receiving content deployments (under Content Deployment Settings, select Reject incoming content deployment jobs). This is the default setting.

If you are using content deployment features to deploy content from one server farm to another server farm, ensure that the Central Administration site for the receiving server farm is configured to use SSL. This will ensure that server communication related to content deployment between the two server farms is secured by using SSL.

Additionally, to protect the identities of your authors, disable the Deploy user names setting when you configure the content deployment path.

Disable incoming e-mail

Do not use e-mail integration for incoming e-mail. This protects your environment from risks associated with e-mail sent from anonymous sources on the Internet. If you do allow incoming e-mail, configure the Central Administration site to enable anonymous e-mail. While this option is available, it is not very secure.

Use lockdown mode

Lockdown mode is a feature that you can use to secure published sites. When lockdown mode is turned on, fine-grain permissions for the limited access permission level are reduced. The following table details the default permissions of the limited access permission level and the reduced permissions when lockdown mode is turned on.

Permission Limited access — default Limited access — lockdown mode

List permissions: View Application Pages

●

Site permissions: Browse User Information

●

●

Site permissions: Use Remote Interfaces

●

Site permissions: Use Client Integration Features

●

●

Site permissions: Open

●

●

Lockdown mode is applied to sites under the following circumstances:

  • The Stsadm.exe command-line tool is used to turn lockdown mode on.

  • The Publishing Portal site template is applied to the site collection. By default, lockdown mode is turned on when this template is applied.

Consider using lockdown mode on published sites if greater security on these sites is a requirement. Additionally, if you applied the Publishing Portal site template, determine if lockdown mode is the desired configuration for these sites. If not, use the Stsadm.exe command-line tool to turn off lockdown mode.

The following table lists the Stsadm commands related to using lockdown mode.

Action Command

Turn on lockdown mode for a site collection

stsadm -o activatefeature -url <site collection url> -filename ViewFormPagesLockDown\feature.xml

Turn off lockdown mode for a site collection

stsadm -o deactivatefeature -url <site collection url> -filename ViewFormPagesLockDown\feature.xml

Secure design checklist

Use this design checklist together with the checklists in Review the secure topology design checklists (Office SharePoint Server).

Topology

[ ]

Protect back-end servers by placing at least one firewall between front-end Web servers and the application and database servers.

[ ]

Plan a dedicated front-end Web server for crawling content. Do not include this front-end Web server in the end-user front-end Web rotation.

Logical architecture

[ ]

Enable anonymous access only for Web application zones that host sites or site collections that are configured to allow anonymous access.

For more information, see Plan authentication methods (Office SharePoint Server).

[ ]

Use SSL to secure content deployment.

[ ]

Block access to the Central Administration site and configure SSL for the site.

Plan security hardening for server roles

The following table describes additional hardening recommendations for an external anonymous access environment.

Component Recommendation

Ports

Block external access to the port for the Central Administration site.

Protocols

  • Disable SMTP.

  • Use SSL to secure content as it is deployed from the authoring farm to the staging and published farms.

IIS

If you are configuring a dedicated front-end Web server for indexing, configure IIS to restrict SiteData.asmx (the crawler SOAP service) to allow only the index server (or other crawlers) to access it.

Plan secure configurations for Office SharePoint Server features

The following table describes additional recommendations for securing Microsoft Office SharePoint Server 2007 features in an external anonymous access environment.

Feature or area Recommendation

Authentication

Specify Anonymous authentication in IIS.

Content deployment

If you are not using the content deployment feature, disable the server farm from receiving content deployments. This is the default setting.

If you are using the content deployment feature, the following configurations are recommended:

  • Turn on SSL for the Central Administrator site on the receiving server farm.

  • Disable the Deploy user names setting when you configure the content deployment path.

E-mail integration

Do not enable e-mail integration for incoming mail.

Content caching of pages that have personalized content

Output caching can be used to optimize performance for sites that display some personalized content. In this scenario, post-cache substitution is used to ensure that the personalized content is refreshed for the user. Consequently, if the entire page or most of the page includes personalized content, there is little benefit received by using output caching.

If you are using output caching on pages that have personalized content, be aware of the security implications resulting from how this is configured. If the following conditions are true, ensure that sites that display personalized content support post-cache substitution:

  • You plan to enable page output caching (to optimize performance).

  • Both anonymous and authenticated users are accessing content.

  • Your solution includes sites that have controls that display personalized content (for authenticated users).

In this scenario, anonymous users all see identical content. The content that authenticated users see depends on whether personalized content is displayed and if post-cache substitution is supported for this content:

  • If post-cache substitution is supported for personalized content, authenticated users who have the same rights can view only their own personalized content.

  • If post-cache substitution is not supported for personalized content, users who have the same rights as each other will also see identical content. In this scenario, if personalized content is first cached for user A, all subsequent users who have the same rights will see user A's personalized content instead of their own.

InfoPath Forms Server

In an anonymous environment, disable the InfoPath Forms Services Web service proxy. This service runs as a trusted service account and forwards requests to Web services by using the identity of the trusted service account.

In environments where InfoPath forms are accessed only by authenticated users, access to a back-end data system is protected by authentication. However, if subsequent InfoPath forms are created for use by anonymous users and these forms access the same back-end data system, the back-end data system is configured to trust the Web service proxy and provide the requested data. In this case, it is possible for anonymous users to access data that is typically only available to authenticated users.

By default, the Web service proxy is disabled. You manage this service in Central Administration. On the Application Management tab, look in the InfoPath Forms Services category and click Manage the Web service proxy.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

See the full list of available books at Downloadable content for Office SharePoint Server 2007