"Check Server Extensions" Grants Extra Permissions

In certain situations, when you run Check Server Extensions on a FrontPage Web on Microsoft Internet Information Server (IIS), and you select Yes at the question, "Do you want to tighten security as much as possible for all FrontPage webs," FrontPage actually grants greater permissions to some users and groups on certain files and folders.

An example of this behavior is if you have a virtual server configured for C:\Inetpub\Wwwroot, and you grant a user Add permissions, Write, and Execute, using Windows Explorer. You then perform a Check Server Extensions and answer Yes to the tighten permissions question. FrontPage grants the user Change Permission, Read, Write, Execute, and Delete.

Another example is if you have a virtual server configured for C:\Inetpub\Wwwroot, and you grant a user Add and Read permissions, Read, Write, and Execute, using Windows Explorer. You then perform a Check Server Extensions and answer Yes to the tighten permissions question. FrontPage grants the user Change Permission, Read, Write, Execute, and Delete.

In FrontPage permissions, there are three types of access that can be granted, Browse, Author, and Administer. When the Check Server Extensions is run, FrontPage attempts to correct permissions to match the level associated with Browse, Author, and Administer. This means that accounts are granted the following permissions:

Top Level Folder for the Web

Accounts with Browse: Read and Execute
Accounts with Author: Read, Write, Execute, and Delete
Accounts with Administer: Read, Write, Execute, Delete, and Change Permission

New Content Created within the Folder

Accounts with Browse: Read
Accounts with Author: Read, Write, and Delete
Accounts with Administer: Read, Write, Delete, and Change Permission

In the scenarios described in the "Symptoms" section, the user had either Write or Delete permission, which is associated with a user with Author permission. Because of this, FrontPage detected that the account needed additional permissions, and during the Check Server Extensions, made adjustments to the permissions to match the Author level of permission.

This is not a fool-proof explanation, but explains the rationale for the methodology for the permissions changes.

The resolution is to use the Server Extensions Administrator for IIS 3.0 or the Server Extensions Snap-in on IIS 4.0 to set your Web to Manage permissions manually. This setting can be found on the Server Extensions tab. After you make this setting and perform a Check Server Extensions, you will not be prompted to tighten security and your permissions will not be modified.

You can bypass FrontPage's built-in security management and set permissions manually on the content of a FrontPage-extended Web. Doing this allows you to set permissions on a per-folder or per-file basis, giving you more granular control over permissions on a Web's content, but you need to manage the Access Control Lists (ACLs) yourself. This is an advanced technique and must be done carefully to avoid weakening the security of the content on your server.

For additional information about setting Manage permissions manually, please refer to the Server Extensions Resource Kit, which can be found at http://www.microsoft.com/downloads/details.aspx?FamilyID=8ad8d9f5-51af-4d17-b1cd-a4be003d6920.

The work around is to select No during a Check Server Extensions, when asked "Do you want to tighten security as much as possible for all FrontPage webs?".

Microsoft has confirmed that this is a problem in FrontPage 2000 Server Extensions.