      FrontPage Server Extensions: Security Considerations

Security Considerations

This chapter of the Server Extensions Resource Kit describes
general Web hosting security issues and how FrontPage protects
Web server security on UNIX-based Web servers and on the
Internet Information Server (IIS) Web server for Windows NT.
This chapter has three sections:
  * General Web-Hosting Security Issues
  * FrontPage Security on UNIX-based Systems
  * FrontPage Security on IIS Systems

General Web Hosting Security Issues

Regardless of what software you are running, the two major
security issues when you host Web sites from your computer are:
  * Protecting your computer from unauthorized users

Hosting Web sites, even on an intranet, opens your host computer
to a wider community of users. Authentication is the process of
allowing users access to the Web service based on usernames and
passwords or based on IP addresses. Restricting users by IP
address is less secure, because clever users can "spoof" an IP
address and gain access to the host computer.

  * Protecting your computer from programs that run on the host
    computer

Programs can run on your computer based on the content of a Web
site for many reasons. For example:
    * An HTML page that "includes" or "substitutes" another page
      can cause a program to be run on the host computer.
    * Marking directories executable to allow a script to run on
      the host computer can allow a program to do anything
      within the limits of the host computer's resource
      protection scheme.
    * Saving HTML in general introduces risk. HTML pages can
      contain embedded controls, scripts, applets, and other
      programs that can cause programs to run on a host
      computer. Form handlers can introduce a further risk,
      because users can submit HTML commands from within form
      fields, causing programs to be run when the page
      containing the form results is browsed. (FrontPage form
      handers do not allow this.)

FrontPage Security Strategy

FrontPage addresses these security issues by using the built-in
security mechanisms of the host computer. Using the FrontPage
Server Extensions requires no changes to the host computer's
security method. You do not have to recompile any Web-server
programs and there are no custom filters or other security
modifications.
  * On UNIX-based Web servers, the server maintains a list of
    accounts, with usernames and passwords, and a list of groups
    of users with various levels of permissions for using the
    services of the Web server. The accounts and groups
    maintained by the Web server are separate from the list of
    users and groups with access to the host computer's file
    system. Access to a Web server's content, CGI (Common
    Gateway Interface) scripts, and configuration files is
    controlled by entries in access files. By creating access
    files throughout the Web server's content, different sets of
    users, with varying levels of permissions, can be given
    access to different areas of the server. FrontPage relies on
    this mechanism to add FrontPage web administrators, authors,
    and end-users with the proper permissions to the Web
    server's account list and to protect content and programs in
    FrontPage webs.

For a full discussion of FrontPage security on UNIX-based Web
servers, see FrontPage Security on UNIX-based Systems.

  * On IIS Web Servers, each HTTP request to IIS from a Web
    browser or the FrontPage client runs under a user account on
    the Windows NT operating system hosting IIS. Windows NT
    maintains account lists of local users and groups and of
    users and groups in a domain. The operations that are
    performed during the execution of HTTP requests are limited
    by the capabilities granted to that user account on the
    Windows NT Server. Windows NT File System (NTFS) allows the
    association of an access-control list (ACL) with any file or
    folder. An ACL contains users and groups with sets of
    permissions that allow a user or group to read, write,
    execute, or delete that file or folder. FrontPage implements
    Web security on IIS by changing the ACLs for all files and
    folders in each FrontPage web.

For a full discussion of FrontPage security on IIS-based Web
servers, see FrontPage Security on IIS Systems.

FrontPage Security on UNIX-based Systems

UNIX Security Concepts

     The UNIX Security Model
     UNIX Authentication

The FrontPage Server Extensions on UNIX Web Servers

     FrontPage Server Extensions File Structure
     FrontPage Access File Settings
     Setting Permissions on Web Content
     Setting the Server Extensions to SUID/SGID
     Modifying the Web Server's Configuration File
     The Server Extensions Configuration File

UNIX Security Concepts

The UNIX Security Model

In the UNIX security model, the Web server maintains a list of
accounts, with usernames and passwords, and a list of groups of
users with various levels of permissions to use the services of
the Web server. The accounts and groups maintained by the Web
server are entirely separate from the list of users and groups
with access to the host computer's file system. To fetch files
and run scripts and programs on the host computer, the Web
server runs as a UNIX account, typically "www."

Access to a Web server's content, CGI scripts, and configuration
files is controlled by entries in an access file. On Apache and
NCSA Web servers the file is .htaccess, on Netscape servers it
is .nsconfig, and on CERN it is .www_acl. These files associate
users, groups, and IP addresses with various levels of
permissions: GET (read), POST (execute), PUT (write), and
DELETE. For example, a FrontPage author would have permission to
use HTTP POST commands (to save new content), and a user with
browse permissions would be permitted to use HTTP GET commands
(to read content).

Multiple access files can be stored on a Web server. Each access
file will provide security for the directory containing it and
for any of its subdirectories that do not contain their own
access files. By creating access files throughout the web
server's content, different sets of users with varying levels of
permissions, can be given access to different areas of the
server.

Because the Web server is running under a UNIX account (such as
"www") any process it runs and any files that it accesses must
be available under the permissions of that UNIX account. Having
all content available under a single UNIX account can cause a
security problem because one user's CGI script could read files
in another user's content area on the server. With write access,
as with the FrontPage client, if a user's CGI script has
sufficient permissions to write to a file in the user's own
content area, the CGI script could write or overwrite files in
other user's content areas in a multi-hosted environment.

To address this security issue (which is common to all CGI
scripts including the FrontPage Server Extensions), the SUID
(Set User ID) bit of the CGI script's execute-permissions can be
set, forcing the Web server to switch to the UNIX user account
of the owner of the CGI script when the script is run. Because
the script owner's account is not likely to have permission to
write to other user's content areas, it protects against
unauthorized writing to files.

UNIX Authentication

In UNIX authentication, when a user browses to a page on a Web
server, the server receives an HTTP GET request with a username
and password. The Web server checks the user's permissions in
the appropriate access file. If the GET cannot be executed under
the user's authentication, the Web server returns a 401 error,
indicating that the user is unauthorized. The client then
prompts for a new name and password and resubmits the request.
Once the user is authenticated, the Web server attempts to fetch
the content from the file system. If UNIX does not allow the Web
server access to the file for some reason, it will return a
fatal error to the Web server. At this point, the user is not
prompted for a new username.

When a client or Web browser sends an HTTP POST request, as is
the case when a FrontPage author posts to the FrontPage
authoring program author.exe, the Web server again checks the
user's permissions in the appropriate access file. If the POST
cannot be executed under the user's authentication, the Web
server returns a 401 error. The client then prompts for a new
name and password and resubmits the request. Once the user is
authenticated, the Web server tries to run author.exe. If the
SUID bit of author.exe is set, the process runs as the owner of
the file. Otherwise, author.exe runs under the Web server's UNIX
account.

UNIX Web servers usually communicate with client programs using
Basic Authentication. When using Basic Authentication, the Web
browser (or the FrontPage Explorer) prompts the user for a
username and password. The username and password are then
transmitted across HTTP, lightly encoded using a technique known
as UUencoding. (Some Web servers use a technique known as MD5,
but this method is not supported by FrontPage.)

One security risk of Basic Authentication is that usernames and
passwords are transmitted across the network in an easily
decoded format. However, Basic Authentication is the only
authentication technique that works through a firewall via a
proxy server.

The FrontPage Server Extensions on UNIX Web Servers

FrontPage Server Extensions File Structure

In FrontPage, there are three kinds of users defined for every
FrontPage web: administrators, authors, and browsers
(end-users). All permissions are cumulative; all authors also
have browsing permission, and all administrators have authoring
and browsing permissions.

Each FrontPage web (including each sub-web) contains copies of
three executable scripts. These scripts are created in folders
below the top-level folder of a FrontPage web:
_vti_bin/_vti_adm/admin.exe for administrative tasks,
_vti_bin/_vti_aut/author.exe for authoring FrontPage webs, and
_vti_bin/shtml.exe for browse-time FrontPage components such as
form handlers. FrontPage performs all authoring and
administrative tasks by sending HTTP POST requests to these
scripts.

In FrontPage, the list of administrators, authors and browsers
is defined on a per-web basis. All FrontPage sub-webs either
inherit the permissions (list of administrators, authors and
browsers) of the FrontPage root web or use their own, unique
permissions. (For a description of the root web and sub-webs,
see FrontPage Webs.) As with other CGI programs, the FrontPage
Server Extensions must be stored in directories that are marked
"Executable," indicating that the directories contain executable
files. The document root is the top-level directory in a
FrontPage web. The FrontPage Server Extensions are stored in
three directories in each document root:

/document root
   /_vti_bin
      shtml.exe
      /_vti_adm
         admin.exe
      /_vti_aut
         author.exe

The server's configuration file needs to be modified to mark the
directories _vti_bin, _vti_adm, and _vti_aut as executable
directories. A Web server administrator initiates and controls
this operation using the FrontPage Server Administrator.

To reduce the total amount of disk space needed to support
FrontPage webs, the FrontPage scripts stored in the various
_vti_* directories are stub executables. They each invoke a full
executable file installed in the directory
/usr/local/frontpage/version3.0/exes.

FrontPage Access File Settings

FrontPage creates a directory _vti_pvt for the root web and for
each FrontPage sub-web. For each FrontPage web with unique
permissions, the _vti_pvt directory contains two files for the
FrontPage web that the access file points to:
  * service.pwd contains the list of users and passwords for the
    FrontPage web.
  * service.grp contains the list of groups (one group for
    authors and one for administrators in FrontPage).

On Netscape servers, there are no service.grp files. The
Netscape password files are:
  * administrators.pwd for administrators
  * authors.pwd for authors and administrators
  * users.pwd for users, authors, and administrators

An access file in the _vti_bin directory controls access to the
run-time FrontPage program shtml.exe. If all users have browse
permission, this is set in the access file. Otherwise, the
access file points to the list of users and groups with browse
access. A separate access file in the _vti_adm directory sets
POST permissions for the administrative program admin.exe. A
third access file in the _vti_aut directory sets the POST
permissions on the authoring program author.exe.

When a Web administrator uses the FrontPage Explorer's
Permissions command to give a user browse access to a FrontPage
web, the user is given an account on the Web server by adding a
username and password to the single service.pwd file pointed to
from _vti_bin directory's access file. (On Netscape servers the
file is users.pwd.) Also when an IP address restriction is set
on users of the FrontPage web, this restriction is added to the
_vti_bin access file.

When a Web administrator gives a user authoring access to a
FrontPage web, the user is given an account on the Web server.
This is done by adding the user's name and password to the
service.pwd file and to the authors group in the service.grp
file pointed to from the access files stored in the _vti_bin and
_vti_aut directories. This enables the user to do HTTP POST
requests to author.exe and to use the run-time program
shtml.exe. (On Netscape servers the process is similar.)

When a Web administrator gives a user administrative access to a
FrontPage web, the user is given an account on the web server.
This is done by adding the user's name and password to the
service.pwd file and to the administrators group in the
service.grp file pointed to from the access files stored in the
_vti_bin , _vti_aut, and _vti_adm directories. This enables the
user to do HTTP POSTs to admin.exe, author.exe, and shtml.exe.
(On Netscape servers the process is similar.)

The set of access files for a FrontPage web is illustrated in
the following two diagrams. The first diagram shows the access
files and UNIX file permissions for the content of a FrontPage
web: the directories, files, and executable files that an author
creates. The second diagram shows the access files and UNIX file
permissions for the FrontPage _vti directories:

For a list of the entire contents of a FrontPage installation,
see FrontPage UNIX Files.

Setting Permissions on Web Content

Setting secure access-modes for files and directories in a
customer's content directory is a key to maintaining your
Web-server security. All files and directories should be owned
by the customer's user identifier/group identifier. Suggested
UNIX permission settings are shown in the following table:

Single UNIX account per customer  | files:  | rw- r-- r--

directories:  | rwx r-x r-x

umask:  | --- -w- -w-

Multiple UNIX accounts per customer  | files:  | rw- rw- r--

directories:  | rwx rwx r-x

umask:  | --- --- -w-

The permissions for customers with multiple UNIX accounts per
customer also apply to an organization that has several UNIX
accounts that are part of the same UNIX group. Shared
write-access allows any members of the group to write to all
shared Web documents.

Setting the Server Extensions to SUID/SGID

Using the FrontPage Server Administrator (fpsrvadm.exe), you can
change the execute-permissions of the Server Extensions
executables to SUID/SGID. This forces the Server Extensions to
execute with the file system permissions of the owner of
shtml.exe, author.exe, and admin.exe. Combined with suitable
permissions for each customer's content area, the FrontPage
Server Extensions (and any other CGI scripts) for one customer
are prevented from writing to the content areas of other
customers.

The FrontPage Server Extensions do not require root access at
any time. However, the FrontPage Server Extensions installation
script should be run as root, because it sets EXECUTE privileges
of the extensions to SUID. Because it is written in Perl, the
Web administrator can review the script before running it on the
Web server.

Modifying the Web Server's Configuration File

On some web servers, such as NCSA, CERN and Apache, the
FrontPage Server Extensions need to modify the Web server's
configuration file to mark directories containing the Server
Extensions as "executable." Since the FrontPage Server
Extensions run as "www" and the Web-server configuration file is
owned and modifiable only by "root," the FrontPage Server
Administrator must be manually run as "root" on the host
computer to do this. This prevents administrators from remotely
creating FrontPage webs because the Web server's configuration
file would need to be owned by "www," which would potentially
compromise the host system's security.

The FrontPage Server Extensions also read the Web server's
configuration file to learn what virtual servers there are,
where the content roots are, and what directories are marked
executable.

The Server Extensions Configuration File

Some security settings of the FrontPage Server Extensions can be
controlled in the Server Extensions configuration file. The
configuration file is in /usr/local/frontpage and is named
wexxxx.cnf or, on multi-hosted servers, host:xxxx.cnf, where
xxxx is the port number of your server and "host" is its name or
IP address. The global configuration file
/usr/local/frontpage/version 3.0/frontpage.cnf contains the
default settings which apply to all FrontPage webs.

See List of UNIX Configuration File Settings for a complete
listing of the parameters that you can set in this file.

FrontPage Security on IIS Systems

Windows NT Security Concepts

IIS Security Overview

     IIS Authentication
     The Anonymous Account
     Basic Authentication
     Windows NT Challenge/Response
     Distributed Password Authentication
     Windows NT Challenge/Response and Network vs. Local
     Logon Rights

The FrontPage Server Extensions on IIS

     The FrontPage DLLs
     FrontPage Access Control List Settings
     FrontPage and System DLLs
     Virtual FrontPage Directories
     Restricting Windows NT Account Lists
     Making a Directory Unreadable

Windows NT Security Concepts

Windows NT security helps you protect your computer and its
resources by requiring assigned user accounts for all
operations. You can control access to all computer resources,
including Web content, by limiting the user rights of these
accounts. Windows NT maintains account lists of local users and
groups and of users and groups in the domain.

Every operation on a Windows NT computer identifies who is doing
the operation. The username and password that you use to log on
to Windows NT identifies who you are and defines what you are
authorized to do on that computer.

What a user is authorized to do on a computer is configured in
User Manager by setting User Rights in the Policies menu. User
rights authorize a user to perform certain actions on the
system, including the right to "Log on locally," which is
required for users to use Internet Information Server services
under Basic Authentication.

NTFS is the recommended file system choice for Windows NT
systems that host Web sites. Windows NTFS allows the association
of an access-control list (ACL) with any file or directory. An
ACL contains users and groups with sets of permissions that
control whether or not a user or group can read, write, execute,
or delete that file or directory.

Windows NT also supports the File Allocation Table (FAT) file
system. Because there are no file permissions maintained there,
storing web content in a FAT partition completely bypasses
FrontPage and IIS access control. You are warned about this when
you attempt to install the FrontPage Server Extensions on a FAT
partition. To apply security to a Web site, you must either
convert the partition from FAT to NTFS or move the content to an
NTFS partition. With either solution you will have to uninstall
and reinstall the FrontPage Server Extensions.

For more information on Windows NT Security, see Windows NT
Server for IS Professionals.

IIS Security Overview

IIS Authentication

Under IIS design, each HTTP request to IIS from a Web browser
(or from the FrontPage client) runs under a user account on the
Windows NT computer hosting IIS. The operations that are
performed during the execution of that HTTP request are limited
by the capabilities granted to that user account on the Windows
NT Server.

When IIS receives an HTTP request from a Web browser or from the
FrontPage client, it does the following:
  * IIS validates the user against an account (a user/password)
    from the Windows NT account list, then "impersonates" that
    account to process the Web request.

The request is first attempted as the anonymous account,
IUSR_<hostname>. If that execution fails to have sufficient
access to complete the request, or if IIS does not have
anonymous browsing enabled, then IIS returns error 401 (access
denied). At this point, user authentication is performed to
allow the remote user to identify themselves using the
techniques of Basic Authentication or Windows NT
Challenge/Response. If the Web browser or FrontPage client is
using Windows NT Challenge/Response, the user may not see a
prompt, because the FrontPage client or the Web browser simply
supplies the username and password of the logged in user from
the client computer.

  * IIS allows access to a file in the Web server only if the
    NTFS ACL for the file contains the account being
    impersonated by the Web server, with the correct
    permissions.

You can restrict IIS access to only authenticated clients
(clients that supply a valid Windows NT username and password),
or you can allow anonymous access using the anonymous account.
When you use authenticated clients, no access is permitted
unless a valid username and password are supplied. Password
authentication is useful if you want only authorized individuals
to access your Web site or specific portions controlled by NTFS.
You can have both anonymous logon access and authenticated
access enabled at the same time.

The Anonymous Account

Each Internet service, such as World Wide Web and FTP, maintains
a Windows NT username and password that is used to process
anonymous requests. The anonymous account for Web services,
IUSR_<hostname>, is automatically created by Internet
Information Server during its setup. By default, all Web client
requests use this account, and clients are given access to Web
content using the IUSR_<hostname> account.

When an anonymous account request is received, the WWW service
"impersonates" the user configured as the anonymous logon user.
The request succeeds if the anonymous logon user has permission
to access the requested resource, as determined by the
resource's Access Control List (ACL). If the anonymous logon
user does not have permission, the request fails. The WWW
service responds to a failed anonymous request by requiring that
the user provides a valid Windows NT username and password.

Basic Authentication

Basic Authentication is supported by the majority of Web servers
on the Internet. When using Basic Authentication, the Web
browser (or the FrontPage client) prompts the user for a
username and password. The username and password are then
transmitted across HTTP, lightly encoded using a technique known
as UUencoding. Using this username and password IIS then
authenticates the user as the corresponding Windows NT user.

One security risk of Basic Authentication is that usernames and
passwords are transmitted across the network in an easily
decoded format. However, if your Web site must support authoring
by FrontPage 1.1 clients (which do not support NTLM), or if you
want to ensure that your Web site is accessible from all browser
types, then you must keep Basic Authentication enabled.
Furthermore, Basic Authentication is the only authentication
technique that works through a firewall via a proxy server. If
you are running your Web server over the Internet via a proxy
server (as opposed to running it within an intranet) you must
use Basic Authentication.

Windows NT Challenge/Response

Windows NT Challenge/Response (also called NTLM) is a more
secure authentication method than Basic Authentication. In
Windows NT Challenge/Response, the Web browser or FrontPage
client first attempts to use the Windows NT credentials used to
log on to the computer on which the browser or FrontPage client
is running. If those credentials are rejected, Windows NT
Challenge/Response will prompt the user for a name and password.

The username and password are securely encrypted in a multiple
transaction interaction between the client and Web server. This
interaction is secure against network snoopers that attempt to
break into systems by monitoring network traffic between a
client and a server.

There are some limitations of Windows NT Challenge/Response:
  * Windows NT Challenge/Response Authentication cannot be
    performed through a firewall via a proxy. In this case,
    users must use Basic Authentication.
  * Some browsers may not support Windows NT Challenge/Response.
  * Windows NT Challenge/Response does not support delegation to
    third party servers.

Because Windows NT Challenge/Response Authentication cannot be
performed through a firewall, it is most useful on intranets,
where communication occurs inside an organization's firewall.

You can have both Basic and Windows NT Challenge/Response
authentication enabled. If the Web browser supports Windows NT
Challenge/Response, it uses that authentication method.
Otherwise, it uses Basic authentication. Windows NT
Challenge/Response authentication is currently supported only by
Microsoft Internet Explorer 2.0 or later.

Distributed Password Authentication

The FrontPage Server Extensions supports Microsoft Commercial
Internet System Membership service, which uses the Microsoft
Distributed Password Authentication (DPA) protocol. DPA is a
challenge and response authentication protocol that uses
passwords and a trusted third-party authentication server. In
DPA, a generic user name in the domain is mapped to a set of
users maintained in a database. This lets Internet service
providers extend the number of users an NT domain can
accommodate. Generic usernames, such as "FrontPage_Authors," are
available in the FrontPage Permissions dialog box in the same
way as other usernames and groups.

FrontPage client machines that use DPA must have Microsoft
Internet Explorer 3.0 (or higher) or Netscape Navigator 2.0 or
3.0. If the client machine is running Microsoft Internet
Explorer 3.0, the user must install the Microsoft Internet
Explorer 3.0x DPA update. If the client machine is running
Netscape Navigator 2.0 or 3.0, the user must install the
Microsoft Authentication Proxy for Netscape Navigator update.

Windows NT Challenge/Response and Network vs. Local Logon Rights

IIS 2.0 implements Windows NT Challenge/Response and Basic
Authentication slightly differently than later IIS versions.
When a user is authenticated using Windows NT
Challenge/Response, the user is logged on to the Web server
computer as a network logon. When Basic Authentication is used,
the user is logged on with local logon rights by default, which
is similar to logging on for an interactive session at the
computer's console.

In most situations, there are no differences between a network
logon and a local logon. The one situation for which this makes
a difference is delegation applications. A delegation
application is one in which part of the Web server's work is
delegated to a secondary server process running on a different
computer. For example, a Web server that accesses a database
server running on a different host computer is a delegation
application. If the user has logged on locally, Windows NT
security permits those user credentials to be honored by the
secondary server. If the user has logged on via the network,
those credentials are not honored. Consequently, when using
Windows NT Challenge/Response, the database server and Web
server must be running on the same host computer.

There are two potential problems caused by Basic
Authentication's use of local logon that administrators should
be aware of. First, Basic Authentication will not succeed if the
user account does not have local logon rights. Even if the
FrontPage, IIS, and Windows NT configuration appears to be
correct, the lack of local logon rights granted to the user in
the Windows NT User Manager will prevent Basic Authentication
from authenticating the user. Second, with local logon, if a
user can obtain physical access to the host running IIS, the
user will be permitted to start an interactive session at the
console.

The FrontPage Server Extensions on IIS

The FrontPage DLLs

In FrontPage, there are three kinds of users defined for every
FrontPage web: administrators, authors and browsers (end-users).
All permissions are cumulative; all authors also have browsing
permission, and all administrators also have authoring and
browsing permissions.

In FrontPage, the list of administrators, authors and browsers
is defined on a per-web basis. All content in a FrontPage web
will be accessible to the same set of users and groups. It is
not possible to control permissions on a per-file or
per-directory basis with FrontPage. All FrontPage sub-webs
either inherit the permissions (list of administrators, authors
and browsers) of the FrontPage root web or use their own, unique
permissions.

Each FrontPage web (including each sub-web) contains copies of
three ISAPI DLLs that make up the FrontPage Sever Extensions.
These DLLs are created in directories below the top-level
directory of a FrontPage web:
  * _vti_bin/_vti_adm/admin.dll for administrative tasks
  * _vti_bin/_vti_aut/author.dll for authoring FrontPage webs
  * _vti_bin/shtml.dll for browse-time FrontPage components such
    as form handlers.

FrontPage performs all authoring and administrative tasks by
sending HTTP POST requests to these DLLs. The FrontPage Server
Extensions are stored in separate directories in the customer's
document root:

/document root
   /_vti_bin
      shtml.dll
      /_vti_adm
         admin.dll
      /_vti_aut
         author.dll

FrontPage Access Control List Settings

FrontPage implements web security on IIS by changing the
access-control lists (ACLs) for all files and directories in
each FrontPage web. FrontPage controls who can administer a
FrontPage web by setting the ACL on admin.dll, the
administrative DLL. Similarly, FrontPage sets authoring
permissions by setting the ACLs on author.dll. The default ACL
sets browsing permission on Web content and lets all users
execute the run-time DLL, shtml.dll.

You set the ACLs for a FrontPage web using the FrontPage
Explorer's Permissions command, on the Tools menu. To add new
users and groups, this command makes the Windows NT computer
account list available. In FrontPage 98, you can set up a
restricted list of users and groups that does not expose the
entire contents of the Windows NT computer and domain account
lists. This lets you protect the confidentiality of your user
community. For details, see Restricting Windows NT Account Lists.

FrontPage sub-webs can have unique permissions by maintaining
separate access-control lists on their own copies of the
admin.dll, author.dll and shtml.dll DLLs. Alternatively, a
FrontPage sub-web can inherit the permissions of the root web by
keeping the access-control lists on its admin.dll, author.dll
and shtml.dll the same as the root web's lists.

The set of ACLS for a FrontPage web is illustrated in the
following two diagrams. The first diagram shows the ACLs for the
content of a FrontPage web: the directories, files, and
executable files that an author creates. The second diagram
shows the ACLs for the FrontPage _vti directories.

Note in these diagrams that two sets of permissions are given.
The first set applies to the directory, and the second set
applies to the files in the directory. For example, the
permissions (rx) (r) specify read and execute-permissions on the
directory but only read permissions on the files in the
directory.

For the complete set of ACLs set on FrontPage files, along with
a list of the entire contents of a FrontPage installation, see
FrontPage Windows NT File Permissions.

Notes:

  * All FrontPage ACLs have full control (all) (all) for Windows
    NT Administrators group members and the SYSTEM account.
  * The root web root directory's ACL is the same as the default
    ACL, except that the interactive and network accounts have
    (rx), or list files, access to the directory only (not to
    the content of the directory). This access is required in
    order to list sub-webs in the FrontPage Explorer. The
    top-level directory of sub-webs does not require these
    additional accounts, therefore sub-web root directories use
    the default ACL.
  * The Executable ACL is applied to directories that are marked
    with an executable virtual root. For the web server to run
    application or script files in response to browser requests,
    the web server's virtual root must be marked executable in
    addition to having the executable permission on the file's
    ACL.  FrontPage will set up both of these conditions when
    folders are made executable using the FrontPage Explorer's
    Folder Properties dialog box.

    The Executable ACL is allowed only if the
    AllowExecutableScripts=1 setting is present for the
    FrontPage web in the FrontPage configuration file
    frontpg.ini (either globally or on a per-web basis). The
    default for AllowExecutableScripts is off. If
    AllowExecutableScripts is off for a FrontPage web, the
    Executable ACL will never be applied and the default ACL is
    used even if the directory is marked executable. In IIS 2.0
    and IIS 3.0, the execute permission granted in the
    Executable ACL affects all files in a directory, including
    EXEs, DLLs, and interpreted scripts such as .ASP and .PL
    files. On IIS 4.0, the execute permission affects only DLLs
    and EXE files, and, depending on the server configuration,
    may not affect interpreted script files.
  * The Result File ACL is used only on files that contain the
    results of a form that uses the FrontPage default form
    handler. For a Discussion form handler, this ACL is placed
    on the directory for that discussion. This ACL grants write
    and delete access to users of the FrontPage web.
  * If, in the FrontPage Explorer's Permissions dialog box, the
    setting "Everyone has browse access" is selected, anonymous
    browsing for a web is implemented. This is done by adding
    the anonymous account IUSR_<hostname> to the default ACL.

FrontPage and System DLLs

On Windows NT, a DLL that is called from another DLL must run
under the same user account as the calling DLL. Therefore, all
system DLL code that is run as a consequence of an IIS request
must run on the impersonated user's permissions. The FrontPage
DLLs admin.dll, author.dll, and shtml.dll contain calls to
Windows NT system DLLs. To ensure that the system DLLs will have
the correct level of permissions to run under any administrator,
author, or end-user's account, FrontPage adds the Interactive
and NETWORK accounts to the ACLs of any system DLLs that are
used as a result of a FrontPage DLL call. These added users are
given "read" and "execute" permissions on the system DLLs. Note
that this is necessary when installing any generic CGI scripts
that use any Windows NT system services on a Web server. Because
FrontPage makes calls to Windows NT system DLLs:
  * Some shared FrontPage DLLs in the \winnt\system directory
    are made accessible to impersonated users.
  * Some core system DLLs that implement APIs for core system
    services are made accessible to impersonated users.

    Click here for the full list of system DLLs affected by
    FrontPage.

Virtual FrontPage Directories

Virtual directories are IIS 2.0 and IIS 3.0 constructs that map
the URL space of the Web site onto the file system of the local
computer. They control read and execute access to specified
directories within the file system and allow seemingly related
URLs to refer to noncontiguous content areas in the file system.

FrontPage automatically manages the use of virtual directories
for executable and unreadable directories. When installed,
FrontPage sets up virtual directories in each FrontPage web to
mark the directories that contain the FrontPage Server Extension
DLLs as executable and to mark hidden directories as unreadable.
FrontPage creates the following virtual directories for each
sub-web:

    _vti_bin

    _vti_bin\_vti_aut

    _vti_bin\_vti_adm

    _vti_pvt

  * _vti_cnf

    _vti_txt

The root FrontPage web has a seventh virtual directory:
  * _vti_log.

In the FrontPage Explorer, authors can mark directories
executable to allow the directories to store executable objects
such as Active Server Pages (ASP), Database Connector files
(IDC), CGI Scripts, ISAPI Extensions, and Perl scripts. Each
directory that is marked executable causes FrontPage to create a
virtual directory.

Restricting Windows NT Account Lists

In FrontPage 98, you can set up a single user and group list for
each virtual root FrontPage web. This lets you protect the
confidentially of your user community by not displaying the full
Windows NT account list. To globally enable Windows NT computer
account list restrictions, add the following line to your
frontpg.ini file, located in the \Winnt directory:

[FrontPage 3.0]
RestrictIISUsersAndGroups = 1

Setting the value to 1 enables restrictions. This same line can
also be added for a specific virtual root FrontPage web, for
example:

[Port 157.55.49.66:80]
RestrictIISUsersAndGroups = 1

A setting of RestrictIISUsersAndGroups=0 can be used to
explicitly disable restrictions, allowing you to set
restrictions by default to enabled for all FrontPage Webs except
for those where restrictions are explicitly overridden. The
default for the global setting is that restrictions are off if
the RestrictIISUsersAndGroups key is missing. The default for
individual FrontPage webs is to inherit the global setting.

If users and groups restrictions are enabled for a given
FrontPage web, the Server Extensions look for a Windows NT group
named in the following convention:

FP_[ServiceName][_Subweb]

On a multihosted IIS2.0/3.0 machine [ServiceName] is the
service's IP address and port number combination  and [_Subweb]
is the name of the sub-web. On a single-hosted machine, the
ServiceName portion is simply the port number.

On IIS 4.0, [ServiceName] can be of the form /LM/W3SVC/<N>,
where <N> is an instance number. This is the recommended method.
On IIS 4.0, [ServiceName] can also be of the form
<virtual_server>:<port_number>. If you use this form, you must
use specify the virtual server's name; you cannot use the
virtual server's IP address on IIS 4.0.

To specify a root web's restriction group, omit the _Subweb
portion.

Some examples are:

FP_157.55.49.66:80_MySubweb

FP_80_MySubweb

FP_80

FP_/LM/W3SVC/1_MySubweb

If restrictions are enabled on a sub-web but no local group is
defined, the FrontPage Server Extensions look for the group of
the root web and use it if found. If no appropriately named
groups are found then no restriction is placed on permissions
visibility setting or contents.

Making a Directory Unreadable

A standard way of saving form results in FrontPage is to use the
default form handler (also called the WebBot Save Results
component) to write to a results file in a directory in a
FrontPage web. In FrontPage 1.1 and FrontPage 97, writing form
results to a directory made the contents of the directory
readable to any user who discovered the URL of the results file.

In FrontPage 98, authors can assign a virtual directory mapping
for a form results directory that has both the execute and the
read bits turned off. This prevents any end-user from reading
the contents of the directory, but it requires the FrontPage web
author to fetch the contents of the directory using the
FrontPage Explorer.

To make a directory unreadable, select it in the FrontPage
Explorer's Folders view and select Properties from the Edit
menu. In the Folder Properties dialog box, deselect the two
settings: Allow scripts or programs to be run and Allow files to
be browsed.

Note that if you make the /_private directory unreadable, some
FrontPage Wizards will not work properly.

