Security and SharePoint Team Services

  • Article
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.
On This Page

Introduction
Security Features
Locking down SharePoint™ Team Services
Other Considerations

Introduction

This document discusses the security features for SharePoint™ Team Services from Microsoft® and shows how to configure the server from a security standpoint. There is often a fine balance that must be maintained between functionality, performance, and security. This white paper leans toward security. When there is a functionality or performance loss as a result of a security configuration it will be noted. All registry keys discussed are under HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\All Ports unless otherwise noted.

Security Features

Roles: Roles are a key security feature that is introduced in SharePoint Team Services. They allow an administrator to granularly define a set of permissions and define that set as a role. These individual permissions are known as rights. Some rights should not be thought of as secure; a determined user can bypass these rights. The non-secure rights include Theme Web, Border Web, and Link Style Sheets. For example, the Theme Web right should not be considered secure because while it does stop a user from applying a theme to the entire web directly, it does not stop the user from applying the theme to each page which effectively applies the theme to the entire web.

Roles can be configured to use Windows NT® machine groups or to use Windows NT user accounts. Under the machine group configuration, a separate machine group is created for each role. When a user is added to the role, the user is added to the corresponding machine group. The file system ACLs will include the machine group and not individual user accounts. This is the default configuration. Under the user account configuration, SharePoint Team Services will maintain a list of individual user accounts and their role membership. SharePoint Team Services will add each individual user account to the file system ACLs. To enable this configuration, you must set the registry key NoMachineGroups to the string value of "1" before extending any virtual server on the server. This is a machine wide setting; it is not possible to use different configurations for separate virtual servers on the same machine.

NT Account Creation: Web administrators have the ability to create NT accounts. These accounts can be added through the "Manage virtual server accounts", "Manage Users" or the "Invitation Wizard" administration pages. Although it is possible to remove accounts through Windows tools like Computer Management, the accounts should be removed through the "Manage virtual server accounts" page. This allows SharePoint Team Services to easily update various configuration files including quota information.

Server Health: The Server Health feature will check various aspects of a SharePoint Team Services virtual server. The following are security related checks that Server Health can perform.

Reapply file security settings: Windows NT file permissions (ACLs) are added to files and directories in the web content space. This check does not remove any permissions; it just adds permissions that are required but are missing.

Check roles configuration: Verify the roles configuration files are syntactically correct. The roles configuration would most likely become incorrect if user accounts, machine groups, or the SharePoint Team Services configuration files are modified behind the product's back.

Tighten security: Unnecessary ACLs are removed from files and directories in the web content space. Necessary ACLs are determined by the web's role configuration. If a machine group or user ACL exists on the file system, but is not listed in the role configuration file, it is unnecessary and will be removed. Therefore if you have added custom ACLs to files or directories, your customizations will be lost when the tighten check is performed.

Check anonymous access: This check determines if an anonymous user account (IUSR, Everyone, etc) is a member of a role with higher access than the role used for anonymous access.

User Account Limits: The Windows NT administrator can use this feature to set a maximum number of NT accounts each virtual server can create. Once this limit is reached, to add more user accounts the virtual server admin must either delete an existing account or ask the NT administrator to raise the account limit. The limit only counts user accounts created through the SharePoint Team Services product. Existing accounts and accounts created outside of SharePoint Team Services are exempt from the quota feature. The account limit can be set through the global admin pages. Setting the limit to zero would disable account creation. Accounts created through SharePoint Team Services can only be used by the virtual server that created them. For example, if example1.microsoft.com and example2.microsoft.com are virtual servers on the same machine and example1.microsoft.com creates a user named "tom", this account cannot be added as an existing user to example2.microsoft.com. Setting the AccountTracking registry key to the string value of "0" will disable limiting SharePoint Team Services created accounts to one virtual server. The default value is "1".

Require Secure Socket Layer (SSL) for Authoring and Administration: Many administrators do not want to require SSL for all transactions because most are anonymous requests for non-sensitive data and https put more stress on the server than plain http. However, when authoring or performing administration on a Web site based on SharePoint Team Services, the user's credentials are sent with the request. A malicious user may sniff the network to look for credentials and then compromise the server. By requiring SSL, the credentials will be sent across a secure channel. If authoring or administration is attempted over http when SSL is required, the user will be told to use https. If you are extremely concerned about credential sniffing, you should disable http altogether through IIS. This will impact performance, but will also stop sniffing of credentials for other actions besides authoring and administration that require authentication. Require SSL for Authoring and Administration can be enabled through the global admin pages. This option can be configured through "Set Installation Defaults" page on the global administration virtual server for all virtual servers or on the "General Settings" page for a specific virtual server. By default, this feature is not enabled. The administrator will need to setup SSL through IIS with a server certificate. Please visit the link in the recommended reading section of this document to learn more about installing a certificate for SSL.

Log Authoring Actions: When this feature is enabled a log file is created in the _vti_log directory of each web. Each authoring operation is recorded with the current time, remote host, author's user name, web name, operation performed, and the per-operation data. This log file should only be used for debugging purposes and not trusted as secure data. This option can be configured through "Set Installation Defaults" page on the global administration virtual server for all virtual servers or on the "General Settings" page for a specific virtual server. By default, this feature is not enabled.

Allow Authors to Upload Executables: This feature will allow a user to uploading an executable file to a directory marked executable. By default this option is disabled. The option can be configured through "Set Installation Defaults" page on the global administration virtual server for all virtual servers or on the "General Settings" page for a specific virtual server.

Global Rights Mask: Any SharePoint Team Services right can be disabled for all virtual servers. If a right is disabled through the global rights mask but it is enabled in a role for a specific web, the right will be disabled for that web. This is a useful option if the administrator wishes to disable a certain right for all users on the machine. The NT administrator can manage the global rights mask through the global administration pages. This option can be configured through the "Set List of Available Rights" page on the global administration virtual server. By default, all rights are enabled.

Local NT Accounts Only: The option will prohibit using domain users and groups in any part of a Web site based on SharePoint Team Services. For example, the invitations feature attempts to find usernames based on user-supplied data, setting this registry key will limit the lookup scope to the local machine. Setting the LocalNTAccountsOnly registry key to a string value of "1" will enable this option. The default value is "0" (disabled).

Restrict Account Visibility: Setting the RestrictAccountVisibility registry key to a string value of "1" will limit the list of usernames displayed in the FrontPage 2000 and earlier versions of the client. The display is limited to users created through SharePoint Team Services for the current virtual server and users belonging to a role in the current web. The default value for this registry key is "0".

Locking down SharePoint™ Team Services

Before Installation

File system type: For the most security you should install the SharePoint Team Services program (\Program Files\Common Files\Microsoft Shared\Web Server Extensions\50) on a NTFS partition as well as having virtual server's directories on a NTFS partition. Previous versions of the FrontPage Server Extensions allowed anonymous authoring if the virtual server's home directory was on a FAT partition. This is no longer the case, but for file system security you must use NTFS. If you have already installed on FAT, you can use a Windows tool, convert.exe, to convert from FAT to NTFS. After the file system is converted the permissions are set to Everyone:Full Control.

Anonymous User Account: A separate anonymous user account (also referred to as the IUSR account) should be used for each virtual server. The anonymous user account is placed on the ACLs on certain files in the web content space. If virtual servers use the same account for anonymous access, virtual servers may be able to access files that you didn't expect. The anonymous access account can be configured through IIS's Internet Services Manager.

Accessing files outside of SharePoint Team Services: There are several common ways files are modified behind SharePoint Team Services' back. These include FTP, UNC, and the File System Object (FSO). For both stability and security reasons, files in the web content space should not be modified behind SharePoint Team Services' back. It is recommended that you disable FTP access to Web sites based on SharePoint Team Services; users should use an Office client or Web Folders to transfer files between their machine and the web server. Disabling the FSO may result in a functionality loss. SharePoint Team Services has no dependencies on the FSO, but many ASP developers use the FSO to manipulate files on the server. SharePoint Team Services' security does not crumble if the FSO is enabled on the server, but it is recommended that you disable this object. It can be disabled by issuing the following command: "regsvr32 scrrun.dll /u". You may also wish to disable the Windows Script Host (WSH) object. This object includes a great deal of functionality including a run method to execute commands on the server. This object is used by many scripts including MBSA (discussed later in this document). If you do not need the WSH, you can disable it with the following command: "regsvr32 wshom.ocx /u".

SQL interactions: Much of SharePoint Team Services' data is stored in the database. The security of your Web site based on SharePoint Team Services also relies on the security of the database. If you did not have a database (SQL or MSDE) installed on your web server prior to installing SharePoint Team Services, Microsoft Data Engine (MSDE) will be installed with a random administration password. If you already have a database installed it is essential that you use a strong database password. For more information about SQL security, please visit the link listed in the recommended reading at the end of this document.

After Installation

SharePoint Search Proxy: SharePoint Team Services creates two virtual servers – the SharePoint Search Proxy and the SharePoint Administration virtual servers. The search proxy is used to index all SharePoint Team Services virtual servers for searching. Users do not need to directly connect to this virtual server. It is best if you change the IP restrictions on this virtual server to deny all. To do this by following these steps:

  1. In the Internet Services Manager, view the properties for the Microsoft SharePoint Search Proxy.

  2. Click the Directory Security tab.

  3. Click Edit under IP address and domain name restrictions

  4. Set the default setting to be Deny Access

  5. Remove any IPs in the exception list.

Microsoft SharePoint Administration Port: This virtual server is created when SharePoint Team Services is installed. It is used for the Windows NT administrator to manage SharePoint Team Services virtual servers. Since only members of NT's BUILTIN\Administrators group will be authorized to use this feature, https should be enabled and http disabled through IIS. All requests to this virtual server will require authentication so SSL will make sniffing credentials difficult. If you will only perform administration from known IPs, you might consider adding IP restrictions to this virtual server as an added layer of protection.

User Management: Verify the list of users that are a member of your web. This can be done by browsing to https://server/_vti_bin/_vti_adm/fpadmdll.dll?page=user.htm. On the Internet, it is recommended to remove the Everyone group from all roles even if you want everyone to have browse access and the Everyone group is in the Browser role. The preferred way to give everyone access to a site is to enable anonymous access with a specified role. This is operation can be performed on the "Change Anonymous Access Settings" administration web page. On an Intranet, anonymous access can be disabled and domain groups can be added to a specific role. For example, "DOMAIN\Domain users" can be added to the Author role. This would allow all users in the "DOMAIN" domain author access. This method is preferred over using the anonymous role in an Intranet because the authoring actions are not done anonymously. This will allow tracking which users perform certain actions.

Locking down ACLs: The ACLs on Program Files\Common Files\Microsoft Shared\Web Server Extensions\50\servsupp and \Inetpub\OWS_Search_Proxy should be tightened. This can be done with the following commands:

cacls "c:\Inetpub\OWS_Search_Proxy" /P Everyone:R

cacls "c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\50\servsupp" /P "NT Authority\Terminal Server User":R

Using SSL: If you are particularly concerned about attackers sniffing your network traffic, you should enable SharePoint Team Services' option to require SSL for authoring and administration on both the web site and the global administration port. You should also disable http traffic in IIS. Even if you are not very concerned, it is recommended that you only use SSL on the global administration port because a NT administrator account's credentials are used.

Server Health: After you have installed SharePoint Team Services and extended a virtual server, you should run Server Health with the checks for Reapply file security settings, Check roles configuration, Tighten security, and Check anonymous access.

Other Considerations

Ongoing Security

The security of your Web site based on SharePoint Team Services is dependent on the security of Windows 2000, Internet Information Server (IIS), Index Server, and SQL Server. Ensuring your sever is secure should be an everyday activity. It is very important to check https://www.microsoft.com/technet/security/current.aspx for new Microsoft security bulletins in these products as well as SharePoint Team Services. You can also subscribe to the Microsoft Security Notification Service https://www.microsoft.com/technet/security/bulletin/notify.mspx to receive an email about new security bulletins. A tool called Microsoft Baseline Security Analyzer (MBSA) has been created to check your server to verify all of the IIS security patches have been installed. This tool can be downloaded from https://www.microsoft.com/downloads/details.aspx?FamilyID=b13ebd6b-e258-4625-b0a3-64a4879f7798.

Locking Down Other Products

Since the security of your Web site based on SharePoint Team Services depends on the security of Windows 2000, IIS, Index Server, and SQL, you should consider locking down these products as well. If one of these products is compromised, your SharePoint Team Services site can likely be compromised.

© 2001 Microsoft Corporation. All rights reserved.