Windows SharePoint Services 2.0 Security Model
Microsoft Windows SharePoint Services includes or takes advantage of the following elements that interact with and affect your security for Web site content:
User authentication The 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 Windows SharePoint Services, because distribution lists are not used for authentication in Windows.
SharePoint administrators group A Microsoft Windows user group authorized to perform administrative tasks for Windows SharePoint Services.
Site groups A means of controlling the rights assigned to particular users or groups in a Web site based on Windows SharePoint Services. 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.
Windows SharePoint Services 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 Windows SharePoint Services.
Administrative port security A means of controlling access to the administrative port for Windows SharePoint Services. 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 (SQL Server computer: A computer running Microsoft SQL Server with a configured database.) connection security A way to help secure your data. Use either Integrated Windows authentication or SQL Server authentication to connect you to your configuration database and content database.
Firewall protection A firewall helps protect your data from exposure to other people and organizations on the Internet. Windows SharePoint Services can work inside or through your organization's firewall.
User authentication for Windows SharePoint Services is based on Internet Information Services (IIS) authentication methods. Windows SharePoint Services can be used with the following forms of user 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 Windows SharePoint Services 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 (Windows SharePoint Services 2.0).
For more information about IIS authentication methods, see the topic About authentication in IIS 6.0 Help.
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 (Windows SharePoint Services 2.0).
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 Windows SharePoint Services, SSL helps secure authoring across firewalls and allows more secure remote administration of Windows SharePoint Services. You can also specify that SSL be used when opening any Web site based on Windows SharePoint Services.
The SharePoint Administrators Group
To install Windows SharePoint Services, 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 Windows SharePoint Services, 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 Windows SharePoint Services 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 Windows SharePoint Services:
Extend virtual servers (they can, however, create top-level Web site or change settings for a virtual server).
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 Windows SharePoint Services.
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.
Windows SharePoint Services Site Groups
Windows SharePoint Services 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 Windows SharePoint Services 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 Windows SharePoint Services 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.
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 (Windows SharePoint Services 2.0). For more information about site groups, see Managing Site Groups and Permissions (Windows SharePoint Services 2.0).
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 Windows SharePoint Services, the administration port is assigned to a random port number. It is important to restrict access to the Windows SharePoint Services 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 Windows SharePoint Services 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 Windows SharePoint Services. Note that when you use SSL, the Uniform Resource Locator (URL) for SharePoint Central Administration changes from http:// to https://. For more information about configuring SSL, see Configuring Authentication (Windows SharePoint Services 2.0).
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) for your databases, you can choose between the following two security methods for your interactions between Windows SharePoint Services and SQL Server:
Integrated Windows authentication — Connect to SQL Server using an IIS application pool. This method is the more secure option, and is the default authentication type for Windows SharePoint Services installations with SQL Server.
Note that if you are using SQL Server on a separate server from the server running Windows SharePoint Services, 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 authentication — Connect to SQL Server using credentials you type in Windows SharePoint Services administrative controls.
About Integrated Windows Authentication
Windows SharePoint Services uses the authentication method specified in the IIS metabase, which is Integrated Windows Authentication, by default. Integrated Windows Authentication contains both Kerberos v5 authentication and NTLM authentication methods. New in SP2, the authentication method that is used when Windows SharePoint Services connects to the database is determined by the value of the NTAuthenticationProviders metabase property in IIS. If this property is not set (is null) or is set to Negotiate,NTLM, Kerberos authentication is used; otherwise NTLM is used. For more information about Integrated Windows Authentication, see the Integrated Windows Authentication topic in the IIS 6.0 Administrator Guide.
In earlier versions (prior to Service Pack 2) installing Windows SharePoint Services changed the authentication method to NTLM for all virtual servers. This meant that existing sites that relied on Kerberos authentication no longer worked after Windows SharePoint Services was installed. Windows SharePoint Services Service Pack 2 no longer changes the default authentication method to NTLM. For additional information, see Installation Considerations for Windows SharePoint Services 2.0.
Using a domain user account might require additional steps to add a Service Principal Name (SPN) to the account. Information about adding a Service Principal Name (SPN) to a domain user account is available in Using Integrated Windows Authentication with Windows SharePoint Services 2.0 and the Microsoft Knowledge base article 832769: How to configure a Windows SharePoint Services virtual server to use Kerberos authentication.
With Integrated Windows 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 Windows SharePoint Services 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 Windows SharePoint Services 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 Integrated Windows authentication for connections between Windows SharePoint Services and the SQL Server databases.
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.
Windows SharePoint Services 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 Windows SharePoint Services, see Managing Site Groups and Permissions (Windows SharePoint Services 2.0) and Managing Users and Cross-Site Groups (Windows SharePoint Services 2.0).