Implementing Information, Communication, and Collaboration Security

Every IT organization places security as a top priority for the systems and services it provides. Security as it relates to managing the knowledge and data of the company is equally paramount. Just as this book begins with an account of security measures and best practices in Windows Server 2003, it seems fitting to complete the book on the same note.

For traditional data and user management, Windows Server 2003 leverages the NTFS file system, Active Directory, and group Policies as detailed in Chapter 5, "Managing User Rights and Permissions." As Windows SharePoint Services is installed on Windows Server 2003, the best practices detailed in that chapter also apply here. In addition to security practices that leverage the file system and Active Directory, though, WSS has its own security measures built in to ensure that data managed through the SharePoint is equally secure.

WSS Security

Many of the security measures of WSS have been touched on in various points throughout the chapter. The following is a rundown of features that maximize secure data management through SharePoint technologies:

• User Authentication. The process used to validate the user account that is attempting to gain access to a Web site or network resource. The administrator manages security using Windows users and security groups either locally or at the domain level.

• SharePoint Administrators Group. A Microsoft Windows user group authorized to perform administrative tasks for WSS. When WSS is installed, this unique administrative group is created.

• Site Groups. A means of controlling the rights assigned to particular users or groups in WSS Web sites. Similar to delegation of control in Active Directory, site groups help to distribute the management of data in the WSS framework. There is a predefined list of site groups for each Web site (Administrators, Web Designers, and so on). Granting a user a particular level of access to a Web site is accomplished by assigning that user to a site group.

• Administrative Port Security. A means of controlling access to the administrative port for WSS. 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 Connection Security. When SQL is an integrated component of the WSS solution, there is an additional layer of security added. Use either Windows Integrated 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. WSS can be placed either inside or outside the organization's firewall depending on the function it will play. If WSS will be used to create an extranet or to provide services on the Internet, it is a best practice to use a DMZ network configuration to protect the WSS server.

Internet Explorer Enhanced Security

By default, Windows Server 2003 provides a set of security settings called Internet Explorer Enhanced Security Configuration. These settings limit the types of content that a user at the server can view using Internet Explorer, except for sites listed in the Local intranet and Trusted sites zones. For example, by default, scripting on Internet pages will not run when the site is accessed from the server.

The goal of these settings is to help ensure that a local user on the server will not download a virus or other harmful files from the Internet and infect the server. This is especially pertinent to Web servers. The security features of Internet Explorer Enhanced Security Configuration do not affect remote users viewing content on the server, only users running Internet Explorer on the server computer itself.

Using Internet Explorer Enhanced Security Configuration on a Web Server running WSS prevents some code necessary for viewing site pages or HTML administration pages from running. Again, remote users with proper access rights can still view the pages correctly, but a user running Internet Explorer on the server computer will be unable to view or administer the site. Note also that the user at the server computer will be unable to view and administer a remote SharePoint site because of the security settings.

Adding All the URLs for Virtual Servers

If you choose to add all the URLs for virtual servers and domain named sites to the Local Intranet zone of IE in a Web farm implementation, this must be done on each front-end server that is participating in the WSS Web farm. Depending on the size of the implementation, this could be a time-consuming process.

There are ways to get around this security issue so that a local user can run the necessary scripts from the WSS server and still maintain a level of security:

• For simple SharePoint installations, the local administrator can run WSS by using the default localhost name . By default, the SharePoint Central Administration link uses the localhost naming method. This method is not a good option for more complex SharePoint installations that use host-header based site or Web farms.

• The recommended workaround that preserves the highest level of security involves adding the URLs for all of the hosted virtual servers to the Internet Explorer Local intranet zone. In a Web farm, the administrator must also add the URLs of all domain named sites to the list of local intranet sites.

• Internet Explorer Enhanced Security can also be uninstalled . This is perhaps the least secure alternative. If you are not concerned about users working locally at the Web server, this will resolve any problems with scripts running as expected. This alternative requires the least amount of time to configure as the Internet Explorer Enhanced Security can be uninstalled quickly using Add or Remove Windows Components.