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.

Digest authentication requires .NET Web services and Internet Explorer, and is very secure. It will work with proxy servers and firewalls. Therefore, it is a good choice for Web sites that require high levels of security but must be Internet accessible.

Integrated Windows authentication is the most secure authentication method. Like Digest authentication, this uses a hash algorithm to send encrypted login information between the client and the server. 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.

Sometimes called Challenge/Response authentication, one of the major drawbacks of Integrated Windows authentication is that it generally will not work with proxy servers and firewalls. Therefore, it is a good choice for secure intranets, but not for highly secure Web sites that must be accessible over the Internet.

If all of these authentication methods are enabled and anonymous access is disabled, IIS will attempt to authenticate moving from the most secure method to the least—that is, it will start with Integrated Windows authentication, then try Digest, and finally Basic.

Before we look at ASP.NET, we need to remember that IIS also has a level of authorization. IIS can be set to grant or restrict read, write, script source access, and directory browsing. These attributes are set for a directory or a Web site, not for a particular user or group. Where these settings conflict with Windows Access Control List (ACL) settings, the more restrictive of the settings will be applied.

Once the user is authenticated, the request is then passed to ASP.NET. ASP.NET executes a series of decisions. Ultimately, all of these end up at the Windows ACLs.

ASP.NET provides five methods of authentication and authorization. These are Default (or IIS) authentication, Windows authentication, Forms authentication, Custom authentication (really a subset of Default authentication), and Passport authentication. These methods tie authentication to authorization. Passport authentication is complete but is outside the scope of this article. Except where noted, you configure these authentication methods in the Web.config for your Web site.

In ASP.NET Default authentication, IIS anonymous access is enabled, and ASP.NET checks to see if ASP.NET impersonation is enabled (see Figure 2). If it is not, requests are made using the system-level process account. This account is configured in the <processModel> element of the machine.config file. If ASP.NET impersonation is enabled, requests are made either using the IIS anonymous access account (IUSR_machinename by default) or using a user account specified in the <identity> element of the <system.Web> section. In addition, if no account is specified in the <identity> element of the <system.Web> section, then permissions for user accounts may be specified in the <allow> element of the <authorization> section.

<system.web>
   <authentication mode="None" />
</system.web>

The above configures Web.config for ASP.NET default authentication, which the following configures machine.config for ASP.NET impersonation.

// impersonation enabled, will 
impersonate using account pass by IIS
<identity impersonate="true"/>
// authentication enabled and user 
account specified
<identity impersonate="true" 
name="domain\user" password="pwd"/>
// authentication disabled
<identity impersonate="false" />

There is one special situation to be aware of when running ASP.NET on a domain controller. All accounts on a domain controller are domain accounts, not simply local machine accounts. Because ASP.NET is looking for an account named localmachinename\ASPNET, it will fail to start because that account doesn't exist. Therefore, if you are having problems with ASP.NET starting, you can use the system account or you will need to explicitly define an account configured in the <processModel> element of the machine.config file.

When using ASP.NET Windows authentication, initial requests are made using the authenticated user account through whichever authentication method was used, Integrated, Digest, or Basic. That account can be changed, depending on additional settings in the Web.config file. If impersonation is not enabled, requests are made using the system-level process account. If impersonation is enabled, requests are made either using the authenticated user account or using a user account specified in the <identity> element of the <system.Web> section. In addition, if no account is specified in the <identity> element of the <system.Web> section, then permissions for user accounts may be specified in the <allow> element of the <authorization> section.

You can also use the <authorization> element to specify users or groups to allow or deny. You can also specify specific actions—GET and POST—that users and groups are allowed to or denied from performing. Finally, you can use the <location> element to specify multiple <system.Web> elements. These can be defined for particular pages, and the <allow> and <deny> elements may be configured for these individual pages.

Here are three ways to configure Web.config for ASP.NET Windows authentication:

<system.web>
   <authentication mode="Windows" 
/>
   <authorization>
      <allow roles="domainA\group1, 
domainC\group2"
             users="domainA\user1, 
domainA\user2, domainB\user3, 
domainC\user4" />
      <deny users="*" />
   </authorization>
</system.web>

or

<system.web>
   <authentication mode="Windows" 
/>
   <authorization>
      <allow verb="GET" users="*" 
/>
      <allow verb="POST" 
users="domainA\user1, domainB\user3" 
/>
      <deny verb="POST" users="*" 
/>
   </authorization>
</system.web>

or

<system.web>
   <authentication mode="Windows" />
   <authorization>
      <allow verb="GET" users="*" />
      <allow verb="POST" users="domainA\user1, 
domainB\user3" />
      <deny verb="POST" users="*" />
   </authorization>
</system.web>
<location path="aboutus.aspx">
   <system.web>
      <authentication mode="Windows" />
      <authorization>
         <allow verb="GET" users="*" />
         <allow verb="POST" 
users="domainA\user2, domainC\user4" />
         <deny verb="POST" users="*" />
      </authorization>
   </system.web>
</location>

Finally, ASP.NET Forms authentication provides an excellent authentication method for moderately secure applications. ASP.NET Forms authentication has a number of similarities in its process flow. Once IIS authenticates (it is usually set to Anonymous in this case for the very reason that you want the Form to handle the authentication), it passes the request to ASP.NET, which checks to see if there is an authentication cookie in the request headers (see Figure 3).

Because ASP.NET Forms authentication generates a cookie with identification information once the user is authenticated, the existence of a cookie indicates that the user has already been authenticated. It is best to run this form from a directory that implements SSL; however, once the encrypted cookie is created, non-SSL directories can be used, as the cookie has no sensitive information in it. The request, using the authenticated account, is then passed to Windows for authorization. If a cookie doesn't exist, the user hasn't been authenticated. The user is redirected to a login page that you must provide. The user enters username and password information, and the custom login page performs the requisite authentication. If the user is authenticated, the request, using the authenticated account, is then passed to Windows for authorization. If they are not authenticated, the request is denied.

When you configure the Web.config, you set the name of the cookie, the path the cookie is being applied to (usually it is the entire site), the virtual path for the custom login form, the protection level (are you going to perform encryption, validation, neither, or both; the latter is the default), and the cookie's expiration time in minutes. You may also optionally specify an encryption algorithm (<credentials> element). The <credentials> element may optionally contain <user> elements that further restrict resource access.

The following configures Web.config for ASP.NET Forms authentication:

<system.web>
   <authentication mode="Forms">
      <forms name="MyCookie" path="/" 
loginUrl="/LoginFormVPath/" protection="All" 
timeout="60" />
    </authentication
</system.web>

Below is the code that creates the form for gathering user credentials, as a well as code for processing user credentials.

<body MS_POSITIONING="GridLayout">
  <form id="Login" method="post" 
runat="server">
    <table>
      <tr>
        <td colspan="2">
          Content Manager Login
        </td>
      </tr>
      <tr>
        <td colspan="2">

You must login to perform content management functionality.

        </td>
      </tr>
      <tr>
       
<td><b>Domain</b></td>
        <td><asp:textbox id="txtDomain" 
runat="server" maxlength="50" 
Width="118"></asp:textbox></td>
      </tr>
      <tr>
        <td><b>User 
Name</b></td>
        <td><asp:textbox id="txtUserName" 
runat="server" maxlength="50" 
Width="118"></asp:textbox></td>
      </tr>
      <tr>
        
<td><b>Password</b></td>
        <td><asp:textbox id="txtPwd" 
runat="server" maxlength="50" Width="118" 
TextMode="Password"></asp:textbox></td
>
      </tr>
      <tr>
        <td colspan="2"><asp:Button 
id="btnGo" Text="Go" 
runat="server"></asp:Button>
          <asp:Label id="lblErrorMsg" 
runat="server">Label</asp:Label></td>
      </tr>
    </table>
  </form>
</body>

Code for processing user credentials:

private void btnGo_Click(object sender, 
System.EventArgs e)
{
  CmsAuthenticationTicket ticket = 
CmsFormsAuthentication.AuthenticateAsUser(txtDomai
n.Text + "\" + txtUserName.Text, txtPwd.Text);
  if( ticket != null )
  {
    
CmsFormsAuthentication.RedirectFromLoginPage(ticke
t, false, false); 
  }
  else
  {     
    lblErrorMsg.Visible = true;
    lblErrorMsg.Text = "Invalid username or 
password";
  }
}

Custom Authentication
Custom authentication is a subset of Forms authentication. It requires you to provide a form that gathers account information from users. This information can be whatever is necessary to perform the authentication, such as an e-mail address and password. Then you take these credentials and authenticate the user against your data source. If the user is authenticated, the request, using the authenticated account, is then passed to Windows for authorization. If they are not authenticated, the request is denied.

Once you have completed ASP.NET authentication, you have a user account context with which to request a resource from Windows. The request is made and Windows performs the authorization (see Figure 4).

Now that you have seen the various options for IIS and ASP.NET authorization, the combinations for each use may seem a bit unwieldy. They are, however, relatively straightforward: If you are going to use ASP.NET Default, Forms, or Custom authentication, you will probably be using IIS Anonymous authentication. If you plan to implement ASP.NET Windows authentication, then you will use any or all of IIS Basic, Digest, and Integrated authentication. You may also use certificate mapping in Windows authentication. Any of these methods may use IP address and Domain Name restrictions.

Windows ACLs determine which Windows users and groups may access a resource and their permissions. This spans from file and folder resources to more complex resources, such as applications. Once ASP.NET has finished its decision tree, it hands Windows a request for a resource under the determined user account. Windows evaluates this against the ACL and determines whether the request can be honored.

Remember that it is preferred to add user accounts to a group account and assign that group rights to a resource. This way, individual users can be added and removed, but the group rights to its domain of resources remain constant, and management is simplified.

Now that you have moved through the entire decision tree and determined that the user is who she says she is (authentication) and whether she has the right to access the resource in the way she wants (authorization), you can examine how MCMS fits into this model.

There are a number of additional layers once you add MCMS to the equation. Learning about MCMS management tools and roles provides background for MCMS's internal security, that is, the OS accounts that it uses to access the various resources that it needs fulfill a request. I'll discuss the need to return to the management tools to configure MCMS so that it can access the content repository and allow guest users if desired. Then I will detail MCMS authentication and page processing.

MCMS has three tools for managing security—the Database Configuration Application (DCA), the Server Configuration Application (SCA), and Site Manager. The DCA manages the relationship between the Content Server and the Content Repository. The SCA manages the relationship between the Content Server and both IIS and Windows. Site Manager manages the objects in the Content Repository and their relationship to each other. I will return to these tools shortly, once you understand the Windows user accounts that need to be created, their permissions and purposes, and where they are configured in MCMS.

MCMS has eight roles, including Administrator, Channel Administrator, Moderator, Editor, Author, Resource Manager, Template Designer, and Subscriber. This article will not discuss the MCMS workflow and therefore will not cover any roles besides Administrator and Subscriber.

The Administrator role group has access to and control over the entire server. If you are reading this article, you are in that group. Subscribers refer to the users who browse your site. You can have as many subscriber role groups as you need, depending on which objects in the content repository are necessary to deliver the project.

MCMS Internal Security
When installing and configuring MCMS, you need to start with two accounts: an MCMS administrator account and an MCMS system account. If you plan to provide public content, you will need a guest user account (see the sidebar, MCMS Roles, Security, and Workflow).

The MCMS administrator account is added to the Administrators role group when the DCA is run. Then, this account will have full control over MCMS because it will allow access to Site Manager. MCMS uses the system account to access resources, such as SQL Server, Active Directory (AD), the MCMS temporary folder, and the various /NR folders.

The MCMS system account will be used to log in to SQL Server if you have Windows authentication selected in SQL Server. Therefore, this account will need db_datareader and db_datawriter permissions. If you use the import functionality of site deployment then the system account will also need db_ddladmin permissions. If you select SQL Server mixed authentication and use a SQL Server login then that login will need the same rights.

The MCMS system account must also have permissions to access AD organizational units (OU), domains, and other OS information. Specifically for AD, the system account must have read and enumeration rights in all MCMS user domains. This account should be a domain account, though it could be a local account if AD allows anonymous enumeration. A domain user, or a user in a trusted domain, is perfectly fine to use for this account.

The MCMS system account is the only MCMS account that requires permissions to file system and database assets. The IIS anonymous user account (IUSR_machinename) should never be used as the system account because that would grant anonymous permission to the MCMS database. Your best choice is to create a new domain account specifically to be the MCMS system account.

As noted earlier, the DCA manages the relationship between the Content Server and the Content Repository. The DCA allows an MCMS administrator to select a content repository database from a list of SQL Servers. After stopping IIS and all dependent services, you can select the database you wish to connect to. Select the server, chose whether you want to use a trusted connection, and, if not, enter the appropriate login information. The trusted connection will be the MCMS system account, so that account needs the appropriate database permissions, as discussed earlier. A note of warning: Administrators frequently get an error here even though the user credentials they enter, whether trusted or not, are correct and have the appropriate rights in the database. The trick is that when running the DCA, it is the user logged in to the machine who needs to have dbo access to the MCMS database. Remembering this can save you much pain and heartache. Subsequently, all database access by MCMS is accomplished by the MCMS system account or the SQL user.

Next, select the database from the dropdown list and change the other properties that need alteration. Clicking the Next button causes the DCA to examine the database selected. If it has the MCMS schema in it, it will ask if you want to continue. If the database doesn't, the DCA will ask if you want to add the schema. After you indicate that you want to continue, it will ask if you want to add another administrator to the database. This is another trick to keep handy: By running the DCA you can add any user to any MCMS database. This allows you to move, examine, and work with databases from multiple servers without being a user in the domain that the database came from. After this, click the Finish button and you are done.

If you allow guest access, you need to create a guest user account. After creating a guest account, open Site Manager and create a new Subscriber rights group. Add the guest user and give it permissions to all the appropriate channels, resource galleries, and template galleries. It is important to note here that you need to give this user rights to the template galleries and resource galleries that contain templates, and resources that are used in posting that reside in channels you have given them permission to see. MCMS manages the kind of access they get, in this case read-only, based on their role. You are not giving them permission to design templates or add resources.

Next, you need to set up the SCA. Finally, make sure you set anonymous access in IIS. Enable guest access in the SCA and set the account to the guest account that you set up earlier.

MCMS Authorization
Now that guest access is configured, understanding how MCMS processes it is very important. When MCMS receives a request, it checks to see if guest access is enabled. If it is, the name of the user is set to the guest account. It is important to note that this is not impersonation, it is simply a string substitution. MCMS then checks to see if the guest user has permissions to the requested channel. This can cause a problem when the guest account is part of a group account that is assigned to that Subscriber role. MCMS doesn't enumerate the group members, and the comparison (which is a string comparison) between the group account name and guest account name fails (see Figure 5).

MCMS uses the guest account to provide anonymous permissions to MCMS objects. As with the MCMS system account, you should not use the IUSR_machinename account as the guest account and you should create a new domain account specifically to be the MCMS guest account. MCMS directly integrates with ASP.NET security. All of the security options and configurations outlined above can be set for MCMS. MCMS uses the authentication provided by IIS and ASP.NET as well as the authorization provided by IIS and Windows to protect files system resources, such as template files. MCMS uses Windows ACLs to protect objects stored in the content repository, such as templates, resources, postings, and channels.

MCMS is an ISAPI extension, and the DLL, ReAuthFilt.dll, is installed in the IIS metabase. All incoming requests are checked by this extension and, if a valid MCMS request, are processed by MCMS. Therefore, MCMS integrates directly into the security model already specified and is configured using exactly the same techniques used earlier.

Set up your own server and experiment with a variety of configurations. Work with Default, Windows, and Forms authentication. Turn IIS anonymous access on and off. Try sites with and without MCMS guest access configured. Make sure you have a good handle on it so that you can administer the server effectively, protecting your enterprise's assets from the cold, cruel world.

About the Author
Bill Schneider delivers knowledge management solutions that help clients inspire loyalty from and deliver value to their customers while generating revenue and reducing operating costs. He is a senior project manager at Susquehanna Technologies and a 16-year veteran of portal implementation, Web content management, and custom application development and delivery. Contact him by e-mail at .