Security Recmommendations for MOSS 2007 Features

• Do not use client-side automatic logon when using the Central Administration site.
• Allow only front-end Web server computers to perform authentication of users. Do not allow end-user accounts or groups to authenticate against the database server computer.

• Configure Office SharePoint Server 2007 to accept only e-mail that has been relayed through a dedicated mail server, such as Microsoft Exchange Server, which filters out viruses and unsolicited commercial e-mail, and authenticates the mail sender.
• When configuring workflow settings, Office SharePoint Server 2007 allows you to enable participants who do not have permissions to access a document on a site to receive the document as an e-mail attachment instead. In a secure environment, do not select the Allow external users to participate in workflow by sending them a copy of the document option. In Office SharePoint Server 2007, this option is not selected, by default.

• Ensure that you deploy only trusted code to your server farm. All code, XML, or ASP.NET code that you deploy should be from a trusted source, even if you intend to tighten security after deployment with defense-in-depth measures such as code access security.
• Ensure that the SafeControl list in the Web.config file contains the set of controls and Web Parts that you want to allow.
• Ensure that custom Web Parts that you plan to reinforce with defense-in-depth measures are installed into the bin directory of the Web application (where partial trust is turned on), with specific permissions for each assembly.
• Consider removing the Content Editor Web Part from the SafeControl list. This prevents users from adding JavaScript into the page as a Web Part and using JavaScript that is hosted on external servers.
• Ensure that appropriate people in your organization are granted the Design and Contribute permission levels in your site. A user with the Contribute permission level can upload Active Server Page Extension (ASPX) pages to a library and add Web Parts. Users with the Design permission level, who are allowed to add Web Parts, can modify pages, including the home page on your site (Default.aspx).

• The Default content access account must not be a member of the Farm Administrators group; otherwise, the Office SharePoint Server Search service indexes unpublished versions of documents.
• Ensure that additional IFilters and word breakers that you deploy are trusted by your IT team.
• By default, the search index file is accessible only by members of the Farm Administrators group. Ensure that this file is not accessible to users who do not belong to this group.

• People who have the Read permission level can view all My Sites. By default, all authenticated users are granted the Read permission level. For a more secure environment, grant only the necessary groups the Read permission level. You can grant individual groups the Read permission level in the Default Reader Site Group section on the My Site Settings page in the Shared Services Administration Web site. To specify the actions that members of a group can perform, on the Shared Services Administration home page, click Personalization services permissions settings, select the group whose permissions you want to change, and then click Modify Permissions of Selected Users.
• Shared Services Providers (SSPs) can be configured to trust other SSPs in an environment. This trust allows an SSP to determine to which SSP a user belongs. Consequently, when a user creates a My Site, trusted SSPs can determine which SSP should host the My Site, regardless of where the user is browsing when they click the link to create a My Site. This ensures that users have only one My Site in the organization. Also, when users add links to their personal site, trusted SSPs will create the link from the context of the user’s SSP, rather than the SSP the user is currently browsing. Trusted SSPs also ensure that links are not added to nontrusted locations. For a more secure environment, ensure that the Trusted My Site Hosts Locations lists are uniformly managed across all SSPs. Ideally, configure the lists the same for all SSPs.

Whether you should enable self-service site creation depends on the environment:

• Intranet environment Enable self-service site creation according to business need.
• Secure collaboration environment Enable self-service site creation only for people or groups who have a business need for this feature.
• External anonymous environment Do not enable self-service site creation on the Internet.

• In a secure intranet, do not approve links to sites outside the corporate firewall.
• By default, anyone who has the Contributor permission level can submit sites for approval. This is not recommended for large intranet sites and for public-facing sites. For these sites, limit the number of people who can submit sites by reducing the number of people to whom you grant the Contributor permission level or by allowing only site directory administrators to submit sites.

If you plan to enable output caching on pages with personalized content, ensure that sites that display personalized content support post-cache substitution if the following conditions apply:

• Both anonymous and authenticated users are accessing content.
• Your solution includes sites with 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 substation is supported for this content:

• If post-cache substitution is supported for personalized content, authenticated users with the same permissions can view only their own personalized content.
• If post-cache substitution is not supported for personalized content, users with the same permissions will also see identical content. For example, if personalized content is first cached for user A, all subsequent users with the same permissions will see user A’s personalized content instead of their own.

• If enabled, the InfoPath Forms Services Web service proxy should run under a unique application pool account. Disable the proxy if not used.
• Review all form templates that contain code before uploading to the server computer. For more information, see Deploy administrator-approved form templates (Office SharePoint Server).
• In browser-only scenarios, use the access control lists (ACLs) in Office SharePoint Server 2007 to prevent the XSN from being downloaded by users.
• Carefully consider whether to allow user form templates to be browser-enabled.
• Carefully consider whether to allow browser rendering of user form templates.
• Use the configurable thresholds to mitigate denial-of-service attacks. User sessions are terminated based on thresholds, including:
  • Maximum number of postbacks allowed per form session state.
  • Maximum number of actions allowed per postback.
  • Maximum size of form session state.
  • Maximum time that a form session can be active.
• Carefully use features in browser-enabled forms. The following features can cause form XML to increase significantly in size, which might increase the risk of denial-of-service attacks:
  • Digital signatures
  • File attachment control
  • Rich-text control
  • Data connection queries that could return large result sets

• Leave Content Approval turned on in data connection libraries, and ensure that only trusted users have content approval rights.
• Protect server-only authentication information by using the AltDataSource attribute in the universal data connection (UDC) file and by giving users only the View permission on the server UDC file, or by setting webAccessible to false in the administrator-managed connection library (Manage Data Connection Files).
• Review and monitor the use of cross-domain data connections to ensure that only appropriate data is moving into and out of the domain.
• By default, user form templates rendered in a browser cannot use server-only authentication. In a secure environment, limit the use of server-only authentication, such as single sign-on (SSO) or explicit user name and password authentication.
• Do not use explicit user names and passwords in UDC files except for prototyping on a test server computer. Use SSO instead.
• Do not use embedded SQL Server credentials in a database connection string. Use SSO instead.
• Use the Web Service proxy only with a Web service designed to use the supplied UserNameToken to authorize access to the data or to limit the data set that is returned.
• Require a Secure Sockets Layer (SSL) connection when connecting to data sources that require basic or digest authentication, because credentials are passed insecurely over the network.
• Do not authenticate users based on data entered into a form by the user. Instead, use a more secure method of authentication.

• Trusted subsystem The default setting for a Windows server farm, because it does not have the extra configuration requirements of the delegation model. In the trusted subsystem model, front-end Web servers and application servers running Excel Calculation Services trust the accounts of the associated Office SharePoint Server 2007 applications by using the SSP. In a trusted subsystem environment, when opening files from Office SharePoint Server 2007, permission checks on the files can be performed against end-user identities even if Kerberos authentication is not configured. If Excel Calculation Services application servers are opening workbooks from Universal Naming Convention (UNC) shared folders or HTTP Web sites, the user account cannot be impersonated, and the process account must be used.
• Constrained Kerberos delegation Constrained Kerberos delegation is the preferred configuration for deploying Excel Services. Constrained Kerberos delegation is the most secure configuration for communication between front-end Web servers and Excel Calculation Services application servers. Constrained Kerberos delegation is also the most secure configuration for accessing back-end data sources from application servers. For external data connections, Integrated Windows authentication will only work if the delegation model is implemented.

If you decide to require encrypted data transmission, you must manually configure IPsec or SSL. You can require encrypted connections between client computers and front-end Web servers while allowing unencrypted connections between front-end Web servers and Excel Calculation Services application servers.”