email article printer friendly more resources

Locking Down MCMS 2002
How the security aspects of MCMS and a Web server work together.
by Bill Schneider

Posted March 26, 2004

On the one hand, you need to make your public Web server as secure as Fort Knox to keep it safe from hijackers. On the other hand, you need make its content as accessible as possible so that the right people can update your site quickly and efficiently. Microsoft Content Management Server 2002 (MCMS) attempts to address these conflicting aims, and, when configured properly, succeeds admirably.

This article explains how the security aspects of MCMS and a Web server work together, and the smartest choices when configuring MCMS's security. It also features configuration examples and some best practices, as well as the best hardware architecture and software configurations for Web server farms. But first it's important to outline the business values you gain by applying these principles correctly.

Chances are your public Web server hides information from the hoi polloi that only paying subscribers can see. Your Web server might also be the point of contact between your organization and partners. This extranet might allow partners to collaborate and update critical information.

You might also want to provide a personalized browsing experience. Once a user logs in, perhaps he or she gets information anonymous users don't see. This might be special promotions, discounts, and, if your company is profiling, targeted information on topics in which the user expressed an interest.

Spiders are important for the health of your Web site. A well-designed site allows crawlers to reach appropriate URLs so that your pages get a high rank on Yahoo, Google, and other search engines.

Before I discuss the specifics on MCMS security, you need a solid grounding in Web security from the Windows OS, IIS, and .NET perspective. Web security is like an onion—it is layered. This article looks at each layer and paints a picture of the whole onion. The three major security concepts that play across this discussion are authentication, authorization, and impersonation. Authentication is uniquely identifying and verifying the incoming user's identity. Authorization involves providing access to the correct resources. Impersonation is when a user authenticates and/or is authorized as if he or she were another person.

Four Types of Authentication
When a Web server receives a request, IIS attempts to authenticate a user. IIS's first authentication steps are to check access restrictions based on IP addresses and domain names. IIS will also check access restrictions based on the certificate provided. As long as these tests are passed, or if there are no restrictions, IIS will proceed with the authentication.

IIS performs one of four types of authentication—Anonymous, Basic, Digest, and Integrated Windows. Anonymous authentication is the most straightforward method. IIS will pass the resource access request to ASP.NET using the IUSR_machinename account (see Figure 1).

Basic authentication requires the user to provide a username and password via a dialog box. The information provided is matched against account information on the server and, if it is legitimate, the resource access request will be passed to ASP.NET using the authenticated user information. The encryption method for this information is relatively weak and should not be used when a high level of security is required.

Digest authentication is more secure. The user is again asked to provide username and password information. This information is encrypted (hashed) and sent to the server. The server decrypts the information and performs the authentication. The information provided is matched against account information on the server and, if it is legitimate, the resource access request will be passed to ASP.NET using the authenticated user information.