This type of deployment generally consists of a small farm with two or three servers, and its users are restricted to one team or department in your organization. Microsoft states that this type of deployment is not hosted by the primary IT team in the organization; however, some organizations will have deployments of this type that are hosted by IT. This type of deployment has slightly lesser security requirements than other types of deployments because generally everyone who can access the site is authorized to access any of the information on the site. Many of the default security settings are intended for this type of environment, so securing this type of deployment usually requires less effort than the other types.

Microsoft refers to an internal IT-hosted deployment as one that provides services for multiple teams and departments within the organization. The security requirements for this type of deployment are typically more stringent because usually teams and departments are not authorized to access at least some information from other teams or departments due to the sensitive nature of the information.

An external secure collaboration environment is a server or farm accessible from the Internet to outside users. These users may be employees or contractors of your organization, or customers, resellers, suppliers, or business partners. These sites may also include some level of anonymous access in some circumstances—for instance, if your external secure site is an extension of your organization’s public web site. In general, an external secure collaboration environment should not have any level of anonymous access enabled, to avoid disclosing sensitive information. However, in some environments, this may be desirable and an acceptable risk.

An external anonymous access environment is one accessible from the Internet where outside users can access content on the site without authenticating. This is generally used as a public web site.

For details and checklists on specific security guidance for each environment, see the TechNet article “Choosing your security environment” at http://technet2.microsoft.com/Office/en-us/library/753fc3f6-e888-4bb6-ab67-288df065c2511033.mspx?mfr=true.

Sites that are accessible from the Internet have more stringent topology design requirements than internal sites. Frontend servers servicing requests from the Internet should be located in a Demilitarized Zone (DMZ). A DMZ is a dedicated network segment, usually located off of a third interface of your perimeter firewall, where servers providing services to Internet hosts are homed (Figure 22-1). The purpose of a DMZ is to protect these servers as much as possible, recognizing that these servers are at a higher risk of being compromised, and providing protection to the internal network in case a DMZ host is compromised.

Figure 22-1. Typical DMZ layout

For Office SharePoint Server deployments, you may wish to implement a second DMZ to host the machines in your farm that are not directly accessible to outside users, such as your SQL Server and any application servers that potentially include search or indexing (Figure 22-2).

DMZ-less design. Every publicly accessible Office SharePoint Server environment should reside in a DMZ segment. However, in some small organizations with only a single server, like a Microsoft Small Business Server implementation, this may not be feasible for financial reasons. It may be desirable to make a site hosted on a multipurpose server on the internal network available externally. In these instances, if the risk and impact of an attacker compromising the entire internal network through this server is not a serious concern, the organization may choose to go without using a DMZ when considering the cost of a dedicated server deployment. This should be avoided in all but the smallest networks, and should never be used in a security-conscious environment.

Figure 22-2. A two-DMZ SharePoint Server deployment

Single or multiple DMZ design. Whether to implement one, two, or more DMZ segments depends on the security requirements of your environment. A single DMZ containing all servers in your Office SharePoint Server farm should be considered a minimum requirement. Segregating servers that are not directly accessible to users (such as your SQL Servers) and application servers (such as search and indexing) provides a greater level of protection for these servers, which need not be accessible directly to Internet users. If a web frontend server is compromised, additional DMZ segments may help limit the exposure to your database and application servers, and possibly prevent them from becoming compromised as well.

DMZ performance considerations. Putting a firewall between your servers will reduce the network performance between those servers. The level of performance impact depends mostly upon the performance capabilities of your firewall. For highly trafficked farms, a firewall has the potential to cause performance degradation for users of your site. This is not likely to affect most environments, but it is something to keep in mind when designing a high-traffic site. Always ensure the firewall is adequately sized to provide the required level of performance.

For certain limited team or department sites, segregating the servers from other portions of the network may be desirable. Some departments in larger organizations that require a high degree of confidentiality and data protection have a dedicated network segment for that group and do not allow other parts of the network access to that segment. If the team or department using the site has its own dedicated segment, you should place the Office SharePoint Servers it will use in that protected segment as well.

If your SharePoint site will be accessible to users outside your organization—whether they are business partners, vendors, suppliers, customers, or anonymous users—you need to be extremely vigilant in designing and implementing security properly. If you have sensitive content that only internal users are authorized to access on the site, you should strongly consider deploying an internal server or farm with a separate site accessible only to internal users. This negates the potential of disclosing that information to outside users through human error in configuring security, or through newly discovered security vulnerabilities that may arise.

Internal sites generally do not pose the same level of security risk as externally accessible sites. However, that’s not to say they don’t require consideration of potential security risks during site design. The same primary security risks also apply to internal sites—human error in security configuration, and the risk of newly discovered security vulnerabilities that may arise in the future. Generally, the latter is of less concern on an internal site, but the former is just as much of a potential issue, if not more so. If your site will contain highly sensitive information to which only some internal users require access, you should consider deploying a dedicated server or farm and a dedicated site for that sensitive information.

You should never use anything but NTFS on your server filesystems. There is no good reason to use FAT or FAT32 file systems on servers, and their use makes it difficult—and in some circumstances impossible—to maintain a secure server.

Install all available service packs, roll ups, hot fixes, and other available updates from Microsoft Update. This ensures your system is protected from known vulnerabilities.

After addressing these two areas, the Security Configuration Wizard, as outlined in the next section, will assist you in numerous areas of the Windows Server 2003 Security Guide that are not covered in detail within this chapter.

Do not install any subcomponents of IIS that are not required for your site to function. Every installed subcomponent is a potential attack vector for an intruder. The less you have installed, the less you need to secure and the fewer possibilities for your system to be compromised. Table 22-1 lists all the available IIS subcomponents and whether they are required for Office SharePoint Server 2007. Table 22-2 lists the sub-components of the World Wide Web Service under IIS.

If possible, you should put your inetpub directory as well as your Office SharePoint Server installation on a dedicated partition rather than the system partition (generally the C: drive). IIS 5.0 suffered from numerous directory traversal vulnerabilities, as have many web applications. A directory traversal vulnerability allows a user to access files outside the intended web accessible folder (inetpub) by allowing them access to the entire partition where this folder is located. As a high-profile example, a directory traversal vulnerability in IIS 5.0 enabled the Nimda worm to infect IIS servers. A patch to fix this vulnerability was available prior to this worm breaking out and is the appropriate means of mitigating such a risk. However, locating the inetpub folder on a separate partition would have prevented this worm from infecting the server, because it required access to cmd.exe and tftp.exe on the system partition.

There are protections in IIS 6.0 and Windows Server 2003 to avoid directory traversal vulnerabilities and to limit the damage if one were discovered, but this is still a good precaution.

If you need to permit anonymous access to your site, you should ensure the IUSR_ machinename account does not have write access anywhere on your server’s filesystem.

The default method of Windows authentication in Office SharePoint Server 2007 is NT LAN Manager (NTLM). It offers the best compatibility, as it is compatible with pre-Windows 2000 versions of Windows and requires less configuration. However, it is not the recommended method of authentication because of the benefits of Kerberos.

Kerberos is the preferred method of Windows authentication for sites running all Windows 2000 and newer clients and servers. Kerberos is faster and more secure than NTLM, but requires some planning and configuration to utilize. For more information on implementing Kerberos as your Windows authentication provider, refer to the following site:

SQL Server authentication is commonly used for users outside your organization who do not have accounts in your Active Directory domain. Using this authentication provider enables you to create accounts for outside users without giving them any rights to your Active Directory domain.

The LDAP authentication provider enables you to authenticate users off of an LDAP server. You may use this for external users, or for internal users if your primary directory service is not Active Directory. This also can be used to authenticate your SharePoint users off of a directory hosted by a non-Windows server, including Unix, BSD, Linux, and any other operating system capable of running an LDAP server.

You may wish to utilize forms authentication even when Active Directory is your authentication provider. The most common use of Active Directory forms-based authentication is where internal users need access to a site from outside the organization’s network. It may also be used in combination with other providers to provide Active Directory authentication for your internal users, and as another means of authentication for external users.

Active Directory Federation Services (ADFS) is a new feature in Windows Server 2003 R2 that enables organizations to securely share a user’s identity information across the boundaries of your organization’s network. ADFS allows an organization to utilize its Active Directory infrastructure to provide controlled access to resources, without the security risk and operational challenges of configuring and maintaining trust between the separate Active Directory forests and separate networks.

ADFS can be a secure, convenient solution to allowing employees of business partners to authenticate to your network using their Active Directory credentials on their employer’s network. Tables 22-3 and 22-4 list some resources.

Employing SSL encryption on your site requires the use of an SSL certificate. An SSL certificate is generated by a Certificate Authority (CA). Web browsers come preinstalled with a list of trusted CAs, which is a list of companies known and trusted to follow specific stringent guidelines in issuing certificates. Two of the well-known CAs are VeriSign and Thawte, though there are more than 40 trusted organizations built into current versions of Mozilla Firefox and Internet Explorer. Large organizations commonly have an internal CA that is trusted by the web browsers on its internal network.

You can also generate your own SSL certificate. However, certificates that are not generated by a trusted CA will cause a certificate warning in the user’s browser. Aside from the user confusion and support calls this is likely to generate, it also provides very little protection. It is possible to perform a man-in-the-middle attack on SSL connections, rendering the previously mentioned protections useless, and tools such as sslmitm are widely available to assist in accomplishing this. If someone is attempting a man-in-the-middle attack on one of your users, it will generate a certificate warning because the attacker will be using a self-generated certificate. If your users are accustomed to seeing certificate warnings when using your site, they will dismiss it as normal and your SSL will be worthless.

Always use a certificate that will not generate warnings in any of your users’ browsers, and educate your users that if they ever see a certificate warning, they should stop what they are doing and call for help immediately. If users outside your organization will access the site, or you do not have a trusted internal CA, you need to purchase a certificate from a trusted CA. SSL certificates are not nearly as costly as they used to be, but some CAs still charge exorbitant prices. Make sure you compare prices between a few trusted CAs before purchasing. If your site is accessible only to internal users and you have an internal trusted CA, you can generate your SSL certificate from that CA.

SSL encryption can be enabled on your site in the Internet Information Services Manager under Administrative Tools. First, you must prepare the certificate request from which a Certificate Authority will generate your certificate.

Preparing your certificate request. Under Web Sites, right-click on the site you wish to protect, and then click Properties. Click the Directory Security tab. Under “Secure communications,” click the “Server Certificate” button. This will bring up the Web Server Certificate Wizard. At the Welcome screen, click Next.

At the next screen, select “Create a new certificate” (Figure 22-3) and click Next.

At the “Delayed or Immediate Request” screen, select “Prepare the request now, but send it later” (Figure 22-4) and click Next.

“Name and Security Settings” is the next screen (Figure 22-5). Fill in a name for the certificate (this is cosmetic only; you can leave it at the default), choose a bit length (the default of 1024 is fine), and click Next.

Figure 22-3. Create a new certificate

Figure 22-4. Prepare the request now, but send it later

Figure 22-5. Name and Security Settings

At the Organization Information screen, fill in the name of your organization and your organizational unit (Figure 22-6).

Figure 22-6. Organization Information

The Common Name screen is next (Figure 22-7). This is very important, because if you enter the wrong common name here, the certificate will always generate security warnings in your users’ browsers. Enter the server name that your users use to connect to your server. If that’s just the server’s NetBIOS name (for example, SHAREPOINT), enter that here. If your users use the Fully Qualified Domain Name (FQDN), enter that here instead (for example, sharepoint.example.com). After filling in the Common Name appropriately, click Next.

Figure 22-7. Common Name

At the Geographical Information screen, fill in your country, state/province, and city/locality (Figure 22-8). Note that these must be the full, official names; no abbreviations may be used.

Next, you will enter the filename to use to store the certificate request (Figure 22-9). Enter a path of your choosing, or accept the default and click Next.

At this point, you will see the Request File Summary screen (Figure 22-10). It will show the information you entered on the previous screens so you can confirm that it has all been entered correctly. After clicking Next, the certificate request will be created.

You have now successfully completed the certificate request wizard. Click Finish to exit it.

You now having a pending certificate request in the web site you selected. If there is a problem with the certificate request you created, you can delete the pending request by clicking the Server Certificate button on the Directory Security tab of the site’s properties page, the same way you initiated the certificate request wizard.

Figure 22-8. Geographical Information

Figure 22-9. Certificate Request File Name

After clicking Next on the initial page of the wizard, you will see the option of deleting the pending request.

Figure 22-10. Request File Summary

Leave the web site properties screen up, as you will be coming back to it as soon as you have your certificate ready for installation.

Obtaining the SSL certificate. Now that you have the certificate request ready, you can obtain the SSL certificate. If you are going to purchase your certificate, I recommend first getting a test certificate from a trusted CA. Numerous CAs provide free test/trial certificates. If you search the Internet for “test SSL certificate,” you will find numerous options.

You can also generate your own SSL certificate (for testing purposes only) with the Certificate Creation Tool available from Microsoft:

Once you have your certificate ready for installation, continue to the next section.

Processing the certificate request. Now that you have your certificate, it is time to install it. Click the Server Certificate button again on the Directory Security tab of the properties page of your web site.

Click Next on the Welcome page of the wizard.

Select “Process the pending request and install the certificate” and click Next (Figure 22-11).

Figure 22-11. Pending Certificate Request

At the next screen, browse to or enter the path and filename of the certificate file you generated or received from the CA, and then click Next (Figure 22-12).

On the SSL Port screen, enter the port this web site should use. In most cases, you will want to accept the default of 443 (Figure 22-13).

The certificate summary screen will now be displayed, summarizing the details of the certificate about to be installed (Figure 22-14). Click Next.

You have now successfully installed the server certificate. Click Finish. Leave the Properties screen open with the Directory Security tab up.

You will now be able to access your site using SSL. By default, SSL is not required, and so you should configure your site to make the use of SSL mandatory. To do so, click the Edit button under “Secure communications” on the Directory Security tab. Check the top checkbox, “Require secure channel (SSL),” and click OK to force users to use SSL when accessing the site.

Full control means exactly what it implies: users with this level of permission can do everything granted by the other permission levels, as well as modify permissions.

The design permission enables users to change the layout of a site, either via a web browser and through Office SharePoint Designer 2007.

The contribute permission allows users to add and change an item or items, depending on the scope of the permission.

The manage hierarchy permission gives users the ability to create sites, edit pages, and list items and documents.

This permission enables users to read the site, page, or other item or items where this permission is granted. This also allows downloading of files available on the site, so they can be used and/or viewed in their native applications.

Restricted read allows users to view pages and documents, but not the rights assigned to those documents. It does not provide the ability to read any previous revisions to those items. This can be useful for things like organization-wide policies and procedures, where you want most users to be able to access only the current accepted version of these items.

View only and read permissions may seem like the same thing, but there is one main difference between the two. If a user has only view-only rights to a file, and a server-side viewer for the file (such as Excel Services) is enabled, the user can only view the file using the server-side viewer and cannot work with the file in its native application. This functionality is not limited to Excel; Word, PowerPoint, and several other file types have server-side viewers.

Limited access permissions are automatically assigned by Office SharePoint Server when you grant a user or group access to an object on your site that is contained in a higher-level object to which the user or group does not have access. This permission level cannot be directly assigned to a user or group.

To configure site level permissions, on the front page of your site, click Site Actions, and then Site Settings.

Under "Users and Permissions,” you will see three items: “People and Groups,” “Site collection administrators,” and “Advanced permissions” (Figure 22-15).

Figure 22-15. Users and Permissions

People and Groups. After clicking “People and Groups,” you will see the Quick Launch list under Groups on the lefthand side of the page (Figure 22-16). The default items in this list are as follows, where Sitename is the name of your SharePoint site. These are the default built-in SharePoint groups, as discussed earlier in this chapter:

Figure 22-16. Groups screen

You can configure which items will appear in this Quick Launch list from any page under “People and Groups” by clicking Settings, and then Edit Quick Launch Groups (Figure 22-17).

At this screen you can add or remove groups from the Quick Launch list on the “People and Groups” page (Figure 22-18).

If you remove a group from the Quick Launch list, you can still access it through the “More…” link, which is always available on the Quick Launch list.

Under “Users and Permissions” on the Site Settings page, you will see the Advanced Permissions link. This takes you to a page that lists in detail the users and groups that have been granted permissions on this site, along with the level of access they have been granted. You can add and remove users and groups from the site from this screen, as well as modify their levels of access rights.

Figure 22-17. Edit Group Quick Launch

Figure 22-18. Quick Launch Groups edit screen

At the permissions page, unless the permissions of this library have been previously modified, you will see a message at the top explaining where the existing permissions are coming from: “This library inherits permissions from its parent Web site. To manage permissions directly, click Edit Permissions from the Actions menu.”

For a library that requires differing permissions from its parent web site, click Actions, and then Edit Permissions. You can also manage the permissions of the parent object on the Actions menu.

When you click Edit Permissions on a library that is inheriting permissions from its parent site, you will receive a pop-up warning that you are about to create unique permissions for this library and that changes to the parent site’s permissions will no longer affect this library. Click OK to continue.

Next, you will be looking at the same permissions list as before, except the list now can be edited at this level without affecting permissions at higher levels. If you decide later to revert to inheriting permissions from the parent site, you can do so by clicking Inherit Permissions on the Action menu.

To remove permissions from users or groups, check the user(s) and group(s) for which you want to remove permissions, click Actions, and then select Remove User Permissions (Figure 22-21).

Figure 22-21. Remove User Permissions

You will be prompted with a pop-up message confirming you want to remove these permissions. Click OK to do so.

You can modify the permissions of listed users or groups by checking the ones you wish to modify, clicking Actions, and then selecting Edit User Permissions (Figure 22-22).

Figure 22-22. Edit User Permissions

You can check multiple users and groups, but only if you want to assign them all identical permissions.

You can enable or disable access requests for a library by clicking Settings, and then selecting Access Requests on the Permissions page (Figure 22-23).

Figure 22-23. Access Requests

If the checkbox on the Manage Access Requests screen appears dimmed, access requests for this library are disabled.

The list of individuals authorized to enter any of your computer rooms should be as restricted as possible. If at all feasible, some sort of biometric authentication should be used for admission (such as a fingerprint scanner, palm scanner, etc.) in addition to a PIN code. Keys and combination locks are undesirable because they are much more difficult to control, and they do not maintain an audit log.

Make sure the room itself is reasonably protected from unauthorized entry. If rooms adjacent to a raised-floor computer room also have raised floor, ensure the wall goes all the way down below the raised floor so people cannot crawl under the floor. If the facility has a drop ceiling, ensure the wall goes all the way up and doesn’t stop at the ceiling tiles. An intruder could easily get above the raised ceiling in the insecure area, go over the wall, and drop into your computer room through the drop ceiling.

There is much more to a true vulnerability assessment than what we just covered, and far more than can be covered in this book. If you do not employ security experts internally who are qualified to perform a complete vulnerability assessment, your organization should consider bringing in outside security experts to perform an assessment on an annual basis.

Be careful in selecting a company or individual to perform this work. Many security consultants will do nothing more than run a few tools (such as MBSA) and then simply hand you either a CD of the results or a huge binder with the results printed out, along with a big bill. A qualified security professional will analyze those results, compare results between multiple tools, and determine where to look closer for potential weaknesses that a scanning tool cannot find, along with other things that vary depending on the environment. Following the assessment, a report with specific verified findings you can actually use to improve your security posture should be provided.

Table 22-6 lists some relevant resources for further information on the topics covered in this section.