Configuring and Deploying Anonymous Publishing Sites for SharePoint Server 2007

Andrew Connell, Critical Path Training, LLC (Microsoft MVP)

April 2009

Applies to: Microsoft Office SharePoint Server 2007

Summary: Explore and learn how to address security and performance issues of Microsoft Office SharePoint Server 2007 publishing sites before launching them as Internet-facing publishing sites. (8 printed pages)

Contents

• Deploying Anonymous, Internet-Facing SharePoint 2007 Publishing Sites

• Development Issues for Page Size, ActiveX Controls, and Custom Code

• Configuring a SharePoint Site Collection or Site

• Configuring a SharePoint Web Application

• Separating Content Between Authoring and Production Environments

• Conclusion

• Additional Resources

Deploying Anonymous, Internet-Facing SharePoint 2007 Publishing Sites

Microsoft Office SharePoint Server 2007 provides the capability to host content-centric sites, complete with a rich Web content management (WCM) publishing infrastructure on the SharePoint platform. SharePoint publishing sites are commonly used in Internet-facing scenarios for anonymous users and carry additional considerations for the site implementation, configuration, and deployment phases. Security concerns arise because publishing sites are commonly exposed to anonymous users and the surface area of attack is much larger than that of a site that is accessible only to users who are on a trusted corporate network. In addition to addressing these security concerns, you can take additional steps to both harden the servers running Office SharePoint Server and to disable unnecessary services. This article presents some common topics for publishing site implementers to consider before launching an Internet-facing SharePoint Server 2007 publishing site.

Development Issues for Page Size, ActiveX Controls, and Custom Code

Compared to more traditional SharePoint collaboration or internally-facing publishing sites, anonymous Internet-facing publishing sites have different demands placed on them. Internet-facing content sites should be developed to reach the largest audience possible. However, you should consider two things: the size of the combined page, also known as the page payload, and the use of Microsoft ActiveX controls on a page.

Limiting the Page Payload

Usually, SharePoint pages have a large page payload. This is due to historically collaborative and primarily internal network usage scenarios. Unfortunately, this is a negative aspect for sites that should reach the largest audience possible because long download times for pages impede the success of a content-centric site. However, by inspecting the payload of a publishing site by using a tool such as the free Fiddler Web Debugging Proxy, you can see that one file stands out in terms of size: core.js (Figure 1). The core.js file is an ECMAScript (JavaScript, JScript) library that represents 54 KB of the page payload. This file was dynamically compressed by Microsoft Internet Information Services (IIS) from the actual 248 KB core.js file on the server, but it still represents a big file that can be addressed to reduce the overall size of the page payload.

Figure 1. Default publishing portal home page payload inventory

The core.js file contains functionality that not all users need; a significant portion is used to implement the Site Actions menu. As one option, you can suppress core.js from being added to the page if users are not authenticated (and thus, not incur the 54 KB download). The Microsoft Knowledge Base article How to Create a Detached Page That Downloads the Core.js File but That Does Not Reference the Core.js file on a SharePoint Server 2007 Site (KB933823) demonstrates how to create a "lazy loading" core.js file. This means that you change the order of where core.js is found in the markup of the page and, as a result, push the download of the file to much later in the page request. The user still downloads core.js but it happens after the browser retrieves everything it needs to render the page and thus, it happens in the background.

Managing the Name ActiveX Control

Another common requirement of Internet-facing sites is that ActiveX controls are not used. By default, SharePoint sites all include the Name ActiveX Control and, if it is not installed or approved by Internet Explorer (which it is not by default), Internet Explorer displays a message until it is installed or approved. This is shown in Figure 2.

Figure 2. Internet Explorer requesting installation of Name ActiveX control

Message in the Information Bar in Internet Explorer 7 When You Browse to a Windows SharePoint Services 3.0 Site or to a SharePoint Server 2007 Site: "The Web site wants to run the following add-on: 'Name ActiveX Control'" (KB31509) explains a few things you can do on the client computer to prevent this message from appearing. Unfortunately, this is not an ideal scenario because users should not have to configure their desktops or browsers to view a content site. Also, many users may not have privileges to change the registry or the Internet Explorer trusted sites list. The Knowledge Base article also describes a third option that involves changing the ECMAScript files installed by SharePoint Server. Unfortunately, this method is not ideal because it does not always work and it involves changing built-in files that can be overwritten by future hotfixes, service packs, or upgrades.

Another option is to create a custom ECMAScript file that overrides the ECMAScript function that contains a call to the Name ActiveX control, as demonstrated in Randy Drisgill's blog entry, Fixing the name.dll ActiveX Problem the Mossman Way. The ECMAScript file should include a function that overrides the built-in ProcessDefaultOnLoad() function and simply comments out the call to the ProcessImn()function. Add a reference to the new ECMAScript file in the <head> portion of the master page for the site.

Taking Advantage of Custom CAS Policies for Custom Code

SharePoint Server uses Microsoft .NET Framework code access security (CAS) fully for all sites. You use CAS to enforce certain permissions on executing code, regardless of the user the code is running under. By default all SharePoint sites run under a minimal trust (WSS_Minimal), which is the most restrictive policy. Among other things, the WSS_Minimal policy blocks custom code from accessing Web services outside of the current domain, establishing database connections, or interacting with the SharePoint object model. Another policy is provided, WSS_Medium, which allows custom code to establish database connections and interact with the SharePoint object model. A final provided policy, Full, puts no restrictions on custom code.

You change the CAS trust level from WSS_Minimal to WSS_Medium to Full by changing the <trust /> node in the web.config file of the Web application.

However, changing the trust level by using one of the provided policies is not the most secure way to protect a SharePoint site, because the policies provided will apply to all custom code deployed in a Web application, not just a specific assembly. A much more secure approach is to create custom CAS policies for custom components and grant those components only the permissions they require to run. There is no reason to grant a custom assembly rights to establish database connections when all it needs is the ability to call a Web service or touch the SharePoint object model. For information about creating custom CAS policies for custom SharePoint components, see Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 (Part 2 of 2).

Configuring a SharePoint Site Collection or Site

SharePoint Server publishing sites are just like Windows SharePoint Services 3.0 sites. What makes them publishing sites is the activation of a few SharePoint Features that add the required infrastructure and libraries to facilitate a WCM system. However, one aspect of traditional SharePoint sites is present in publishing sites that is not desirable in most implementations, especially those that are accessible by anonymous users. This is described in the following section.

Blocking Users from Seeing All Pages in a SharePoint Publishing Site

All content pages are stored within a special library, Pages, in each publishing site within a site collection. These pages are rendered by using a process unique to the publishing infrastructure that retrieves the item in the Pages library that corresponds to the actual page that is requested. This page tells SharePoint Server which page layout to use to render the page. Because all the page content is in a SharePoint list, savvy users who are granted access to the site, including all anonymous users, can request one of the special SharePoint application pages used to display the contents of the list. For example, users who are granted access to a SharePoint site can see all the items in the Task list of a Blank site by using the following URL: http://[siteurl]/Lists/Tasks/Forms/AllItems.aspx. The AllItems.aspx page displays all the contents of a list.

This means that users who have access to a publishing site could see a list of all the pages within a particular site. Although these users would not see pages they do not have permission to see, site owners usually do not want their site users to see this list. In fact, publishing site owners usually strive to control the complete user experience and prefer that users do not find alternate ways to view the content within a site. Therefore, site owners need a way to block users from seeing these special forms.

SharePoint Server includes a specific permission right that grants users access to these special pages: View Application Pages (see SPBasePermissions Enumeration (Microsoft.SharePoint)). This permission is automatically granted to users, and all anonymous users, by way of the Limited Access permission level. The challenge is that site administrators cannot change this permission level through the browser interface, as shown in Figure 3.

Figure 3. Limited Access permission level and View Application Pages permission

Therefore, Microsoft included the ViewFormPagesLockdown Feature, also known as the "Lockdown Feature", which programmatically removes this permission right from the Limited Access permission level when activated. After it is activated, when users try to navigate to the page, they are presented with an authentication prompt because the current logged-on user, including an anonymous user, does not have rights to that page.

The Publishing Portal site definition automatically activates this permission level for you. However, if you create publishing sites by using a custom permission level, you should activate the ViewFormPagesLockdown Feature to modify the Limited Access permission level.

Enabling and Configuring Caching

One of the greatest advantages publishing sites have over non-publishing sites in SharePoint Server 2007 and in Windows SharePoint Services 3.0 is the configurable and robust caching infrastructure. Caching can significantly improve the performance of a publishing site in two ways:

• By preventing the Microsoft ASP.NET 2.0 page life cycle from spinning up, which keeps the SharePoint front-end Web server from having to execute a page and instead uses previously generated HTML.

• By reducing or eliminating the number of roundtrips to the SharePoint content databases.

By default, most caching is not enabled on a SharePoint publishing site; a site administrator should enable and configure caching before launching a publishing site. Publishing site collection administrators have two types of caching available to them: page output caching and object caching.

For more information about the caching capabilities in publishing sites, see Custom Caching Overview.

Configuring a SharePoint Web Application

SharePoint Web applications have global settings that affect all site collections within the Web applications. If a site collection does not use specific capabilities such as presence, blogs, or incoming e-mail information, these settings should be disabled at the Web application level.

Disabling User Presence Information

A user's presence information is the icon that appears next to their name in SharePoint sites and indicates whether they are online or not. For anonymous Internet-facing sites, presence information is generally not used and therefore should be disabled (in Central Administration, click Application Management, and then click Web Application General Settings).

Figure 4. User presence settings

Disabling the Blog API

From a security perspective, if a publishing site does not use blogs, the blog API should be disabled (in Central Administration, click Application Management, and then click Web Application General Settings). This reduces the surface area that can be attacked on the production server. In addition, if a publishing site uses content deployment, the read-only production environment should have the blog API disabled because all content authoring should occur in the authoring environment.

Figure 5. Blog API settings

Disabling Incoming E-Mail

Production publishing sites generally do not use the incoming e-mail capabilities that SharePoint Server provides. Servers running SharePoint Server 2007 can be configured to monitor e-mail mailboxes and to store messages in SharePoint lists. Because this capability is not commonly used in publishing sites, as addressed in the previous topics, you should reduce the surface area of attack and so disable incoming e-mail messages (in Central Administration, click Operations, and then click Incoming E-Mail Settings).

Figure 6. Disabling incoming e-mail settings

Separating Content Between Authoring and Production Environments

Many large WCM sites have a business requirement to physically separate the authoring environment where content on the site is created and managed from the production environment that contains only approved and published content, is read-only, and is highly secure. SharePoint publishing sites facilitate this architecture through a capability called content deployment. Content deployment jobs run at scheduled intervals in the authoring environment, collect all new and changed content that is published and approved, deploy it to the target production environment, and commit the changes.

You can implement content deployment jobs in two ways:

• Using connected servers: the two environments (authoring and production) are physically connected or accessible over the wire.

• Using disconnected servers: the two environments are not connected or accessible over the wire, such as in a hardened co-location facility.

Configuring content deployment in a connected model is supported through the Web interface in the SharePoint farm's Central Administration site. When configuring content deployment, administrators have various options in the server and path configuration. If a publishing site architecture is designed to deploy content to a read-only environment outside of a trusted network (such as over the Internet or WAN to a co-location facility), the connection should be encrypted via HTTPS instead of using HTTP. HTTPS is the default setting and should always be used when deploying content outside of a trusted network.

When creating a content deployment path that defines the source and target site collections, administrators can choose to deploy the security information to the target system. There are two deployment options for this: deploying user names and deploying security information. When you deploy content to a public, Internet-facing environment, do not deploy user names or security information (such as access control lists, roles, and role membership). These options are available to administrators when creating a new content deployment path (in Central Administration, click Operations, and then click Content Deployment Paths and Jobs).

If the two servers that are running Central Administration for each farm are not connected or accessible to each other, the built-in Central Administration user interface, which is designed for connected farms, will not work. For disconnected farms, developers must write custom code to handle the export and import process between the two farms. For more information about this scenario, see How to: Customize Deployment for Disconnected Scenarios.

Finally, if content deployment is being used in a project, all SharePoint servers in the farm should be updated to the latest service pack and patch level. The Infrastructure Update for Windows SharePoint Services 3.0 (KB951695) and Infrastructure Update for Microsoft Office Servers (KB951297) should be installed on all servers in the farm after Windows SharePoint Services 3.0 Service Pack 1 (SP1) (KB936988) and The 2007 Microsoft Office Servers Service Pack 1 (SP1) (KB936984) are installed. These post–Service Pack 1 infrastructure updates include many fixes and performance improvements that are specific to content deployment and the underlying architecture that content deployment is built on.

If your publishing site implementation does not take advantage of content deployment, as a security measure you should verify that the production environment is not accepting incoming jobs. This is the first option on the Content Deployment Settings page (in Central Administration, click Operations, and then click Content Deployment Settings).

For more information about content deployment, see How to: Deploy Content Between Servers.

Conclusion

This article addresses many areas related to the performance, tuning, and securing of an Internet-facing Microsoft Office SharePoint Server 2007 publishing site. Office SharePoint Server 2007 publishing sites are commonly used for Internet-facing scenarios. An Internet-facing site has requirements that are different from those of a site that is internally facing. In general, internally-facing sites do not have as heavy a load on them because the total number of site users is much easier to anticipate. Usually, this is a percentage of the total employees in a company who would hit the site at any given time. Internet-facing sites require additional considerations because their potential users, who are usually anonymous, can vary as a result of many different factors. Therefore, an Internet-facing publishing site and the servers that host it must be configured and tuned accordingly. Because an Internet-facing site is available to a large number of unknown users, the site and servers must also be hardened and secured to help prevent them from being tampered with or compromised.

Additional Resources

For more information, see the following resources:

• Web Content Management Resource Center for SharePoint Server

• How to Optimize a SharePoint Server 2007 Web Content Management Site for Performance

• Additional Performance and Capacity Planning Factors (Office SharePoint Server)

• Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 (Part 2 of 2)

• Randy Drisgill's Blog: Fixing the name.dll ActiveX Problem the Mossman Way

• Infrastructure Update for Windows SharePoint Services 3.0 (KB951695)

• Infrastructure Update for Microsoft Office Servers (KB951297)

• Office Developer Center