Physically Securing SharePoint Portal Servers

One of the most overlooked but perhaps most critical components of server security is the actual physical security of the server itself. The most secure, unbreakable web server is powerless if a malicious user can simply unplug it. Worse yet, someone logging in to a critical file server could potentially copy critical data or sabotage the machine directly.

Physical security is a must for any organization because it is the most common cause of security breaches. Despite this fact, many organizations have loose levels, or no levels, of physical security for their mission-critical servers. An understanding of what is required to secure the physical and login access to a server is a must.

Restricting Physical Access to Servers

Servers should be physically secured behind locked doors, in a controlled-access environment. Soft-felt cubicles do not provide much in the realm of physical security, so it is therefore unwise to place mission-critical servers at the feet of administrators or in similar, unsecure locations. Rather, a dedicated server room or server closet that is locked at all times is the most ideal environment for the purposes of server security.

Most hardware manufacturers also include mechanisms for locking out some or all of the components of a server. Depending on the other layers of security deployed, it may be wise to use these mechanisms to secure a server environment.

Restricting Login Access

All servers should be configured to allow only administrators to physically log in to the console. By default, such use is restricted on domain controllers, but other servers such as file servers, utility servers, and the like must specifically forbid these types of logins. To restrict login access, follow these steps:

1.	Choose Start, All Programs, Administrative Tools, Local Security Policy.
2.	In the left pane, navigate to Security Settings\Local Policies\User Rights Assignment.
3.	Double-click Allow Log On Locally.
4.	Remove any users or groups that do not need access to the server, as shown in Figure 15.4. (Keep in mind that, on SharePoint web front-end servers, the IUSR_SERVERNAME account needs to have Log on Locally access to properly display web pages.) Click OK when finished. Figure 15.4. Restricting login access.

NOTE

A Group Policy set on an OU level can be applied to all SharePoint servers, simplifying the application of policies and negating the need to perform it manually on every server.

Using the Run As Command for Administrative Access

Logging off administrators after using any and all workstations and servers on a network is often the most difficult security precaution to enforce. If an administrator forgets, or simply steps away from a workstation temporarily without logging out, any persons passing by can disrupt the network infrastructure as they please.

For this reason, it is wise to consider a login strategy that incorporates the Run As command embedded in Windows Server 2003. Essentially, this means that all users, including IT staff, log in with restricted, standard User accounts. When administrative functionality is required from a workstation, IT support personnel can invoke the tool or executable by using the Run As command, which effectively gives that tool the administrative capabilities of the account designated by Run As. If an administrator leaves a workstation console without logging off, the situation is not critical because the console will not grant a passerby full administrator access to the network. For SharePoint servers, only administrators should be able to log in to the console, however.

The following example illustrates how to invoke the Computer Management MMC snap-in using the Run As command from the GUI interface:

1.	Navigate to (but do not select) Start, All Programs, Administrative Tools, Computer Management.
2.	Right-click Computer Management in the program list and then choose Run As.
3.	In the Run As dialog box, shown in Figure 15.5, choose the credentials which the program will run under and click OK. Figure 15.5. Using the Run As command.

NOTE

A command-line version of the Run As tool allows for the same type of functionality. For example, you can enter the following syntax from the Start, Run window to open a command prompt with administrator access:

 runas /user:DOMAINNAME\administrator cmd 

In addition to the manual method of using Run As, an administrator's desktop can be configured to have each shortcut automatically prompt for the proper credentials upon entering an administrative tool. For example, you can permanently set the Active Directory Users and Computers MMC snap-in to prompt for alternative credentials by following these steps:

1.	Choose Start, All Programs, Administrative Tools.
2.	Right-click Computer Management and choose Properties.
3.	On the Shortcut tab, click the Advanced button.
4.	Check the Run with Different Credentials box, as shown in Figure 15.6, and click OK twice to save the settings. Figure 15.6. Running a shortcut with alternative credentials.

NOTE

Administrative access is sometimes required to change some of the shortcut properties. You might need to log in as a user with higher privileges to set up the shortcuts on other users' profiles.

Securing SharePoint Access by Using Smartcards

The ultimate in secured infrastructures utilizes so-called smartcards for login access; these smartcards are fully supported in Windows Server 2003. A smartcard is a credit cardsized piece of plastic with an encrypted microchip embedded within. Each user is assigned a unique smartcard and an associated PIN. Logging in to a workstation is as straightforward as inserting the smartcard into a smartcard reader and entering the PIN, which can be a combination of numbers and letters, similar to a password.

Security can be raised even higher by stipulating that each smartcard be removed after logging in to a console. In this scenario, users insert into the smartcard reader a smartcard physically attached to their person via a string. After entering their PIN, they log in and perform all necessary functions. Upon leaving, they simply remove the smartcard from the reader, which automatically logs them off the workstation. In this scenario, it is nearly impossible for users to forget to log off because they must physically detach themselves from the computer to leave.