Windows SharePoint Services Security Model

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Microsoft includes or takes advantage of the following elements that interact with and affect your security for Web site content:

  • User authenticationThe process used to validate the user account that is attempting to gain access to a Web site or network resource. You manage security using Microsoft Windows NT users and security groups (DOMAIN\user and DOMAIN\security group). You cannot use distribution lists to control access to content in , because distribution lists are not used for authentication in Windows.

  • SharePoint administrators groupA Microsoft Windows user group authorized to perform administrative tasks for .

  • Site groupsA means of controlling the rights assigned to particular users or groups in a Web site based on . There is a pre-defined list of site groups for each Web site (Administrators, Web Designers, and so on). To grant a user access to a Web site, you assign that user to a site group.

    also uses cross-site groups. Cross-site groups are a group of users that can be assigned to a site group on any Web site in a site collection. There are no cross-site groups defined by default in .

  • Administrative port securityA means of controlling access to the administrative port for . Help secure the administrative port by using Secure Sockets Layer (SSL) security or by configuring the firewall to not allow external access to the administration port, or both.

  • Microsoft SQL Server computer connection securityA way to help secure your data. Use either Windows NT Integrated authentication or SQL Server authentication to connect you to your configuration database and content database.

  • Firewall protectionA firewall helps protect your data from exposure to other people and organizations on the Internet. can work inside or through your organization's firewall.

User Authentication

User authentication for is based on Internet Information Services (IIS) authentication methods. can be used with the following forms of user authentication:

  • Anonymous authentication

  • Basic authentication

  • Integrated Windows authentication

  • Certificates authentication (SSL)

You choose the authentication method you want to use when you set up your Web server. You cannot change the authentication method by using the administration tools; you must use the Internet Information Services administration tool for your server computer to change the authentication method. For more information about setting an authentication method, see Configuring Authentication .

Note: For more information about IIS authentication methods, see the topic About authentication in IIS 6.0 Help.

Anonymous Authentication

Anonymous authentication provides access to users who do not have Windows NT server accounts on the server computer (for example, Web site visitors). IIS creates the anonymous account for Web services, which is often named IUSR_ computername . When IIS receives an anonymous request, it impersonates the anonymous account.

You can enable or disable anonymous access in IIS for a particular virtual server, and enable or disable anonymous access for a site on that virtual server by using HTML Administration pages. Anonymous access must be enabled in IIS before you can enable it for a Web site on that virtual server. For more information about configuring anonymous access for a site, see Managing Site Groups and Permissions .

Basic Authentication

Basic authentication is an authentication protocol supported by most Web servers and browsers. Although Basic authentication transmits user names and passwords in easily decoded clear text, it has some advantages over more secure authentication methods, in that it works through a proxy server firewall and ensures that a Web site is accessible by almost any Web browser. If you use Basic authentication in combination with Secure Sockets Layer (SSL) security, you can help protect the user names and passwords, making your user information more secure.

Integrated Windows Authentication

Integrated Windows authentication (also known as Windows NT Challenge Response) encrypts user names and passwords in a multiple transaction interaction between client and server, thus making this method more secure than Basic authentication. Disadvantages are that this method cannot be performed through a proxy server firewall, and some Web browsers (most notably, Netscape Navigator) do not support it. You can, however, enable both this method and Basic authentication at the same time, and most Web browsers will select the most secure option (for example, if both Basic and Integrated Windows authentication are enabled, Microsoft Internet Explorer will try Integrated Windows authentication first).

Certificates Authentication (SSL)

Certificate authentication (also known as Secure Sockets Layer (SSL) security) provides communications privacy, authentication, and message integrity for a TCP/IP connection. By using the SSL protocol, clients and servers can communicate in a way that prevents eavesdropping, tampering, or message forgery. With , SSL helps secure authoring across firewalls and allows more secure remote administration of . You can also specify that SSL be used when opening any Web site based on .

The SharePoint Administrators Group

To install , you must be a member of the local administrators group on the server computer. This group also gives users the permissions needed to control settings on the Central Administration pages, and to run the command-line tool Stsadm.exe. You can also identify a specific domain group to allow administrative access to , in addition to the local administrators group. You can add users to this group rather than to the local administrators group, to separate administrative access to from administrative access to the local server computer.

Members of the SharePoint administrators group do not have access to the IIS metabase, so they cannot perform the following actions for :

  • Extend virtual servers (they can, however, create top-level Web site or change settings for a virtual server).

  • Manage paths.

  • Change the SharePoint administrators group.

  • Change the configuration database settings.

  • Use the Stsadm.exe command-line tool.

Members of the SharePoint administrators group can perform any other administrative action using the HTML Administration pages or object model for .

Members of both the SharePoint administrators group and the local administrators group have rights to view and manage all sites created on their servers. This means that a server administrator can read documents or list items, change survey settings, delete a site, or perform any action on a site that the site administrator can perform.

Site Groups

includes site group to help you assign particular rights to users and cross-site groups. With site groups, you do not have to control the file and folder permissions separately, or worry about keeping your local groups synchronized with your list of Web users. You use site groups to give users permissions on your Web site, and use administration tools to add new users directly.

In effect, user management is delegated from server administrators to the site owners and administrators. Site administrators control site access and, by default, have rights to add, delete, or change site group membership for users. Inside an organization, this typically means that site administrators can select users from the list of the organization's users, and grant them access to varying degrees. For example, if the Web site is for members of a particular workgroup to share documents and information, the site administrator adds members of that workgroup to the site and assigns them to the Contributor site group, so that they can add documents and update lists.

In an ISP or extranet environment, a site owner can add new users and create accounts in an Active Directory group, using separate user lists for each site collections. The site administrator adds the users to the Web site and automatically adds the users to the Active Directory directory service.

Members of the Administrator site group for a top-level Web site can control more options than administrators of a subsites. Administrators of a top-level Web site can perform actions such as enabling or disabling Web document discussions or alerts, viewing usage and quota data, and changing anonymous access settings.

Note: The owner and secondary owner of a top-level Web site may be members of the Administrator site group for their site, but they are also identified separately in the configuration database as site collection owners. This owner flag can only be changed by using the Manage Site Collection Owners page in Central Administration or by using the siteowner operation with Stsadm.exe. If you remove an owner from the Administrator site group for the site, the owner retains the owner flag in the database, and can still perform site collection administration tasks.

For more information about user accounts and Active Directory account creation mode, see Managing Users and Cross-Site Groups . For more information about site groups, see Managing Site Groups and Permissions .

Securing the Administrative Port

If a malicious user can gain access to your administrative port, he or she can potentially block other users from accessing their sites, or can change or delete content from the sites, or even completely disable your Web server. When you install , the administration port is assigned to a random port number. It is important to restrict access to the administration port, and you can do so by using the following methods:

  • Use Secure Sockets Layer (SSL) encryption.

    If you want to be able to manage across an Internet connection, use SSL to provide more secure communication between a client machine and the server, even across the Internet. To use SSL, you must first configure SSL in IIS, and then use the command line to configure . Note that when you use SSL, the Uniform Resource Locator (URL) for SharePoint Central Administration changes from https:// to https://. For more information about configuring SSL, see Configuring Authentication .

  • Use a firewall or IIS to restrict external access to certain domains.

    You can use the settings for your firewall to block access to the administrative port altogether (if you don't need to allow administration over the Internet), or to restrict access to the administrative port to certain domains. Use the stsadm -o setadminport operation to set each server in your server farm to the same port number, and configure the firewall to help protect that port on all servers. Alternatively, you can use the IP and name restrictions feature in IIS to restrict access to specific domains (you must set this for each virtual server that you want to restrict access to). For more information about helping to protect a port in IIS, see the Securing Your Site with IP Address Restrictions topic in the IIS Help system.

  • Use the SharePoint administrators group to restrict internal access.

    Use the SharePoint administrators group to control which users can access SharePoint Central Administration. Only the domain group you specify, and local administrators, can then access the administrative port. Limit the local administrator access to only a few computer operators.

  • Use Integrated Windows authentication instead of Basic authentication.

    When you use Integrated Windows authentication, you avoid having passwords sent in clear text, as can happen when Basic authentication is used. Basic authentication is less secure because it uses clear text.

  • Disable anonymous access.

    Allowing anonymous access makes your server inherently less secure. If anonymous users can get access to your server, they can change settings or content, and their actions cannot be traced to a real user account. Anonymous access is disabled by default for the administration port.

Securing SQL Server Connections

If you are using SQL Server instead of Microsoft SQL Server 2000 Desktop Engine (Windows) (WMSDE 20) for your databases, you can choose between the following two security methods for your interactions between and SQL Server:

  • Windows NT Integrated authenticationConnect to SQL Server using an IIS application pool. This method is the more secure option, and is the default authentication type for installations with SQL Server.

    Note that if you are using SQL Server on a separate server from the server running , you must use a domain account (or the Local System or Network Service account) as the IIS application pool account. If you are using a local account, it will not be able to access the SQL Server computer. For the administration virtual server, the IIS application pool account must also have rights to create new databases in SQL Server. In other words, this account must be a member of the Security Administrators and Database Creators roles in SQL Server. If you use Local System or Network Service, you must grant the SQL Server privileges to the machine account for the Web server computer. Application pool accounts for other virtual servers do not need database creation rights; they rely on the administration virtual server to create databases.

  • SQL Server authenticationConnect to SQL Server using credentials you type in administrative controls.

About Windows NT Integrated Authentication

With Windows NT Integrated authentication, you use the IIS application credentials and the IIS application process (called an application pool) to connect to the database. The credentials are stored securely in the IIS metabase with other IIS worker processes. When connects to the SQL Server database, it runs under its usual process, and uses the IIS process for the connection. This configuration can require a few more steps in a server farm environment on occasion. For example, if your domain has a policy requiring frequent password resets, you must remember to change the password in IIS for every server computer in your server farm.

You can have a single process for all of your virtual servers, or you can isolate each virtual server with its own application pool. Using separate processes is more secure. For example, if you have a custom script running for one virtual server, it could potentially be written to access pages in another virtual server if they are sharing an application pool. If they have separate application pools, the script is unable to authenticate for the database across virtual servers.

About SQL Server Authentication

SQL Server authentication uses an administrator account and password (often the default sa account) stored in the SQL Server database to connect between and the databases. This same user name and password are used for all updates to the databases, no matter which server (in a server farm) or virtual server (server farm or single server) requests the update. Also, when you use SQL Server authentication, the password for the administrator account is sent over the network, and can potentially be detected by malicious users. It is recommended that you use Windows NT Integrated authentication for connections between and the SQL Server databases.

Caution: When you use SQL Server authentication, the user name and password you specify is available to all members of the STS_WPG group, which may include accounts associated with other applications on your server.

About Firewalls

supports connectivity through firewalls. Depending on your configuration, you must make sure your firewall is open for the standard HTTP ports 80 and 443. When using a firewall, you must configure your Web sites with Basic authentication because Integrated Windows authentication cannot pass through a firewall.

For more information about site groups in , see Managing Site Groups and Permissions and Managing Users and Cross-Site Groups .