Download.microsoft.com
[pic]
Planning and architecture for Windows SharePoint Services 3.0 technology, part 2
Microsoft Corporation
Published: April 2009
Author: Microsoft Office Systems and Server Team (o12ITdx@)
Abstract
This guide describes the planning activities that are necessary to successfully deploy Windows SharePoint Services 3.0 to a server computer or server farm. The audiences for this guide include information architects, IT generalists, and program managers who are planning to host Windows SharePoint Services 3.0 sites.
The content in this book is a copy of selected content in the Windows SharePoint Services technical library () as of the publication date. For the most current content, see the technical library on the Web.
[pic]
Copyright
Topic Last Modified: 2009-04-09
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred.
© 2009 Microsoft Corporation. All rights reserved.
Microsoft, Access, Active Directory, Excel, Groove, InfoPath, Internet Explorer, OneNote, Outlook, PowerPoint, SharePoint, SQL Server, Visio, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Contents
Planning and architecture for Windows SharePoint Services 3.0 technology, part 2 1
Copyright 1
I. Plan for system requirements 1
Determine hardware and software requirements (Windows SharePoint Services) 1
About hardware and software requirements 1
Stand-alone installation 1
Database 1
Operating system 1
Windows components 1
Microsoft .NET Framework 3.0 1
Server farm installation 1
Hardware requirements 1
Software requirements 1
Plan browser support (Windows SharePoint Services) 1
About browser support 1
Levels of browser support 1
Feature-specific compatibility listed by Web browser 1
II. Design server farms and topologies 1
Design server farms and topologies (Windows SharePoint Services) 1
Plan for redundancy (Windows SharePoint Services) 1
About redundancy 1
Define server redundancy requirements 1
Plan for a limited server deployment 1
Plan for a minimum level of server redundancy 1
Choosing a baseline server farm topology 1
Plan front-end Web server redundancy 1
Plan search server redundancy 1
Plan database server redundancy 1
Select a baseline topology 1
Design extranet farm topology (Windows SharePoint Services) 1
About extranet environments 1
Planning for extranet environments 1
Edge firewall topology 1
Back-to-back perimeter topology 1
Split back-to-back topology 1
III. Design logical architecture 1
Design logical architecture (Windows SharePoint Services) 1
Logical architecture components (Windows SharePoint Services) 1
Server farms 1
Application pools 1
Web applications 1
Zones 1
Configuration requirements of the Default zone 1
Configuring zones for an extranet environment 1
Policy for a Web application 1
Content databases 1
Site collections 1
Sites 1
Host-named site collections 1
Logical architecture sample design: collaboration sites 1
About the model 1
Overall design goals 1
Server farms 1
Users, zones, and authentication 1
Users and authentication 1
Zones 1
Administration sites 1
Application pools 1
Web applications 1
Site collections 1
Content databases 1
Zones and URLs 1
Designing load-balanced URLs 1
Using explicit and wildcard inclusions for URL paths 1
Zone policies 1
Backing up and restoring collaboration sites 1
Designing for secure external collaboration 1
Design logical architecture for collaboration sites (Windows SharePoint Services) 1
Team sites design recommendations 1
Host team sites in a dedicated Web application 1
Plan Web application general settings 1
Plan site creation method 1
Design content database settings for team sites 1
Automatically delete sites that are not used 1
Use paths or host names to organize team site URLs 1
Plan for custom elements 1
Plan the permissions to apply to team sites 1
Plan alternate access mappings (Windows SharePoint Services) 1
About alternate access mappings 1
Reverse proxy publishing 1
Alternate access mapping integration with authentication providers 1
Alternate access mapping integration with Web application policies 1
Alternate access mapping and external resource mapping 1
Troubleshooting alternate access mappings 1
Fully Qualified Domain Name (FQDN) 1
Localhost 1
IP addresses 1
Plan for host-named site collections (Windows SharePoint Services) 1
About host-named site collections 1
Create a host-named site collection 1
Apply host headers 1
Configure a host-named site collection 1
Expose host-named sites over HTTP and HTTPS 1
White paper: Create shared hosting solutions on Windows SharePoint Services 1
Update a Web application URL and IIS bindings (Windows SharePoint Services) 1
About updating a Web application URL and IIS bindings 1
Unextending and re-extending a Web application 1
Additional steps for updating a Web application URL and IIS bindings 1
IV. Plan for authentication (Windows SharePoint Services) 1
Plan for authentication (Windows SharePoint Services) 1
Plan authentication methods (Windows SharePoint Services) 1
About authentication 1
Supported authentication methods 1
Configure authentication 1
Plan authentication for crawling content 1
Choose methods of authentication allowed in your environment 1
Worksheet 1
Plan authentication settings for Web applications (Windows SharePoint Services) 1
Plan authentication settings 1
Plan authentication exclusions 1
Worksheet 1
Authentication samples (Windows SharePoint Services) 1
SQL membership provider 1
Active Directory membership provider 1
Web SSO with AD FS 1
Plan for and design security 1
Plan for and design security (Windows SharePoint Services) 1
Choose your security environment (Windows SharePoint Services) 1
Internal team or department 1
Internal IT-hosted 1
External secure collaboration 1
External anonymous access 1
Plan server farm security (Windows SharePoint Services) 1
Review the secure topology design checklists (Windows SharePoint Services) 1
Server topology design checklist 1
Networking topology design checklist 1
Logical architecture design checklist 1
Operating system design checklist 1
Plan for secure communication within a server farm (Windows SharePoint Services) 1
Plan server-to-server communication 1
Scenarios to consider for SSL 1
Plan client-server communication 1
Plan for using SSL 1
Plan security hardening for server roles within a server farm (Windows SharePoint Services) 1
About security hardening 1
Application server recommendations 1
Secure communication with the Microsoft SQL Server database 1
Configure SQL Server 1
Configure Windows Firewall 1
Configure a SQL client alias 1
File and Printer Sharing service requirements 1
Service requirements for e-mail integration 1
Windows SharePoint Services services 1
Accounts and groups 1
Web.config file 1
Secure snapshot additions 1
Plan security hardening for extranet environments (Windows SharePoint Services) 1
Network topology 1
Domain trust relationships 1
Communication with server-farm roles 1
Communication with infrastructure server roles 1
Active Directory communication between network domains 1
Plan secure configurations for Windows SharePoint Services features 1
Recommendations for Windows SharePoint Services features 1
Plan environment-specific security (Windows SharePoint Services) 1
Plan security for an internal team or department environment (Windows SharePoint Services) 1
Secure design checklist 1
Topology 1
Logical architecture 1
Plan security hardening for server roles 1
Plan secure configurations for Windows SharePoint Services features 1
Plan security for an internal IT-hosted environment (Windows SharePoint Services) 1
Secure design checklist 1
Logical architecture 1
Plan security hardening for server roles 1
Plan secure configurations for Windows SharePoint Services features 1
Plan security for an external secure collaboration environment (Windows SharePoint Services) 1
Protect back-end servers 1
Secure client-server communication 1
Secure the Central Administration site 1
Secure design checklist 1
Topology 1
Logical architecture 1
Plan security hardening for server roles 1
Plan secure configurations for Windows SharePoint Services features 1
Plan security for an external anonymous access environment (Windows SharePoint Services) 1
Protect back-end servers 1
Configure anonymous access 1
Secure the Central Administration site 1
Disable incoming e-mail 1
Secure design checklist 1
Topology 1
Logical architecture 1
Plan security hardening for server roles 1
Plan secure configurations for Windows SharePoint Services features 1
Plan for security roles (Windows SharePoint Services) 1
Farm-level administration 1
Site-level administration 1
Worksheet 1
Plan for administrative and service accounts (Windows SharePoint Services) 1
About administrative and service accounts 1
Single server standard requirements 1
Server farm requirements 1
Least-privilege administration requirements when using domain user accounts 1
Least-privilege administration requirements when using SQL authentication 1
Least-privilege administration requirements when connecting to pre-created databases 1
Technical reference: Account requirements by scenario 1
VI. Plan for performance and capacity 1
Plan for performance and capacity (Windows SharePoint Services) 1
About performance and capacity planning (Windows SharePoint Services) 1
Planning for capacity vs. availability 1
64-bit vs. 32-bit 1
Performance and capacity planning approach 1
Performance and capacity planning process 1
Plan for software boundaries (Windows SharePoint Services) 1
Test environment 1
Test results 1
Guidelines for acceptable performance 1
Estimate performance and capacity requirements (Windows SharePoint Services) 1
Windows SharePoint Services collaboration environments 1
Key characteristics 1
Test environment 1
Usage profile 1
Recommendations 1
Capacity and performance of scaled-out topologies 1
Estimate throughput targets 1
Database server disk space requirements 1
Search server disk space requirements 1
Web server disk space requirements 1
Web server 1
Database server 1
Additional performance and capacity planning factors (Windows SharePoint Services) 1
Environmental factors 1
Tools for performance and capacity planning (Windows SharePoint Services) 1
About the Windows SharePoint Services test data load tool 1
Constructing a Windows SharePoint Services test data load configuration file 1
Deleting SharePoint test data 1
VII. Plan for data protection and recovery 1
Plan for data protection and recovery (Windows SharePoint Services) 1
Data protection and recovery features in Windows SharePoint Services 1
Additional data protection and recovery tools 1
Service level agreements 1
Data protection and recovery strategy 1
Plan for versioning (Windows SharePoint Services) 1
Content versioning 1
Site versioning 1
Plan for capturing and storing deleted objects (Windows SharePoint Services) 1
Planning to use the Recycle Bin 1
Planning to capture and recover deleted sites 1
Plan for backup and recovery (Windows SharePoint Services) 1
Disaster recovery 1
Migrating data 1
Choose what to protect (Windows SharePoint Services) 1
Protecting content databases 1
Protecting content stored in external data sources 1
Protecting search 1
Protecting configuration settings 1
Protecting customizations 1
Protecting binary files 1
Choose backup and recovery tools (Windows SharePoint Services) 1
Available tools 1
Built-in backup and recovery tools 1
Performance 1
Recovering the configuration database and Central Administration content database 1
External backup and recovery tools 1
Third-party solutions and custom tools 1
Recommendations for data protection and recovery (Windows SharePoint Services) 1
Protecting and recovering data for a site (Windows SharePoint Services) 1
Versioning 1
Deletion protection 1
Backup and recovery 1
Protecting and recovering data stored in InfoPath form templates (Windows SharePoint Services) 1
Versioning 1
Deletion protection 1
Backup and recovery 1
Protecting and recovering data when working with software updates (Windows SharePoint Services) 1
Back up search 1
Back up databases 1
After backing up, and before you apply a software update 1
Using database backups after a software update 1
Protecting and recovering data in a non-production environment (Windows SharePoint Services) 1
Development environment 1
VIII. Additional Resources 1
White paper: Intel Performance Testing of Windows SharePoint Services 1
I. Plan for system requirements
Determine hardware and software requirements (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
In this article:
• About hardware and software requirements
• Stand-alone installation
• Server farm installation
This article describes the hardware and software requirements for installing Windows SharePoint Services 3.0.
About hardware and software requirements
An installation of Windows SharePoint Services 3.0 can range from a single computer (stand-alone installation) to many computers (server farm). The requirements for your installation will depend on the availability and scale requirements for your solution. This article describes the minimum and recommended hardware requirements based on whether you are deploying a stand-alone installation or a server farm. This article also lists the software prerequisites for installing Windows SharePoint Services 3.0.
This article does not provide guidance about choosing a farm topology or hardware based on availability requirements or performance and capacity requirements. For more information about designing your solution to address these requirements, see Plan for performance and capacity (Windows SharePoint Services).
The hardware and software requirements described in this article apply to both x32-bit–based and x64-bit–based systems. However, if you installed the 64-bit version of Windows Server 2008 and then modified the Enable32bitAppOnWin64 registry key so that Internet Information Server (IIS) is running in 32-bit emulation mode, you cannot install Windows SharePoint Services 3.0. To install either 32-bit or 64-bit Windows SharePoint Services 3.0 you must run IIS in 64-bit mode.
[pic] Note:
Itanium-based systems are not supported.
Using a mix of 32-bit servers and 64-bit servers in a server farm is supported. However, this scenario is not recommended because of the potential performance issues that could occur. For example:
• With a clustered front-end Web server that uses round robin, the 32-bit server will be the bottleneck.
• If a 64-bit front-end Web server is making calls to a 32-bit SQL Server database, there may be a bottleneck if SQL Server does not have adequate resources. This also applies to a 64-bit indexer that is working against a 32-bit SQL Server database.
If circumstances require a heterogeneous server architecture, we recommend that you use homogeneous (32-bit or 64-bit) servers on each application tier, for example, 32-bit servers for all the front-end Web servers.
If server farm performance in a heterogeneous environment becomes an issue, the recommended solution is to migrate all of the SharePoint farm servers to the 64-bit architecture. We highly recommend that you have a migration plan in place to move to a 64-bit only environment as soon as possible. Our support and test data shows that SharePoint products and technologies that are installed on 64-bit servers have significant gains in system throughput and performance during peak loads.
[pic] Note:
While migrating 32-bit servers to 64-bit servers there will be times during the migration process that you cannot maintain homogenous servers on each tier. However, performance issues will only occur during the migration process.
Stand-alone installation
You can install Windows SharePoint Services 3.0 on a single computer by using either of the following methods:
• By selecting Basic.
• By selecting Advanced, and then selecting Stand-alone in Windows SharePoint Services 3.0 Setup.
Hardware requirements
The following table lists the minimum and recommended hardware requirements for deploying Windows SharePoint Services 3.0, including the deployment of Windows Internal Database, for a stand-alone installation.
|Component |Minimum |Recommended |
|Processor |2.5 gigahertz (GHz) |Dual processors that are each 3 GHz or faster|
|RAM |1 gigabyte (GB) |2 GB |
|Disk |NTFS file system–formatted partition with a |NTFS file system–formatted partition with |
| |minimum of 3 GB of free space |3 GB of free space plus adequate free space |
| | |for your Web sites |
|Drive |DVD drive |DVD drive or the source copied to a local or |
| | |network-accessible drive |
|Display |1024 × 768 |1024 × 768 or higher resolution monitor |
|Network |56 kilobits per second (Kbps) connection |56 Kbps or faster connection between client |
| |between client computers and server |computers and server |
Software requirements
The Windows SharePoint Services 3.0 installation and configuration wizard marshals many components. If you uninstall Windows SharePoint Services 3.0, and then later install Windows SharePoint Services 3.0 on the same computer, the Setup program could fail when creating the configuration database, which would cause the entire installation process to fail. You can prevent this failure by deleting the existing configuration database or by using the psconfig command to create a new configuration database.
Database
When you perform a Basic installation, Windows Internal Database is automatically installed. When you perform an Advanced installation on a stand-alone computer that already has Microsoft SQL Server installed, ensure that the computer meets the hardware and software requirements for a database server. For more information, see Database server later in this article.
[pic] Note:
If you are installing Windows SharePoint Services 3.0 with Service Pack 1 (SP1) on Windows Server 2008, setup installs Windows Internal Database with Service Pack 2 (SP2).
Because of Windows licensing restrictions, if you are using Windows Server 2003, Web Edition in a single server environment, you can only perform an Advanced, front-end Web server installation. This is because the full SQL Server editions cannot be installed on Windows Server 2003, Web Edition. In this scenario, you need to have a full SQL Server edition installed on a compatible edition of Windows Server 2003 for use with Windows SharePoint Services 3.0. Windows Server 2003, Web edition does not support Basic installation of Windows SharePoint Services 3.0.
Operating system
The initial release of Product Short Name 2007 runs on Windows Server 2003 with SP1. We recommend that you apply all critical updates. You can use the following Windows Server 2003 editions:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Because of Windows licensing restrictions, if you are using Windows Server 2003, Web Edition in a single server environment, you can only perform an Advanced, front-end Web server installation. This is because the full SQL Server editions cannot be installed on Windows Server 2003, Web Edition. In this scenario, you need to have a full SQL Server edition installed on a compatible edition of Windows Server 2003 for use with Windows SharePoint Services 3.0. Windows Server 2003, Web edition does not support Basic installation of Windows SharePoint Services 3.0.
Windows SharePoint Services 3.0 administration functions require Microsoft Internet Explorer 6.0 with the most recent service packs, Internet Explorer 7.0, or Internet Explorer 8.0.
[pic] Important:
Windows SharePoint Services 3.0 requires Active Directory directory services for farm deployments. Therefore Windows SharePoint Services 3.0 cannot be installed in a farm on a Windows NT 4.0 domain.
The following are updates to supported operating systems since the initial release of Windows SharePoint Services 3.0:
• SP1 - Windows SharePoint Services 3.0 with Service Pack 1 (SP1) is supported on Windows Server 2008. As with the Windows Server 2003 operating system, you must download and run Setup and the SharePoint Products and Technologies Configuration Wizard. You cannot install Windows SharePoint Services 3.0 on Windows Server 2008 without also installing service packs for Windows SharePoint Services 3.0.
• SP2 – Windows SharePoint Services 3.0 with Service Pack 2 (SP2) is supported on Windows Server 2008 R2 with Service Pack 1 (SP1). You must create a slipstreamed installation source for Windows SharePoint Services 3.0. This installation source must include the files from Windows SharePoint Services 3.0 with SP1. For more information about how to use the updates folder to create a slipstreamed source, see Create an installation source that includes software updates (Windows SharePoint Services 3.0).
• SP3 - Windows SharePoint Services 3.0 with Service Pack 3 (SP3) is supported on Windows Server 2008 R2 with Service Pack 1 (SP1). However, you must create a slipstreamed installation source for Windows SharePoint Services 3.0. This installation source must include the files from Windows SharePoint Services 3.0 with Service Pack 2 (SP2). For more information about how to use the updates folder to create a slipstreamed source, see Create an installation source that includes software updates (Windows SharePoint Services 3.0).
Windows components
After you have installed the operating system and applied all critical updates, you must configure the computer to be a Web server by enabling Internet Information Services (IIS) 6.0, including:
• Common files
• WWW
• Simple Mail Transfer Protocol (SMTP)
You must configure the server to use IIS 6.0 worker process isolation mode. This is the default setting in new installations. However, if you have upgraded from IIS 5.0 on Windows Server 2000, Run WWW in IIS 5.0 isolation mode is enabled, and you must change this setting to use IIS 6.0 worker process isolation mode.
[pic] Note:
You must have IIS 7.0 installed to install Windows SharePoint Services 3.0 with SP1 on Windows Server 2008. Windows SharePoint Services 3.0 does not support IIS 7.0 shared configuration.
To enable e-mail notifications, you need to configure incoming and outgoing e-mail settings. To configure sending e-mail alerts and notifications, you must specify an SMTP e-mail server. To configure your installation so that your SharePoint sites can accept and archive incoming e-mail, you must install the IIS SMTP service.
[pic] Important:
The following components are required for Windows SharePoint Services 3.0 to run correctly: the Web Server role, the Microsoft .NET Framework version 3.0, and Windows Internal Database. Do not uninstall them, or Windows SharePoint Services 3.0 will cease to run.
Microsoft .NET Framework 3.0
Before installing Windows SharePoint Services 3.0, you must install the Microsoft .NET Framework 3.0 and then ensure that 2.0 is enabled.
[pic] Note:
You can also use the Microsoft .NET Framework version 3.5. You can download the .NET Framework version 3.5 from the Microsoft Web site ().
To enable v2.0.50727, open the Web service extension in the IIS snap-in on the Microsoft Management Console (MMC). If 2.0 is installed on the computer before IIS is enabled, you must enable 2.0 by running the command aspnet_regiis -i.
Server farm installation
The primary difference between a single server and a server farm topology is that you can use one or more computers to host the following server roles:
• Front-end Web server
• Database server
This section describes the minimum and recommended system requirements for each server role. If you install more than one role on a single computer, ensure that the computer meets the minimum requirements for all server roles.
Front-end Web server
Hardware requirements
The following table lists the minimum and recommended hardware requirements for deploying a Windows SharePoint Services 3.0 front-end Web server.
|Component |Minimum |Recommended |
|Processor |2.5 GHz |Dual processors that are each 3 GHz or faster|
|RAM |2 GB |More than 2 GB |
|Disk |NTFS file system–formatted partition with a |NTFS file system–formatted partition with |
| |minimum of 3 GB of free space |3 GB of free space plus adequate free space |
| | |for your data storage requirements |
|Drive |DVD drive |DVD drive or the source copied to a local or |
| | |network-accessible drive |
|Display |1024 × 768 |1024 × 768 or higher resolution monitor |
|Network |56 Kbps connection between client computers |56 Kbps or faster connection between client |
| |and server |computers and server |
| |For connections between computers in your |For connections between computers in your |
| |server farm, 100 Mbps connection |server farm, 1 Gbps connection |
Software requirements
We recommend that you perform the installation on a computer that has a new installation of the Microsoft Windows Server 2003 operating system with Service Pack 1 (SP1) or later and all critical updates.
Operating system
Windows SharePoint Services 3.0 runs on Windows Server 2003 with SP1 or later. We recommend that you apply all critical updates. You can use the following Windows Server 2003 editions:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Because of Windows licensing restrictions, if you are using Windows Server 2003, Web Edition in a single server environment, you can only perform an Advanced, front-end Web server installation. This is because the full SQL Server editions cannot be installed on Windows Server 2003, Web Edition. In this scenario, you need to have a full SQL Server edition installed on a compatible edition of Windows Server 2003 for use with Windows SharePoint Services 3.0. Windows Server 2003, Web edition does not support Basic installation of Windows SharePoint Services 3.0.
Windows SharePoint Services 3.0 administration functions require Microsoft Internet Explorer 6.0 with the most recent service packs, Internet Explorer 7.0, or Internet Explorer 8.0.
As of Windows SharePoint Services 3.0 with SP1, you can now install Windows SharePoint Services 3.0 on Windows Server 2008. As with the Windows Server 2003 operating system, you must download and run Setup and the SharePoint Products and Technologies Configuration Wizard. You cannot install Windows SharePoint Services 3.0 without service packs on Windows Server 2008.
Windows components
After you have installed the operating system and applied all critical updates, you must configure the computer to be a Web server by enabling IIS 6.0, including:
• Common files
• WWW
• SMTP
You must configure the server to use IIS 6.0 worker process isolation mode. This is the default setting in new installations. However, if you have upgraded from IIS 5.0 on Windows Server 2000, Run WWW in IIS 5.0 isolation mode is enabled, and you must change this setting to use IIS 6.0 worker process isolation mode.
[pic] Note:
You must have IIS 7.0 installed to install Windows SharePoint Services 3.0 with SP1 on Windows Server 2008. Windows SharePoint Services 3.0 does not support IIS 7.0 shared configuration.
To enable e-mail notifications, you need to configure incoming and outgoing e-mail settings. To configure sending e-mail alerts and notifications, you must specify an SMTP e-mail server. To configure your installation so that your SharePoint sites can accept and archive incoming e-mail, you must install the IIS SMTP service.
[pic] Important:
The following components are required for Windows SharePoint Services 3.0 to run correctly: the Web Server role and the Microsoft .NET Framework version 3.0. Do not uninstall them, or Windows SharePoint Services 3.0 will cease to run.
Microsoft .NET Framework 3.0
Before installing Windows SharePoint Services 3.0, you must install the Microsoft .NET Framework 3.0 and then ensure that 2.0 is enabled.
[pic] Note:
You can also use the Microsoft .NET Framework version 3.5. You can download the .NET Framework version 3.5 from the Microsoft Web site ().
To enable v2.0.50727, open the Web service extension in the IIS snap-in on the MMC. If 2.0 is installed on the computer before IIS is enabled, you must enable 2.0 by running the command aspnet_regiis -i.
Database server
The computer that hosts the database server role must have SQL Server 2000 with the latest service pack or Microsoft SQL Server 2005 SP1 or later. Some advanced features require SQL Server 2005 Analysis Services SP1 or later.
[pic] Important:
You must update SQL Server 2000 to the latest service pack, which is SQL Server 2000 Service Pack 4. For more information, see Microsoft SQL Server 2000 Service Pack 4 ().
[pic] Note:
We recommend that you install SQL Server 2005 SP2 before upgrading to Windows SharePoint Services 3.0.
[pic] Note:
Windows SharePoint Services 3.0 supports SQL Server 2008. However, you must install Windows SharePoint Services 3.0 SP1 or later in order to use SQL Server 2008. Windows SharePoint Services 3.0 also supports SQL Server 2008 R2. Ensure that you have installed Windows SharePoint Services 3.0 with Service Pack 2 (SP2) or later.
[pic] Important:
Windows SharePoint Services 3.0 does not support SQL Server 2012 or later versions of SQL Server.
For information about the hardware and software required to deploy a database server, see SQL Server 2005 System Requirements ().
Because of Windows licensing restrictions, if you are using Windows Server 2003, Web Edition in a single server environment, you can only perform an Advanced, front-end Web server installation. This is because the full SQL Server editions cannot be installed on Windows Server 2003, Web Edition. In this scenario, you need to have a full SQL Server edition installed on a compatible edition of Windows Server 2003 for use with Windows SharePoint Services 3.0. Windows Server 2003, Web edition does not support Basic installation of Windows SharePoint Services 3.0.
Plan browser support (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
Windows SharePoint Services 3.0 is compatible with commonly used browsers. Supported functionality, however, varies among browsers.
In this article:
• About browser support
• Levels of browser support
• Feature-specific compatibility list by Web browser
About browser support
Windows SharePoint Services 3.0 supports several Web browsers that are commonly used. However, there are certain browsers that might cause some Windows SharePoint Services 3.0 functionality to be downgraded, limited, or available only through alternative steps. In some cases, functionality might be unavailable for noncritical administrative tasks.
As part of planning your deployment of Windows SharePoint Services 3.0, we recommend that you review the browsers used in your organization to ensure optimal performance with Windows SharePoint Services 3.0.
Levels of browser support
Web browser support is divided into two levels: level 1 and level 2. Although administrative tasks on SharePoint sites are optimized for level 1 browsers, Windows SharePoint Services 3.0 also provides support for other browsers that are commonly used. To ensure that you have complete access to all the functionality, we recommend that you use a level 1 browser for administrative tasks.
Level 1 Web browsers
Level 1 Web browsers take advantage of advanced features provided by ActiveX controls and provide the most complete user experience. Level 1 browsers offer full functionality on all SharePoint sites, including the SharePoint Central Administration Web site.
Level 1 Web browsers for Windows SharePoint Services 3.0 with SP2 are as follows:
• Windows Internet Explorer 6.x (32-bit)
• Windows Internet Explorer 7.x (32-bit)
• Windows Internet Explorer 8.x (32-bit) (includes running in compatibility mode)
• Windows Internet Explorer 9.x (32-bit) (includes running in compatibility mode)
Level 1 Web browsers for Windows SharePoint Services 3.0 original release and Service Pack 1 (SP1) are as follows:
• Internet Explorer 6.x (32-bit)
• Internet Explorer 7.x (32-bit)
[pic] Note:
Level 1 browser support is only available for computers running the Windows operating system.
Level 2 Web browsers
Level 2 Web browsers provide basic functionality so that users can both read and write in SharePoint sites and perform site administration. However, ActiveX controls are supported only in level 1 browsers. In addition, there are functionality differences between different browsers. As a result, there might be a user experience that is different from that in level 1 browsers.
Level 2 Web browsers for Windows SharePoint Services 3.0 with SP2 are listed in the following table.
|Browser |Windows |Linux/Unix |Macintosh OSX Leopard |
|Internet Explorer 7.x (64-bit) |X | | |
|Internet Explorer 8.x (64-bit) |X | | |
|Internet Explorer 9.x (64-bit) |X | | |
|Firefox 3.x |X |X |X |
|Safari 3.x | | |X |
Level 2 Web browsers for Windows SharePoint Services 3.0 original release and Service Pack 1 (SP1) are listed in the following table.
|Browser |Windows |Linux/Unix |Macintosh OSX |
|Firefox 1.5 |X |X |X |
|Mozilla 1.7 |X | | |
|Netscape Navigator 7.2 | |X | |
|Netscape Navigator 8.1 |X | | |
|Safari 2.0 | | |X |
If a browser is not listed in either level 1 or level 2, it is not supported. For example, older browsers — such as Internet Explorer 5.01, Internet Explorer 5.5x, Internet Explorer for Macintosh, and versions of third-party Web browsers that are earlier than the ones listed as level 2 browsers — are not supported.
Feature-specific compatibility listed by Web browser
The following table lists more specific feature compatibilities by browser for Windows SharePoint Services 3.0 with Service Pack 2 (SP2). The compatibility is listed as either completely compatible (Y) or not compatible (N). Detailed notes for some entries are provided immediately following the table.
|Feature |Internet Explorer 7.x (64-bit) |
|External partners |External partners can participate in business processes and |
| |collaborate with employees of your organization. You can use an |
| |extranet to help enhance the security of data in the following ways: |
| |Apply appropriate security and user-interface components to isolate |
| |partners and to segregate internal data. |
| |Authorize partners to use only sites and data that are necessary for |
| |their contributions. |
| |Restrict partners from viewing other partners’ data. |
| |You can optimize processes and sites for partner collaboration in the|
| |following ways: |
| |Enable employees of your organization and partner employees to view, |
| |change, add, and delete content to promote successful results for |
| |both companies. |
| |Configure alerts to notify users when content changes or to start a |
| |workflow. |
|Customers |Makes sites available to customers: |
| |Provide anonymous access to information about your business. |
| |Allow clients to log on and participate in a workflow. |
Windows SharePoint Services 3.0 provides flexible options for configuring extranet access to sites. You can provide Internet-facing access to a subset of sites on a server farm or make all content on a server farm accessible from the Internet. You can host extranet content inside your corporate network and make it available through an edge firewall, or you can isolate the server farm inside a perimeter network.
Planning for extranet environments
The rest of this article discusses specific extranet topologies that have been tested with Windows SharePoint Services 3.0. The topologies that are discussed in this article can help you to understand the options that are available with Windows SharePoint Services 3.0, including requirements and tradeoffs.
The following sections highlight additional planning activities for an extranet environment.
Plan network edge technology
In each topology, the network edge technology illustrated is one or both of the following products from the Microsoft Forefront Edge suite of products: Microsoft Internet Security and Acceleration (ISA) Server and Intelligent Application Gateway (IAG) 2007. For more information about these Microsoft Forefront Edge products, see the following resources:
• ISA Server home page ()
• Network Concepts in ISA Server 2006 ()
• Intelligent Application Gateway home page
• Intelligent Application Gateway 2007 technical library
[pic] Note:
You can substitute a different network edge technology.
IAG Server provides these additional features:
• Information leakage prevention: No residues are left on the client computer, and all cache, temporary files, and cookies are deleted.
• Endpoint, health-based authorization: Administrators can define an access policy that is based not only on the identity of the user and the information that is exposed but also on the condition of the client computer.
• Access SharePoint sites from Outlook Web Access: Users can access SharePoint sites from links sent in e-mail through Outlook Web Access. IAG provides the link translation for links that refer to internal URLs.
• Unified portal: Upon logon, IAG presents to each user the list of SharePoint sites and other applications that are available and authorized for that user.
The following table summarizes the difference between the servers.
|Capability |ISA 2006 |IAG 2007 |
|Publish Web applications using HTTPS |X |X |
|Publish internal mobile applications to |X |X |
|roaming mobile devices | | |
|Layer 3 firewall |X |X* |
|Outbound scenarios support |X |X* |
|Array support |X | |
|Globalization and administration console |X | |
|localization | | |
|Wizards and predefined settings to publish |X |X |
|SharePoint sites and Exchange | | |
|Wizards and predefined settings to publish | |X |
|various applications | | |
|Active Directory Federation Services (ADFS) | |X |
|support | | |
|Rich authentication (for example, one-time |X |X |
|password, forms-based, smart card) | | |
|Application protection (Web application |Basic |Full |
|firewall) | | |
|Endpoint health detection | |X |
|Information leakage prevention | |X |
|Granular access policy | |X |
|Unified Portal | |X |
* Supported by ISA, which is included with IAG 2007.
Plan for authentication and logical architecture
In addition to choosing or designing an extranet topology, you will need to design an authentication strategy and logical architecture to enable access to the intended users outside the internal network and to secure sites and content on the server farm. For more information, see the following articles:
• Plan for authentication (Windows SharePoint Services)
• Logical architecture sample design: collaboration sites
Plan domain trust relationships
When the server farm is located inside a perimeter network, this network requires its own Active Directory directory service infrastructure and domain. Typically, a perimeter domain and a corporate domain are not configured to trust each other. However, if you configure a one-way trust, in which the perimeter domain trusts the corporate domain, you can use Windows authentication to authenticate both internal and remote employees by using corporate domain credentials. Another option is to authenticate employees using forms authentication or Web single sign-on (SSO). You can also use these methods to authenticate against an internal domain directory service.
The following table summarizes these authentication options and indicates whether a trust relationship is required.
|Scenario |Description |
|Windows authentication |If the perimeter domain trusts the corporate network domain, you can |
| |authenticate both internal and remote employees by using their |
| |corporate domain credentials. |
|Forms authentication and Web SSO |You can use forms authentication and Web SSO to authenticate both |
| |internal employees and remote employees against an internal Active |
| |Directory environment. For example you can use Web SSO to connect to |
| |Active Directory Federation Services (ADFS). Using forms |
| |authentication or Web SSO does not require a trust relationship |
| |between domains. |
| |However, several features of Windows SharePoint Services 3.0 might |
| |not available, depending on the authentication provider. For more |
| |information about features that might be affected when forms |
| |authentication or Web SSO is used, see Plan authentication settings |
| |for Web applications (Windows SharePoint Services). |
For more information about configuring a one-way trust relationship in an extranet environment, see Plan security hardening for extranet environments (Windows SharePoint Services).
Plan for availability
The extranet topologies described in this article are intended to illustrate:
• Where a server farm is located within an overall network.
• Where each of the server roles is located within an extranet environment.
This article is not intended to help you plan which server roles you need to deploy or how many servers for each role you need to deploy to achieve redundancy. After you determine how many server farms are required for your environment, use the following article to plan the topology for each server farm: Plan for redundancy (Windows SharePoint Services).
Plan for security hardening
After you have designed your extranet topology, use the following resources to plan for security hardening:
• Plan security hardening for server roles within a server farm (Windows SharePoint Services)
• Plan security hardening for extranet environments (Windows SharePoint Services)
Edge firewall topology
This configuration uses a reverse proxy server on the border between the Internet and the corporate network to intercept and then forward requests to the appropriate Web server located in the intranet. 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. The following illustration shows an edge firewall topology.
[pic]
Advantages
• Simplest solution that requires the least amount of hardware and configuration.
• Entire server farm is located within the corporate network.
• Single point of data:
• Data is located within the trusted network.
• Data maintenance occurs in one place.
• Single farm used for both internal and external requests ensures that all authorized users view the same content.
• Internal user requests are not passed through a proxy server.
Disadvantages
• Results in a single firewall that separates the corporate internal network from the Internet.
Back-to-back perimeter topology
A back-to-back perimeter topology isolates the server farm in a separate perimeter network, as shown in the following illustration.
[pic] This topology has the following characteristics:
• 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 server or routed through the public interface of 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.
• By using a separate Active Directory infrastructure, external user accounts can be created without affecting the internal corporate directory.
Disadvantages
• Requires additional network infrastructure and configuration.
Split back-to-back topology
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. Search servers can be hosted in either the perimeter network or the corporate network.
[pic] In the preceding illustration:
• The search server is hosted inside the perimeter network. This option is illustrated by the blue server inside the dashed line.
• Search servers can optionally be deployed inside the corporate network, with the database servers. This option is illustrated by the gray server inside the dashed line. If you deploy search servers inside the corporate network with the database servers, you must also have an Active Directory environment to support these servers (illustrated as gray servers inside the corporate network).
If the server farm is split between the perimeter network and the corporate network with the database servers located inside the corporate network, a domain trust relationship is required if Windows accounts are used to access SQL Server. In this scenario, the perimeter domain must trust the corporate domain. If SQL authentication is used, a domain trust relationship is not required. For more information about configuring accounts for this topology, see "Domain trust relationships" in the following article: Plan security hardening for extranet environments (Windows SharePoint Services).
To optimize search performance and crawling, place the search server role inside the corporate network with the database servers. You can also add the Web server role to a search server inside the corporate network and configure this Web server for dedicated use by the search role for content crawling. If you place Web servers in the perimeter network and the search role inside the corporate network, you must configure a one-way trust relationship in which the perimeter network domain trusts the corporate network domain. This one-way trust relationship is required in this scenario to support inter-server communication within the farm, regardless of whether you are using Windows authentication or SQL authentication to access SQL Server.
Advantages
Advantages of the split back-to-back topology include the following:
• Computers running SQL Server are not hosted inside the perimeter network.
• Farm components both within the corporate network and the perimeter network can share the same databases.
• With a separate Active Directory infrastructure, external user accounts can be created without affecting the internal corporate directory.
Disadvantages
• 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 typically split across two domains.
III. Design logical architecture
Design logical architecture (Windows SharePoint Services)
Topic Last Modified: 2009-04-15
Logical architecture is the manner in which logical components of a solution are organized and integrated. In Windows SharePoint Services 3.0, the logical components include Internet Information Services (IIS) application pools, Web applications, zones, policy for Web applications, content databases, site collections, sites, and host-named site collections.
Currently in this chapter:
• Logical architecture components (Windows SharePoint Services) introduces each of the logical architecture components and discusses the following considerations for each component: capacity, sharing and isolation, configurable items, administration, and planning recommendations.
• Plan alternate access mappings (Windows SharePoint Services) provides information about configuring Windows SharePoint Services 3.0 to map Web requests to the correct Web applications and sites. It describes how to implement alternate access mappings for common Internet deployment scenarios in which a Web application that receives a request for an internal URL, in one of the five authentication zones, returns pages that contain links to the public URL for the zone.
• Plan for host-named site collections (Windows SharePoint Services) provides information about creating host-named site collections to provide a scalable hosting solution with distinct host names for each site collection.
• White paper: Create shared hosting solutions on Windows SharePoint Services provides information about using Windows SharePoint Services 3.0 to host sites. It explains different recommended hardware architecture solutions, security and authentication issues, ways to add sites and users, and how to configure search.
• Update a Web application URL and IIS bindings (Windows SharePoint Services) provides guidance for changing the URL and IIS bindings of a Web application.
Logical architecture components (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
In this article:
• Server farms
• IIS application pools
• Web applications
• Zones
• Policy for Web applications
• Content databases
• Site collections
• Sites
• Host-named site collections
There are a variety of ways you can arrange the components in a logical architecture design. Each of the components presents different opportunities for sharing and isolation. Before you begin your logical architecture design:
• Know what your sharing and isolation goals are.
• Evaluate the tradeoffs for each choice.
Each section in this article describes a particular logical architecture component and discusses the following considerations for that component: capacity, sharing and isolation, configurable items, administration, and planning recommendations.
Server farms
Technically, server farms are not a logical architecture component. However, a server farm represents the top-level element of a design. Individual server farms provide physical isolation.
Several criteria that are determined by your organization might affect the number of server farms that are required, including:
• Separate operational divisions of responsibility.
• Dedicated funding sources.
• Separate datacenter locations.
• Industry requirements for physical isolation between sites.
However, you can satisfy many isolation requirements on a single server farm. For example, you can use different Internet Information Services (IIS) application pools with different process identities to achieve isolation at the process level. You can also use separate Web applications to achieve isolation at the Web application level.
In addition to isolation requirements that might require more than one server farm, an organization might implement multiple server farms to satisfy performance and scale goals.
Application pools
An application pool is a grouping of one or more URLs (or Web sites as they are represented in IIS) served by a worker process. Each application pool has its own worker process and identity (security account) which prevents two processes from interacting.
Capacity
The memory overhead of an application pool is 30-50 megabytes (MB) plus any memory for the applications running in the application pool process space. The limit for the number of application pools is influenced by the available memory on the system. That is, the number of application pools is dictated by the following two factors:
• Available addressable memory.
• The size of the application running in the application pool.
The general guideline for acceptable performance is to use eight or fewer application pools.
Sharing and isolation
IIS application pools provide a way for multiple sites to run on the same server computer but still have their own worker processes and identity. This can help to prevent an exploit on one site which enables the attacker to inject malicious code that can attack sites in different application pools.
Configurable items
Use a separate application pool identity for each application pool.
Administration
Administration includes maintaining separate application pool identities for each application pool.
Planning recommendations
Practically speaking, consider using a dedicated application pool for each of the following reasons:
• To separate authenticated content from anonymous content.
• To isolate applications that store passwords for and interact with external business applications.
• To isolate applications with which users have great liberty to create and administer sites and to collaborate on content.
Web applications
A Web application is an IIS Web site that is created and used by SharePoint Products and Technologies. Each Web application is represented by a different Web site in IIS. You assign each Web application a unique domain name, which helps to prevent cross-site scripting attacks.
Capacity
Each page generates a separate dynamic-link library (DLL) for each Web application. The separate DLLs consume memory, limiting the number of Web applications that can run on a server. The guideline for acceptable performance is to implement 99 or fewer Web applications.
Sharing and isolation
Galleries and templates are registered in the configuration database for the server farm. You can specify which Web applications can use these.
Each Web application has a unique domain name, which helps to prevent cross-site scripting attacks.
Configurable items
The following table lists configurable items that contribute to isolation and sharing.
|Item |Description |
|Zones |Within a Web application, you can create up to five zones. Use zones |
| |to enforce different access and policy conditions for large classes |
| |of users. |
|Policy for Web application |Create an "All Zones" policy to enforce a policy condition that |
| |applies across all zones in the Web application. |
Administration
Ongoing administration of Web applications is not significant.
Planning recommendations
Generally speaking, use dedicated Web applications to:
• Separate content available to anonymous users from content available to authenticated users.
• Isolate users. For example, you can ensure that partners do not have access to intranet content by placing partner sites in a separate Web application.
• Enforce permissions. A dedicated Web application provides the opportunity to enforce permissions by policies by using the Policy for Web Application page in Central Administration. For example, you can create a policy to explicitly deny write access to one or more groups of users. Policies for a Web application are enforced regardless of permissions configured on individual sites or documents within the Web application.
• Optimize database performance. Applications achieve better performance if they are placed in Web applications with other applications of similar data characteristics. For example, the data characteristics of My Sites typically include a large number of sites that are small in size. In contrast, team sites typically encompass a smaller number of very large sites. By placing these two different types of sites in separate Web applications, the resulting databases are composed of data with similar characteristics, which optimizes database performance.
• Optimize manageability. Because creating separate Web applications results in separate sites and databases, you can implement different limits for each site's Recycle Bin, expiration, and size, and negotiate different service-level agreements. For example, you might allow more time to restore sites that are not critical to your business.
Zones
Zones represent different logical paths (URLs) of gaining access to the same Web application. Within each Web application, you can create up to five zones using one of the available zone names: Default, Intranet, Internet, Custom, or Extranet. Each zone is represented by a different Web site in IIS.
The Default zone is the zone that is first created when a Web application is created.
Capacity
You can create up to five zones within a Web application. A farm that hosts more than one Web application can support user requests from more than five different network zones. Typically, zones are coordinated across Web applications so that zones of the same name are configured for the same users.
Sharing and isolation
Zones provide a method of partitioning users by:
• Authentication type Each zone can be configured to use a different authentication provider, enabling you to share the same content across partner companies.
• Network zone Each zone can be configured to accommodate users entering from a different network zone, such as an extranet or the Internet.
• Policy permissions You can explicitly allow or deny read or write access to content per zone based on a user account or a group account.
Configurable items
The following table lists configurable items that contribute to isolation and sharing.
|Item |Description |
|Authentication provider |Each zone can be configured to use a different authentication |
| |provider. |
|Secure Sockets Layer (SSL) |Turn SSL on or off per zone. |
|Load-balanced URL and alternate access mapping |Specify the domain name users will type to access content in the Web |
| |application. Alternatively, use alternate access mapping to map |
| |user-friendly or zone-appropriate URLs to the default URL (server |
| |name and port) for each zone. Alternate access mapping provides |
| |support for off-box termination of SSL. Off-box termination of SSL is|
| |when a proxy server terminates an SSL request and then forwards the |
| |request to a Web server by using HTTP. In this case, alternate access|
| |mappings can be configured to return these requests using SSL, thus |
| |maintaining secure communication between the client and the proxy |
| |server. |
|Policy for Web application |Create a unique set of policies for each zone within the Web |
| |application. If you have a special group of users that require |
| |exceptions to your overall security policy, consider using a separate|
| |zone to accommodate these users. |
Administration
If you use alternate access mapping, consider that all public URLs require Domain Name System (DNS) entries to map the public URLs to the IP address of the load balancer used for the farm.
Planning recommendations
When you design zones, several key decisions are critical to the success of the deployment. These decisions include design and configuration decisions for the following zones:
• The Default zone
• Zones for external access
The following sections describe some of the planning recommendations and requirements for zones.
Configuration requirements of the Default zone
The zone that involves the greatest consideration is the Default zone. The following requirements apply to how the Default zone is configured:
• The Default zone must be the most secure zone. This is because when a user request cannot be associated with a zone, the authentication and policies of the Default zone are applied.
• The index component requires access to content through at least one zone to crawl content. By default, the index component uses NTLM authentication. The search service administrator can configure crawl rules to use either basic authentication or a client certificate when crawling a particular range of URLs. Consequently, to crawl content, at least one of the zones must be configured to use NTLM authentication, basic authentication, or certificates. Also, the crawler will poll zones in the following order until it encounters a zone that it can authenticate through: Default zone, Intranet zone, Internet zone, Custom zone, Extranet zone. However, if the crawler first encounters a zone that is configured to use Kerberos authentication, the crawler will not authenticate and will not attempt to access the next zone. Therefore, ensure that the configuration of zones using Kerberos authentication does not prevent the index component from crawling content. For more information about authentication requirements related to crawling content, see Plan authentication methods (Windows SharePoint Services).
• Administrative e-mail is sent with links from the Default zone. This includes e-mail to owners of sites that are approaching quota limits. Consequently, users who receive administrative e-mail messages and alerts must be able to access links through the Default zone. This is especially important for site owners.
• Host-named site collections are only available through the Default zone. All users who are intended to access host-named site collections must have access through the Default zone.
Configuring zones for an extranet environment
In an extranet environment, the design of zones is critical for two reasons:
• User requests can be initiated from several different networks, such as the internal network, a partner company network, or the Internet.
• Users consume content across multiple Web applications. For example, an intranet environment might include sites that are hosted in several different Web applications. Additionally, employees might have access to both the intranet content and to partner collaboration content.
In an extranet environment, ensure that the following design principles are followed:
• Configure zones across multiple Web applications to mirror each other. The configuration of authentication and the intended users should be the same. However, the policies associated with zones can differ across Web applications. For example, ensure that the Intranet zone is used for the same employees across all Web applications. In other words, do not configure the Intranet zone for internal employees in one Web application and remote employees in another.
• Configure alternate access mappings appropriately and accurately for each zone and each resource.
Policy for a Web application
A policy for a Web application enforces permissions on all content within a Web application, enabling you to set security policy for users at the Web application level. The permissions in a policy override all other security settings that are configured for sites and content.
You can configure policy based on users, or user groups, but not SharePoint groups. A policy can be defined for the Web application in general or just for a specific zone.
Capacity
There are no capacity restrictions that apply to policies for Web applications.
Sharing and isolation
A policy for a Web application provides a method of setting permissions based on users and the zone that they access content through.
For example, by using a policy, you can:
• Allow Help desk staff access to all content.
• Deny write access to partners or vendors.
• Deny access to secure data to a class of users regardless of how site owners configure permissions.
• Ensure that the crawl account has access to crawl all content.
Configurable items
The following table lists configurable items that contribute to isolation and sharing.
|Item |Description |
|Zone |Apply a policy to a specific zone within the Web application — for |
| |example, the Intranet zone — or to all zones within the Web |
| |application. |
|Users |Specify users to whom to apply the policy by using one of the |
| |following: |
| |User accounts |
| |Group accounts |
| |E-mail addresses |
|Permissions |Choose the permissions that you want to enforce for the users: |
| |Full control |
| |Full read |
| |Deny write |
| |Deny all |
| |These permissions override any permissions assigned within the Web |
| |application, including permissions set for site collections, sites, |
| |lists, documents, and so on. |
Administration
Ongoing administration of policies for Web applications is not significant.
Planning recommendations
Because policies are managed centrally, consider using policies to manage large classes of users, rather than individual users.
Content databases
By default, all content for a Web application is stored in one content database. You can separate content into multiple content databases at the site collection level. A content database can include one or more site collections. A single site collection cannot span multiple databases. Backing up and restoring sites takes place at the content database level.
Capacity
The guideline for acceptable performance is to implement 99 or fewer content databases per Web application.
Sharing and isolation
Planning for databases enables you to either optimize for efficiency (multiple site collections sharing a database) or isolation (one database per site collection).
Achieve scale efficiency by managing databases to the maximum target size. In this case, you configure database settings to add new site collections to existing databases until the maximum number of site collections has been reached. You calculate the maximum number of site collections by estimating the average or maximum size of site collections divided into the maximum size target for the database. This approach works well when you expect a large number of small site collections, such as My Sites.
Achieve isolation of content between teams or projects by limiting a database to one site collection. This approach enables you to independently manage the content of individual teams. For example, you can independently manage each team's database for backup, recovery, and migration. This approach provides the opportunity to implement different service-level agreements for different teams or projects. This approach also enables you to manage content to the life cycle of a project. For example, you can archive a database when a project is completed.
Configurable items
The following table lists configurable items that contribute to isolation and sharing.
|Item |Description |
|Database server |Specify which SQL Server computer a content database is created on. |
|Search server |Associate a search server with each content database. |
|Capacity settings |Maximum number of sites that can be created in each database. |
| |Number of sites that can be created before a warning event is |
| |generated. |
Administration
A manageable database administration plan balances the number of databases with the resources required to manage the databases.
Administration of databases includes:
• Creating new databases for new team sites or site collections that require dedicated databases.
• Monitoring database sizes and creating new databases when size targets are approached.
• Backing up and restoring databases.
Planning recommendations
Choose one of the following two approaches:
• Establish target sizes for content databases with appropriate size-warning thresholds. Create new databases when size-warning thresholds are reached. With this approach, site collections are automatically added to the available database or databases, based on size targets alone.
• Associate site collections with specific content databases. This approach enables you to place one or more site collections in a dedicated database that can be managed independently from other databases.
If you want to associate site collections to specific content databases, you can use the following methods to accomplish this:
• Use the Stsadm command-line tool to create a site collection in a specific database.
• Dedicate a database to a single site collection by applying the following database capacity settings on the Manage Content Database Settings page on the SharePoint Central Administration Web site:
• Number of sites before a warning event is generated = 1
• Maximum number of sites that can be created in this database = 1
• Add a group of site collections to a dedicated database by performing the following steps:
• Within the Web application, create the database, and then on the Manage Content Database Settings page in Central Administration, set the database status to Ready.
• Set the status of all other databases to Offline. While content databases are offline, new site collections cannot be created. However, existing site collections in offline databases are still accessible for both read and write operations.
• Create the site collections. They are automatically added to the database.
• Set the status of all other databases back to Ready.
Site collections
A site collection is a set of Web sites that have the same owner and share administration settings. Each site collection contains a top-level Web site and can contain one or more subsites.
Capacity
The recommended guideline for acceptable performance is to implement fewer than 50,000 site collections per Web application. Scaling out by distributing site collections across multiple database servers provides additional storage capacity and throughput.
Sharing and isolation
Site collections introduce several sharing and isolation opportunities that affect permissions, navigation, and feature deployment.
The following items can be shared within a site collection and cannot be shared across site collections:
• Master pages
• Page layouts
• Images
• Site templates
Additionally, permissions and navigation are isolated at the site collection level in the following ways:
• Subsites within a site collection can inherit permissions from the top-level site.
• Site collections cannot inherit permissions from other site collections.
• There is no built-in navigation from one site collection to another.
Finally, Windows SharePoint Services 3.0 search provides search results only within a single site collection. Windows SharePoint Services 3.0 search does not include results across multiple site collections.
It is important to note that although permissions are enforced on individual sites, the sites are still vulnerable to cross-site scripting attacks from other sites within the domain.
Configurable items
The following table lists configurable items in Central Administration that contribute to isolation and sharing.
|Item |Description |
|Site collection administrator |You can specify one user to be the primary site collection |
| |administrator and one user to be the secondary site collection |
| |administrator. In Central Administration, you cannot enter more than |
| |one account for these roles, nor can you enter a group account for |
| |these roles. |
|Quota template |You can apply a quota template to limit resources used for a site |
| |collection. The following templates are provided: |
| |Personal Site (100 MB) |
| |Team Sites (2,000 MB) |
The following table lists configurable items within a site collection that contribute to isolation and sharing.
|Item |Description |
|Site collection administrators |You can specify multiple user accounts to be site collection |
| |administrators. You cannot add group accounts. |
|Permission level |Add user and group accounts to site collections and specify |
| |permission levels for each. |
Administration
Site collection creation does not require DNS entries and can be easily automated or delegated to users. You can create site collections for your team sites centrally, or you can allow users to create their own site collections by using Self-Service Site Management. Assigning a site collection to a single database provides the ability to perform backup and recovery at the site collection level.
Planning recommendations
Site collections bridge logical architecture and information architecture. When you design your site collections, consider the following two design tasks:
• Design consistent URLs across your organization.
• Create logical divisions of content.
Unless you are using host-named site collections, each Web application must have a single root-level site collection. This provides a single URL path into the sites that reside in the Web application. This is also a requirement if you are implementing multiple zones within a Web application.
Many organizations plan to implement multiple site collections within a Web application for use by different teams or divisions within the organization. Common design goals include the following:
• Maintain a separate and independent site collection for each team.
• Create a unique URL for each team.
To satisfy these goals, you can use managed paths to incorporate multiple top-level site collections within a Web application. By defining managed paths, you can specify which paths in the URL namespace of a Web application are used for site collections. You can specify that one site collection or more than one site collection exists at a distinct path below the root site. Without managed paths, all sites created below the root site collection are part of the root site collection.
You can create the following two types of managed paths:
• Explicit inclusion A site collection with the explicit URL that you assign. An explicit inclusion is applied to only one site collection. You can associate each of these site collections with a different content database if you want to manage growth and to provide the opportunity to back up and restore these sites separately. An example URL for a site collection created by using this method is . The limit on site collections created with an explicit inclusion is approximately 100 site collections. If your organization requires a greater number of site collections, use a wildcard inclusion instead.
• Wildcard inclusion A path that is added to the URL. This path indicates that all sites that are specified directly after the path name are unique site collections. This option is typically used to support Self-Service Site Management, such as sites created for partner collaboration. Example URLs for site collections created by using this method are and . In these examples, "" represents the root-level site collection and "/sites" represents the wildcard inclusion.
Sites
A site is one or more related Web pages that are hosted inside a site collection.
Capacity
The guideline for acceptable performance is to implement fewer than 250,000 sites per site collection. You can create a very large total number of Web sites by nesting the subsites. For example, 100 sites, each with 1000 subsites, is 100,000 Web sites. The maximum recommended number of sites and subsites is 125 sites with 2,000 subsites each, for a total of 250,000 sites.
Sharing and isolation
Sites include built-in navigation from one subsite to another within a site collection. There is no built-in navigation from one site collection to another.
As with site collections, separate sites are vulnerable to cross-site scripting attacks from other sites within the domain.
Configurable elements
From within each site, you can add user or group accounts to the Owners group for that site.
Administration
You can use Microsoft Office SharePoint Designer 2007 to back up and restore individual sites. For more information about site administration, see the following articles:
• Back up, restore, or move a SharePoint site ()
• Plan for site creation and maintenance (Windows SharePoint Services)
Planning recommendations
For information about planning sites, see the following article: Plan Web site structure and publishing (Windows SharePoint Services).
Host-named site collections
Host-named site collections are an option if you want to create multiple root-level site collections within a Web application. For example, administrators for hosting organizations use host-named site collections to create multiple domain-named sites.
There is no special mode, such as host header mode, that is required to create host-named site collections. You create host-named site collections by using the Stsadm command-line tool.
Host-named site collections give you more control over URLs. However, there are tradeoffs. The following caveats apply to host-named site collections:
• Host-named site collections are only available through the Default zone. User accounts that are configured to authenticate through other zones cannot access host-named site collections.
• The alternate access mapping feature does not work with host-named site collections. The alternate access mapping feature provides support for off-box termination of SSL, which enables the remote employee access and partner access scenarios to use SSL (HTTPS).
Capacity
You can create up to 100,000 host-named site collections within a single IIS Web site.
Sharing and isolation
The independent domain names that result from host-named site collections help to prevent cross-site scripting attacks between two sites.
Administration
Administrative tasks for host-named site collections include the following:
• Add host-named site collections by using the Stsadm command-line tool.
• Each host-named site collection requires a separate DNS entry.
Planning recommendations
For information about creating host-named site collections by using the Stsadm command-line tool and using host-named site collections in a hosting environment, see White paper: Create shared hosting solutions on Windows SharePoint Services.
Logical architecture sample design: collaboration sites
Topic Last Modified: 2015-03-09
In this article:
• About the model
• Overall design goals
• Server farms
• Users, zones, and authentication
• Administration sites
• Application pools
• Web applications
• Site collections
• Content databases
• Zones and URLs
• Zone policies
• Backing and restoring collaboration sites
• Designing for secure external collaboration
This article describes a practical implementation of logical architecture components to achieve a workable design. This article is intended to be used together with the following model Logical Architecture Sample Design: Windows SharePoint Services Collaboration ().
About the model
The model illustrates a deployment for a fictitious company named Fabrikam, Inc. If you are planning a solution with one or more of the types of collaboration sites represented in this model, you can use the model as a basis for your own design.
The model illustrates a generic deployment of Windows SharePoint Services 3.0 with three different types of collaboration sites represented:
• Team sites
• Self-service sites
• Partner collaboration sites
The model applies nearly all of the logical architecture components and illustrates how these are incorporated into the overall design. This article describes the design goals for the model and explains how these goals are achieved using the logical architecture components illustrated in the model.
Each of the different types of collaboration sites:
• Hosts data with different data characteristics.
• Is subject to a different usage profile.
• Requires a different permissions management strategy.
Consequently, the design choices in the model are intended to optimize the performance and security for each application.
Team sites
Team sites represent highly structured and managed collaboration sites in which:
• There is a smaller number of top-level site collections, and these site collections are intended to include a large amount of data (in contrast to self-service sites).
• Top-level URLs are meaningful for each team.
• More planning is invested in site hierarchies, taxonomies, and customizations.
• Each team’s content is in a separate database and can be managed separately.
The following diagram illustrates the site hierarchy for team sites:
[pic]
Self-service sites
Self-service sites provide an alternative to highly managed team sites. You can allow users and teams to create their own site collections, using Self-Service Site Management. You turn on Self-Service Site Management in Central Administration. This method is best used when you want to allow groups or communities to create sites. This method also works well if you are hosting sites and want to allow users to create sites without waiting for a detailed process.
The characteristics of self-service sites are typically different from highly managed sites. Characteristics might include the following:
• Large number of top-level site collections.
• Small amount of data per site collection.
• URLs that are automatically generated but typically not meaningful.
The following diagram illustrates self-service sites as implemented in the design sample:
[pic]
There are several tradeoffs to be aware of when planning to implement self-service sites, and these tradeoffs will affect the way you manage these types of sites:
• Rather than implementing a thoughtful taxonomy, sites are created at will with no organizing principle across sites. Because each new site is a site collection, templates and navigation cannot be shared across self-service sites.
• Because each site collection provides search only for content on that site collection, there is no aggregation of search results across site collections.
• Sites collections can vary greatly in size and use.
• Sites may be easily abandoned.
Managing self-service sites can include managing content storage based on the target size of content databases and regularly deleting sites that are no longer used.
For more information about implementing Self-Service Site Management, see Plan process for creating sites (Windows SharePoint Services).
Partner collaboration sites
The Partner Web application hosts externally available sites for secure collaboration with employees of partner companies. This application is intended for employees to easily create secure sites for collaboration. Key factors that drive design choices for this application include:
• Content isolation Partners are not allowed to access other types of content hosted on the server farm.
• Separate authentication of partner accounts Partner accounts are managed through forms authentication. Partner accounts are not added to the corporate directory.
• Permissions management Individual site owners manage permissions for their sites, inviting only necessary participants to collaborate.
The following diagram illustrates partner collaboration sites.
[pic]
Overall design goals
The model illustrates a practical implementation of Windows SharePoint Services 3.0 features within several different types of collaboration applications (team sites, self-service sites, and partner sites). The design implementations for each of the individual site applications are discussed in this article. The key design goals for the model include:
• Create a framework for designing an environment that can grow. Design decisions for individual collaboration applications do not prevent the addition of other applications. For example, an initial deployment might include only collaborative team sites or only partner sites. By using a similar logical architecture design, you can add the other types of collaboration sites to the solution without affecting the design of the initial collaboration sites. In other words, the design does not incorporate design choices that limit the use of the environment.
• Provide access for several classes of users without compromising the security of the content within the different collaboration applications. Users from different network zones (both internal and external) with different authentication providers can participate in collaboration. Also, users can only access the content they are intended to access. By following a similar logical architecture design, you create the opportunity to provide access to users in multiple locations and with different objectives. For example, your initial design might be intended only for internal employee access. However, by using a similar design you can enable access to remote employees, partner employees, or even customers.
• Ensure that the design can be used in an extranet environment. You can make deliberate design choices to ensure that the server farms can be securely deployed in a perimeter network or within any of the extranet topologies discussed in Design extranet farm topology (Windows SharePoint Services).
The rest of this article discusses each of the logical components that appear in the model (from top to bottom) and discusses the design choices that are applied to the model. The purpose of this approach is to demonstrate the different ways in which logical architecture components can be configured based on the application.
Server farms
The model illustrates a five-server farm. However, the model could be implemented on any size farm, including a single server. The server farm in the model is composed of five servers with the following topology:
• Two front-end Web servers
• One application server for the search server
• Two database servers, either clustered or mirrored
The model illustrates the logical architecture of Windows SharePoint Services 3.0 by showing that:
• All sites are mirrored across front-end Web servers.
• The Central Administration site is installed on an application server to protect it from direct user access.
In reality, the number of server computers and the topology of the server farm are not important to the logical architecture, except to increase capacity and performance, as needed. The logical architecture can be designed independent of the server-farm topology. The performance and capacity planning process will help you size the server farm to meet performance and capacity goals. For more information, see Plan for performance and capacity (Windows SharePoint Services).
Users, zones, and authentication
The model illustrates five different classes of users, each assigned to a different zone. Within each Web application, you can create up to five zones using one of the available zone names: Default, Intranet, Internet, Custom, or Extranet. A farm that hosts more than one Web application can support user requests from more than five network zones (up to five zones per Web application). However, the model shows only five zones.
Users and authentication
The model demonstrates how authentication is applied across users from different network zones. The following table also demonstrates the authentication applied to each type of user and zone.
|Zone |Users |Authentication |
|Intranet |Internal employees |NTLM (Integrated Windows) |
|Default |Remote employees |NTLM (Integrated Windows) or forms |
| | |authentication with Lightweight Directory |
| | |Access Protocol (LDAP). |
|Extranet |Partner employees |Forms authentication |
Internal employees
The Intranet zone is used for internal employee access. Integrated Windows authentication is used.
Remote employees
The Default zone is used for remote employee access. The design goals for the Default zone are:
• Authenticate against the internal Active Directory directory service environment.
• Simplify permissions management by using Windows authentication for both internal employees and remote employees. This goal is important, because if users connect to sites through two different authentication providers, Windows SharePoint Services 3.0 creates two different accounts for each user, and each of the two accounts must have permissions.
The model presents two different options for authenticating remote employees. With the first option (Integrated Windows authentication using NTLM), both design goals are accomplished. The second option (forms authentication with LDAP) satisfies the first goal but not the second. Consequently, the first option is the preferred method for remote employees.
The following table summarizes the differences between these two authentication options.
|Type of comparison |Integrated Windows authentication using NTLM |Forms authentication |
| | |using an LDAP provider |
|Functionality |This method relies on using Internet Security and Acceleration (ISA) Server 2006 or |Windows SharePoint |
| |Intelligent Application Gateway (IAG 2007) to authenticate users and then to send the |Services 3.0 uses forms |
| |user credentials to Windows SharePoint Services 3.0. These servers use forms |authentication with an |
| |authentication to authenticate users against the Active Directory environment. They then |LDAP provider to |
| |forward the Windows credentials to Windows SharePoint Services 3.0. For more information,|authenticate remote |
| |see the following resources: |employees against the |
| |Authentication in ISA Server 2006 |internal Active |
| |(). |Directory environment. |
| |Planning for IAG authentication and authorization | |
| |(). | |
| |Because the zone is the Default zone, NTLM authentication is used to satisfy a | |
| |requirement of the index component. For more information, see "Configuration requirements| |
| |of the Default zone" later in this article. | |
|Advantages |Windows SharePoint Services 3.0 does not create two different accounts for users who work|Does not require a proxy|
| |both internally and remotely. This greatly simplifies permissions management. |server to authenticate |
| | |users and forward |
| | |credentials. |
|Disadvantages |Requires additional coordination with, and configuration of, ISA Server 2006, IAG 2007, |If users connect to |
| |or another proxy server product. |Windows SharePoint |
| | |Services 3.0 both |
| | |internally and remotely,|
| | |two different user |
| | |accounts are created in |
| | |Windows SharePoint |
| | |Services 3.0. |
| | |Consequently, both |
| | |accounts require |
| | |permissions to sites and|
| | |documents. Employees |
| | |need to manage |
| | |permissions for their |
| | |own sites and documents |
| | |for both user accounts |
| | |if they plan to work |
| | |from both the internal |
| | |network and remotely. |
Partner employees
Partner employees access the network through the Extranet zone and are authenticated by using forms authentication. This requires a separate directory and provider, such as a Microsoft SQL Server database and provider, to store partner accounts in the extranet. The advantages of this approach are that you can manage partner accounts separately, and you do not need to add partner accounts to the internal employee directory.
Alternatively, you can use Web single sign-on (SSO) to authenticate against a partner's own directory. However, this approach requires a separate zone for each partner directory.
Because the model assumes that Fabrikam is working with partners from several different companies within the same partner application, forms authentication is used. The directory and provider are not specified.
Zones
When you design zones, several key decisions are critical to the success of the deployment. These decisions include design and configuration decisions for the following zones:
• The Default zone
• Zones for external access
The following sections describe the decisions that are incorporated in the model.
Configuration requirements of the Default zone
The zone that involves the greatest consideration is the Default zone. Windows SharePoint Services 3.0 places the following requirements on how the Default zone is configured:
• When a user request cannot be associated with a zone, the authentication and policies of the Default zone are applied. Consequently, the Default zone must be the most secure zone.
• The index component requires access to content through at least one zone to crawl content. The index component uses NTLM authentication. Consequently, in order to crawl content, at least one of the zones must be configured to use NTLM authentication. Also, the crawler will poll zones in the following order, until it encounters a zone that it can authenticate through: Default zone, Intranet zone, Internet zone, Custom zone, and Extranet zone. However, if the crawler first encounters a zone that is configured to use Kerberos, basic, or digest authentication, the crawler will not authenticate and will not attempt to access the next zone. Therefore, ensure that the configuration of zones does not prevent the index component from crawling content. For more information about authentication requirements related to crawling content, see Plan authentication methods (Windows SharePoint Services).
• Administrative e-mail is sent with links from the Default zone. These include e-mail messages to owners of sites that are approaching quota limits. Consequently, users who receive this type of e-mail must be able to access links through the Default zone. This is especially important for site owners.
• Host-named site collections are only available through the Default zone. All users who need to access host-named site collections must have access through the Default zone.
In the model, the Default zone is used for remote employee access for the following reasons:
• Employees can access links in administrative e-mail regardless of whether they are accessing the sites internally or remotely.
• Internal server names and URLs are protected from being exposed when the zone associated with a user request cannot be determined. Because the Default zone is already configured for remote employees, URLs do not expose sensitive data when this zone is applied.
Configuring zones for an extranet environment
In an extranet environment, the design of zones is critical for the following two reasons:
• User requests can be initiated from several different networks. In the model, users initiate requests from the internal network, the Internet, and partner companies.
• Users can participate in collaboration across multiple Web applications. For example, internal and remote employees can potentially contribute to and administer content across all of the Web applications: team sites, self-service sites, and Partner Web.
In an extranet environment, ensure that the following design principles are followed:
• Configure zones across multiple Web applications to mirror each other. The configuration of authentication and the intended users should be the same. However, the policies associated with zones can differ across Web applications. For example, ensure that the Intranet zone is used for the same employees across all Web applications. In other words, do not configure the Intranet zone for internal employees in one Web application and remote employees in another.
• Configure alternate access mappings appropriately and accurately for each zone and each resource.
In the model, the Default zone for each of the Web applications is configured identically for remote employee access. Additionally, the Intranet zone is configured identically across all Web applications for internal employee access. The Extranet zone is configured for only one Web application.
Alternate access mappings are automatically created when you create the zone. However, if you use a proxy server or gateway product to make sites available from the Internet, you will need to add an additional alternate access mapping entry for each zone. This ensures that URLs that are returned to users outside of the internal network are available to users according to the context of their zone. For more information, see Plan alternate access mappings (Windows SharePoint Services).
If zones across Web applications do not mirror each other, and links to external resources are not appropriate, the risks include:
• Server names, Domain Name System (DNS) names, and IP addresses can potentially be exposed outside of the internal network.
• Users might be unable to access Web sites and other resources.
Administration sites
In the model, the Central Administration site is hosted on the search server. This protects the site from direct user contact. If a performance bottleneck or security compromise affects the availability of the front-end Web servers, the Central Administration site remains available. Additionally, the Central Administration site is hosted inside a dedicated application pool and Web application.
The load-balanced URLs for the administration sites are not articulated in the model or in this article. Recommendations include the following:
• If port numbers are used in administrative URLs, use non-standard ports. Port numbers are included in URLs by default. While port numbers are typically not used in customer-facing URLs, using port numbers for administration sites can increase security by limiting access to these sites to non-standard ports.
• Create separate DNS entries for administration sites.
Application pools
Separate Internet Information Services (IIS) application pools are typically implemented to achieve process isolation between sites. Application pools provide a way for multiple sites to run on the same server computer but still have their own worker processes and identity. This mitigates any possible security issues on one site that enable an attacker to inject code onto the server to attack other sites.
Practically speaking, consider using a dedicated application pool for each of the following scenarios:
• To separate authenticated content from anonymous content.
• To isolate sites that are primarily for collaboration with external partners or customers. This isolates external accounts to sites within one application pool.
• To isolate sites where users have more freedom to create and administer sites and to collaborate on content.
The model uses application pools in the following way:
• The administration site is hosted in a dedicated application pool. This is a requirement of Windows SharePoint Services 3.0.
• The internal collaboration sites (team sites and self-service sites) are hosted in one application pool.
• The Partner Web application is hosted in a dedicated application pool.
Web applications
A Web application is an IIS Web site that is created and used by SharePoint Products and Technologies. Each Web application is represented by a different Web site in IIS. You assign each Web application a unique domain name, which helps to prevent cross-site scripting attacks.
Generally speaking, use dedicated Web applications to:
• Separate anonymous content from authenticated content.
• Isolate users. In the model, Partner Web is hosted in a dedicated Web application and application pool to ensure that partners do not have access to the internal collaboration content.
• Enforce permissions. A dedicated Web application provides the opportunity to enforce permissions by using the Policy for Web Application page in Central Administration. For example, you can create a policy on the internal collaboration sites to explicitly deny access to partner accounts. Policies for a Web application are enforced regardless of permissions configured on individual sites or documents within the Web application.
• Optimize performance. Sites achieve better performance if they are placed in Web applications with other applications of similar data characteristics. For example, the data characteristics of self-service sites include a large number of sites that are small in size. In contrast, team sites typically encompass a smaller number of very large sites. By placing these two different types of sites in separate Web applications, the resulting databases are composed of data with similar characteristics, which optimizes database performance. In the model, team sites and self-service sites do not have unique data isolation requirements — they share the same application pool. Nonetheless, team sites and self-service sites are placed in separate Web applications to optimize performance.
• Optimize manageability. Because creating separate Web applications results in separate sites and databases, you can implement different site limits (recycle bin, expiration, and size) and negotiate different service-level agreements. For example, you might allow more time to restore self-service sites if this is not the most critical type of content within your organization. This allows you to restore more critical content before restoring these sites. In the model, self-service sites are placed in a separate Web application to enable administrators to more aggressively manage growth compared to other applications.
Site collections
Site collections bridge logical architecture and information architecture. The design goals for site collections in the model are to satisfy requirements for URL design and to create logical divisions of content.
To satisfy the requirements for URL design, each Web application includes a single root-level site collection. Managed paths are used to incorporate a second tier of top-level site collections. For more information about URL requirements and using managed paths, see "Zones and URLs" later in this article. Beyond the second tier of site collections, each site is a subsite.
The following figure shows the site hierarchy of team sites.
[pic] Given the requirement for a root-level site collection, the design decisions revolve around the second tier of site collections. The model incorporates choices based on the nature of the application.
Self-service sites
In the model, the self-service sites incorporate a top-level site with the URL of . A managed path is incorporated (by using wildcard inclusion), which allows an indefinite number of user-created sites. All sites below the managed path are independent site collections that inherit the site template that was used to create the top-level site. The following figure illustrates self-service sites.
For more information about self-service sites, see Plan process for creating sites (Windows SharePoint Services).
Team sites
When designing site collections within a team site application, the recommendation is to create a finite number of site collections for your organization based on the way your organization operates. In this approach, site collections are created by a Windows SharePoint Services 3.0 administrator. After the site collection is created, teams can create sites within the site collection based on their needs.
This approach provides the opportunity to implement a thoughtful taxonomy that provides structure to the way team sites are managed and grow. There is also more opportunity to share templates and navigation between projects and teams that share a site collection. The challenge for information architects is to create a second tier of site collections that makes sense for the organization. The following table lists suggestions for different types of organizations.
|Type of organization |Suggested site collection taxonomies |
|Product development |Create a site collection for each product under development. Allow |
| |contributing teams to create sites within the site collection. |
| |For each long-term development project, create a site collection for |
| |each large team that contributes to the product. For example, create |
| |one site collection for each of the following teams: designers, |
| |engineers, and content developers. |
|Research |Create a site collection for each long-term research project. |
| |Create a site collection for each category of research projects. |
|Higher education institution |Create a site collection for each academic department. |
|State legislative office |Create a site collection for each political party. Government |
| |officials who share party affiliation can share templates and |
| |navigation. |
| |Create a site collection for each committee. Or, create one site |
| |collection for all committees. |
|Corporate law office |Create a site collection for each corporate client. |
|Manufacturing |Create a site collection for each line of products. |
Partner Web
Partner Web is intended to be used for collaboration with external partners on projects that have finite scopes or finite durations. By design, sites within the Partner Web application are not intended to be related. The requirements for Partner Web include ensuring that:
• Project owners can easily create sites for partner collaboration.
• Partners and other contributors have access to only the projects they work on.
• Permissions are managed by site owners.
• Search results from within one project do not expose content from other projects.
• Administrators can easily identify sites that are no longer used and delete these sites.
To satisfy these requirements, the model incorporates a site collection for each project, which provides the following benefits:
• Individual site collections provide the appropriate level of isolation between projects.
• Self-service site creation can be implemented.
Content databases
You can use the following two approaches to incorporate content databases into the design (the model incorporates both approaches):
• Establish target sizes for content databases with appropriate size warning thresholds. Create a new database when size warning thresholds are reached. With this approach, site collections are automatically added to the available database or databases, based on size targets alone.
• Associate site collections to specific content databases. This approach enables you to place one or more site collections in a dedicated database that can be managed independently from the rest.
If you choose to associate site collections to specific content databases, you can use the following methods to accomplish this:
• Use the Stsadm command-line tool to create a site collection in a specific database.
• Dedicate a database to a single site collection by applying the following database capacity settings:
• Number of sites before a warning event is generated = 1
• Maximum number of sites that can be created in this database = 1
• Add a group of site collections to a dedicated database by performing the following steps:
• Within the Web application, create the database and set the database status to Ready.
• Set the status of all other databases to Offline. While content databases are offline, new site collections cannot be created. However, existing site collections in offline databases are still accessible for both read and write operations.
• Create the site collections. They are automatically added to the database.
• Set the status of all other databases back to Ready.
Team sites
The model incorporates a dedicated database for each of the team site collections. This approach enables you to manage each team's database independently for backup, restore, and migration. Also, when a project is complete, you can easily archive the database associated with the project.
Self-service sites
For self-service sites, the model achieves scale efficiency by managing databases to the maximum target size. The following settings are configured to achieve this goal:
• Limit site storage to a maximum of This setting, which you configure on the Quota Templates page in Central Administration, limits the size of a personal site.
• Second stage Recycle Bin This setting, which you configure on the Web Application General Settings page, determines how much additional space is allocated to the second-stage recycle bin.
• Maximum number of sites that can be created in this database This setting is configured when you create a database. Calculate the total allowable size of sites by using the numbers you specify for the previous two values. Then, based on the size goal for each database, determine how many sites will fit into the database.
The model provides the following example size settings based on a target database size of 100 gigabytes (GB) and a target My Site size of 500 megabytes (MB):
• Site size limits per site = 500 MB
• Target size of database = 100 GB
• Maximum number of sites = 200
• Site Level Warning = 175
When the site level warning is reached, create a new database. After you create the new database, new self-service sites are added alternately to the new database and the existing database until the maximum number of sites for one of the databases is reached.
Partner Web
Similar to self-service sites, Partner Web achieves scale efficiency by managing databases to the maximum target size.
Because Partner Web is hosted in a dedicated Web application, you can create size limits that are more appropriate to the types of sizes that are created. The model provides the following example size settings:
• Target size of database = 100 GB
• Storage quota per site = 5 GB
• Maximum number of sites = 20
Zones and URLs
The model illustrates how to coordinate URLs across multiple applications within a corporate deployment.
Design goals
The following goals influence design decisions for URLs:
• URL conventions do not limit the zones through which content can be accessed.
• The standard HTTP and HTTPS ports (80 and 443) can be used across all applications in the model.
• Port numbers are not included in URLs. In practice, port numbers are typically not used in production environments.
Design principles
To achieve these design goals, the following design principles are applied:
• Host-named site collections are not used. Note that host-named site collections are different from IIS host headers. Host-named site collections do not work with the alternate access mappings feature. The alternate access mappings feature is required to access the same content through multiple domain URLs. Consequently, when host-named sites are used, these sites are available only through the Default zone. The alternate access mapping feature also provides support for off-box termination of Secure Sockets Layer (SSL), which enables the remote employee access and partner access scenarios to use SSL (HTTPS). For more information on using host-named site collections see White paper: Create shared hosting solutions on Windows SharePoint Services.
• Each application incorporates a single root site collection. This is a requirement for using alternate access mappings. If multiple root site collections are required within a Web application and you expect to use only the Default zone for user access, host-named site collections are a good option.
• For the applications that include multiple high-level site collections, in which each site collection represents a top-level team or project (for example, team sites), the model incorporates managed paths. Managed paths provide greater control over URLs for these types of sites.
Design tradeoffs
Meeting the design goals results in some tradeoffs, including the following:
• URLs are longer.
• Host-named site collections are not used.
Designing load-balanced URLs
When you create a Web application, you must choose a load-balanced URL to assign to the application. Additionally, you must create a load-balanced URL for each zone that you create within a Web application. The load-balanced URL includes the protocol, scheme, host name, and port, if used. The load-balanced URL must be unique across all Web applications and zones. Consequently, each application and each zone within each application requires a unique URL across the model.
Internal collaboration sites
The two different types of internal collaboration sites each require a unique URL. In the model, the target audience for these sites is internal employees and remote employees. The following table lists the URLs for internal and remote employees to access each application.
|Application |Internal employee URL |Remote employee URL |
|Team sites | | |
|Self-service sites | | |
Partner Web
In the model, Partner Web is accessed by internal employees, remote employees, and partner employees. Although both remote employees and partner employees access Partner Web externally using SSL (HTTPS), each requires a different URL to apply the benefits of using separate zones — that is, different authentication methods and different zone policies. The following table lists the URLs that internal employees, remote employees, and partners use to access Partner Web.
|Zone |URL |
|Internal employee URL | |
|Remote employee URL | |
|Partner URL | |
Using explicit and wildcard inclusions for URL paths
By defining managed paths, you can specify which paths in the URL namespace of a Web application are used for site collections. You can specify that one site collection or more than one site collection exists at a distinct path below the root site. Without managed paths, all sites created below the root site collection are part of the root site collection.
You can create the following two types of managed paths:
• Explicit inclusion A site collection with the explicit URL that you assign. An explicit inclusion is applied to only one site collection. You can create many explicit inclusions below a root site collection. An example URL for a site collection created by using this method is .
• Wildcard inclusion A path that is added to the URL. This path indicates that all sites that are specified directly after the path name are unique site collections. This option is typically used for applications that support self-site creation. An example URL for a site collection created by using this method is .
The model incorporates the use of both types as described in the following sections.
Explicit inclusions: team sites
In the model, both of the team sites applications incorporate the use of explicit inclusions.
Team sites
Within the team sites application an explicit inclusion is used for each team site collection. The scale limit on site collections created with an explicit inclusion is about 100 sites. Good governance practices recommend that you keep the number of top-level team sites to a manageable number. Also, the taxonomy for team sites should be logical for the way your business operates. Many organizations fit well within the 100 sites recommendation. If your organization requires greater scale for team sites, use a wildcard inclusion instead.
In the model, the use of explicit inclusions results in the URLs in the following table.
|Internal employee (Intranet zone) |Remote employee (Default zone) |
| | |
| | |
| | |
In this example, the root site collection, , doesn't necessarily host content for users.
Wildcard inclusions: Partner Web and self-service sites
Both Partner Web and self-service sites incorporate the use of a wildcard inclusion. Wildcard inclusions are ideal for applications that allow users to create their own site collections. A wildcard inclusion indicates that the next item after the wildcard is a root site of a site collection.
Self-service sites
In the model, self-service sites include a wildcard inclusion named /sites ().
This results in URLs of the format listed in the following table.
|Internal (Intranet zone) |Remote employee (Default zone) |
| | |
| | |
| | |
Partner Web
Partner Web is designed to allow employees to easily create secure sites for collaboration with external partners. To support this goal, self-service site creation is allowed.
In the model, Partner Web includes a wildcard inclusion named /sites (). This results in URLs of the format listed in the following table.
|Internal employee (Intranet zone) |Remote employee (Default zone) |
| | |
| | |
| | |
Partner contributors can access Partner Web sites using the URLs listed in the following table.
|Partner (Extranet zone) |
| |
| |
| |
Zone policies
You can create a policy for a Web application to enforce permissions at the Web application level. A policy can be defined for the Web application in general or just for a specific zone. A policy enforces permissions on all content within the Web application or the zone. Policy permissions override all other security settings that are configured for sites and content. You can configure policy based on users, or user groups, but not SharePoint groups.
The model provide one example: denying partner accounts access to internal collaboration sites.
Backing up and restoring collaboration sites
There are several options for backing up and restoring content that are appropriate for collaboration sites:
• Built-in backup and recovery tools — Use the tools that come with Windows SharePoint Services 3.0 if databases are under 100 GB and there are not many customizations or customizations are packaged as solution.
• Microsoft SQL Server 2005 Backup and Recovery tools — Use these tools if you have a SQL database administrator.
For more information, see Choose backup and recovery tools (Windows SharePoint Services).
Designing for secure external collaboration
The design sample poster includes an overview of how to plan for external secure collaboration. This section includes the introduction text for each item and links to the corresponding articles in the TechNet library.
|Design recommendation |Guidance |
|Choose an extranet topology |Protect your server farm by either using an edge firewall or by |
| |placing the server farm in a perimeter network. For more information,|
| |see the following articles on TechNet: |
| |Design extranet farm topology Design extranet farm topology (Windows |
| |SharePoint Services) |
| |Plan security hardening for extranet environments (Windows SharePoint|
| |Services) |
|Secure client-server communication |Secure collaboration in an extranet environment relies on secure |
| |communication between client computers and the server-farm |
| |environment. Where appropriate, use Secure Sockets Layer (SSL) to |
| |secure communication between client computers and servers. |
| |For more information, see the following articles on TechNet: |
| |Create or extend Web applications (Windows SharePoint Services) |
| |Plan for secure communication within a server farm (Windows |
| |SharePoint Services) |
|Protect back-end servers and the Central Administration site |External secure collaboration requires Internet-facing servers. You |
| |can limit the exposure to traffic from the Internet by placing a |
| |firewall between Web servers and other servers and by hosting the |
| |Central Administration site on a backend server. |
| |For more information, see the following articles on TechNet: |
| |Plan security for an external secure collaboration environment |
| |(Windows SharePoint Services) |
| |Plan for secure communication within a server farm (Windows |
| |SharePoint Services) |
| |Plan security hardening for extranet environments (Windows SharePoint|
| |Services) |
| |Plan security hardening for server roles within a server farm |
| |(Windows SharePoint Services) |
|Configure alternate access mappings |Alternate access mappings support Internet deployment scenarios in |
| |which the URL of a Web request received by Internet Information |
| |Services (IIS) is not the same as the URL that was typed by an end |
| |user. This is most likely to occur in deployment scenarios that |
| |include reverse proxy publishing and load balancing. For example, |
| |reverse proxies can perform advanced functionality, such as receiving|
| |a Web request over the Internet by using SSL (HTTPS), but forward the|
| |request to the server by using HTTP. This is referred to as "off-box |
| |SSL termination." |
| |For more information see Plan alternate access mappings (Windows |
| |SharePoint Services). |
Design logical architecture for collaboration sites (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
In this article:
• Team sites design recommendations
• Host team sites in a dedicated Web application
• Plan Web application general settings
• Choose whether to allow users to create site collections
• Design content database settings for team sites
• Automatically delete sites that are not used
• Use paths to organize team site URLs
• Plan for custom elements
• Plan the permissions to apply to team sites
The collaboration that team sites enable and the storage space that they provide is useful for long-term and short-term projects, communication, and cross-group collaboration. When you create the initial architecture design for the server farms, you have to plan for hosting and managing team sites. For example, you have to plan for the content databases needed to host the team site content, plan for archiving and deleting short-term project team sites to make way for more projects, and monitor team communication sites to ensure that their sizes are manageable for backup and recovery.
This article contains logical architecture design recommendations for deploying team sites in a server farm. This article does not discuss the information architecture — that is, the internal structure — of team sites. For information about how to design information architecture, see Plan Web site structure and publishing (Windows SharePoint Services).
Team sites design recommendations
In most organizations, the number of team sites increases and the sizes of individual team sites grow, sometimes rather quickly. As teams reorganize or as projects complete and new projects start, teams create new team sites and abandon old sites, or expand their current team sites to contain more data. To manage or control this growth, you have to carefully plan support for team sites.
Design goals for team sites include:
• Optimizing performance of the overall server farm.
• Creating logical divisions of databases for team sites for ongoing maintenance (that is, backup, recovery, and upgrade).
• Enabling you to apply appropriate policies and settings for team sites without affecting other kinds of sites within the intranet.
Design guidance for team sites includes the following recommendations, each of which is elaborated in the following sections:
• Host team sites in a dedicated Web application.
• Apply Web application general settings, such as quota and life-cycle management settings at the Web application level to manage growth of team sites and to keep content current.
• Design content database settings for appropriate storage and scale and to ensure that you can back up and restore databases of the designed size.
• Automatically delete sites that are not used.
• Use paths to organize team site URLs.
• Plan for appropriate policies and permissions.
Host team sites in a dedicated Web application
Use one or more dedicated Web applications to host the team sites. Consider the following examples:
• An investment banking and equities research firm in the United States has to keep sites for the investment banking division and the equities research division completely isolated to comply with U.S. Securities and Exchange Commission regulations. In this example, the firm has to use two Web applications that have isolated sets of team site collections for the two divisions. The firm also has to use Web application policies to ensure that users from each division do not see content produced by the other division.
• A research and manufacturing company has to keep tight control over its intellectual property and research findings. In this example, the company can host the research team sites in a separate Web application and use Web application policies to enforce permissions and ensure that only research staff sees the content in the research team sites.
• An organization hosts both internal (intranet) and external (extranet) team sites and wants to implement and manage them differently. In this example, the organization plans and implements two separate Web applications to host the two sets of team sites. In this way, it can have different authentication methods, different databases, and different IIS logs for each environment in case there is an issue. For more information about how to plan for extranets, see Design extranet farm topology (Windows SharePoint Services).
Generally speaking, use dedicated Web applications to:
• Separate anonymous content from authenticated content.
• Isolate users.
• Enforce permissions.
• Optimize performance.
• Optimize manageability.
For more information about deciding whether to have shared or dedicated Web applications, see Logical architecture sample design: collaboration sites.
Consider performance
When you host team sites on a dedicated Web application, you have several content databases that contain only team site collections. If content databases host sites that have similar data characteristics, Microsoft SQL Server 2005 database software operates more efficiently because SQL Server 2005 uses a query plan based on the characteristics of a database. By contrast, if a database hosts sites that have significantly different data characteristics, the query plan that SQL Server 2005 uses might not be the most efficient method for all content in the database. Therefore, by putting content for team sites in dedicated databases, you can optimize performance for SQL Server 2005, which results in better performance for the overall server farm.
Consider manageability
By hosting team sites on a dedicated Web application, you can improve manageability in the following ways:
• You can separately manage the following items:
• Database settings
• Quota templates
• Recycle Bin settings
• Automated actions for unused sites
• Authentication
• Policies
• You can more effectively manage the growth of team sites by managing team sites separately from other kinds of sites.
• You create the opportunity to negotiate a specific service-level agreement. For example, together with a service-level agreement to store weekly full backups and daily differential backups of the content databases, you could offer quicker turnaround on recovery of individual items of content by using the second-stage Recycle Bin.
Choose an application pool
In a corporate environment, team sites can share an application pool with Web applications that have similar collaboration and isolation requirements.
Generally speaking, you must have a dedicated application pool when you want to do any of the following:
• Separate authenticated content from anonymous content.
• Isolate applications where users have great liberty to create and manage sites and to collaborate on content.
For more information about when to have dedicated application pools, see Logical architecture sample design: collaboration sites.
In a hosting environment in which content for multiple organizations is hosted on a single server farm, we recommend that you host all content for a single organization in the same application pool. This gives you better scalability (with fewer application pools, you have fewer processes running), and process isolation between the application pools (so that if Customer A's application pool stops, it does not affect Customer B's sites). This, of course, depends on how many organizations you have, what performance planning recommends, and what the isolation requirements are.
Plan Web application general settings
There are several settings on the Web Application General Settings page that can help you to manage the growth of data and how current content is in team sites within the environment. These settings are applied to all sites within a Web application. At a minimum, plan to implement the following settings, each of which is discussed later in this section:
• Define and apply a quota template to limit the maximum size of team sites.
• Establish a maximum upload size. Choose a generous size based on business requirements so users can easily collaborate.
• Turn on the site Recycle Bins and use the second-stage Recycle Bin.
In addition to the settings listed previously, evaluate all feature settings on the Web Application General Settings page to ensure that the features are appropriate for team sites in the organization. By default the following features are enabled:
• Person name smart tag and online status (online presence information is displayed)
• Alerts (users can create a maximum of 500 alerts, by default)
• Really Simple Syndication (RSS) feeds
• Blog application programming interface (API) (link to create a blog)
Determine quota template settings
There is no default quota template for team sites. However, the following settings are recommended as a starting point:
• Automated e-mail is sent to a site owner when the size of the site reaches 450 megabytes (MB).
• Users are prevented from uploading additional documents when the size of a site reaches 500 MB.
These settings might work well for the organization, but you should evaluate the size and number of items that you expect users to store in team sites and adjust these settings as appropriate to ensure that team sites are used as intended in the organization.
For example, if the organization includes research or design teams that collaborate together to produce a large volume of content that needs to be stored and archived, consider increasing quota limits — for example, increase the site limit to 5 or 10 gigabytes (GB). In these scenarios, hosting the content on team sites ensures that the content is backed up regularly and that all those individuals who need to contribute to it can do so. You might also consider putting a site collection of the 5-10 GB size into it its own content database, especially if you expect that site collection to grow rapidly.
On the other hand, if team sites are mostly used for short-term projects or team communication sites, consider using a lower quota limit. This encourages teams to store only the information needed to keep short-term projects moving forward (however, be sure not to lower it too far, or you risk an increase in costs associated with help-desk requests to increase the quotas). In this scenario, you encourage teams to store general team content or content for a new project in separate team sites.
If a particular team or group in the organization has a business need to store a greater volume of content on its team site, you can adjust the quota limits for an individual site collection. To adjust quota limits, on the Site Collection Quotas and Locks page, select the site collection that corresponds to the team or group. Change the current quota template to Individual Quota, and then specify the limits that are appropriate.
When planning for quota templates, choose limits that work for most of the organization's team sites. To improve manageability, only adjust quotas on a per-user basis when you must meet a business need.
Determine the maximum upload size
The default maximum upload size is 50 MB. 50 MB is considered a generous limit that gives users the flexibility of uploading many types and sizes of documents without adversely affecting performance. If users in the organization have to store larger files in their team sites, consider adjusting this setting, and be sure to monitor the IIS time-out settings if you have users who have slower connections.
Determine Recycle Bin settings
Turning on the Recycle Bin is a simple way to improve manageability of team sites. The Recycle Bin enables site owners to retrieve items that they have deleted without requiring central administrative intervention (that is, restoring from backup tapes).
The following list describes the default settings for the Recycle Bin, which work well for most organizations:
• Recycle Bin Status: On
• Delete items in the Recycle Bin: After 30 days
• Second-stage Recycle Bin: Add 50 percent of live site quota for second stage deleted items
The second-stage Recycle Bin stores items that users have deleted from their Recycle Bins. Only site collection administrators can restore items from the second-stage Recycle Bin. The size that is specified for the second-stage Recycle Bin increases the total size of the team site. For example, if the team site limit is 500 MB and the second-stage Recycle Bin is set to 50 percent, the total amount that can be used by the site is 750 MB. Therefore, plan database capacity accordingly.
Just as with the Recycle Bin, items in the second-stage Recycle Bin are automatically deleted when the time period for deleted items is reached (by default, 30 days). However, when the size limit of the second-stage Recycle Bin is reached, items are automatically deleted from the second-stage Recycle Bin starting with the oldest items. Site collection administrators can also empty the second-stage Recycle Bin manually.
Key considerations when you are using the Recycle Bin feature are whether to use the second-stage Recycle Bin and how much space to allocate. Consider allocating at least a small amount of space (such as 10%) to the second-stage Recycle Bin to accommodate cases in which a user deletes an important document, a folder in a document library, or a column in a list by mistake.
Plan site creation method
You can decide whether to create site collections for team sites centrally, or allow users to create their own site collections by using Self-Service Site Management. There are tradeoffs to each approach.
If you allow teams to create site collections through self-service site management, teams can easily create a site, as needed, without assistance from an administrator. However, there are many disadvantages to this approach, including the following:
• You lose the opportunity to implement a thoughtful taxonomy.
• The application can become difficult to manage.
• Sites can easily be abandoned.
• You cannot share templates and navigation across projects or teams that might otherwise share a site collection.
[pic] Note:
If you want to use self-service site management, but you want to restrict the templates available for sites that are created, you can edit the webtempsps.XML file (located at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\TEMPLATE\1033\XML) to hide templates from the self-service site management process.
If you instead create site collections centrally, based on the way the organization operates, you gain the opportunity to implement a thoughtful taxonomy that provides structure to the way team sites are managed and grow. There is also more opportunity to share templates and navigation between projects and teams that share a site collection. By using this approach, after the initial site collection is created, teams can create sites within the site collection based on their needs. However, you are spending IT resources every time that a user wants to create a site.
For examples of when to use each method, see Logical architecture sample design: collaboration sites. For more information about how to plan for site creation, see Plan process for creating sites (Windows SharePoint Services).
If the organization has decided to create site collections for team sites instead of allowing users to create their own team site collections, use the Site paths worksheet () to determine the level at which team sites are created: top-level sites in their own site collections, or one large site collection with multiple subsites. For more information about how to determine whether to create many site collections or only a few site collections with many subsites, see "Decide whether to use individual site collections or subsites within one site collection" in Determine sites and subsites needed (Windows SharePoint Services) in the Windows SharePoint Services 3.0 Technical Library.
Design content database settings for team sites
Depending on scale and manageability considerations, you can use dedicated content databases for each site collection or group multiple site collections into one or more content databases. Using a dedicated content database for each site collection enables you to manage each site collection database independently for backup, recovery, and migration. Also, when a project is complete, you can easily archive the database associated with the project. Although by using this approach you create many databases, you gain the ability to individually control the database for each site collection.
However, realize that SQL Server performance can be affected by the number of databases per each instance of SQL Server. In other words, if you plan to have 300 or more team site collections, storing each in a dedicated database might decrease SQL Server performance. This is because each database represents a connection between the application pool and SQL Server. When you add Web servers and databases, the number of active connections increases. If you add too many connections, SQL Server can become non-responsive.
Therefore, if you plan to have more than 300 team site collections, you should not use dedicated databases. Instead, store multiple site collections in each database. 300 databases is the number that is used by the Microsoft IT department. Note that 300 databases is not a point of failure. Instead, it is an estimate based on Windows SharePoint Services 3.0 data, where 300 databases represented a level of confidence for Microsoft IT about how many site collections could safely be hosted on each server. The number will vary based on several parameters including the number of databases. For example, whether to use dedicated databases can also depend on factors such as the following:
• Do teams have different service-level agreements (such as different backup requirements)?
• Do teams require more than 8 GB of storage?
• Do teams have different project timelines? Mixing teams with short projects with teams with long projects might make it difficult to archive sites and move them out of the production environment if they share the same database.
• Do teams expect a high level of autonomy and independence for operations that occur at the database level?
For any of these, if you answer yes, you should consider dedicated databases for site collections.
If you decide to store multiple site collections in each database, you can calculate how many to store in each database by determining the maximum size for any one database and the maximum size for each site collection (based on the quota template storage limit value plus the Recycle Bin allocation). Note that even if you give everyone 500 MB quotas, not everyone will use the full quota. Therefore, you may be creating too many content databases. Use the quota estimates as a consideration in database planning, but be sure to track real usage and adapt. If you had a previous environment that used Windows SharePoint Services 2.0, you can also consider how big those site collections were, and create databases based on the actual site collection sizes instead of on quota estimates.
In a managed environment, database size limits are often determined by the following two factors:
• The time that is required to back up a database. Beyond a certain database size, backup operations become inefficient, require more time than is practical, and become subject to other disruptions. This may also be the point at which you decide to add more database servers to the environment.
• The service window (that is, the time) allowed for restoring content, as determined by the service-level agreement. For example, if the service window for restoring content is four hours, the size of the database is limited to a volume that can be restored within this time.
To determine the maximum manageable database size for team site collections, determine the values listed in the following table.
|Item |Factor |Value |
|A |Service window for restoring content | hr |
|B |Volume of content that can be restored within| GB |
| |the service window, given the chosen recovery| |
| |method and tools | |
|C |Target time window for backing up databases | hr |
|D |Volume of content that can be backed up | GB |
| |within the target window, given the chosen | |
| |backup method and tools | |
Given the two values for volume of content (B and D), the maximum manageable database size for the organization is the lesser of the two values.
After you determine the target size for content databases, you can calculate the number of site collections that can be supported in each database. The following table shows the number of site collections per database based on database size and site collection size limits. Site collection size limits include the space allocated to the second-stage Recycle Bin.
|Database size |500 MB site collection size limit |750 MB site collection size limit |
|Create team site collections |By default, only members of the Farm |On the Central Administration site, on the |
| |Administrators group can create site |Application Management page, in the |
| |collections for team sites. |Application Security section, click |
| |If you want more users to be able to create |Self-service site management. |
| |team site collections, use the Self-Service |Users and groups that have the Use |
| |Site Management feature in Central |Self-Service Site Creation permission can |
| |Administration. For more information, see |create site collections when self-service |
| |Plan process for creating sites (Windows |site management is turned on. |
| |SharePoint Services). | |
| |Alternatively, you can enable Self-Service | |
| |Site Management for a subset of people in the| |
| |organization by turning on self-service site | |
| |management, but limiting the Self-Service | |
| |Site Creation permission to one or more | |
| |security groups, or by limiting access to the| |
| |Self-Service Site Management New SharePoint | |
| |Site page (Scsignup.aspx) to specific | |
| |security groups. | |
|Create subsites within site collections |By default, members of a team site who have |On the Site Settings page, add or delete |
| |the Create Subsites permission (included in |members who belong to the Ownersgroup. |
| |the Full Control permission level) can create| |
| |subsites in a site collection. We recommend | |
| |that you allow site owners to manage | |
| |permissions for creating subsites, instead of| |
| |globally preventing users from creating | |
| |subsites. | |
|View and contribute to team sites |Even if an employee is prevented from |On the Site Settings page, add or delete |
| |creating a team site, they can still view and|members who belong to the Visitors group. |
| |contribute to documents on other team sites, | |
| |based on the permissions that site owners | |
| |apply. We recommend that you allow site | |
| |owners to manage permissions to content on | |
| |their sites, instead of globally preventing | |
| |users from participating in this kind of | |
| |collaboration. | |
|Cannot access team site content |You can block users in the organization from |On the Application Management page, in the |
| |accessing team site content completely by |Application Security section, click Policy |
| |creating a policy for the Web application. |for Web application. On the Policy for Web |
| |Use this option cautiously because this |Application page, select the users whom you |
| |prevents all collaboration on team sites that|want to block, click Edit Permissions of |
| |have the users who are blocked. A policy on |Selected Users, and then on the Edit Users |
| |the Web application overrides any other |page, in the Permission Policy Levels |
| |permissions that are configured within the |section, select Deny All. |
| |Web application. | |
Plan alternate access mappings (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
In this article:
• About alternate access mappings
• Reverse proxy publishing
• Alternate access mapping integration with authentication providers
• Alternate access mapping integration with Web application policies
• Alternate access mapping and external resource mapping
• Troubleshooting alternate access mappings
Alternate access mappings direct users to the correct URLs during their interaction with Windows SharePoint Services 3.0 (while browsing to the home page of a Windows SharePoint Services 3.0 Web site, for example). Alternate access mappings enable Windows SharePoint Services 3.0 to map Web requests to the correct Web applications and sites, and they enable Windows SharePoint Services 3.0 to serve the correct content back to the user.
Alternate access mappings have been implemented because there are common Internet deployment scenarios in which the URL of a Web request received by Internet Information Services (IIS) is not the same as the URL that was typed by an end user. This is most likely to occur in deployment scenarios that include reverse proxy publishing and load balancing.
[pic] Note:
Alternate access mappings must be configured for load balancing, even though it generally does not apply to host header site collections. The default zone public URL should be set to a domain URL that is appropriate for all users to see. Unless this is done, the names of Web servers or their IP addresses may be displayed in parameters passed between pages within Windows SharePoint Services 3.0.
About alternate access mappings
Alternate access mappings enable a Web application that receives a request for an internal URL, in one of the five authentication zones, to return pages that contain links to the public URL for the zone. You can associate a Web application with a collection of mappings between internal and public URLs. Internal refers to the URL of a Web request as it is received by Windows SharePoint Services 3.0. Public refers to the URL of an externally accessible Web site. The public URL is the base URL that Windows SharePoint Services 3.0 uses in the pages that it returns. If the internal URL has been modified by a reverse proxy device, it can differ from the public URL.
[pic] Note:
Host-named site collections cannot use alternate access mappings. Host-named site collections are automatically considered to be in the Default zone, and the URL of the request must not be modified between the end user and the server.
Multiple internal URLs can be associated with a single public URL. Mapping collections can contain up to five authentication zones, but each zone can only have a single public URL. Mapping collections correspond to the following authentication zones:
• Default
• Intranet
• Internet
• Custom
• Extranet
Reverse proxy publishing
A reverse proxy is a device that sits between end users and your Web server. All requests to your Web server are first received by the reverse proxy device and, if those requests pass the proxy's security filtering, the proxy forwards the requests to your Web server. Reverse proxies can perform advanced functionality, such as receiving a Web request over the Internet by using HTTPS (Hypertext Transfer Protocol over Secure Socket Layer), but forward the request to the server by using HTTP. This is referred to as "off-box SSL termination." Reverse proxies can forward the request to a port number other than the port on which the request was originally received. Reverse proxies can also change the HTTP Host header field.
Windows SharePoint Services 3.0 is compatible with many reverse proxy servers, but in the following example the publishing rule is from the reverse proxy software, Microsoft Internet Security and Acceleration (ISA) Server 2006. ISA Server 2006 includes a publishing wizard to help you create a publishing rule for Windows SharePoint Services 3.0. After the rule is created, you can modify it at any time.
[pic] Note:
Some reverse proxy devices can modify the path of a request (the portion of the URL that comes after the hostname and port number) in such a way that a request sent by the user to , for example, is forwarded to the Web server as .
This is referred to as an asymmetrical path. Windows SharePoint Services 3.0 does not support asymmetrical paths. The path of the URL must be symmetrical between the public URL and the internal URL. In the preceding example, this means that the "/sharepoint/default.aspx" portion of the URL must not be modified by the reverse proxy device.
Configuring the reverse proxy server
The first two figures in this example show a modified publishing rule where the Forward the original Host header option is turned off to help demonstrate the flexibility of alternate access mapping. If the Forward the original Host header option is selected, the public hostname also serves as the internal hostname when configuring alternate access mapping.
The following figures show the Listener tab and Public Name tab on the properties sheet for the rule. These properties define the URL to use to access your Web application. This URL is actually the URL of your reverse proxy server, which forwards the request to your server running Windows SharePoint Services 3.0.
[pic] [pic] The end user's URL is made up of the public protocol, the public hostname, and the public port number, as shown in the following table.
|Public protocol | |Public Hostname |
|Windows |The standard IIS Windows authentication |Anonymous |
| |methods are supported. |Basic |
| | |Digest |
| | |Certificates |
| | |Kerberos (Integrated Windows) |
| | |NTLM (Integrated Windows) |
| forms |Windows SharePoint Services 3.0 adds support |Lightweight Directory Access Protocol (LDAP) |
| |for identity management systems that are not |SQL database or other database |
| |based on Windows by integrating with the |Other -based forms authentication |
| | forms authentication system. |solutions |
| |authentication enables Windows SharePoint | |
| |Services 3.0 to work with identity management| |
| |systems that implement the MembershipProvider| |
| |interface. You do not need to rewrite the | |
| |security administration pages or manage | |
| |shadow Active Directory directory service | |
| |accounts. | |
|Web Single Sign-On (SSO) |Windows SharePoint Services 3.0 supports |Active Directory Federation Services (AD FS) |
| |federated authentication through Web SSO |Other identity management systems |
| |vendors. Web SSO enables SSO in environments | |
| |that include services running on disparate | |
| |platforms. You do not need to manage separate| |
| |Active Directory accounts. | |
Authentication of system accounts
forms authentication and Web SSO can be used to authenticate only user accounts. The process accounts used to connect to Microsoft SQL Server database software and run the Web farm must be Windows accounts, even when using alternative methods of authentication to authenticate users.
Windows SharePoint Services 3.0 supports SQL Server authentication and local computer process accounts for farms that are not running Active Directory. For example, you can implement local accounts by using identical user names and passwords across all servers within a farm.
Configure authentication
Although configuring Windows authentication is a straightforward process, configuring authentication to use forms or Web SSO requires more planning. This section provides a summary of how authentication is configured in Windows SharePoint Services 3.0. This information will help you understand how to put together an authentication strategy for your solution and determine who in your organization needs to be involved in planning for authentication.
Configure authentication for SharePoint Web applications
Authentication in Windows SharePoint Services 3.0 is configured at the SharePoint Web application level. The following diagram illustrates a Windows SharePoint Services server farm that is configured to host sites for multiple companies. Authentication is configured separately for each company.
[pic] When you initially create or extend a Web application, you are presented with a limited number of authentication options (Kerberos, NTLM, and anonymous). If you are using one of these methods, you can configure authentication when you create or extend the Web application.
The following illustration shows the limited authentication choices that are available when you initially create or extend a Web application:
[pic] However, if you are using different authentication settings, select the default authentication options, and then configure authentication after the Web application is created or extended. (To do so, in Central Administration, on the Application Management page, in the Application Security section, select Authentication providers, and then click the zone to open the Edit Authentication page.) The settings that are configured on this page depend on the type of authentication that is selected: Windows, forms, or Web SSO.
The following illustration shows the Edit Authentication page:
[pic] Depending on the authentication choices that you select in Central Administration, additional configuration might be necessary. The following table summarizes the configuration steps based on the authentication method. This table also indicates if specialized roles in addition to SharePoint Administrator are needed.
|Authentication method |Additional configuration |Specialized roles |
|Anonymous, |None |None |
|Basic |None |None |
|Digest |Configure digest authentication directly in |None |
| |IIS. | |
|Certificates |Select Windows authentication in Central |Windows Server 2003 administrator, to obtain |
| |Administration. |and configure certificates |
| |Configure IIS for certificate authentication.| |
| | | |
| |Enable Secure Sockets Layer (SSL). | |
| |Obtain and configure certificates from a | |
| |certification authority (CA). | |
|NTLM (Integrated Windows) |None |None |
|Kerberos (Integrated Windows) |Configure the Web application to use Kerberos|IIS administrator |
| |authentication. | |
| |Configure a Service Principal Name (SPN) for | |
| |the domain user account that is used for the | |
| |application pool identity (application pool | |
| |process account). | |
| |Register the SPN for the domain user account | |
| |in Active Directory. | |
|Forms |Register the membership provider in the | developer |
| |Web.config file for the SharePoint Web |Administrator of the identity management |
| |application. |system you are connecting to |
| |Register the role manager in the Web.config | |
| |file for the SharePoint Web application | |
| |(optional). | |
| |Register the membership provider in the | |
| |Web.config file for the Central | |
| |Administration site. | |
|Web SSO |In addition to configuration steps required | developer |
| |for forms authentication, register an|Administrator of the identity management |
| |HTTP module for the Web SSO provider. |system you are connecting to |
Connect to identity management systems that are external or not based on Windows
To use forms or Web SSO to authenticate users against an identity management system that is not based on Windows or that is external, you must register the membership provider in the Web.config file. In addition to registering a membership provider, you can register a role manager as well. Windows SharePoint Services 3.0 uses the standard role manager interface to gather group information about the current user. Each role is treated like a domain group by the authorization process in Windows SharePoint Services 3.0. You register role managers in the Web.config file the same way you register membership providers for authentication.
If you want to manage membership user or roles from the Central Administration site, you can optionally register the membership provider and the role manager in the Web.config file for the Central Administration site (in addition to registering these in the Web.config file for the Web application that hosts the content).
Ensure that the membership provider name and role manager name that you registered in the Web.config file is the same as the name that you entered in the Central Administration Authentication.aspx page. If you do not enter the role manager in the Web.config file, the default provider specified in the machine.config file might be used instead.
For example, the following string in a Web.config file specifies a SQL membership provider:
For additional information about using forms authentication to connect to a SQL Server authentication provider, see Authentication samples (Windows SharePoint Services).
Finally, if you are using Web SSO to connect to an external identity management system, you must also register an HTTP module for the Web SSO. An HTTP module is an assembly that is called on every request made to your application. HTTP modules are called as part of the request pipeline. For more information, see Introduction to HTTP Modules ().
Integrating with forms authentication places additional requirements on the authentication provider. In addition to registering the various elements in the Web.config file, the membership provider, role manager, and HTTP module must be programmed to interact with Windows SharePoint Services 3.0 and methods, as indicated in the following table:
|Category |Description |
|Membership provider |To work with Windows SharePoint Services 3.0, the membership provider|
| |must implement the following methods: |
| |GetUser (String) Windows SharePoint Services 3.0 calls this method |
| |to resolve user names during invitations and to get the user's |
| |display name. |
| |GetUserNameByEmail Windows SharePoint Services 3.0 calls this |
| |method to resolve user names in invitations. |
| |FindUsersByName, FindUsersByEmail Windows SharePoint Services 3.0 |
| |calls these methods to populate the user picker control on the Add |
| |Users page. If the membership provider does not return any users, the|
| |picker will not function and administrators will need to type the |
| |user name or e-mail address in the Add User text box. |
|Role manager |The role manager must implement the following methods: |
| |RoleExists Windows SharePoint Services 3.0 calls this method during|
| |invitations to verify that a role name exists. |
| |GetRolesForUser Windows SharePoint Services 3.0 calls this method |
| |at access check to gather the roles for the current user. |
| |GetAllRoles Windows SharePoint Services 3.0 calls this method to |
| |populate the group and role picker. If the role provider does not |
| |return any groups or roles, the Windows SharePoint Services 3.0 |
| |picker will not function and the administrator will need to type the |
| |name of the role in the Add User text box. |
|HTTP module |The HTTP module must handle the following events: |
| |AuthenticateRequest This event is called when is ready to |
| |authenticate the user. The Web SSO module must unpack the user's |
| |authentication cookie and set the HttpContext.User object with the |
| |identity of the current user. |
| |EndRequest This is the last event in the pipeline. This |
| |event is called just before returning the code to the client. The Web|
| |SSO module must capture 401 responses coming from Windows SharePoint |
| |Services 3.0 and turn these into an appropriate 302 redirect for |
| |authentication to the Web SSO logon server. |
Enabling Anonymous Access
You can enable anonymous access for a Web application in addition to configuring a more secure authentication method. With this configuration, administrators of sites within the Web application can choose to allow anonymous access. If anonymous users want to gain access to secured resources and capabilities, they can click a logon button to submit their credentials.
Using different authentication methods to access a site
You can configure Web applications in Windows SharePoint Services 3.0 to be accessed by up to five different authentication methods or identity management systems. The following figure illustrates a partner application that is configured to be accessed by users from two different identity management systems. Internal employees are authenticated by using one of the standard Windows authentication methods. Employees of the partner company are authenticated against their own company's identity management system.
[pic] To configure a Web application to be accessed by two or more different authentication systems, you must configure additional zones for the Web application. Zones represent different logical paths of gaining access to the same physical application. With a typical partner application, employees of a partner company access the application through the Internet, while internal employees access the application directly through the intranet.
To create a new zone, extend the Web application. On the Extend Web Application to Another IIS Web Site page, in the Load Balanced URL section, specify the URL and zone type. The zone type is simply a category name applied to the zone and does not affect the configuration of the zone.
After extending the Web application, you can configure a separate authentication method for the new zone. The following figure shows the Authentication Providers page for a Web application that is configured by using two different zones. The default zone is the zone used by internal employees. The Internet zone is configured for partner access and uses forms to authenticate partner employees against the partner identity management system.
[pic]
Plan authentication for crawling content
To perform successful crawls of content in a Web application, you must understand the authentication requirements of the index component of the search server (also known as the crawler). This section describes how to configure authentication for Web applications to ensure that the content in those Web applications can be successfully crawled.
When a farm administrator creates a Web application by using all default settings, the default zone for that Web application is configured to use NTLM. The farm administrator can change the authentication method for the default zone to any authentication method supported by Windows SharePoint Services 3.0.
The farm administrator can also extend a Web application one or more times to enable additional zones. Up to five zones can be associated with a particular Web application, and each zone can be configured to use any authentication method supported by Windows SharePoint Services 3.0.
Order in which the crawler accesses zones
When planning the zones for a Web application, consider the polling order in which the crawler accesses zones when attempting to authenticate. The polling order is important, because if the crawler encounters a zone configured to use basic, digest, or Kerberos authentication, authentication fails and the crawler does not attempt to access the next zone in the polling order. If this occurs, the crawler will not crawl content on that Web application.
[pic] Tip:
Ensure that a zone configured for NTLM is earlier in the polling order than a zone configured for basic, digest, or Kerberos authentication.
The crawler polls the zones in the following order:
• Default zone
• Intranet zone
• Internet zone
• Custom zone
• Extranet zone
The following figure shows the decisions that are made by the authentication system when the crawler attempts to authenticate:
[pic] The following table describes the actions associated with each callout in the figure:
|Callout |Action |
|1 |Crawler attempts to authenticate by using the default zone. |
| |[pic] Note: |
| |The crawler always attempts to use the default zone first when |
| |attempting to authenticate for a particular Web application. |
| | |
|2 |If the zone is configured for NTLM, the crawler is authenticated and |
| |proceeds to the authorization phase. |
|3 |If the zone is configured for basic, digest, or Kerberos |
| |authentication, authentication fails and the crawler does not attempt|
| |to authenticate by using another zone. This means the content is not |
| |crawled. |
|4 |If there are no more zones in the polling order, authentication fails|
| |and the content is not crawled. |
|5 |Crawler attempts to authenticate by using the next zone in the |
| |polling order. |
If you configure the default zone to use an authentication method that the crawler does not support — for example, forms authentication or Web SSO — you must create at least one additional zone and configure this zone to use NTLM authentication. Consider the following scenario.
Authentication scenario
The farm administrator creates a Web application and configures it to use forms authentication. Because the farm administrator wants the content in the Web application to be crawled and indexed, and because she knows that the crawler requires a zone configured with NTLM, the farm administrator extends the Web application and configures the intranet zone to use NTLM.
When the crawler attempts to authenticate by using the default zone, the authentication system determines that the crawler and the zone are not configured to use the same authentication method. Because the zone is not configured for basic, digest, or Kerberos authentication and there is at least one additional zone in the polling order, the crawler attempts to authenticate by using the intranet zone. Because the intranet zone is configured to use NTLM and the crawler also uses NTLM, authentication succeeds.
In addition to properly configuring the authentication method, you must ensure that the crawler is authorized to crawl content within the Web application. To do this, you must ensure that the credentials used for the content access account have the Full Read permission level or higher on the Web application that you want to crawl. Farm administrators can use the Policy for Web Application page in Central Administration to create a policy that gives the content access account the Full Read permission level on a particular Web application.
Crawling host-named site collections
The process and rules illustrated in the previous figure do not apply to host-named site collections. This is because host-named site collections are available only through the default zone. If you do not configure the default zone to use NTLM when deploying host-named site collections, you must configure an alternate method for the index component to access content.
For more information about crawling host-named site collections that are not configured for NTLM authentication, see the following articles:
• Prepare to crawl host-named sites that use forms authentication
• Prepare to crawl host-named sites that use Basic authentication
Planning zones for your authentication design
If you plan to implement more than one authentication method for a Web application by using zones, use the following guidelines:
• Use the default zone to implement your most secure authentication settings. If a request cannot be associated with a specific zone, the authentication settings and other security policies of the default zone are applied. The default zone is the zone that is created when you initially create a Web application. Typically, the most secure authentication settings are designed for end-user access. Consequently, the default zone will likely be the zone that is accessed by end users.
• Use the minimum number of zones that is required by the application. Each zone is associated with a new IIS site and domain for accessing the Web application. Only add new access points when these are required.
• If you want content within the Web application to be included in search results, ensure that at least one zone is configured to use NTLM authentication. NTLM authentication is required by the index component to crawl content. Do not create a dedicated zone for the index component unless necessary.
Choose methods of authentication allowed in your environment
In addition to understanding how authentication is configured, planning for authentication includes:
• Considering the security context or environment of your Web application in Windows SharePoint Services 3.0.
• Evaluating the recommendations and tradeoffs for each method.
• Understanding how user credentials and related identity data are cached and consumed by Windows SharePoint Services 3.0.
• Understanding how user accounts are managed.
• Ensuring that authentication methods are compatible with browsers that are used by your users.
|Worksheet action |
|Use the Authentication methods worksheet () to identify which authentication |
|methods you are willing to support in your environment and to record your decisions and recommendations for each. This worksheet will be |
|used when planning authentication methods for individual Web applications in Windows SharePoint Services 3.0. |
Recommendations for specific security environments
Your choice of authentication methods will primarily be driven by the security context of your application. The following table provides recommendations based on the most common security environments:
|Environment |Considerations |
|Internal intranet |At a minimum, protect user credentials from plain view. Integrate |
| |with the user management system that is implemented in your |
| |environment. If Active Directory is implemented, use the Windows |
| |authentication methods built into IIS. |
|External secure collaboration |Configure a separate zone for each partner company that connects to |
| |the site. Use Web SSO to authenticate against each partner’s own |
| |identity management system. This eliminates the need to create |
| |accounts in your own identity management system and also ensures that|
| |contributor identities continue to be maintained and validated by |
| |partner employers. If a contributor is no longer employed by a |
| |partner company, the contributor cannot continue to gain access to |
| |your partner application. |
|External anonymous |Enable anonymous access (no authentication) and allow Read-Only |
| |permissions for users who connect from the Internet. If you want to |
| |provide targeted or role-based content, you can use forms |
| |authentication to register users by using a simple database of user |
| |names and roles. Use the registration process to identify users by |
| |role (such as doctor, patient, or pharmacist). When users log on, |
| |your site can present content that is specific to the user role. In |
| |this scenario, authentication is not used to validate credentials or |
| |to limit who can access the content; the authentication process |
| |simply provides a method of targeting content. |
Recommendations and tradeoffs for authentication methods
Understanding the advantages, recommendations, and tradeoffs for each specific authentication method can help you to determine which methods to use in your environment. The following table highlights the recommendations and tradeoffs for each authentication method. For more information about each of the Windows authentication methods supported by IIS, see IIS Authentication ().
|Authentication method |Advantages and recommendations |Tradeoffs |
|Windows |Authenticate by using your existing Active |Each of the methods has its own associated |
| |Directory accounts. |pros and cons. |
| |Simplify user management. |Some IIS authentication protocols are not |
| |Take advantage of Active Directory groups |supported by all Web browsers. |
| |when configuring Windows SharePoint Services | |
| |3.0 authorization. | |
| |Avoid writing custom code. | |
| forms |Set up Windows SharePoint Services 3.0 in an |Requires customization of the Web.config |
| |environment that does not use Active |file. |
| |Directory (does not require Windows |Subject to replay attacks for the lifetime of|
| |accounts). |the cookie, unless using SSL Transport Layer |
| |Authenticate against two or more different |Security (TLS). |
| |identity management systems when creating | |
| |partner applications. | |
| |Implement a custom authentication scheme | |
| |using arbitrary criteria. | |
| |Authenticate users coming from the Internet. | |
|Web SSO |Implement Windows SharePoint Services 3.0 in |Requires an existing federated authentication|
| |an environment that uses federated |system. |
| |authentication to secure digital identities |Requires customization of the Web.config |
| |across organizations and security |file. |
| |environments. |AD FS requires SSL. Other SSO systems might |
| |Implement Windows SharePoint Services 3.0 in |have other requirements. |
| |an environment that provides SSO to services | |
| |running on disparate platforms, including | |
| |environments that do not use Active | |
| |Directory. | |
| |Take advantage of AD FS. | |
| |Authenticate against two or more different | |
| |identity management systems when creating | |
| |partner applications. | |
Management of user identity information
How user credentials and other identity information is processed and used by Windows SharePoint Services 3.0 can influence your decision about which of the authentication options is best for your intended purpose. This section details how user identity information is processed in the following categories:
• Binary IDs How user binary identifiers (IDs) are created or used by Windows SharePoint Services 3.0.
• Caching The process of retaining a user's identity for a period of time to avoid repeating the authentication process for each request.
• Role and group membership In addition to determining who users are, the authentication process also determines which groups or roles a user belongs to. This information is used during the authorization process to determine which actions a user has permissions to perform. For the purpose of authorization, Windows SharePoint Services 3.0 treats Active Directory groups and roles as the same type of entity.
The following table details how Windows SharePoint Services 3.0 manages user binary IDs, cached user data, and role and group membership data depending on which authentication method is used:
|Item |Windows authentication | forms and Web SSO |
|Binary IDs |Windows SharePoint Services 3.0 uses the |Windows SharePoint Services 3.0 creates a |
| |Windows security identifier (SID). |unique binary ID by combining the provider |
| | |name with the user name. |
|Caching |User credentials are cached and managed by | uses an encrypted cookie to keep the |
| |IIS, Internet Explorer, and Windows. |user's credentials for the duration of a |
| | |session. |
|Role and group membership |Windows maintains the list of Active |When a role manager is registered, Windows |
| |Directory domain groups the user belongs to |SharePoint Services uses the standard role |
| |in the access token. Windows SharePoint |manager interface to gather group information|
| |Services 3.0 uses information stored in the |about the current user. Each role is |
| |access token. |treated like a domain group by the |
| | |authorization process. can cache the |
| | |roles the user belongs to in a cookie, |
| | |depending on the settings that are configured|
| | |in the Web.config file. |
Management of user accounts
Understanding how Windows SharePoint Services 3.0 handles typical user account management tasks can also influence which authentication method you choose. Generally, users who are members of an authentication provider in one zone can manage accounts across all zones as long as they are granted permissions. The information in the following list applies regardless of which authentication method is implemented:
• Adding and inviting new users You can add or invite a new user from any zone and all authentication methods that are configured if the membership provider and role manager are registered in the current Web.config file. When you add a new user, Windows SharePoint Services 3.0 resolves the user name against the following sources in the following order:
• The UserInfoList table stored by Windows SharePoint Services 3.0. User information will be in this list if users have already been added to another site.
• The authentication provider that is configured for the current zone. For example, if a user is a member of the authentication provider that is configured for the default zone, Windows SharePoint Services 3.0 first checks this associated membership provider.
• All other authentication providers.
• Deleting users User accounts are marked as deleted in the Windows SharePoint Services 3.0 database. However, the user record is not removed.
Some user account management behaviors within Windows SharePoint Services 3.0 differ, depending on the authentication provider. The following table highlights several common user account tasks that differ depending on the authentication method that is implemented:
|Task |Windows authenticated accounts | forms–authenticated and Web |
| | |SSO-authenticated accounts |
|Adding and inviting new users |Windows SharePoint Services 3.0 validates |Windows SharePoint Services 3.0 calls the |
| |user identities by using Active Directory. |membership provider and the role manager to |
| | |verify that the user and roles exists. |
|Changes to logon names |Updated user names are automatically |You must delete the old account name and then|
| |recognized by Windows SharePoint Services |add the new account name. Permissions cannot |
| |3.0. New entries are not added to the |be migrated. |
| |UserInfoList table. | |
|Logging on |If Integrated Windows authentication |Windows SharePoint Services 3.0 provides a |
| |(Kerberos or NTLM) is used and the browser is|standard logon page for use with forms |
| |configured to automatically log on, users do |authentication. This page includes the |
| |not need to manually log on to SharePoint |following fields: user name, password, sign |
| |sites. By default, Internet Explorer is |in automatically (to persist the cookie). You|
| |configured to automatically log on to |can create your own logon page to add |
| |intranet sites. If a logon is required (for |additional logon controls (for example, |
| |example, sites that require a different set |create a new account, or reset password). |
| |of credentials), users are prompted only for | |
| |a user name and password. However, if basic | |
| |authentication is used, or the user is using | |
| |a browser that is not configured to | |
| |automatically log on, users might be prompted| |
| |for logon credentials when they access a | |
| |SharePoint site. | |
Browser support
Not all browsers work with each of the authentication methods that are supported. Before selecting authentication methods to allow in your environment, determine which browsers you need to support. Then, determine which authentication methods are supported by the browsers. Internet Explorer works with each of the supported authentication methods. Additional browsers that are supported by Windows SharePoint Services 3.0 include:
• Netscape 8.0
• Netscape 7.2
• Mozilla 1.7.12
• Firefox 1.5
• Safari 2.02
Worksheet
Use the following worksheet to record which authentication methods are appropriate for your environment:
• Authentication methods worksheet ()
The following table represents an example of a completed worksheet:
|Authentication method |Allow |Don't allow |Notes and recommendations |
|Anonymous | |x | |
|Basic | |x | |
|Digest | |x | |
|Certificates | |x | |
|NTLM (Integrated Windows) |x | |"Use NTLM for all department sites|
| | | |except finance." |
|Kerberos (Integrated Windows) |x | |"Use Kerberos authentication for |
| | | |sites with a high security service|
| | | |level agreement." |
| forms |x | |"Use forms authentication to allow|
| | | |partner company access to sites |
| | | |hosted in the partner extranet. We|
| | | |currently allow authentication |
| | | |against the following identity |
| | | |management systems: Active |
| | | |Directory, LDAP. Work with Sidney |
| | | |Higa to develop authentication |
| | | |settings for use with forms |
| | | |authentication." |
|Web SSO |x | |"Use this method for partner |
| | | |applications only if a partner |
| | | |company is participating in |
| | | |federated identity management |
| | | |systems. See David Jones for more |
| | | |information." |
Additional Notes:"Work with Denise Smith to sign off on all authentication settings for SharePoint Web applications prior to implementing."
Plan authentication settings for Web applications (Windows SharePoint Services)
Topic Last Modified: 2016-05-08
In this article:
• Plan authentication settings
• Plan authentication exclusions
• Worksheet
This article discusses the authentication configuration settings that need to be planned for individual Web applications in Windows SharePoint Services 3.0. Use this article with the Web application authentication settings worksheet (.) Complete a separate worksheet for each of the following elements that are a part of your solution design in Windows SharePoint Services 3.0:
• New or extended Web applications in Windows SharePoint Services 3.0.
• Additional zones within a Web application (other than the default zone). Include zones that are created for the search account.
Use completed worksheets with Deploy and configure SharePoint sites (Windows SharePoint Services).
Plan authentication settings
This section discusses each of the settings on the Edit Authentication page of the SharePoint Central Administration Web site. To get to this page, on the Application Management page, in the Application Security section, click Authentication providers. Click the zone that you want to modify authentication settings for. The Edit Authentication page opens.
Depending on the authentication options you choose, you might be able to specify your authentication settings directly when you create or extend the Web application in Windows SharePoint Services 3.0. However, not all options are available when you initially create or extend a Web application. If you cannot configure authentication when you create or extend the Web application, you can accept the default authentication settings initially and then edit the settings on the Edit Authentication page.
Authentication type
Select the method that you want to use. If you are planning to allow anonymous access instead of implementing an authentication method listed in this section, select Windows authentication.
If you select Windows, specify the Windows authentication method in the IIS Authentication Settings section of the Edit Authentication page. If you select Forms or Web single sign on, the options on the Edit Authentication page change to allow you to enter the membership provider name and the role manager name.
If you want to use Certificate authentication or Kerberos authentication, review the following table to identify the additional configuration steps required to configure these methods.
|Authentication method |Additional configuration |Specialized roles |
|Certificates |Select Windows authentication in Central |Microsoft Windows Server 2003 administrator, |
| |Administration. |to obtain and configure certificates |
| |Configure Internet Information Services (IIS)| |
| |for certificates. | |
| |Enable Secure Sockets Layer (SSL). | |
| |Obtain and configure certificates from a | |
| |certification authority (CA). | |
|Kerberos (Integrated Windows) |Select Kerberos authentication in Central |IIS administrator |
| |Administration. | |
| |Configure a Service Principal Name (SPN) for | |
| |the domain user account that is used for the | |
| |application pool identity (application pool | |
| |process account). | |
| |Register the SPN for the domain user account | |
| |in Active Directory. | |
|Worksheet action |
|Record the additional configuration necessary in the Additional Configuration section of the Web application authentication settings |
|worksheet (). |
Anonymous access
Indicate whether anonymous access is allowed. If you selected Forms or Web single sign-on in the Authentication Type section, select the Enable anonymous access check box.
Client integration
You can disable client integration, which removes features that start client applications. This is the optimal configuration for some scenarios, such as publishing read-only content to the Web for anonymous access. Additionally, if you select forms authentication or Web Single Sign-On (SSO) authentication, client integration is set to No by default.
If you have installed Windows SharePoint Services 3.0 with Service Pack 2 (SP2), client integration is supported, except for Outlook integration. All other client integration is supported, including SharePoint Designer authoring.
[pic] Note:
If you have not installed Windows SharePoint Services 3.0 with SP2, client integration is disabled by default when you use forms-based authentication. This is because client integration does not natively support forms-based authentication prior to Windows SharePoint Services 3.0 with SP2.
Expected behaviors when client integration is disabled
When client integration is disabled, sites behave in the following ways:
• Links that start client applications are not visible.
• Documents are opened in the browser. Documents cannot be opened by client applications.
• Users cannot edit documents on the site directly from the client applications. However, users can download the document, edit the document locally, and then upload the document.
The following table lists specific menu commands and features that are not available when client integration is disabled.
|Category |Command or feature that is unavailable |
|Toolbars |New document |
| |Work in Microsoft Office Outlook |
| |Open in Windows Explorer |
| |Export to spreadsheet |
| |Open with Database Program |
|Editing documents |Edit in Microsoft Office applications such as Word and Excel. |
|Views |Explorer view |
| |Create an Access view |
|Picture libraries |Upload multiple |
| |Edit picture |
| |Download |
| |Send to |
|Slide libraries |Publish slide |
| |Send to Microsoft Office PowerPoint |
|Other |Discuss |
| |Connect to Office Outlook |
Behaviors of specific authentication methods
In addition to the deployment scenario (such as publishing read-only content), the choice of authentication method might determine how to configure client integration. Some authentication methods behave differently with client applications. In some cases, the behavior depends on whether client browsers are configured to use persistent cookies or session cookies.
The following table summarizes the potential behaviors of client integration when used with specific authentication methods.
|Authentication method |Behavior |
|Basic |Users are prompted to enter their credentials each time they access a|
| |document. Other features might also require that they enter their |
| |credentials again. |
| forms and Web SSO |If the following conditions are true, a persistent cookie is created:|
| |The authentication provider supports persistent cookies. |
| |The user clicks Sign me in automatically when they log in. |
| |The persistent cookie is shared by all applications that use the same|
| |cookie store and the user can open documents in the client |
| |applications. The persistent cookie is created with a default |
| |time-out value of 30 minutes. This value can be changed by adding or |
| |updating the time-out parameter in the forms node in the Web.config |
| |file. For example: |
| | |
| |When the cookie expires, client integration stops working. If users |
| |are in a browser, they will be prompted to re-enter credentials. |
| |If the authentication provider does not support persistent cookies or|
| |the user did not click Sign me in automatically when they logged in, |
| |a session cookie is used. A session cookie is only accessible by the |
| |browser. The user will not be able to open document directly in the |
| |client applications. |
| |If the authentication provider does not provide support for |
| |persistent cookies or if persistent cookies are not allowed in your |
| |environment, turn off client integration. For example, Active |
| |Directory Federation Services (AD FS) does not provide support for |
| |persistent cookies. |
|Anonymous |When opening a document, users are repeatedly prompted for their |
| |credentials. If they click Cancel in the authentication dialog box 10|
| |times, the site might open the document by using the client |
| |application. Because of this poor experience, it is recommended that |
| |client integration be turned off for anonymous access scenarios. |
Using the Windows Vista operating system with Internet Explorer 7
In Windows Vista, Internet Explorer 7 includes an additional security feature called protected mode. By default, protected mode is enabled for the Internet, Intranet, and Restricted Sites zones. Because this feature places persistent cookies in a location that prevents sharing across applications, client integration does not work as intended.
To configure Internet Explorer 7 to work with client integration, do one of the following:
• Disable protected mode.
• If protected mode is enabled, add SharePoint sites to the Trusted sites zone in Internet Explorer.
For information about disabling protected mode, see "Configuring Protected Mode" in Understanding and Working in Protected Mode Internet Explorer ().
Testing client integrations settings
If you are uncertain about how to configure the client integration setting, test the results in a test environment before deploying sites into production. If this setting is changed after it is applied, sites and client applications might behave unusually.
|Worksheet action |
|On the Web application authentication settings worksheet (), in the Enable Client|
|Integration section, select Yes or No. |
Settings for forms authentication and Web SSO
If you are implementing forms authentication or Web SSO, you must develop the configuration settings to insert into the applicable Web.config files. See Authentication samples (Windows SharePoint Services) to review examples of properly configured strings for several common scenarios.
|Worksheet action |
|On the Web application authentication settings worksheet (), enter the following |
|two types of information: |
|Name The name of the membership provider, role manager, and HTTP module (if applicable). These names appear in the Central |
|Administration site. |
|Web.config configuration Paste the appropriate configuration strings into the worksheet. These strings can be copied from the worksheet |
|into the Web.config files when the Web application is deployed. |
Ensure that the MembershipProvider name and RoleManager name you registered in the Web.config file is the same as the name that you entered in the Central Administration authentication.aspx page. If you do not enter the role manager in the Web.config file, the default provider specified in the machine.config file might be used instead.
For example, the following string in a Web.config file specifies a SQL membership provider:
For more information about requirements for membership providers and role managers, see "Connect to identity management systems that are not based on Windows or that are external" in Plan authentication methods (Windows SharePoint Services).
Plan authentication exclusions
If you are implementing forms authentication or Web SSO, you need to plan for authentication exclusions. If you are implementing Windows authentication, you do not need to read this section.
When you create or extend a Web application or when you add a zone to a Web application, IIS creates a new Web site. Authentication settings that are registered in the Web.config file for this Web application are inherited by virtual directories below the Web site. Virtual directories that are added below a Web application in Windows SharePoint Services 3.0 are not managed by Windows SharePoint Services 3.0 and are considered to be excluded virtual directories.
If you are implementing forms authentication or Web SSO and you plan to add virtual directories below these Web sites, you need to decide whether you want these excluded virtual directories to inherit the forms authentication or Web SSO settings.
|Worksheet action |
|On the Web application authentication settings worksheet (), indicate whether |
|excluded virtual directories will be added in IIS beneath the Web site that corresponds to this Web application in Windows SharePoint |
|Services 3.0. If excluded virtual directories will be added, indicate whether authentication settings should be inherited. |
Use the following procedure to configure IIS so authentication settings are not inherited.
Configure IIS so authentication settings are not inherited
1. Add a new IIS virtual directory beneath the IIS Web site that corresponds to the applicable Web application or zone in Windows SharePoint Services 3.0.
2. In IIS Manager, right-click the new virtual directory, and then click Properties.
3. Click the Virtual Directory tab.
4. Click Create (this makes the virtual directory an application).
5. Click Configuration.
6. Select the wildcard application maps, and then click Remove.
7. Click Yes, and then click OK.
8. Create a new Web.config file at the root of the new virtual directory file system path, and add the following entries:
Worksheet
Use the following worksheet to plan and record configuration settings for each of your Web applications in Windows SharePoint Services 3.0.
• Web application authentication settings worksheet ()
Authentication samples (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
In this article:
• SQL membership provider
• Active Directory membership provider
• Web SSO with AD FS
This article includes sample configuration settings for several common forms authentication and Web single sign-on (SSO) authentication providers.
SQL membership provider
The following table provides examples of Web.config file entries for using forms authentication to connect to a SQL membership provider.
|Configuration |Description and example Web.config file entries |
|steps | |
|Turn on |You can set the authentication type for a particular zone to forms authentication on the Edit Authentication page on the|
|forms |SharePoint Central Administration Web site. |
|authentication. |This automatically changes the mode specified in the authentication element of the Web.config file for that zone to |
| |forms. |
| |For example: |
| | |
| | |
|Register the |If you are using Microsoft SQL Server database software on the local server as your membership provider database, and |
|membership |you specify AspNetSqlMembershipProvider for the membership provider name, you might not need to make any additional |
|provider. |changes to the Web.config file. In this scenario, if the machine.config file has the correct configuration for the |
| |AspNetSqlMembershipProvider, you can use it for Windows SharePoint Services without making any changes. |
| |If the default configuration in the machine.config file does not apply (for example, if you want to use a SQL Server |
| |database on a remote server), you must edit the Web.config files for both the Web application and the Central |
| |Administration Web site to specify the connection information in the connectionStrings element for the membership |
| |provider database. |
| |For example: |
| | |
| | |
| | |
| |Replace SQLSERVERMACHINE with the name of server computer on which you have installed the SQL Server membership |
| |database. |
| |Next, add the membership and providers elements to register the membership provider in the Web.config file. Because a |
| |default provider is already registered in the machine.config file, you must include a element prior to the |
| | element. |
| |For example: |
| | |
| | |
| | |
| | |
| | |
| | |
| |The membership element must be included within the system.web element of the Web.config file for both the Web |
| |application and the Central Administration site. |
|Register the role |You can use the default role provider for by adding a roleManager element to the system.web element of the |
|manager |Web.config file. For example: |
|(optional). | |
| |The preceding syntax uses the AspNetSqlRoleProvider, which is defined in the machine.config file. This role manager can |
| |connect to the ASPNETDB database in either the local or remote instance of SQL Server. If you want to use a SQL Server |
| |database on a remote server as your role provider database, you must edit the Web.config file to specify the connection |
| |information for the remote database server. |
| |For example: |
| | |
| | |
| | |
| |Replace SQLSERVERMACHINE with the name of the remote server that hosts the SQL database. You can specify the same |
| |connectionStringName element value for both the membership provider and role manager, so you do not need to add a new |
| |connectionStrings element for the role provider. However, if you want to use a different database for the role provider,|
| |you must add a separate connectionStrings element for the role provider. |
| |Next, you need to add the roleManager and providers elements to register the roleManager provider in the Web.config. |
| |Because a default provider is already registered in the machine.config file, you must include a element prior |
| |to the element. |
| |For example: |
| | |
| | |
| | |
| | |
| | |
| | |
| |The roleManager element must be included within the system.web element of the Web.config file for both the Web |
| |application and the Central Administration Web site. |
|Register the HTTP |Not applicable |
|module. | |
Active Directory membership provider
The following table provides examples of Web.config file entries for using forms authentication to use an Active Directory directory service membership provider.
[pic] Note:
This will only work in a scenario with a single domain.
|Configuration steps |Description and example Web.config file entries |
|Turn on forms |You can set the authentication type for a particular zone to forms authentication on the Edit |
|authentication. |Authentication page in Central Administration. |
| |This automatically changes the mode specified in the authentication element of the Web.config file for |
| |that zone to forms. |
| |For example: |
| | |
| | |
| |You can also specify the login page URL in the forms element, for example: |
| | |
| | |
| | |
|Register the membership |If you want to use an Active Directory server for a membership provider, you must edit the Web.config file|
|provider. |to register the membership provider. To do this, you must specify the connection information to the Active|
| |Directory server in the connectionStrings element. |
| |For example: |
| | |
| | |
| | |
| |Replace DirectoryServer with the name of membership directory server. |
| | |
| | |
| | |
| | |
| | |
| |[pic] Note: |
| |The preceding example does not specify account credentials. If you do not specify account credentials, |
| |your application's process identity is used to access Active Directory. |
| |If another account is required to access Active Directory, you can specify different account credentials |
| |in the connectionUsername and connectionPassword attributes, which means you are supplying the user name |
| |and password in plaintext. As a result, we recommend that you encrypt this configuration section. For more|
| |information, see the following articles: |
| |How To: Encrypt Configuration Sections in 2.0 Using DPAPI |
| |() |
| |How To: Encrypt Configuration Sections in 2.0 Using RSA |
| |() |
|Register the role manager | |
|(optional). | |
|Register the HTTP module. |Not applicable |
Web SSO with AD FS
The Microsoft Windows Server 2003 R2 operating system introduces Active Directory Federation Services (AD FS), which enables organizations to securely share a user's identity information. AD FS provides Web single sign-on (SSO) technologies to authenticate a user to multiple Web applications during a single online session.
The following two membership and role provider pairs are included with AD FS:
• SingleSignOnMembershipProvider/SingleSignOnRoleProvider The standard membership provider and role provider included with Windows Server 2003 R2.
• SingleSignOnMembershipProvider2/SingleSignOnRoleProvider2 The membership provider and role provider that operate in partial trust environments. These providers are included in Service Pack 2 of Windows Server 2003 R2.
SingleSignOnMembershipProvider/SingleSignOnRoleProvider
The following table provides examples of Web.config file entries for a Web SSO AD FS environment that uses the standard provider.
|Configuration steps|Description and example Web.config file entries |
|Turn on | |
|forms | |
|authentication. | |
| | |
|Register the | |
|membership | |
|provider. | |
| | |
| | |
| |For the fs attribute, replace FEDERATIONSERVER with the actual server name. |
| |The membership element must be included within the system.web element of the Web.config file. |
|Register the role | |
|manager (optional).| |
| | |
| | |
| | |
| |For the fs attribute, you will need to replace FEDERATIONSERVER with the actual server name. |
|Register the HTTP | |
|module. | |
| | |
SingleSignOnMembershipProvider2/SingleSignOnRoleProvider2
If you are implementing the second AD FS provider set, the settings for registering the membership provider and role manager are different. The following table provides examples of Web.config file entries for a Web SSO AD FS environment that uses the provider that operates in partial trust environments.
|Configuration steps|Description and example Web.config file entries |
|Turn on | |
|forms | |
|authentication. | |
| | |
|Register the | |
|membership | |
|provider. | |
| | |
| | |
| |For the fs attribute, replace FEDERATIONSERVER with the actual server name. |
| |The membership element must be included within the system.web element of the Web.config file. |
|Register the role | |
|manager (optional).| |
| | |
| | |
| | |
| |For the fs attribute, you will need to replace FEDERATIONSERVER with the actual server name. |
|Register the HTTP | |
|module. | |
| | |
Plan for and design security
Plan for and design security (Windows SharePoint Services)
Topic Last Modified: 2009-04-15
This chapter provides a methodical approach to building security into your solution design for Windows SharePoint Services 3.0. This approach is based on a foundation of the following security guides that are provided in Microsoft patterns & practices ():
• Securing Your Web Server ()
• Securing Your Database Server ()
• Securing Your Network ()
These guides explain practical secure configurations for specific server roles. The guidance for each server role includes recommended secure settings for the network, the operating system, and the applications that are installed, including Internet Information Services (IIS), Microsoft Framework, and Microsoft SQL Server.
The information in this chapter supplements the patterns & practices security guides in several ways:
• Provides recommendations for each server role within a server farm.
• Identifies additional networking, operating system, and application settings that are appropriate for server roles.
• Provides recommendations for securing the specific applications and features that are installed by Windows SharePoint Services 3.0.
• Targets security recommendations to security environments that are common for Windows SharePoint Services 3.0 solutions.
Plan for and design security by using the following steps:
1. Plan your security environment The security guidance that is recommended for your organization depends on which environment best matches your intended use of Windows SharePoint Services 3.0. Use the following article to help plan your security environment:
• Choose your security environment (Windows SharePoint Services) describes the four key security environments: internal team or department, internal IT-hosted, external secure collaboration, and external anonymous access.
2. Plan server farm security Plan how to secure individual servers within a server farm. The patterns & practices security guides are used as a foundation for securing Windows SharePoint Services 3.0 environments. Use the following articles to help plan server farm security:
• Review the secure topology design checklists (Windows SharePoint Services) to ensure that your topology and logical architecture meet the criteria for a secure design.
• Plan for secure communication within a server farm (Windows SharePoint Services) to ensure that the methods of secure communication are most appropriate for your solution.
• Plan security hardening for server roles within a server farm (Windows SharePoint Services) to determine the specific hardening settings for each of the server roles in your server farm.
3. Plan secure configurations for features Plan how to configure Windows SharePoint Services 3.0 features in a secure manner. Use the following article to help plan secure configurations:
• Plan secure configurations for Windows SharePoint Services features provides recommendations for securely configuring Windows SharePoint Services 3.0 features. The recommendations in this article are usually configured by using Central Administration, rather than in the network, operating system, IIS, or .NET Framework.
4. Plan environment-specific security Plan security targeted to your specific environment. Use the following articles to help plan environment-specific security:
• Plan security for an internal team or department environment (Windows SharePoint Services) provides additional security guidance targeted to the internal team or department environment.
• Plan security for an internal IT-hosted environment (Windows SharePoint Services) provides additional security guidance targeted to the internal IT-hosted environment.
• Plan security for an external secure collaboration environment (Windows SharePoint Services) provides additional security guidance targeted to the external secure collaboration environment.
• Plan security for an external anonymous access environment (Windows SharePoint Services) provides additional security guidance targeted to the external anonymous access environment.
5. Plan security roles Use the following article to plan for and design security roles:
• Plan for security roles (Windows SharePoint Services) describes planning roles for administrators and for users.
6. Plan for accounts Use the following article to plan for administrative and service accounts:
• Plan for administrative and service accounts (Windows SharePoint Services) provides requirements and recommendations for configuring administrative and service accounts.
Some of these planning articles are intended for specific security environments. The following figure shows the intended planning flow based on the security environment.
[pic]
Choose your security environment (Windows SharePoint Services)
Topic Last Modified: 2009-04-15
Use this article to identify the security environment that most closely matches your intended use of Windows SharePoint Services 3.0.
The security guidance that is recommended for your organization depends on the environment. This article describes the following four security environments:
• Internal team or department
• Internal IT-hosted
• External secure collaboration
• External anonymous access
Review the description for each environment and identify the one that most closely matches your environment.
Internal team or department
Security guidance for an internal team or department environment within a larger organization focuses on recommending practical security configurations and settings for a team or department that uses Windows SharePoint Services 3.0 for collaboration.
This environment is a one- or two-server deployment in which the servers are not hosted by the primary IT team within the organization. Although the guidance for this environment requires some IT knowledge, it is not necessary for server farm administrators to be IT specialists.
The guidance for the internal team or department environment relies on the security of the overall network environment. Many of the default settings are intended to be used with this environment.
This environment is not intended for multiple teams or projects where secure isolation of content is required. If your team or department requires secure isolation of content, a greater number of servers, or a greater level of security than is provided by your overall network environment, use the guidance for the internal IT-hosted environment.
If your environment most closely matches the internal team or department environment, go to the article Plan secure configurations for Windows SharePoint Services features.
Internal IT-hosted
An internal IT-hosted environment is one in which an IT team hosts Web applications and sites for multiple teams and departments in an organization. Security guidance for this environment focuses on:
• Securing a server farm environment, including isolating content between groups.
• Securing server-to-server communication and client-server communication.
• Hardening servers for specific server roles.
• Securely configuring features.
Guidance for this environment assumes that all servers reside within a single internal network.
If your environment most closely matches the internal IT-hosted environment, go to Plan server farm security (Windows SharePoint Services). The three articles in this chapter describe designing solutions for security, securing server-to-server communication and client-server communication, and hardening servers for specific roles.
External secure collaboration
An external secure collaboration environment is one in which content is hosted in an extranet so that contributors who do not have general access to your corporate network can collaborate on content. This environment enables external partners to participate in a workflow or to collaborate on content with employees in your organization. This environment is also intended to support remote employee access, where employees who are working from home or traveling can gain access to sites and data without logging on to the corporate network.
Security guidance for this environment focuses on:
• Isolating Web applications or content to ensure that users can view or have access to only the projects on which they are authorized to work.
• Authenticating and securing communication between contributors and the server farm.
Protecting database servers from direct user interaction and securing the server farm against risks associated with hosting Internet-facing servers.
If your environment most closely matches the external secure collaboration environment, go to Plan server farm security (Windows SharePoint Services). The three articles in this chapter describe designing solutions for security, securing server-to-server communication and client-server communication, and hardening servers for specific roles.
External anonymous access
An external anonymous access environment is one which allows anonymous access to content from the Internet while protecting the server farm from the risks associated with hosting Internet-facing servers. This environment can include multiple farms for testing, staging, and publishing content.
Security guidance for this environment focuses on:
• Making content anonymously available.
• Securing communication between farms when content is deployed to the publishing farm.
• Ensuring that content caching does not expose sensitive data.
• Protecting database servers from direct user interaction and securing the server farm against risks associated with hosting Internet-facing servers in an anonymous environment.
If your environment most closely matches the external anonymous access environment, go to Plan server farm security (Windows SharePoint Services). The three articles in this chapter describe designing solutions for security, securing server-to-server communication and client-server communication, and hardening servers for specific roles.
Plan server farm security (Windows SharePoint Services)
Topic Last Modified: 2009-04-15
Planning server farm security includes the following tasks:
• Review the secure topology design checklists (Windows SharePoint Services)
• Plan for secure communication within a server farm (Windows SharePoint Services)
• Plan security hardening for server roles within a server farm (Windows SharePoint Services)
Use these tasks with the following security environments:
• Internal IT-hosted
• External secure collaboration
• External anonymous access
Review the secure topology design checklists (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
In this article:
• Server topology design checklist
• Networking topology design checklist
• Logical architecture design checklist
• Operating system design checklist
In Windows SharePoint Services 3.0, successful server hardening depends on a server topology and logical architecture that are designed for targeted isolation and secure communication.
Previous planning articles address topology and logical architecture in depth. This article provides checklists that you can use to ensure that your plans meet the criteria for a secure design.
Use the secure topology design checklists with the following security environments:
• Internal IT hosted
• External secure collaboration
• External anonymous access
Server topology design checklist
Review the following checklist to ensure that your plans meet the criteria for a secure server topology design.
|[ ] |The topology incorporates dedicated front-end Web servers. |
|[ ] |Servers that host the Windows SharePoint Services search role and |
| |database server role are protected from direct user access. |
|[ ] |The SharePoint Central Administration site is hosted on the same |
| |server that hosts the Windows SharePoint Services search role. |
Networking topology design checklist
Review the following checklist to ensure that your plans meet the criteria for a secure networking topology design.
|[ ] |All servers within the farm reside within a single data center and on|
| |the same vLAN. |
|[ ] |Access is allowed through a single point of entry, which is a |
| |firewall. |
|[ ] |For a more secure environment, the farm is separated into three tiers|
| |(front-end Web, search, and database), which are separated by routers|
| |or firewalls at each vLAN boundary. |
Logical architecture design checklist
Review the following checklist to ensure that your plans meet the criteria for a secure logical architecture design.
|[ ] |At least one zone in each Web application uses NTLM authentication. |
| |This is required for the search account to crawl content within the |
| |Web application. For more information, see Plan authentication |
| |methods (Windows SharePoint Services). |
|[ ] |Web applications are implemented by using host names instead of the |
| |randomly generated port numbers that are automatically assigned. Do |
| |not use Internet Information Services (IIS) host header bindings if |
| |the Web application will be hosting host header–based site |
| |collections. |
|[ ] |Consider using separate Web applications for the following |
| |circumstances: |
| |Your company policy requires process isolation for content and |
| |applications. |
| |You are implementing sites that integrate with external data sources |
| |where the content provided by these data sources is sensitive or |
| |requires greater security. |
|[ ] |In a reverse proxy environment, consider using the default port for |
| |the public-facing network while using a nondefault port on your |
| |internal network. This can help prevent simple port attacks on your |
| |internal network that assume HTTP will always be on port 80. |
|[ ] |When deploying custom Web Parts, only trustworthy Web Parts are |
| |deployed within Web applications that host sensitive or secure |
| |content. This protects the sensitive content against intradomain |
| |scripting attacks. |
|[ ] |Separate application pool accounts are used for central |
| |administration and for each unique Web application. |
Operating system design checklist
Review the following checklist to ensure that your plans meet the criteria for a secure operating system design.
|[ ] |The server operating system is configured to use the NTFS file |
| |system. |
|[ ] |Clocks on all servers within the farm are synchronized. |
Plan for secure communication within a server farm (Windows SharePoint Services)
Topic Last Modified: 2009-04-15
In this article:
• Plan server-to-server communication
• Plan client-server communication
• Plan for using SSL
Use this article to plan server farm security. This article provides guidance on securing server-to-server communication and client-server communication.
The tasks in the article are appropriate for the following security environments:
• Internal IT hosted
• External secure collaboration
• External anonymous access
Plan server-to-server communication
If your servers are not inside a physically secure data center where the network eavesdropping threat is considered insignificant, you need to use an encrypted communication channel to protect data sent between servers.
In Windows SharePoint Services 3.0, server-to-server communication within a server farm is extensive. Securing this communication helps ensure that sensitive data is not compromised and also helps protect the servers from malicious attacks or unintentional threats.
The following figure shows several common communication transactions among servers in a farm.
[pic] Common communication transactions among servers in a farm include the following:
• Configuration changes Front-end Web servers communicate with the configuration database to communicate configuration changes for farm settings.
• Change requests User requests to add, delete, modify, or view content within a site are sent directly to the content database.
• Search requests Front-end Web servers first communicate with the search server to generate results for search queries. Next, the front-end Web servers communicate with the content database to satisfy user requests for specific documents within the search results.
• Indexing The indexing component communicates through a front-end Web server to crawl content in the content databases and build an index.
[pic] Note:
In a Windows SharePoint Services 3.0 environment, the search and indexing components share the same server role.
Internet Protocol security (IPsec) and Secure Sockets Layer (SSL) can both be used to help protect communication between servers by encrypting traffic. Each of these methods works well. The choice of which method to use depends on the specific communication channels you are securing and the benefits and tradeoffs that are most appropriate for your organization.
IPsec
IPsec is generally recommended for protecting the communication channel between two servers and restricting which computers can communicate with one another. For example, you can help protect a database server by establishing a policy that permits requests only from a trusted client computer, such as an application server or a Web server. You can also restrict communication to specific IP protocols and TCP/UDP ports.
The networking requirements and recommendations for a server farm make IPsec a good option because:
• All servers are contained on one physical LAN (to improve IPsec performance).
• Servers are assigned static IP addresses.
IPsec can also be used between trusted Windows Server 2003 or Windows 2000 Server domains. For example, you can use IPsec to secure communication of a Web server or application server in a perimeter network that connects to a computer running Microsoft SQL Server on an internal network. For more information, see Selecting IPSec Authentication Methods () in the Windows Server 2003 Deployment Guide ().
For more information about recommended environments for IPsec, see Determining Your IPSec Needs () in the Windows Server 2003 Deployment Guide ().
SSL
The general recommendations for using SSL is to use this encryption method when you need granular channel protection for a particular application instead of for all applications and services running on a computer. SSL must be implemented by individual applications. Therefore, you cannot use SSL to encrypt all communications between two hosts.
Additionally, SSL is less flexible than IPsec because it only supports authentication by means of public key certificates. SSL does provide several distinct advantages, however. Most significantly, SSL is supported by a wide variety of servers and client computers, and the maturity of the standard has practically eliminated interoperability problems.
Scenarios to consider for SSL
There are several scenarios that make SSL a good option, including the following:
• Administration sites The Central Administration site and Shared Services Administration sites can be secured by using SSL.
• Content deployment The content deployment process copies files from one site directory on a server within an authoring or staging server farm to a matching site directory on one or more servers within a publishing server farm. In this scenario, IPsec might not be practical if server farms are in different network zones or if there is a high volume of content to deploy or a large number of servers to which to deploy the content. SSL can be used to target secure communication to these specific communication transactions.
• Intrafarm Shared Services Providers (SSPs) If child farms are consuming shared services from a parent farm, sensitive data is shared between farms.
Plan client-server communication
It might not be practical to secure all client-server communication. However, there are several scenarios that justify the extra configuration required to secure communication between client computers and servers within your server farm:
• Secure collaboration with partners Partners access and contribute to applications in an extranet environment.
• Remote employee access Employees access internal data remotely.
• Customers accessing or providing sensitive data Customers log on and provide or gain access to sensitive data. For example, customers might be required to log on to an Internet news site or provide personal information to complete a business transaction.
• Basic or forms authentication If you are using either of these methods of authentication, credentials are sent in the clear. At a minimum, secure the client-server communication for the logon page.
SSL is generally recommended to secure communications between users and servers when sensitive information must be secured. SSL can be configured to require server authentication or both server and client authentication.
Plan for using SSL
SSL can decrease the performance of your network. There are several common guidelines that you can use to optimize pages that use SSL. First, use SSL only for pages that require it. This includes pages that contain or capture sensitive data, such as passwords or other personal data. Use SSL only if the following conditions are true:
• You want to encrypt the page data.
• You want to guarantee that the server to which you send the data is the server that you expect.
For pages where you must use SSL, follow these guidelines:
• Make the page size as small as possible.
• Avoid using graphics that have large file sizes. If you use graphics, use graphics that have smaller file sizes and resolution.
Plan security hardening for server roles within a server farm (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
• About security hardening
• Application server recommendations
• Secure communication with the Microsoft SQL Server database
• File and Printer Sharing service requirements
• Service requirements for e-mail integration
• Windows SharePoint Services services
• Accounts and groups
• Web.config file
• Secure snapshot additions
Use this article to plan server farm security. The tasks in the article are appropriate for the following security environments:
• Internal IT hosted
• External secure collaboration
• External anonymous access
About security hardening
In a server farm environment, individual servers play specific roles. Security hardening recommendations for these servers depend on the role each plays.
The server hardening recommendations are built on top of the recommendations provided in the following security guides that are provided in Microsoft patterns & practices ():
• Securing Your Web Server ()
• Securing Your Database Server ()
• Securing Your Network ()
These guides follow a methodical approach to securing servers for specific roles and for securing the supporting network. The order in which settings are applied and applications are installed and hardened is prescribed as well, starting with applying patches and updates, then hardening networking settings and operating system settings, and then followed by application-specific hardening. For example, Securing Your Web Server () recommends that you install and harden Internet Information Services (IIS) only after patching and hardening the operating system. Additionally, this guide prescribes installing the Microsoft .NET Framework only after IIS is fully patched and hardened.
The categories of security settings that are methodically prescribed in Securing Your Web Server () are detailed in the following figure.
[pic] Additionally, each of the three guides includes a secure snapshot and a list of recommended security settings for either the specific server role or for the network. The snapshot lists are organized by categories that correspond to security settings illustrated in the preceding figure.
The security design and hardening guidance provided in this article is based on the guidance published in these three guides. This guidance assumes that you will use these guides as a baseline for securing and hardening your server farm.
This article describes the exceptions or additions to the snapshots that are recommended for your environment. These are detailed in table format by using the same categories and order as the three security guides. This format is intended to make it easy to identify and apply specific recommendations as you use the guides.
The guide Deployment for Windows SharePoint Services 3.0 Technology () includes instructions for applying specific security guidance that is not covered in the patterns & practices security guides.
The nature of server-to-server communication within a server farm and the specific features provided by Windows SharePoint Services 3.0 are the primary reasons for specific hardening recommendations. This article also describes how key communication channels and Windows SharePoint Services 3.0 features affect security requirements.
Application server recommendations
In Windows SharePoint Services 3.0, application server roles are not typical middle-tier application servers that are packaged inside Enterprise Services applications. Consequently, the recommendations in Securing Your Application Server () do not apply for Windows SharePoint Services 3.0 application servers. Instead, use the guidance provided in Securing Your Web Server () to harden Windows SharePoint Services 3.0 application servers:
• Apply the guidance for networking and operating system settings to all application servers in the server farm. This guidance is contained in the following categories: patches and updates, services, protocols, accounts, files and directories, shares, ports, registry, and auditing and logging.
• Apply the guidance for hardening IIS and other Web settings only on the application server that hosts the Central Administration Web site. This guidance includes the following categories: IIS, Machine.config, code access security, LocalIntranet_Zone, and Internet_Zone.
In addition to using the secure snapshot in Securing Your Web Server (), also apply the recommendations provided in the Secure snapshot additions section later in this article.
Secure communication with the Microsoft SQL Server database
Securing Your Database Server () recommends restricting access to two default Microsoft SQL Server communications ports: TCP port 1433 and UDP port 1434. For secure server farm environments, the recommendation is to:
• Block UDP port 1434 entirely.
• Configure SQL Server named instances to listen on a nonstandard port (other than TCP port 1433 or UDP port 1434).
• For additional security, block TCP port 1433 and reassign the port used by the default instance to a nonstandard port.
• Configure SQL client aliases on all front-end Web servers and application servers in the server farm. After you block TCP port 1433 or UDP port 1434, SQL client aliases are necessary on all computers that communicate with the SQL Server computer.
This approach provides a much higher degree of control over how SQL Server is deployed and run, including the ability to ensure that only authorized computers can communicate with the SQL Server computer.
The hardening steps for creating a SQL client alias must be completed prior to installing Windows SharePoint Services 3.0. When you run Setup for Windows SharePoint Services 3.0 and you are prompted to enter the name of the SQL Server computer to which to connect, you will need to enter the name of the SQL client alias.
Blocking the standard SQL Server ports
The specific ports used to connect to SQL Server are affected by whether databases are installed on a default instance of SQL Server or a named instance of SQL Server. The default instance of SQL Server listens for client requests on TCP port 1433. A named instance of SQL Server listens on a randomly assigned port number. Additionally, the port number for a named instance can be reassigned if the instance restarts (depending on if the previously assigned port number is available).
By default, client computers that connect to SQL Server first connect by using TCP port 1433. If this communication is unsuccessful, then the client computers query the SQL Server Resolution Service listening on UDP port 1434 to determine on which port the database instance is listening.
The default port-communication behavior of SQL Server introduces several issues that affect server hardening. First, the ports used by SQL Server are well-publicized ports and the SQL Server Resolution Service has been the target of buffer overrun attacks and denial-of-service attacks, including the "Slammer" worm virus. Even if SQL Server is patched to mitigate security issues in the SQL Server Resolution Service, the well-publicized ports remain a target. Second, if databases are installed on a named instance of SQL Server, the corresponding communication port is randomly assigned and can change. This behavior can potentially prevent server-to-server communication in a hardened environment. The ability to control which TCP ports are open or blocked is essential to securing your environment.
Consequently, the recommendation for a server farm is to assign static port numbers to named instances of SQL Server and to block UDP port 1434 to prevent potential attackers from accessing the SQL Server Resolution Service. Additionally, consider reassigning the port used by the default instance and blocking TCP port 1433 as well.
There are several methods you can use to block ports. You can block these ports by using a firewall. However, unless you can be sure that there are no other routes into the network segment and that there are no malicious users that have access to the network segment, the recommendation is to block these ports directly on the server that hosts SQL Server. This can be accomplished by using Windows Firewall in Control Panel.
Configuring SQL Server database instances to listen on a nonstandard port
SQL Server provides the ability to reassign the ports that are used by the default instance and any named instances. In SQL Server 2000, you reassign ports by using SQL Server Network Utility. In SQL Server 2005, you reassign ports by using SQL Server Configuration Manager.
Configuring SQL client aliases
In a server farm, all front-end Web servers and application servers are SQL Server client computers. If you block UDP port 1434 on the SQL Server computer or you change the default port for the default instance, you must configure a SQL client alias on all servers that connect to the SQL Server computer.
To connect to an instance of SQL Server 2000, you install the SQL Server client tools on the target computer and then configure the SQL client alias. You install these by running Setup for SQL Server and selecting SQL Server Client Tools.
To connect to an instance of SQL Server 2005, you install SQL Server client components on the target computer and then configure the SQL client alias by using SQL Server Configuration Manager. To install SQL Server client components, run Setup and select only the following client components to install:
• Connectivity Components
• Management Tools (includes SQL Server Configuration Manager)
SQL Server client components work with SQL Server 2000 and can be used instead of the SQL Server client tools.
Hardening steps
Configure SQL Server
Configure a SQL Server 2000 instance to listen on a nondefault port
Use SQL Server Network Utility to change the TCP port that is used by an instance of SQL Server 2000.
1. On the SQL Server computer, run SQL Server Network Utility.
2. On the Instance(s) on this server menu, select the instance. Ensure that you have selected the intended instance. By default, the default instance listens on port 1433. Named instances of SQL Server 2000 are assigned a random port number, so you might not know the current port number assigned to a named instance when you run SQL Server Network Utility.
3. In the Enabled Protocols pane on the right side of the SQL Server Network Utility interface, click TCP/IP, and then click Properties.
4. In the Network Protocol Default Value Setup dialog box, change the TCP port number. Avoid using any of the well-known TCP ports. For example, select a higher-range port number, such as 40000. Do not select the Hide Server check box.
5. Click OK.
6. In the SQL Server Network Utility dialog box, click OK. You will receive a message indicating that the change will not take effect until the SQL Server service is restarted. Click OK.
7. Restart the SQL Server service and confirm that your SQL Server computer is listening on the port you selected. You can confirm this by looking in the event viewer log after restarting the SQL Server service. Look for an information event similar to the following event:
Event Type:Information
Event Source:MSSQLSERVER
Event Category:(2)
Event ID:17055
Date:3/6/2008
Time:11:20:28 AM
User:N/A
Computer:computer_name
Description:
19013:
SQL Server listening on 10.1.2.3: 40000
Configure a SQL Server 2005 instance to listen on a nondefault port
Use SQL Server Configuration Manager to change the TCP port that is used by an instance of SQL Server 2005.
1. Use SQL Server Configuration Manager to change the TCP port that is used by an instance of SQL Server 2005.
2. On the SQL Server computer, open SQL Server Configuration Manager.
3. In the left pane, expand SQL Server 2005 Network Configuration.
4. Under SQL Server 2005 Network Configuration, click the corresponding entry for the instance that you are configuring. The default instance is listed as Protocols for MSSQLSERVER. Named instances will appear as Protocols for named_instance.
5. In the right pane, right-click TCP/IP and click Properties.
6. Click the IP Addresses tab. For every IP address assigned to the SQL Server computer, there is a corresponding entry on this tab. By default, SQL Server is listening on all IP addresses assigned to the computer.
7. To globally change the port that the default instance is listening on, perform the following:
a) For each IP except IPAll, clear all values for both TCP dynamic ports and TCP Port.
b) For IPAll, clear the value for TCP dynamic ports. In the TCP Port field, enter the port that you want the instance of SQL Server to listen on. For example, enter 40000.
8. To globally change the port that a named instance is listening on, perform the following:
a) For each IP including IPAll, clear all values for TCP dynamic ports. A value of 0 for this field indicates that SQL Server uses a dynamic TCP port for the IP address. A blank entry for this value means that SQL Server 2005 will not use a dynamic TCP port for the IP address.
b) For each IP except IPAll, clear all values for TCP Port.
c) For IPAll, clear the value for TCP dynamic ports. In the TCP Port field, enter the port that you want the instance of SQL Server to listen on. For example, enter 40000.
9. Click OK. You will receive a message indicating that the change will not take effect until the SQL Server service is restarted. Click OK.
10. Close SQL Server Configuration Manager.
11. Restart the SQL Server service and confirm that the SQL Server computer is listening on the port you selected. You can confirm this by looking in the event viewer log after restarting the SQL Server service. Look for an information event similar to the following event:
Event Type:Information
Event Source:MSSQL$MSSQLSERVER
Event Category:(2)
Event ID:26022
Date:3/6/2008
Time:1:46:11 PM
User:N/A
Computer:computer_name
Description:
Server is listening on [ 'any' 50000]
Configure Windows Firewall
Configure Windows Firewall to block default SQL Server listening ports
1. In Control Panel, open Windows Firewall.
2. On the General tab, click On. Ensure that the Don't allow exceptions check box is cleared.
3. On the Exceptions tab, click Add Port.
4. On the Add a Port dialog box, enter a name for the port. For example, enter UDP-1434. Then, enter the port number. For example, enter 1434.
5. Select the appropriate option button: UDP or TCP. For example, to block port 1434, click UDP. To block port 1433, click TCP.
6. Click Change Scope and ensure that the scope for this exception is set to Any computer (including those on the Internet).
7. Click OK.
8. On the Exceptions tab, locate the exception you created. To block the port, clear the check box for this exception. By default, this check box is selected, which means that the port is open.
Configure Windows Firewall to open manually assigned ports
1. Follow steps 1-7 in the previous procedure to create an exception for the port you manually assigned to a SQL instance. For example, create an exception for TCP port 40000.
2. On the Exceptions tab, locate the exception you created. Ensure that the check box for the exception is checked. By default, this check box is selected, which means that the port is open.
[pic] Note:
For more information about using Internet Protocol security (IPsec) to secure communication to and from your SQL Server computer, see the Microsoft Knowledge Base article 233256: How to Enable IPSec Traffic Through a Firewall ().
Configure a SQL client alias
Configure a SQL client alias
If you block UDP port 1434 or TCP port 1433 on the SQL Server computer, you must create a SQL client alias on all other computers in the server farm. You can use SQL Server client components to create a SQL client alias for computers that connect to SQL Server 2000 or SQL Server 2005.
1. Run Setup for SQL Server 2005 on the target computer and select the following client components to install:
a) Connectivity Components
b) Management Tools
2. Open SQL Server Configuration Manager.
3. In the left pane, click SQL Native Client Configuration.
4. In the right pane, right-click Aliases, and select New Alias.
5. In the Alias dialog box, enter a name for the alias and then enter the port number for the database instance. For example, enter SharePoint_alias.
6. In the Port No field, enter the port number for the database instance. For example, enter 40000. Ensure that the protocol is set to TCP/IP.
7. In the Server field, enter the name of the SQL Server computer.
8. Click Apply, and then click OK.
Test the SQL client alias
Test connectivity to the SQL Server computer by using Microsoft SQL Server Management Studio, which is available by installing SQL Server client components.
1. Open SQL Server Management Studio.
2. When you are prompted to enter a server name, enter the name of the alias that you created, and then click Connect. If the connection is successful, SQL Server Management Studio is populated with objects that correspond to the remote database.
[pic] Note:
To check connectivity to additional database instances from within SQL Server Management Studio, click the Connect button and select Database Engine.
File and Printer Sharing service requirements
Several core features depend on the File and Printer Sharing service and the corresponding protocols and ports. These include, but are not limited to, the following:
• Search queries All search queries require the File and Printer Sharing service.
• Crawling and indexing content To crawl content, the index component sends requests through the front-end Web server. The front-end Web server communicates with content databases directly and sends results back to the index server. This communication requires the File and Printer Sharing service.
The File and Printer Sharing service requires the use of named pipes. Named pipes can communicate by using either direct-hosted SMB or NBT protocols. For a secure environment, direct-hosted SMB is recommended instead of NBT. The hardening recommendations provided in this article assume that SMB is used.
The following table describes the hardening requirements that are introduced by the dependency on the File and Printer Sharing service.
|Category |Requirement |Notes |
|Services |File and Printer Sharing |Requires use of named pipes. |
|Protocols |Named pipes that use direct-hosted SMB |Named pipes can use NBT instead of |
| |Disable NBT |direct-hosted SMB. However, NBT is not |
| | |considered as secure as direct-hosted SMB. |
|Ports |TCP/UDP port 445 |Used by direct-hosted SMB. |
For more information about disabling NBT, see the Microsoft Knowledge Base article 204279: Direct hosting of SMB over TCP/IP ().
Service requirements for e-mail integration
E-mail integration requires the use of two services:
• Simple Mail Transfer Protocol (SMTP) service
• Microsoft SharePoint Directory Management Service
SMTP service
E-mail integration requires the use of the SMTP service on at least one of the front-end Web servers in the server farm. The SMTP service is required for incoming email. For outgoing e-mail, you can either use the SMTP service or route outgoing email through a dedicated e-mail server in your organization, such as a Microsoft Exchange Server computer.
Microsoft SharePoint Directory Management Service
Windows SharePoint Services 3.0 includes an internal service, the Microsoft SharePoint Directory Management Service, for creating e-mail distribution groups.
When you configure e-mail integration, you have the option to enable the Directory Management Service feature, allowing users to create distributions lists. When users create a SharePoint group and they select the option to create a distribution list, the Microsoft SharePoint Directory Management Service creates the corresponding Active Directory directory service distribution list in the Active Directory environment.
In security-hardened environments, the recommendation is to restrict access to the Microsoft SharePoint Directory Management Service by securing the file associated with this service, which is SharePointEmailws.asmx. For example, allow access to this file by the server farm account only.
Additionally, this service requires permissions in the Active Directory environment to create Active Directory distribution list objects. The recommendation is to setup a separate organizational unit in Active Directory for SharePoint objects. Only this organizational unit should allow write access to the account used by the Microsoft SharePoint Directory Management Service.
Windows SharePoint Services services
Do not disable services that are installed by Windows SharePoint Services 3.0. The following services are installed on all front-end Web servers and application servers and appear in the Microsoft Management Console (MMC) Services snap-in (alphabetical order):
• Windows SharePoint Services Administration
• Windows SharePoint Services Search
• Windows SharePoint Services Timer
• Windows SharePoint Services Tracing
• Windows SharePoint Services VSS Writer
If your environment disallows services that run as a local system, you can consider disabling the Windows SharePoint Services Administration service only if you are aware of the consequences and can work around these. This service is a Win32 service that runs as a local system.
This service is used by the Windows SharePoint Services Timer service to perform actions that require administrative privileges on the server, such as create IIS Web sites, deploy code, and stop and start services. If you disable this service, you cannot run deployment-related tasks from the Central Administration site. You will need to use the Stsadm.exe command-line tool and run the execadminsvcjobs command to complete multi-server deployments for Windows SharePoint Services 3.0 and to run other deployment-related tasks.
Accounts and groups
The secure snapshots in the patterns & practices security guides provide recommendations for securing accounts and groups.
For recommendations on planning for accounts, see Plan for administrative and service accounts (Windows SharePoint Services).
For recommendations on planning for administrative and user roles, see Plan for security roles (Windows SharePoint Services).
Web.config file
The .NET Framework, and in particular, uses XML-formatted configuration files to configure applications. The .NET Framework relies on configuration files to define configuration options. The configuration files are text-based XML files. Multiple configuration files can, and typically do, exist on a single system.
System-wide configuration settings for the .NET Framework are defined in the Machine.config file. The Machine.config file is located in the %SystemRoot%\\Framework\%VersionNumber%\CONFIG\ folder. The default settings that are contained in the Machine.config file can be modified to affect the behavior of applications that use the .NET Framework on the whole system. For recommendations about configuring Machine.config files, see Securing Your Web Server ().
You can change the configuration settings for a single application if you create a Web.config file in the root folder of the application. When you do this, the settings in the Web.config file override the settings in the Machine.config file.
When you extend a Web application by using Central Administration, Windows SharePoint Services 3.0 automatically creates a Web.config file for the Web application.
The Secure snapshot additions section later in this article lists recommendations for configuring Web.config files. These recommendations are intended to be applied to each Web.config file that is created, including the Web.config file for the Central Administration site.
For more information about configuration files and editing a Web.config file, see Configuration ().
Secure snapshot additions
This section lists the additions to snapshots in the patterns & practices security guides that are recommended for Windows SharePoint Services 3.0 environments. These are detailed in table format by using the same categories and order as the patterns & practices security guides.
This format is intended to make it easy to identify and apply specific recommendations as you use the patterns & practices security guides. Except for a few noted exceptions, these hardening recommendations are intended to be applied before running Setup for Windows SharePoint Services 3.0.
For more information about communication between specific server roles in a server farm, see Plan security hardening for extranet environments (Windows SharePoint Services).
Securing your network snapshot additions
The following table describes recommendations for securing your network additions.
|Component |Characteristic exception |
|All |No additional recommendations |
Securing your Web server snapshot additions
The following table describes recommendations for securing your Web server additions.
|Component |Characteristic |
|Services |Enable: |
| |File and Printer Sharing |
| |World Wide Web Publishing Service |
| |Ensure these services remain enabled after running Setup: |
| |Windows SharePoint Services Administration |
| |Windows SharePoint Services Search |
| |Windows SharePoint Services Timer |
| |Windows SharePoint Services Tracing |
| |Windows SharePoint Services VSS Writer |
|Protocols |Enable: |
| |SMB |
| |SMTP (if using integrated e-mail) |
| |Disable: |
| |NBT |
|Accounts |If the Microsoft Directory Management Service is enabled as part of |
| |e-mail integration, configure your Active Directory environment to |
| |allow write access to the account used by the Microsoft Directory |
| |Management Service (the server farm account). |
| |For additional guidance on configuring accounts, see Plan for |
| |administrative and service accounts (Windows SharePoint Services) for|
| |Windows SharePoint Services 3.0 account requirements and |
| |recommendations. |
|Files and directories |If e-mail integration is enabled and the Directory Management Service|
| |feature is turned on, restrict access to the Microsoft SharePoint |
| |Directory Management service by securing the file associated with |
| |this service: SharePointEmailws.asmx. For example, allow access to |
| |this file only to the server farm account. |
|Shares |No additional recommendations |
|Ports |Open TCP/UDP port 445. |
| |If UDP port 1434 is blocked on the SQL Server computer and databases |
| |are installed on a named instance, configure a SQL client alias for |
| |connecting to the named instance. |
| |If TCP port 1433 is blocked on the SQL Server computer and databases |
| |are installed on the default instance, configure a SQL client alias |
| |for connecting to the named instance. |
| |Ensure that ports remain open for Web applications that are |
| |accessible to users. |
| |Block external access to the port used for the Central Administration|
| |site. |
|Registry |If using SSO, edit the registry to configure static RPC. |
|Auditing and logging |If log files are relocated, ensure that the log file locations are |
| |updated to match. |
|IIS |See guidance for IIS below. |
|Sites and virtual directories |No additional recommendations |
|Script mappings |No additional recommendations |
|ISAPI filters |No additional recommendations |
|IIS metabase |No additional recommendations |
|.NET Framework |See guidance for .NET Framework below. |
|Machine.config: HttpForbiddenHandler |No additional recommendations |
|Machine.config: Remoting |No additional recommendations |
|Machine.config: Trace |No additional recommendations |
|Machine.config: compilation |No additional recommendations |
|Machine.config: customErrors |No additional recommendations |
|Machine.config: sessionState |No additional recommendations |
|Code access security |Ensure that you have a minimal set of code access security |
| |permissions enabled for your Web application. (The element in|
| |Web.config for each Web application should be set to WSS_Minimal |
| |(where WSS_Minimal has its low defaults as defined in |
| |12\config\wss_minimaltrust.config) or your own custom policy file, |
| |which is minimally set.) |
|LocalIntranet_Zone |No additional recommendations |
|Internet_Zone |No additional recommendations |
|Web.config |Apply the following recommendations to each Web.config file that is |
| |created after running Setup: |
| |Do not allow compilation or scripting of database pages via the |
| |PageParserPaths elements. |
| |Ensure CallStack=""false"" and |
| |AllowPageLevelTrace=""false"". |
| |Ensure that the Web Part limits around maximum controls per zone is |
| |set low. |
| |Ensure that the SafeControls list is set to the minimum set of |
| |controls needed for your sites. |
| |Ensure that your Workflow SafeTypes list is set to the minimum level |
| |of SafeTypes needed. |
| |Ensure that customErrors is turned on (). |
| |Consider your Web proxy settings as needed |
| |(/). |
| |Set the upload.aspx limit to the highest size you reasonably expect |
| |users to upload (default is 2 GB). Performance of can be affected by |
| |uploads greater than 100 MB. |
Securing your database server snapshot additions
The following table describes recommendations for securing your database server additions.
|Component |Characteristic exception |
|Services |No additional recommendations |
|Protocols |No additional recommendations |
|Accounts |Manually remove unused accounts regularly. |
|Files and directories |No additional recommendations |
|Shares |No additional recommendations |
|Ports |Block UDP port 1434. |
| |Consider blocking TCP port 1433. |
|Registry |No additional recommendations |
|Auditing and logging |No additional recommendations |
|SQL Server settings |See guidance for SQL Server settings below. |
|SQL Server security |No additional recommendations |
|SQL Server logins, users, and roles |No additional recommendations |
|SQL Server database objects |No additional recommendations |
Plan security hardening for extranet environments (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
In this article:
• Network topology
• Domain trust relationships
• Communication with server-farm roles
• Communication with infrastructure server roles
• Active Directory communication between network domains
This article details the hardening requirements for an extranet environment in which a Windows SharePoint Services 3.0 server farm is placed inside a perimeter network and sites are available from the Internet or from the corporate network.
Network topology
The hardening guidance in this article can be applied to many different extranet configurations. The following figure shows an example implementation of a back-to-back perimeter network topology that illustrates the server and client roles across an extranet environment.
[pic] The purpose of the figure is to articulate each of the possible roles and their relationship to the overall environment. The Central Administration site can be installed to either a Web server or to the Search server (pictured). The routers illustrated can be exchanged for firewalls.
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 directory service 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. Forms authentication and Web SSO 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 with the database servers residing 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 authentication is used, a domain trust relationship is not required. The following table summarizes the differences between these two approaches.
| |Windows authentication |SQL authentication |
|Description |Corporate domain accounts are used for all |Windows SharePoint Services 3.0 accounts are |
| |Windows SharePoint Services 3.0 service and |configured in the following ways: |
| |administration accounts, including |SQL authentication is used for every database|
| |application pool accounts. |that is created. |
| |A one-way trust relationship, in which the |All other administration and service accounts|
| |perimeter network trusts the corporate |are created as domain accounts in the |
| |network, is required. |perimeter network. |
| | |Web servers and search 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. |
| | |[pic] Note: |
| | |If search 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: |Setup includes the following: |
| |Windows SharePoint Services 3.0 |All database accounts must be created as SQL |
| |administration and service accounts are |login accounts in SQL Server 2000 Enterprise |
| |created in the corporate domain. |Manager or SQL Server 2005 Management Studio.|
| |Web servers and application servers are |These accounts must be created before the |
| |joined to the perimeter network. |creation of any Windows SharePoint Services |
| |A trust relationship is established in which |3.0 databases, including the configuration |
| |the perimeter domain trusts the corporate |database and the SharePoint_AdminContent |
| |domain. |database. |
| | |You must use the Psconfig command-line tool |
| | |to create the configuration database and the |
| | |AdminContent database. You cannot use the |
| | |SharePoint Products and Technologies |
| | |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 |
| | |authentication accounts. |
| | |You can create additional content databases |
| | |in Central Administration by selecting the |
| | |SQL authentication option. However, you must |
| | |first create the SQL login accounts in SQL |
| | |Server 2000 Enterprise Manager or SQL Server |
| | |2005 Management Studio. |
| | |Secure all communication with the database |
| | |servers using 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|SQL login accounts are encrypted in the |
| |servers and application servers that are |registry of the Web servers and application |
| |joined to the extranet domain to resolve |servers. |
| |accounts that are in the corporate domain. |The server farm account is not used to access|
| | |the configuration database and the |
| | |SharePoint_AdminContent database. The |
| | |corresponding SQL login accounts are used |
| | |instead. |
The information in the preceding table assumes the following:
• 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.
For more information about Windows SharePoint Services 3.0 accounts, see Plan for administrative and service accounts (Windows SharePoint Services).
For more information about creating databases by using the Psconfig command-line tool, see Command-line reference for the SharePoint Products and Technologies Configuration Wizard (Windows SharePoint Services).
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 that follows the figure describes the ports and protocols that are represented in the figure. The arrows indicate which server role initiates communication. For example, the Web server initiates communication with the database server. The database server does not initiate communication with the Web server. This is important to know when configuring inbound and outbound communication on a router or firewall.
[pic]
|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/SSL port 443 |
| |Custom ports |
|2 |File and printer sharing service — Either of the following: |
| |Direct-hosted server message block (SMB) (TCP/UDP 445) — Recommended |
| |NetBIOS over TCP/IP (TCP/UDP ports 137, 138, 139) — Disable if not |
| |used |
|3 |Search crawling — 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 port 80 |
| |TCP/Secure Sockets Layer (SSL) port 443 |
| |Custom ports |
|4 |Database communication: |
| |TCP/SSL port 1433 (default) for default instance (customizable) |
| |TCP/SSL random port for named instances (customizable) |
Communication between administrator workstations and Central Administration
The Central Administration site can be installed on any Web server or the search server. Configuration changes that are made through the Central Administration site are communicated to the configuration database. Other server roles in the farm pick up 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. However, depending on which server you deploy the Central Administration site to, be sure to enable access from administrator workstations.
The following figure includes the communication from an administrator workstation to the Central Administration site and the configuration database.
[pic] The following table describes the ports and protocols that are required for communication to and from the Central Administration site.
|Callout |Ports and protocols |
|1 |Central Administration site — One or more of the following: |
| |TCP port 80 |
| |TCP/SSL port 443 |
| |Custom ports |
|4 |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 controller
The following table lists the port requirements for inbound connections from each server role to an Active Directory domain controller.
|Item |Web Server |Search Server |Database Server |
|TCP/UDP 445 (directory services) |X |X |X |
|TCP/UDP 88 (Kerberos |X |X |X |
|authentication) | | | |
|Lightweight Directory Access |X | | |
|Protocol (LDAP)/LDAPS ports | | | |
|389/636 by default, customizable | | | |
The Web servers require the use of LDAP/LDAPS ports only if LDAP authentication is configured.
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 controller and the DNS server.
|Item |Web Server |Search Server |Database Server |
|DNS, TCP/UDP 53 |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 |Search Server |Database Server |
|TCP port 25 |X | | |
Active Directory communication between network domains
Active Directory communication between domains to support authentication with a domain controller 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 ISA Server B to support a one-way trust relationship:
• TCP/UDP 135 (RPC)
• TCP/UDP 389 by default, customizable (LDAP)
• TCP 636 by default, customizable (LDAP SSL)
• TCP 3268 (LDAP GC)
• TCP 3269 (LDAP GC SSL)
• TCP/UDP 53 (DNS)
• TCP/UDP 88 (Kerberos)
• TCP/UDP 445 (Directory Services)
• TCP/UDP 749 (Kerberos-Adm)
• TCP port 750 (Kerberos-IV)
When configuring ISA Server 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:
• How to configure a firewall for domains and trusts ().
• Active Directory in Networks Segmented by Firewalls ()
Plan secure configurations for Windows SharePoint Services features
Topic Last Modified: 2015-03-09
In this article:
• Recommendations for Windows SharePoint Services features
Use this article to find recommendations for configuring and managing Windows SharePoint Services 3.0 features in a more secure manner. You will usually perform the recommended configurations in Central Administration, rather than in the network, operating system, Internet Information Services (IIS), or the Microsoft .NET Framework. The recommendations in this article are appropriate for the following security environments:
• Internal team or department
• Internal IT-hosted
• External secure collaboration
• External anonymous access
For more information about these environments, see Choose your security environment (Windows SharePoint Services).
Recommendations for Windows SharePoint Services features
The following table describes recommendations to help you secure Windows SharePoint Services 3.0 features.
|Feature or area |Recommendation |
|Authentication |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. |
|Authorization |Assign permissions to groups instead of individual accounts. |
|Permission levels |Assign users the least permissions required to complete their tasks. |
|Administration |Use access permissions to secure the Central Administration site and |
| |allow administrators to connect to the site remotely (as opposed to |
| |enabling the Central Administration site for local computer use |
| |only). This alleviates the requirement for administrators to log on |
| |locally to the computer that is hosting Central Administration. |
| |Configuring Terminal Services access to the computer creates a |
| |greater security risk than leaving the Central Administration Web |
| |site available for remote access. |
|E-mail integration |Configure Windows SharePoint Services 3.0 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, Windows SharePoint Services 3.0 |
| |allows you to enable participants who do not have rights 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 Windows SharePoint Services 3.0, this option is |
| |not selected, by default. |
|Web Part storage and security |Ensure that you deploy only trusted code to your server farm. All |
| |code, XML, or 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). |
|Search |The Windows SharePoint Services Search service account must not be a |
| |member of the Farm Administrators group; otherwise, the Windows |
| |SharePoint Services Search service will index 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. |
Plan environment-specific security (Windows SharePoint Services)
Topic Last Modified: 2009-04-15
Planning environment-specific security includes the following tasks:
• Plan security for an internal team or department environment (Windows SharePoint Services)
• Plan security for an internal IT-hosted environment (Windows SharePoint Services)
• Plan security for an external secure collaboration environment (Windows SharePoint Services)
• Plan security for an external anonymous access environment (Windows SharePoint Services)
Use the appropriate tasks based on your target security environment:
• Internal team or department
• Internal IT-hosted
• External secure collaboration
• External anonymous access
For the internal team or department environment, these recommendations are intended to be used instead of the recommendations provided in Plan server farm security (Windows SharePoint Services). This approach relies on the security implemented in an organization's overall network environment and greatly simplifies the amount of security configuration required for an individual team or department.
For the other three environments, the recommendations provided represent additional guidance that is intended to be used together with the recommendations provided in Plan server farm security (Windows SharePoint Services).
This article provides the following information for each environment, as applicable:
• Server design checklist, including topology and logical architecture
• Security hardening for server roles
• Secure configurations for Windows SharePoint Services 3.0 features
Plan security for an internal team or department environment (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
In this article:
• Secure design checklist
• Plan security hardening for server roles
• Plan secure configurations for Windows SharePoint Services features
Security guidance for an internal team or department focuses on recommending practical security configurations and settings for a team or department within a larger organization. This guidance assumes that the servers are not hosted by the primary IT team within the organization.
While the guidance for this environment requires some IT knowledge, it is not necessary for farm administrators to be dedicated IT specialists. If more specialized roles are required to implement a setting, these roles are noted.
This guidance is intended to be used together with the guidance provided in Plan secure configurations for Windows SharePoint Services features.
Secure design checklist
Review the following checklist to ensure that your plans meet the criteria for a secure server topology design.
Topology
|[ ] |For a team or department deployment that has internal access only, |
| |Windows SharePoint Services 3.0 can be installed on a single server |
| |or on two servers. |
|[ ] |In a two-server or more deployment, the Central Administration site |
| |should be hosted on a different server than the front-end Web server,|
| |where possible. This can only be accomplished if application server |
| |roles are hosted on a different server than the front-end Web server |
| |role. |
| |For example, if Server A hosts the front-end Web server role and |
| |Server B hosts the database and application server roles, the most |
| |secure location for the Central Administration site is on Server B. |
| |However, if Server A hosts the front-end Web server and application |
| |server roles and Server B hosts only the database role, the only |
| |option is to host the Central Administration site on Server A. |
Logical architecture
|[ ] |At least one zone in each Web application uses NTLM authentication. |
| |This is required for the search account to crawl content within the |
| |Web application. The search account cannot use Kerberos |
| |authentication to crawl content. |
| |For more information, see Plan authentication methods (Windows |
| |SharePoint Services). |
|[ ] |When deploying custom Web Parts, ensure that only trustworthy Web |
| |Parts are deployed within Web applications that host sensitive or |
| |secure content. This protects the sensitive content against |
| |intradomain scripting attacks. |
Plan security hardening for server roles
Guidance for an internal team or department environment assumes that only internal access is allowed for the servers, sites, and content and that the overall network environment is secured by policies developed by an IT department. Consequently, hardening servers for specific roles is not necessary to the same extent as for other environments. However, there are several features that require specific services or other settings that otherwise might not be configured.
The following table describes recommended hardening settings for an internal team or department.
|Feature |Setting |
|E-mail integration |If e-mail integration is enabled, the SMTP service is required on one|
| |front-end Web server. |
Plan secure configurations for Windows SharePoint Services features
The following table describes additional recommendations for securing Windows SharePoint Services 3.0 features. These recommendations are appropriate for an internal team or department environment.
|Feature or area |Recommendation |
|Authentication |Authenticate against the existing identity management system. If this|
| |is not the Active Directory directory service, use forms |
| |authentication to connect to your identity management system. Using |
| |forms authentication might require assistance from the following |
| |roles: |
| | developer to develop the authentication provider. |
| |Administrator of the identity management system to which you are |
| |connecting. |
|Central Administration site |Restrict access to the Central Administration site to appropriate |
| |users only. |
| |If you are enabling the Central Administration site for remote |
| |administration, secure the Central Administration site by using |
| |Secure Sockets Layer (SSL). |
| |Administrators who run deployment operations must be members of the |
| |local administrators group on the server that hosts the Central |
| |Administration site. |
|Windows SharePoint Services Administration service |In a single-server deployment, the Windows SharePoint Services |
| |Administration service is disabled by default for the following |
| |reasons: |
| |This service, which is used to run deployment tasks that are |
| |initiated from the Central Administration site, is generally not |
| |required for a single-server deployment. However, deployment tasks |
| |can be run by using the Stsadm.exe command-line tool, which does not |
| |require the use of this service. |
| |The account that is used for the Central Administration site is |
| |shared with all other processes. Consequently, disabling this service|
| |results in a more secure configuration. |
| |For a secure single-server deployment, it is recommended to: |
| |Change the server farm account after running Setup. |
| |Start the Windows SharePoint Services Administration service. |
| |Performing these actions will enable you to perform |
| |deployment-related tasks directly from the Central Administration |
| |site. |
Plan security for an internal IT-hosted environment (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
In this article:
• Secure design checklist
• Plan security hardening for server roles
• Plan secure configurations for Windows SharePoint Services features
Security guidance for the internal IT-hosted environment targets guidance to an IT team that is hosting Windows SharePoint Services 3.0 Web applications and sites for multiple teams and departments in an organization.
Secure design checklist
Logical architecture
|[ ] |Organize your environment into separate hosted services. A hosted |
| |service includes sites and services that need to be managed by a |
| |distinct group. This includes managing user profiles and user |
| |permissions. |
Plan security hardening for server roles
No additional guidance is recommended for this environment.
Plan secure configurations for Windows SharePoint Services features
No additional guidance is recommended for this environment.
Plan security for an external secure collaboration environment (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
In this article:
• Protect back-end servers
• Secure client-server communication
• Secure the Central Administration site
• Secure design checklist
• Plan security hardening for server roles
• Plan secure configurations for Windows SharePoint Services features
Security guidance for an external secure environment is targeted to hosting content in an extranet for the purpose of collaborating on content with contributors who do not have general access to your corporate network. This environment allows external partners to participate in a workflow or to collaborate on content together with employees of your organization.
There are several unique recommendations for an external secure collaboration environment. Some of these recommendations might not be practical for all solutions.
Protect back-end servers
External secure collaboration requires Internet-facing servers. You can limit the exposure to traffic from the Internet by protecting back-end servers:
• 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 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.
Secure client-server communication
Secure collaboration in an extranet environment relies on secure communication between client computers and the server farm environment. Where appropriate, use Secure Sockets Layer (SSL) to secure communication between client computers and servers. To increase security, consider the following:
• Require certificates on client computers. SSL can be implemented without requiring client certificates. You can increase the security of external collaboration by requiring certificates on all client computers.
• Use IPsec. If client computers support IPsec, you can configure IPsec rules to achieve a greater level or granularity of security compared with SSL.
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 SSL. This ensures that communication from the internal network to the Central Administration site is secured.
Secure design checklist
Use this design checklist together with the checklists in Plan server farm security (Windows SharePoint Services).
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
|[ ] |Block access to the Central Administration site and configure SSL for|
| |this site. |
|[ ] |Secure SSP administration sites by configuring these sites with SSL, |
| |by hosting these sites in a dedicated Web application, and by |
| |configuring a policy to deny external access to these sites. |
Plan security hardening for server roles
The following table describes additional hardening recommendations for an external secure collaboration environment.
|Component |Recommendation |
|Ports |Block external access to the port for the Central Administration |
| |site. |
|IIS |Restrict SiteData.asmx (the crawler SOAP service) to allow only the |
| |index server (or other crawlers) to access it. |
Plan secure configurations for Windows SharePoint Services features
The following table describes additional recommendations for securing Windows SharePoint Services 3.0 features. These recommendations are appropriate for an external secure collaboration environment.
|Feature or area |Recommendation |
|Authentication |Use SSL for authenticated users. This does not apply to the anonymous|
| |user who is browsing the site. |
|Authorization |Use security policy to cap external users permission (create deny |
| |policies to limit what external users can do). |
Plan security for an external anonymous access environment (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
In this article:
• Protect back-end servers
• Configure anonymous access
• Secure the Central Administration site
• Disable incoming e-mail
• Secure design checklist
• Plan security hardening for server roles
• Plan secure configurations for Windows SharePoint Services 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 application servers (search) 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 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.
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.
Secure design checklist
Use this design checklist together with the checklists in Review the secure topology design checklists (Windows SharePoint Services).
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 (Windows |
| |SharePoint Services). |
|[ ] |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. |
|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 Windows SharePoint Services features
No additional guidance is recommended for this environment.
Plan for security roles (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
In this article:
• Farm-level administration
• Site-level administration
• Worksheet
One of the new features in Windows SharePoint Services 3.0 is a two-tier administrative model that centralizes configuration and management tasks, allows administrative roles to be differentiated, and administration to be delegated and assigned to the appropriate people in your organization. The enhancements in the administrative model can help IT organizations perform administrative tasks more efficiently and effectively. You can use the administrative model and SharePoint groups to give only the permissions that are necessary to perform specific tasks based on specific roles in your organization. To more effectively work within the two-tier administrative model, many organizations designate specific administrative roles within each tier. This article discusses administrative roles within each tier that you can use to help administer your solution.
The following list describes each administrative tier.
• Tier 1: Farm-level administrators Administrators in this tier are the top-level administrators and have permissions to and responsibility for all servers in the server farm. Members can perform all administrative tasks in the SharePoint Central Administration Web site for the server or server farm.
• Tier 2: Site collection administrators Site collection administrators have the Full Control permission level on their site collections.
Windows SharePoint Services 3.0 provides flexibility in how you assign administrative roles. In a centralized management model, you can assign many roles to one or two people in your organization. Alternatively, in a distributed management model, you can delegate specific roles to different people in your organization.
Farm-level administration
Farm-level administration typically is performed by the following roles:
• Farm administrators
• Server-level administrators
Farm administrators
The farm administrator has permissions to and responsibility for all servers in the server farm. The Farm Administrators SharePoint group replaces the SharePoint Administrators group that was used in Windows SharePoint Services version 2.0. Members of the Farm Administrators group do not need to be added to the Administrators group for each server. Farm administrators are members of the WSS_WPG and WSS_RESTRICTED_WPG groups on the computers where Central Administration is hosted and have the Full Control permission level on all servers in the environment. By default, members of the Administrators group are members of the Farm Administrators SharePoint group.
Members of the Farm Administrators group have broad ability to manage the Central Administration site, but are restricted in performing some actions (that is, create Internet Information Services (IIS) Web sites, create or delete SharePoint Web applications, update account passwords or Windows services) due to certain constraints in IIS and the Microsoft .NET Framework. Members of the Farm Administrators group have no administrative access to individual sites or their content by default. However, they can take control of a specific site collection to view any content. For example, if a site collection administrator leaves the organization and a new administrator must be added, farm administrators can add themselves as site collection administrators, which action is recorded in the audit logs. As a best practice, we recommend that you remove farm administrators' permissions to the site collection after the necessary site-level activity is completed. The Farm Administrators group is used in Central Administration only, and is not available for any sites.
[pic] Note:
Although anyone with the Full Control permission level on the Central Administration site can delete the SSP Web application from the Central Administration site, doing so is strongly discouraged because it renders the SSP non-functional. If the Web application is deleted, the only resolution is to restore the SSP from a recent backup. For more information about how to restore from a backup, see Back up and restore the entire farm (Windows SharePoint Services 3.0 technology).
[pic] Note:
Carefully choose to whom you grant memberships in the Administrators group on the local database server computer and to whom you grant memberships in fixed database roles and fixed server roles in Microsoft SQL Server. This is because this group and these roles have the Full Control permission level on the SharePoint Products and Technologies configuration database.
The following table lists tasks that members of the Farm Administrators group can perform.
|SharePoint group |Does role exist by default? |Can do this |Cannot do this |
|Farm Administrators |Yes |Perform administrative tasks in |Administer individual sites or |
| | |Central Administration |site content unless they take |
| | |Take ownership of any content |ownership of the site. |
| | |site. | |
For more information about the Farm Administrators group, see Choose administrators and owners for the administration hierarchy (Windows SharePoint Services).
Server-level administrators
Members of the Administrators group on the local server computer are automatically added to the Farm Administrators group and can perform all farm administrator actions. The Administrators group is a Windows group, not a SharePoint group, but the Administrators group on the local computer performs certain administrative tasks in Windows SharePoint Services 3.0. Like farm administrators, members of the Administrators group on the local computer have no administrative access to site content, by default. However, they can take control of specific site collections, if needed. To take control, they can add themselves as site collection administrators by using the Site Collection Administrators page in Central Administration.
The following table describes the server-level administrator role.
|Group |Does role exist by default? |Can do this |Cannot do this |
|Administrators |Yes. Windows group that exists by |Install products. |Administer individual sites or |
| |default; not a SharePoint group. |Create new Web applications and |site content. |
| | |new Internet Information Services |Administer databases. |
| | |(IIS) Web sites. | |
| | |Start services. | |
| | |Deploy Web Parts and new features | |
| | |to the global assembly cache. | |
| | |Perform all farm-level tasks in | |
| | |Central Administration (provided | |
| | |that the Central Administration | |
| | |site is located on the local | |
| | |computer). | |
| | |Run the Stsadm command-line tool. | |
| | |[pic] Note: | |
| | |Being a server-level administrator| |
| | |is a pre-requisite of running the | |
| | |Stsadm command-line tool. | |
| | |Depending on which command you | |
| | |actually run, you might need | |
| | |additional permissions. For | |
| | |example, if you run stsadm.exe –o | |
| | |deleteweb, the command requires | |
| | |that the account have write access| |
| | |to the content database that | |
| | |contains the Web application. | |
| | | | |
Site-level administration
Site-level administration includes the following roles:
• Site collection administrators
• Site owners
Site collection administrators
Site collection administrators have the Full Control permission level on all Web sites and content within a site collection. From the site collection level, site collection administrators manage settings (such as site collection features, site collection audit settings, and site collection policies) from the Site Settings page for the top-level site. When you create a site collection, you can specify the primary and secondary site collection administrators. A site collection administrator is a user with a flag in the content database that states they can perform all tasks within a site collection, including all tasks for specific sites with a site collection. This flag can be changed by using the Site Collection Administrators page in Central Administration, by using the Site Settings page on a top-level site, or using the site owner operation with the Stsadm command-line tool. Generally, you designate site collection administrators when you create the site, but you can change them as needed in Central Administration or by using Site Settings pages.
The following table describes the site collection administrator role.
|SharePoint group |Does role exist by default? |Can do this |Cannot do this |
|Site collection administrator |Yes |Perform all administration tasks |Access the Central Administration |
| | |for sites within the site |site. |
| | |collection. | |
Site owners
Site owners are those who have been specifically granted the Full Control permission level on the site, either directly or by being a member of a SharePoint group —for example, the Owners group — that has the Full Control permission level on the site. Site owners can perform tasks related to the site only, not the entire site collection.
[pic] Note:
The user that creates the site is automatically added to the Owners group for the site.
The following table illustrates tasks that site owners can perform.
|SharePoint group |Does role exist by default? |Can do this |Cannot do this |
|Site name Owners |Yes |Perform administration for the |Access the Central Administration |
| | |site only, not the entire site |site. |
| | |collection. |Perform site collection |
| | |Perform administrative tasks for |administration tasks, such as |
| | |documents, lists, and libraries. |restoring items from the |
| | | |second-stage Recycle Bin and |
| | | |managing the site hierarchy. |
For more information about site-level administration, see Choose administrators and owners for the administration hierarchy (Windows SharePoint Services).
Worksheet
• Administrators and owners worksheet ()
See Also
Other Resources
Determine permission levels and groups to use (Windows SharePoint Services)
Plan for administrative and service accounts (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
In this article:
• About administrative and service accounts
• Single server standard requirements
• Server farm standard requirements
• Least-privilege administration requirements when using domain user accounts
• Least-privilege administration requirements when using SQL authentication
• Least-privilege administration requirements when connecting to pre-created databases
• Technical reference: Account requirements by scenario
This article describes the accounts that that you must plan for and describes the deployment scenarios that affect account requirements.
Use this article with the following planning tool: Windows SharePoint Services security account requirements (). This planning tool lists the requirements for each account based on the deployment scenario. The requirements are also listed in the Technical reference: Account requirements by scenario section of this article.
The account requirements detail the specific permissions that you need to grant prior to running Setup. In some cases, additional permissions that are automatically granted by running Setup are noted in the planning tool.
This article does not describe security roles and permissions required to administer Windows SharePoint Services 3.0. For more information, see Plan for security roles (Windows SharePoint Services).
About administrative and service accounts
This section lists and describes the accounts that you must plan for. The accounts are grouped according to scope. If an account has a limited scope, you might need to plan multiple accounts for this category.
After you complete installation and configuration of accounts, ensure that you do not use the Local System account to perform administration tasks or to browse sites. For example, do not use the same account that is used to run Setup to perform administration tasks.
Server farm-level accounts
The following table describes the accounts that are used to configure Microsoft SQL Server database software and to install Windows SharePoint Services 3.0.
|Account |Purpose |
|SQL Server service account |SQL Server prompts for this account during SQL Server Setup. This |
| |account is used as the service account for the following SQL Server |
| |services: |
| |MSSQLSERVER |
| |SQLSERVERAGENT |
| |If you are not using the default instance, these services will be |
| |shown as: |
| |MSSQL$InstanceName |
| |SQLAgent$InstanceName |
|Setup user account |The user account that is used to run: |
| |Setup on each server computer |
| |The SharePoint Products and Technologies Configuration Wizard |
| |The Psconfig command-line tool |
| |The Stsadm command-line tool |
|Server farm account |This account is also referred to as the database access account. |
| |This account is: |
| |The application pool identity for the SharePoint Central |
| |Administration Web site. |
| |The process account for the Windows SharePoint Services Timer |
| |service. |
Windows SharePoint Services Search accounts
The following table describes the accounts that are used to set up and configure Windows SharePoint Services Search.
|Account |Purpose |
|Windows SharePoint Services Search service account |Used as the service account for the Windows SharePoint Services |
| |Search service. There is one instance of this service on each search |
| |server. Typically, a server farm will include only one search server.|
|Windows SharePoint Services Search content access account |Used by the Windows SharePoint Services Search application server |
| |role to crawl content across sites. |
| |Plan for multiple accounts if the server farm includes multiple |
| |search server computers. This is not common. |
Additional application pool identity accounts
If you create additional application pools to host sites, plan for additional application pool identity accounts. The following table describes the application pool identity account. Plan one application pool account for each application pool you plan to implement.
|Account |Purpose |
|Application pool identity |The user account that the worker processes that service the |
| |application pool use as their process identity. This account is used |
| |to access content databases associated with the Web applications that|
| |reside in the application pool. |
Single server standard requirements
If you are deploying to a single server computer, account requirements are greatly reduced. In an evaluation environment, you can use a single account for all of the account purposes. In a production environment, ensure that the accounts you create have the appropriate permissions for their purposes.
For a list of account permissions for single server environments, see the Windows SharePoint Services security account requirements () planning tool, or view the requirements listed in the Technical reference: Account requirements by scenario section of this article.
Server farm requirements
If you are deploying to more than one server computer, use the server farm standard requirements to ensure that accounts have the appropriate permissions to perform their processes across multiple computers. The server farm standard requirements detail the minimum configuration that is necessary to operate in a server farm environment. For a more secure environment, consider using the least privilege administration requirements using domain user accounts.
For a list of standard requirements for server farm environments see the Windows SharePoint Services security account requirements () planning tool, or view the requirements listed in the Technical reference: Account requirements by scenario section of this article.
For some accounts, additional permissions or access to databases are configured when you run Setup. These are noted in the accounts planning tool. An important configuration for database administrators to be aware of is the addition of the WSS_Content_Application_Pools database role. Setup adds this role to the following databases:
• SharePoint_Config database (configuration database)
• SharePoint_AdminContent database
Members of the WSS_Content_Application_Pools database role are granted the Execute permission to a subset of the stored procedures for the database. Additionally, members of this role are granted the Select permission to the Versions table (dbo.Versions) in the SharePoint_AdminContent database.
For other databases, the accounts planning tool indicates that access to read from these databases is automatically configured. In some cases, limited access to write to a database is also automatically configured. To provide this access, permissions to stored procedures are configured. For the SharePoint_Config database, for example, access to the following stored procedures is automatically configured:
• proc_dropEmailEnabledList
• proc_dropEmailEnabledListsByWeb
• proc_dropSiteMap
• proc_markForDeletionEmailEnabledList
• proc_markForDeletionEmailEnabledListsBySite
• proc_markForDeletionEmailEnabledListsByWeb
• proc_putDistributionListToDelete
• proc_putEmailEnabledList
• proc_putSiteMap
Least-privilege administration requirements when using domain user accounts
Least privilege administration is a recommended security practice in which each service or user is provided with only the minimum privileges needed to accomplish the tasks they are authorized to perform. This means that each service is granted access to only the resources that are necessary to its purpose. The minimum requirements to achieve this design goal include the following:
• Separate accounts are used for different services and processes.
• No executing service or process account is running with local administrator permissions.
By using separate service accounts for each service and limiting the permissions assigned to each account, you reduce the opportunity for a malicious user or process to compromise your environment.
Least privilege administration with domain user accounts is the recommended configuration for most environments.
For a list of least privilege administration requirements with domain user accounts, see the Windows SharePoint Services security account requirements () planning tool, or view the requirements listed in the Technical reference: Account requirements by scenario section of this article.
Least-privilege administration requirements when using SQL authentication
In environments where SQL authentication is a requirement, you can follow the principle of least privilege administration. In this scenario:
• SQL authentication is used for every database that is created.
• All other administration and service accounts are created as domain user accounts.
Setup and configuration
Using SQL authentication requires additional setup and configuration:
• All database accounts must be created as SQL Server login accounts in SQL Server 2000 Enterprise Manager or SQL Server 2005 Management Studio. These accounts must be created before the creation of any databases, including the configuration database and the 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 Products and Technologies Configuration Wizard to create these databases. To create a farm or to join a computer to a farm, specify the SQL Server login that you created for these databases as the dbusername and dbpassword. The same SQL Server login is used to access both databases.
• 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 SQL Server 2000 Enterprise Manager or SQL Server 2005 Management Studio.
• Secure all communication with the database servers by using Secure Sockets Layer (SSL) or Internet Protocol security (IPsec).
When SQL authentication is used:
• 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.
Creating service and administration accounts
For a list of least privilege administration requirements with SQL authentication, see the Windows SharePoint Services security account requirements () planning tool, or view the requirements listed in the Technical reference: Account requirements by scenario section of this article.
Creating SQL Server logins
Before creating databases, create SQL Server logins for each of the databases. Two logins are created for the configuration and SharePoint_AdminContent databases. Create one login for each content database.
The following table lists the logins that must be created. The Login column indicates the account that is specified or created for the SQL Server login. For the first login, you must enter the Setup user account. For all other logins, you create a new SQL Server login account. For these logins, the Login column provides an example account name.
|Login |Database |SQL Rights |
|Setup user account |Configuration and SharePoint_AdminContent |Specify Windows authentication when creating |
| |databases |the login. |
| |Configuration and SharePoint_AdminContent |Specify SQL authentication when creating the |
| |databases |login. |
| | |Assign the dbcreator server role. |
| |WSS_Search database |Specify SQL authentication when creating the |
| | |login. |
| | |Assign the dbcreator server role. |
| |Content databases |Specify SQL authentication when creating the |
| | |login. |
| | |Assign the dbcreator server role. |
Least-privilege administration requirements when connecting to pre-created databases
In environments where databases are pre-created by a database administrator, you can follow the principle of least privilege administration. In this scenario:
• Administration and service accounts are created as domain user accounts.
• SQL Server logins are created for the accounts that are used to configure databases.
• Databases are created by a database administrator.
For more information about deploying Windows SharePoint Services 3.0 using pre-created blank databases, see Deploy using DBA-created databases (Windows SharePoint Services).
Creating service and administration accounts
For a list of least privilege administration requirements when connecting to an existing blank database, see the Windows SharePoint Services security account requirements () planning tool, or view the requirements listed in the Technical reference: Account requirements by scenario section of this article.
Creating SQL Server logins
Before creating databases, create SQL Server logins for each of the accounts that will access the databases. The accounts planning tool details the specific permissions that are configured for each account. For instructions on how to create and grant permissions to databases, see Deploy using DBA-created databases (Windows SharePoint Services).
The following table lists the logins that must be created. The database column indicates which databases are configured with permissions for each login account. For each login, specify Windows authentication when creating the login.
|Login |Database |
|Setup user account (run-as user for the Psconfig command-line tool) |All databases |
|Server farm account (Office SharePoint Server database access |SSP database |
|account) |SSP search database |
|Windows SharePoint Services Search service account |WSS_Search database |
| |Configuration database |
| |SharePoint_AdminContent database |
|Application pool identity for additional content databases |SSP database |
| |SSP search database |
| |Content databases associated with the application pool |
Technical reference: Account requirements by scenario
This section lists account requirements by scenario:
• Single server standard requirements
• Server farm standard requirements
• Least-privilege administration requirements when using domain user accounts
• Least-privilege administration requirements when using SQL authentication
• Least-privilege administration requirements when connecting to pre-created databases
Single server standard requirements
Server farm-level accounts
|Account |Requirements |
|SQL Server service account |Local System account (default) |
|Setup user account |Member of the Administrators group on the local computer |
|Server farm account |Network Service (default) |
| |No manual configuration is necessary. |
Windows SharePoint Services Search accounts
|Account |Requirements |
|Windows SharePoint Services Search service account |By default, this account runs as the Local System account. |
|Windows SharePoint Services Search content access account |Must not be a member of the Farm Administrators group. |
| |The following are automatically configured: |
| |Added to the Web application Full Read policy for the farm. |
Additional application pool identity accounts
|Account |Requirements |
|Application pool identity |No manual configuration is necessary. |
| |The Network Service account is used for the default Web site that is |
| |created during Setup and configuration. |
Server farm standard requirements
Server farm-level accounts
|Account |Requirements |
|SQL Server service account |Use either a Local System account or a domain user account. |
| |If a domain user account is used, this account uses Kerberos |
| |authentication by default, which requires additional configuration in|
| |your network environment. If SQL Server uses a service principal name|
| |(SPN) that is not valid (that is, that does not exist in the Active |
| |Directory directory service environment), Kerberos authentication |
| |fails, and then NTLM is used. If SQL Server uses an SPN that is valid|
| |but is not assigned to the appropriate container in Active Directory,|
| |authentication fails, resulting in a "Cannot generate SSPI context" |
| |error message. Authentication will always try to use the first SPN it|
| |finds, so ensure that there are no SPNs assigned to inappropriate |
| |containers in Active Directory. |
| |If you plan to back up to or restore from an external resource, |
| |permissions to the external resource must be granted to the |
| |appropriate account. If you use a domain user account for the SQL |
| |Server service account, grant permissions to that domain user |
| |account. However, if you use the Network Service or the Local System |
| |account, grant permissions to the external resource to the machine |
| |account (domain_name\SQL_hostname$). |
|Setup user account |Domain user account. |
| |Member of the Administrators group on each server on which Setup is |
| |run. |
| |SQL Server login on the computer running SQL Server. |
| |Member of the following SQL Server security roles: |
| |securityadmin fixed server role |
| |dbcreator fixed server role |
| |If you run Stsadm commands that affect a database, this account must |
| |be a member of the db_owner fixed database role for the database. |
|Server farm account |Domain user account. |
| |Additional permissions are automatically granted for this account on |
| |Web servers and application servers that are joined to a server farm.|
| |This account is automatically added as a SQL Server login on the |
| |computer running SQL Server and added to the following SQL Server |
| |security roles: |
| |dbcreator fixed server role |
| |securityadmin fixed server role |
| |db_owner fixed database role for all databases in the server farm |
| |Note if you configure the Microsoft Single Sign-On Service, the |
| |server farm account will not automatically be given db_owner access |
| |to the SSO database |
Windows SharePoint Services Search accounts
|Account |Requirements |
|Windows SharePoint Services Search service account |Must be a domain user account. |
| |Must not be a member of the Farm Administrators group. |
| |The following are automatically configured: |
| |Access to read from the configuration database and the |
| |SharePoint_Admin Content database. |
| |Membership in the db_owner role for the Windows SharePoint Services |
| |Search database. |
|Windows SharePoint Services Search content access account |Same requirements as the Windows SharePoint Services Search service |
| |account. |
| |The following are automatically configured: |
| |Added to the Web application Full Read policy for the farm. |
Additional application pool identity accounts
|Account |Requirements |
|Application pool identity |No manual configuration is necessary. |
| |The following are automatically configured: |
| |Membership in the db_owner role for content databases and search |
| |databases associated with the Web application. |
| |Access to read from the configuration and the SharePoint_AdminContent|
| |databases. |
| |Additional permissions for this account to front-end Web servers and |
| |application servers are automatically granted. |
Least-privilege administration requirements when using domain user accounts
Server farm-level accounts
|Account |Server farm standard requirements |Least-privilege using domain user accounts |
| | |requirements |
|SQL Server service account |Use either a Local System account or a domain|Server farm standard requirements with the |
| |user account. |following additions or exceptions: |
| |If a domain user account is used, this |Use a separate domain user account. |
| |account uses Kerberos authentication by | |
| |default, which requires additional | |
| |configuration in your network environment. If| |
| |SQL Server uses a service principal name | |
| |(SPN) that is not valid (that is, that does | |
| |not exist in the Active Directory directory | |
| |service environment), Kerberos authentication| |
| |fails, and then NTLM is used. If SQL Server | |
| |uses an SPN that is valid but is not assigned| |
| |to the appropriate container in Active | |
| |Directory, authentication fails, resulting in| |
| |a "Cannot generate SSPI context" error | |
| |message. Authentication will always try to | |
| |use the first SPN it finds, so ensure that | |
| |there are no SPNs assigned to inappropriate | |
| |containers in Active Directory. | |
| |If you plan to back up to or restore from an | |
| |external resource, permissions to the | |
| |external resource must be granted to the | |
| |appropriate account. If you use a domain user| |
| |account for the SQL Server service account, | |
| |grant permissions to that domain user | |
| |account. However, if you use the Network | |
| |Service or the Local System account, grant | |
| |permissions to the external resource to the | |
| |machine account (domain_name\SQL_hostname$). | |
|Setup user account |Domain user account. |Server farm standard requirements with the |
| |Member of the Administrators group on each |following additions or exceptions: |
| |server on which Setup is run. |Use a separate domain user account. |
| |SQL Server login on the computer running SQL |This account should NOT be a member of the |
| |Server. |Administrators group on the computer running |
| |Member of the following SQL Server security |SQL Server. |
| |roles: | |
| |securityadmin fixed server role | |
| |dbcreator fixed server role | |
| |If you run Stsadm commands that affect a | |
| |database, this account must be a member of | |
| |the db_owner fixed database role for the | |
| |database. | |
|Server farm account |Domain user account. |Server farm standard requirements with the |
| |If the server farm is a child farm with Web |following additions or exceptions: |
| |applications that consume shared services |Use a separate domain user account. |
| |from a parent farm, this account must be a |NOT a member of the Administrators group on |
| |member of the db_owner fixed database role on|any server in the server farm, including the |
| |the configuration database of the parent |computer running SQL Server. |
| |farm. |This account does not require permissions to |
| |Additional permissions are automatically |SQL Server before creating the configuration |
| |granted for this account on Web servers and |database. |
| |application servers that are joined to a | |
| |server farm. | |
| |This account is automatically added as a SQL | |
| |Server login on the computer running SQL | |
| |Server and added to the following SQL Server | |
| |security roles: | |
| |dbcreator fixed server role | |
| |securityadmin fixed server role | |
| |db_owner fixed database role for all | |
| |databases in the server farm. | |
| |Note If you configure the Microsoft Single | |
| |Sign-On Service, the server farm account will| |
| |not automatically be given db_owner access to| |
| |the SSO database. | |
Windows SharePoint Services Search accounts
|Account |Server farm standard requirements |Least-privilege using domain user accounts |
| | |requirements |
|Windows SharePoint Services Search service |Must be a domain user account. |Server farm standard requirements with the |
|account |Must not be a member of the Farm |following additions or exceptions: |
| |Administrators group. |Use a separate domain user account. |
| |The following are automatically configured: | |
| |Access to read from the configuration | |
| |database and the SharePoint_Admin Content | |
| |database. | |
| |Membership in the db_owner role for the | |
| |Windows SharePoint Services Search database. | |
|Windows SharePoint Services Search content |Same requirements as the Windows SharePoint |Server farm standard requirements with the |
|access account |Services Search service account. |following additions or exceptions: |
| |The following are automatically configured: |Use a separate domain user account. |
| |Added to the Web application Full Read policy| |
| |for the farm. | |
Additional application pool identity accounts
|Account |Server farm standard requirements |Least-privilege using domain user accounts |
| | |requirements |
|Application pool identity |No manual configuration is necessary. |Server farm standard requirements with the |
| |The following are automatically configured: |following additions or exceptions: |
| |Membership in the db_owner role for content |Use a separate domain user account for each |
| |databases and search databases associated |application pool. |
| |with the Web application. |This account should not be a member of the |
| |Access to read from the configuration and the|Administrators group on any computer in the |
| |SharePoint_AdminContent databases. |server farm. |
| |Additional permissions for this account to | |
| |front-end Web servers and application servers| |
| |are automatically granted. | |
Least-privilege administration requirements when using SQL authentication
Server farm-level accounts
|Account |Server farm standard requirement |Least-privilege using SQL authentication |
| | |requirements |
|SQL Server service account |Use either a Local System account or a domain|Server farm standard requirements with the |
| |user account. |following additions or exceptions: |
| |If a domain user account is used, this |Use a separate domain user account. |
| |account uses Kerberos authentication by |[pic] Note: |
| |default, which requires additional |All database accounts must be created as SQL |
| |configuration in your network environment. If|Server login accounts in Microsoft SQL Server |
| |SQL Server uses a service principal name |2000 Enterprise Manager or SQL Server 2005 |
| |(SPN) that is not valid (that is, that does |Management Studio. These accounts must be |
| |not exist in the Active Directory directory |created before the creation of any content |
| |service environment), Kerberos authentication|databases, including the configuration database|
| |fails, and then NTLM is used. If SQL Server |and the SharePoint_AdminContent database. |
| |uses an SPN that is valid but is not assigned|Create one SQL Server login for both the |
| |to the appropriate container in Active |configuration database and the |
| |Directory, authentication fails, resulting in|SharePoint_AdminContent database. |
| |a "Cannot generate SSPI context" error | |
| |message. Authentication will always try to | |
| |use the first SPN it finds, so ensure that | |
| |there are no SPNs assigned to inappropriate | |
| |containers in Active Directory. | |
| |If you plan to back up to or restore from an | |
| |external resource, permissions to the | |
| |external resource must be granted to the | |
| |appropriate account. If you use a domain user| |
| |account for the SQL Server service account, | |
| |grant permissions to that domain user | |
| |account. However, if you use the Network | |
| |Service or the Local System account, grant | |
| |permissions to the external resource to the | |
| |machine account (domain_name\SQL_hostname$). | |
|Setup user account |Domain user account. |Server farm standard requirements with the |
| |Member of the Administrators group on each |following additions or exceptions: |
| |server on which Setup is run. |Use a separate domain user account. |
| |SQL Server login on the computer running SQL |SQL Server login on the SQL Server computer. |
| |Server. |NOT a member of the following SQL Server |
| |Member of the following SQL Server security |security roles: |
| |roles: |securityadmin fixed server role |
| |securityadmin fixed server role |dbcreator fixed server role |
| |dbcreator fixed server role |NOT a member of the Administrators group on the|
| |If you run Stsadm commands that affect a |computer running SQL Server. |
| |database, this account must be a member of |[pic] Note: |
| |the db_owner fixed database role for the |You must use the Psconfig command-line tool to |
| |database. |create the configuration database and the |
| | |SharePoint_AdminContent database. You cannot |
| | |use the SharePoint Products and Technologies |
| | |Configuration Wizard to create these databases.|
| | |To create a farm or to join a computer to a |
| | |farm, specify the SQL Server login that you |
| | |created for these databases as the dbusername |
| | |and dbpassword. The same SQL Server login is |
| | |used to access both databases. All other |
| | |content databases can be created in Central |
| | |Administration by selecting the SQL |
| | |authentication option. |
|Server farm account |Domain user account. |Server farm standard requirements with the |
| |If the server farm is a child farm with Web |following additions or exceptions: |
| |applications that consume shared services |Use a separate domain user account. |
| |from a parent farm, this account must be a |NOT a member of the Administrators group on any|
| |member of the db_owner fixed database role on|server in the server farm, including the |
| |the configuration database of the parent |computer running SQL Server. |
| |farm. |NOT a SQL Server login on the computer running |
| |Additional permissions are automatically |SQL Server. |
| |granted for this account on Web servers and |This account does not require permissions to |
| |application servers that are joined to a |SQL Server before creating the configuration |
| |server farm. |database. |
| |This account is automatically added as a SQL | |
| |Server login on the computer running SQL | |
| |Server and added to the following SQL Server | |
| |security roles: | |
| |dbcreator fixed server role | |
| |securityadmin fixed server role | |
| |db_owner fixed database role for all | |
| |databases in the server farm | |
| |Note If you configure the Microsoft Single | |
| |Sign-On Service, the server farm account will| |
| |not automatically be given db_owner access to| |
| |the SSO database. | |
Windows SharePoint Services Search accounts
|Account |Server farm standard requirement |Least-privilege using SQL authentication |
| | |requirements |
|Windows SharePoint Services Search service |Must be a domain user account. |Server farm standard requirements with the |
|account |Must not be a member of the Farm |following additions or exceptions: |
| |Administrators group. |Use a separate domain user account. |
| |The following are automatically configured: |NOT a member of the Administrators group on |
| |Access to read from the configuration |any server in the farm, including the |
| |database and the SharePoint_Admin Content |computer running SQL Server. |
| |database. |NOT a SQL Server login. |
| |Membership in the db_owner role for the | |
| |Windows SharePoint Services Search database. | |
|Windows SharePoint Services Search content |Same requirements as the Windows SharePoint |Server farm standard requirements with the |
|access account |Services Search service account. |following additions or exceptions: |
| |The following are automatically configured: |Use a separate domain user account. |
| |Added to the Web application Full Read policy|NOT a member of the Administrators group on |
| |for the farm. |any server in the farm, including the |
| | |computer running SQL Server. |
| | |NOT a SQL Server login. |
Additional application pool identity accounts
|Account |Server farm standard requirement |Least-privilege using SQL authentication |
| | |requirements |
|Application pool identity |No manual configuration is necessary. |Server farm standard requirements with the |
| |The following are automatically configured: |following additions or exceptions: |
| |Membership in the db_owner role for content |Use a separate domain user account. |
| |databases and search databases associated |NOT a member of the Administrators group on |
| |with the Web application. |any server in the farm, including the |
| |Access to read from the configuration and the|computer running SQL Server. |
| |SharePoint_AdminContent databases. |NOT a SQL Server login. |
| |Additional permissions for this account to | |
| |front-end Web servers and application servers| |
| |are automatically granted. | |
Least-privilege administration requirements when connecting to pre-created databases
Server farm-level accounts
|Account |Server farm standard requirement |Least-privilege when connecting to |
| | |pre-created databases requirements |
|SQL Server service account |Use either a Local System account or a domain|Server farm standard requirements with the |
| |user account. |following additions or exceptions: |
| |If a domain user account is used, this |Use a separate domain user account. |
| |account uses Kerberos authentication by | |
| |default, which requires additional | |
| |configuration in your network environment. If| |
| |SQL Server uses a service principal name | |
| |(SPN) that is not valid (that is, that does | |
| |not exist in the Active Directory directory | |
| |service environment), Kerberos authentication| |
| |fails, and then NTLM is used. If SQL Server | |
| |uses an SPN that is valid but is not assigned| |
| |to the appropriate container in Active | |
| |Directory, authentication fails, resulting in| |
| |a "Cannot generate SSPI context" error | |
| |message. Authentication will always try to | |
| |use the first SPN it finds, so ensure that | |
| |there are no SPNs assigned to inappropriate | |
| |containers in Active Directory. | |
| |If you plan to back up to or restore from an | |
| |external resource, permissions to the | |
| |external resource must be granted to the | |
| |appropriate account. If you use a domain user| |
| |account for the SQL Server service account, | |
| |grant permissions to that domain user | |
| |account. However, if you use the Network | |
| |Service or the Local System account, grant | |
| |permissions to the external resource to the | |
| |machine account (domain_name\SQL_hostname$). | |
|Setup user account |Domain user account. |Server farm standard requirements with the |
| |Member of the Administrators group on each |following additions or exceptions: |
| |server on which Setup is run. |Use a separate domain user account. |
| |SQL Server login on the computer running SQL |NOT a member of the Administrators group on |
| |Server. |the computer running SQL Server. |
| |Member of the following SQL Server security |This account is used to configure databases. |
| |roles: |After each database has been created, change |
| |securityadmin fixed server role |the database owner (dbo or db_owner) to the |
| |dbcreator fixed server role |Setup User account. |
| |If you run Stsadm commands that affect a | |
| |database, this account must be a member of | |
| |the db_owner fixed database role for the | |
| |database. | |
|Server farm account |Domain user account. |Server farm standard requirements with the |
| |If the server farm is a child farm with Web |following additions or exceptions: |
| |applications that consume shared services |Use a separate domain user account. |
| |from a parent farm, this account must be a |NOT a member of the Administrators group on |
| |member of the db_owner fixed database role on|any server in the server farm, including the |
| |the configuration database of the parent |computer running SQL Server. |
| |farm. |This account does not require permissions to |
| |Additional permissions are automatically |SQL Server before creating the configuration |
| |granted for this account on Web servers and |database. |
| |application servers that are joined to a |After the Shared Services Provider (SSP) |
| |server farm. |database and the SSP search database are |
| |This account is automatically added as a SQL |created, add this account to the following |
| |Server login on the computer running SQL |for each of these databases: |
| |Server and added to the following SQL Server |Users group |
| |security roles: |db_owner fixed database role |
| |dbcreator fixed server role | |
| |securityadmin fixed server role | |
| |db_owner fixed database role for all | |
| |databases in the server farm | |
| |Note If you configure the Microsoft Single | |
| |Sign-On Service, the server farm account will| |
| |not automatically be given db_owner access to| |
| |the SSO database. | |
Windows SharePoint Services Search accounts
|Account |Server farm standard requirement |Least-privilege when connecting to |
| | |pre-created databases requirements |
|Windows SharePoint Services Search service |Must be a domain user account. |Server farm standard requirements with the |
|account |Must not be a member of the Farm |following additions or exceptions: |
| |Administrators group. |Use a separate domain user account. |
| |The following are automatically configured: |When running the Psconfig command-line tool |
| |Access to read from the configuration |to start the Windows SharePoint Services |
| |database and the SharePoint_Admin Content |Search service, membership is automatically |
| |database. |configured in the following: |
| |Membership in the db_owner role for the |Users group and db_owner role for the |
| |Windows SharePoint Services Search database. |WSS_Search database. |
| | |Users group in the configuration database. |
| | |Users group in the Central Administration |
| | |content database. |
|Windows SharePoint Services Search content |Same requirements as the Windows SharePoint |Server farm standard requirements with the |
|access account |Services Search service account. |following additions or exceptions: |
| |The following are automatically configured: |Use a separate domain user account. |
| |Added to the Web application Full Read policy|When running the Psconfig command-line tool |
| |for the farm. |to start the Windows SharePoint Services |
| | |Search service, membership is automatically |
| | |configured in the following: |
| | |Users group and the db_owner role in the WSS—|
| | |Search database. |
| | |Users group in the configuration database. |
| | |Users group in the Central Administration |
| | |content database. |
Additional application pool identity accounts
|Account |Server farm standard requirement |Least-privilege when connecting to |
| | |pre-created databases requirements |
|Application pool identity |No manual configuration is necessary. |Server farm standard requirements with the |
| |The following are automatically configured: |following additions or exceptions: |
| |Membership in the db_owner role for content |Use a separate domain user account for each |
| |databases and search databases associated |application pool. |
| |with the Web application. |This account should not be a member of the |
| |Access to read from the configuration and the|Administrators group on any computer in the |
| |SharePoint_AdminContent databases. |server farm. |
| |Additional permissions for this account to |After the SSP database and the SSP search |
| |front-end Web servers and application servers|database are created, add this account to the|
| |are automatically granted. |following for each of these databases: |
| | |Users group |
| | |db_owner role |
See Also
Concepts
Plan for security roles (Windows SharePoint Services)
VI. Plan for performance and capacity
Plan for performance and capacity (Windows SharePoint Services)
Topic Last Modified: 2009-04-15
Performance and capacity planning is the process of mapping your solution design to a farm size and set of hardware that will support your business goals.
The articles in this chapter include:
• Plan for performance and capacity (Windows SharePoint Services) provides links to the articles in this section.
• About performance and capacity planning (Windows SharePoint Services) walks you through the process of determining the hardware requirements for a single farm, and provides an overview of the planning process.
• Plan for software boundaries (Windows SharePoint Services) provides a starting point for planning the performance and capacity of your system. This article includes performance and capacity testing results and guidelines for acceptable performance.
• Estimate performance and capacity requirements (Windows SharePoint Services) provides links to key common usage scenario articles that provide test results and recommendations for specific configurations.
• Windows SharePoint Services collaboration environments addresses test results and recommendations specific to Windows SharePoint Services 3.0 collaboration environments.
• Additional performance and capacity planning factors (Windows SharePoint Services) provides information about additional factors such as caching and environmental considerations.
• Tools for performance and capacity planning (Windows SharePoint Services) provides information about tools you can use to perform performance and capacity testing in your own environment.
Intel performed performance testing against Windows SharePoint Services 3.0 to determine how performance characteristics changed between the 64-bit dual-core Intel Xeon X5150 and quad-core Intel Xeon X5355 processors. This white paper presents their findings.
• White paper: Intel Performance Testing of Windows SharePoint Services presents the findings of Intel performance testing against Windows SharePoint Services 3.0 to determine how performance characteristics changed between the 64-bit dual-core Intel Xeon X5150 and quad-core Intel Xeon X5355 processors.
• Advantages of 64-bit hardware and software (Windows SharePoint Services 3.0) describes the many advantages of using 64-bit hardware and software when setting up Windows SharePoint Services 3.0 servers.
About performance and capacity planning (Windows SharePoint Services)
Topic Last Modified: 2009-04-15
This chapter walks you through the process of determining the hardware requirements for a single farm. It identifies the characteristics that will impact your performance and capacity requirements and provides recommendations for the following:
• Number of server computers in the server farm.
• Configuration of application server roles in the server farm.
• Hardware requirements for specific server roles in the server farm.
Your capacity planning process should include a testing program for the characteristics specific to your environment. Due to the variety of factors that can impact performance and capacity in a given environment, testing is a crucial step in establishing the characteristics of your environment.
Planning for capacity vs. availability
This chapter assumes that you have already used the Plan for redundancy (Windows SharePoint Services) article to plan for availability requirements. As a result of using the "Plan for availability" article, you will start the capacity planning exercise with a topology that meets your organization's minimum availability requirements. Given the topology you have determined you will deploy, this chapter will help you determine:
• If you need to add additional servers to meet your goals for capacity and performance.
• If you need to adjust the configuration of application server roles to optimize capacity and performance of the server farm.
• If you need to plan for more than one server farm based on your capacity requirements.
In some cases, an organization's requirements for availability can result in a server farm size that provides greater capacity or performance than is otherwise required. If this is the case, your capacity planning process can focus on sizing the server hardware economically, rather than on adding additional server computers or scaling up with higher-performing hardware.
In many cases, the topology that meets an organization's minimum availability requirements is used as a starting point and server computers are added or scaled up to meet capacity and performance goals.
64-bit vs. 32-bit
Although Windows SharePoint Services 3.0 can be deployed on 32-bit servers, Microsoft recommends that you employ 64-bit servers in Windows SharePoint Services 3.0 farm deployments. The guidance presented in this guide is based on testing conducted on 64-bit servers. Therefore, if you are planning to deploy to 32-bit servers, you should perform additional testing on the 32-bit servers in your environment. The best practices and performance trends in this guide will still generally apply to 32-bit environments, but actual results may vary.
The 64-bit system architecture has several characteristics that contribute to superior server scalability and performance:
• Memory addressability A 32-bit system can directly address only a 4-GB address space. Windows Server 2003 SP1 running on a 64-bit system architecture supports up to 1,024 gigabytes of both physical and addressable memory.
• Larger numbers of processors and more linear scalability per processor Improvements in parallel processing and bus architectures enable 64-bit platforms to support larger numbers of processors (up to 64) while providing close to linear scalability with each additional processor. Server platforms that offer more than 32 CPUs are available exclusively on 64-bit architecture.
• Enhanced bus architecture The bus architecture on current 64-bit chipsets is faster and wider than earlier generations. More data is passed to the cache and processor; this is somewhat analogous to the improvement that broadband connections offer over dial-up connections.
Performance and capacity planning approach
There are many variables that impact performance and capacity planning. For this reason, it can be difficult to receive a crisp answer to a straightforward question. Consequently, the most common answer to a performance- or capacity-related question begins with, "It depends…".
The performance and capacity planning exercise provided in this chapter is designed to reduce the number of variables in consideration so that straightforward answers can be provided based on common scenarios. However, this chapter also includes the guidance for calculating your capacity and performance requirements based on your individual solution characteristics. This chapter includes two types of planning guidance:
• Recommendations for estimating performance and capacity requirements A series of articles are provided based on targeted scenarios. Each article defines a typical usage profile and identifies the key characteristics that will impact capacity and performance for the scenario. Based on the profile and key characteristics, pre-canned data allows you to estimate capacity capabilities for your solution.
• Formulas and guidance for calculating specific performance and capacity requirements Using this guidance, you can develop your own usage profile (or modify one of the scenario profiles) and calculate all of the variables that impact the capacity and performance of your solution.
Performance and capacity planning process
Performance and capacity planning focuses on three aspects of a sizing your solution:
• Software boundaries Each of the features that can be implemented and the objects that can be created have scale limitations. Planning for capacity boundaries ensures that your solution design fits within the scale recommendations of the software. Software boundaries and limits provided in this guide apply to all Windows SharePoint Services 3.0 environments.
• Throughput targets Throughput is the number of operations per second that a server or server farm is able to process. Each type of action performed by a server farm introduces a performance load on the server hardware. Primary actions include user operations, indexing content, and operations tasks (such as backing up the databases). The use of specific features also adds a performance load. Developing throughput targets involves estimating or calculating the number of operations per second that a server farm will need to process in order to support the expected throughput load.
• Data capacity Data capacity includes the expected volume of content databases and the configuration database. Each server role also has unique data requirements based on the solution, such as disk space for content indexes or for cached content.
Guidance for establishing throughput targets and data capacity is provided for each of the scenarios in Estimate performance and capacity requirements (Windows SharePoint Services).
The recommended process includes the following steps:
• Plan for software boundaries Review the software boundaries and limits of the software against your solution design, and make adjustments to your design, if necessary.
• Estimate performance and capacity requirements Identify the scenario that most closely matches your solution and review the guidance in the corresponding planning article. Use the article to identify the key performance and capacity characteristics for your environment, to estimate throughput and data capacity targets for your solution, and to evaluate your targets against the performance of several sample topologies and sizes of hardware.
• Plan scale actions based on performance and growth After you understand the performance characteristics of your solution and you have determined the server hardware that is required to support your solution, you can plan scale actions for future growth.
• Test solution for your environment After you have established a starting point topology, you can deploy a test environment based on your deployment plan. Use the test tools provided to establish actual performance and capacity data for your environment, and revise your deployment plan as required.
Plan for software boundaries (Windows SharePoint Services)
Topic Last Modified: 2015-03-09
In this article:
• Test environment
• Test results
• Guidelines for acceptable performance
This article provides information to help you understand the tested performance and capacity limits of Windows SharePoint Services 3.0, provides information about the test environment and test results, and offers guidelines for acceptable performance. Use the information in this article to determine whether your planned deployment falls within acceptable performance and capacity limits.
The test results and guidelines provided in this article apply to a single installation of Windows SharePoint Services 3.0. Adding server computers to the installation does not increase the capacity limits of the site objects that are listed in the tables in the Guidelines for acceptable performance section. On the other hand, adding server computers does increase the throughput of a server farm, which might be necessary to achieve acceptable performance with large numbers of objects. In some cases, the requirements for high numbers of objects within a solution might require the use of more than one server farm.
In this article, the guidelines are determined by performance. In other words, you can exceed the guidelines provided, but as you increase the scale, you might experience reduced performance.
Note that there are many factors that can affect performance in a given environment, and each of these factors can affect performance in different areas. Some of the test results and recommendations in this article might be related to features or user operations that do not exist in your environment, and therefore do not apply to your solution. Only thorough testing can provide you with exact data related to your own environment.
See the section Additional performance and capacity planning factors (Windows SharePoint Services) in this guide for more information on other factors that can affect performance and capacity but were not part of the testing process for this guide.
Test environment
The following table lists the specifications of the computers in the test environment.
|Role |Specifications |
|Stand-alone computer |1 dual core Intel Xeon 2.8 gigahertz (GHz) 64-bit processor, 2 |
| |gigabytes (GB) RAM |
|Web server computer |2 dual core Intel Xeon 2.8 GHz 64-bit processors, 4 gigabytes (GB) |
| |RAM |
|Database computer running Microsoft SQL Server |4 dual core Intel Xeon 2.8 GHz 64-bit processors, 3 2GB RAM |
|Client computers |Pentium III 1.2 GHz processor, 1 GB RAM |
A gigabit Ethernet network (one billion bits/sec) was used between the farm computers.
Testing was performed against the configurations listed in the following table.
|Database server |1 Web server |
|Team sites |55% |
|Document workspace |20% |
|Meeting workspace |10% |
|Blog |10% |
|Wiki |5% |
Throughput changes when creating a site vs. enumerating sites as the number of sites increases
User response time for certain operations increases with the number of sites in a site collection.
This graph shows the user response time when enumerating the sites in a site collection and when creating a new site as the number of existing sites increases.
[pic]
Throughput vs. number of site collections in a content database
Throughput, measured in RPS, decreases as the number of site collections in a content database increases.
The following figure shows the decrease in throughput when browsing to the home page of different site collections as the number of site collections in a single content database increases. Throughput decreases quickly as the total number of site collections increases from 2000 (RPS=265) to 16,000 (RPS=66), then RPS remains approximately 50 as the total number of site collections increases to 50,000.
[pic]
Throughput differences between flat document library vs. document library with folders
Throughput for certain operations decreases as the number of items in a folder increases.
The following figure shows the difference in throughput between viewing all items in a document library with and without the effective use of folders, which is critical for scaling. As shown in the graph below, throughput performance degrades as the number of documents increases when flat library storage is used. The quickest drop in throughput occurs when the total number of documents is less than 2,000, from 151 RPS (at 200 documents) to 63 RPS (at 2,000 documents). At 4,000 documents, throughput decreases to about 13 RPS, or an overall throughput decrease of over 90% from an empty library.
[pic] The following figure shows the relative performance between folder views when folders are used to store and organize documents, and an indexed view of a flat library structure. Each folder contains 500 documents created by different users. In this scenario, there is no significant throughput degradation up to 1 million documents for either scenario, provided that the number of items in the view does not exceed the performance threshold for your system. However, performance is better when folders are used.
[pic] As the number of items in a folder increases, folder view performance will gradually degrade. Note that the above results are estimates based on our testing, and results may vary in your environment.
Guidelines for acceptable performance
Capacity is directly affected by scalability. This section lists the objects that can compose a solution and provides guidelines for acceptable performance for each type of object. Limits data is provided, along with notes that describe the conditions under which the limits obtain and links to additional information where available. Use the guidelines in this article to review your overall solution plans.
If your solution plans exceed the recommended guidelines for one or more objects, take one or more of the following actions:
• Evaluate the solution to ensure that compensations are made in other areas.
• Flag these areas for testing and monitoring as you build and deploy your solution.
• Re-design the solution to ensure that you do not exceed capacity guidelines.
The following tables list the objects by category and include recommended guidelines for acceptable performance. Acceptable performance means that the system as tested can support that number of objects, but that the number cannot be exceeded without some performance degradation. An asterisk (*) indicates a hard limit; no asterisk indicates a tested or supported limit.
The following table lists the recommended guidelines for site objects.
|Site object |Guidelines for acceptable |Notes |Scope of impact when |
| |performance | |performance degrades |
|Site collection |50,000 per content database |Total farm throughput degrades |Farm |
| | |as the number of site | |
| | |collections increases. | |
|Site collection |150,000 per Web application |This limit is theoretical, and |This is not a hard limit, and |
| | |is dependent largely upon: |assumes a single database |
| | |Performance of the database |server. Your environment may |
| | |server on which the |not be able to host this many |
| | |configuration database resides.|site collections per Web |
| | |Performance of the Web servers |application. Distributing |
| | |in the farm. |content databases across |
| | |Network bandwidth between the |additional database servers can|
| | |Web servers and the database |increase the effective limit of|
| | |server. |the number of site collections |
| | | |per Web application. You should|
| | | |perform testing to determine |
| | | |the actual effective limit in |
| | | |your environment. |
|Subsite |2,000 per Web site |The interface for enumerating |Site view |
| | |subsites of a given Web site | |
| | |does not perform well as the | |
| | |number of subsites surpasses | |
| | |2,000. | |
|Document |5 million per library |You can create very large |Library |
| | |document libraries by nesting | |
| | |folders, using standard views | |
| | |and site hierarchy. This value | |
| | |may vary depending on how | |
| | |documents and folders are | |
| | |organized, and by the type and | |
| | |size of documents stored. | |
|Item |2,000 per view |Testing indicates a reduction |List view |
| | |in performance beyond two | |
| | |thousand items. Using indexing | |
| | |on a flat folder view can | |
| | |improve performance. | |
|Document file size |50MB (2GB max*) |File save performance is |Library, file save performance |
| | |proportional to the size of the| |
| | |file. The default maximum is 50| |
| | |MB. This maximum is enforced by| |
| | |the system, but you can change | |
| | |it to any value up to 2 GB. | |
|List |2,000 per Web site |Testing indicates a reduction |List view |
| | |in list view performance beyond| |
| | |two thousand entries. | |
|Field type |256 per list |This is not a hard limit, but |List view |
| | |you might experience list view | |
| | |performance degradation as the | |
| | |number of field types in a list| |
| | |increases. | |
|Column |2,000 per document library |This is not a hard limit, but |Library and list view |
| |4,096 per list |you might experience library | |
| | |and list view performance | |
| | |degradation as the number of | |
| | |columns in a document library | |
| | |or list increases. | |
|Web Part |50 per page |This figure is an estimate |Page |
| | |based on simple Web Parts. The | |
| | |complexity of the Web Parts | |
| | |dictates how many Web Parts can| |
| | |be used on a page before | |
| | |performance is affected. | |
|Security scope |1,000 per list |The maximum number of unique |Farm |
| | |security scopes set for a list | |
| | |should not exceed 1,000. | |
| | |A scope is the security | |
| | |boundary for a securable object| |
| | |and any of its children that do| |
| | |not have a separate security | |
| | |boundary defined. A scope | |
| | |contains an Access Control List| |
| | |(ACL), but unlike NTFS ACLs, a | |
| | |scope can include security | |
| | |principals that are specific to| |
| | |Product Short Name. The members| |
| | |of an ACL for a scope can | |
| | |include Windows users, user | |
| | |accounts other than Windows | |
| | |users (such as forms-based | |
| | |accounts), Active Directory | |
| | |groups, or SharePoint groups. | |
The following table lists the recommended guidelines for people objects.
|People object |Guidelines for acceptable performance |Notes |
|Users in groups |2 million per Web site |You can add millions of people to your Web |
| | |site by using Microsoft Windows security |
| | |groups to manage security instead of using |
| | |individual users. |
|User profile |5 million per farm |This number represents the number of profiles|
| | |which can be imported from a directory |
| | |service, such as Active Directory, into the |
| | |people profile store. |
|Security principal |2,000 per Web site |The size of the access control list is |
| | |limited to a few thousand security principals|
| | |(users and groups in the Web site). |
The following table lists the recommended guidelines for search objects.
|Search object |Guidelines for acceptable performance |Notes |
|Search index |1 per Search server | |
|Indexed document |10 million per search index |10 million documents per index server are |
| | |supported, and one search index per index |
| | |server. This means that the effective limit |
| | |of documents per index server is 10 million. |
The following table lists the recommended guidelines for logical architecture objects.
|Logical architecture object |Guidelines for acceptable performance |Notes |
|Shared Services Provider (SSP) |3 per farm (20 per farm maximum) | |
|Zone |5* per farm |The number of zones defined for a farm is |
| | |hard coded to 5. |
|Internet Information Services (IIS) |8 per Web server |Maximum number is determined by hardware |
|application pool | |capabilities. |
|Site collection |50,000 per Web application | |
|Content database |100 per Web application | |
|Site collection |50,000 per database | |
The following table lists the recommended guidelines for physical objects.
|Physical object |Guidelines for acceptable performance |Notes |
|Index servers |1 per SSP* | |
|Application servers running Excel Calculation|No limit | |
|Services | | |
|Search servers |No limit |Because 100 content databases are supported |
| | |for each search server, the number of search |
| | |servers required per farm is based on the |
| | |number of content databases in the farm. For |
| | |example, if there are 500 content databases |
| | |in your farm, you will need at least 5 search|
| | |servers. |
|Web server/database server ratio |8* Web servers per database server |The scale out factor is dependent upon the |
| | |mix of operations. |
|Web server/Domain Controller ratio |3 Web servers per Domain Controller |Depending on how much authentication traffic |
| | |is generated, your environment may support a |
| | |greater number of Web servers per domain |
| | |controller. |
Throughput vs. number of Web servers
In our test environment, farm throughput reached a plateau at 5 Web servers per database server, and did not change substantially when additional Web servers were added. Although you can deploy up to 8 Web servers per database server, you may not realize substantial throughput gains after 5 Web servers. This is because as the number of Web servers making calls against a single database server increases, the database server eventually reaches 100% capacity. Results in your environment may vary according to the performance characteristics of your database server. You will need to conduct your own testing to determine the optimum number of Web servers in your farm environment.
Adding more Web servers to a farm after optimum throughput has been achieved may be desirable for other reasons—for example, if a substantial portion of Web server CPU utilization is consumed by user authentication. In such a case, you should conduct testing to determine the correct solution.
User response times
The following table provides guidelines for acceptable user response times for four types of user operations. Note that your business requirements may allow longer or shorter response times than suggested.
The testing goal was to provide sub-second response time for all end-user operations. However, this is not possible in all cases, so the guidelines in the following table were used.
|Type of operation |Examples |Acceptable user response time |
|Common operation |Browsing to the home page | ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.