"Check Server Extensions" Grants Extra Permissions (216820)
The information in this article applies to:
- FrontPage 2000 Server Extensions from Microsoft
This article was previously published under Q216820 SYMPTOMS
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.
CAUSE
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.
RESOLUTION
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://offic
eupdate.microsoft.com/frontpage/wpp/serk/.
WORKAROUND
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?".
STATUSMicrosoft has confirmed that this is a problem in FrontPage 2000 Server Extensions.
Modification Type: | Major | Last Reviewed: | 4/17/2002 |
---|
Keywords: | kbbug KB216820 |
---|
|