Using Security Features in FrontPage

Administering Security Through FrontPage Server Extensions

The key component that Microsoft FrontPage uses to provide security is a set of three programs that are collectively called Microsoft FrontPage Server Extensions. On a Web site that they support, called a FrontPage-extended web, they provide enhanced authoring, browsing, and administering functionality.

For example, authors can collaborate on Web sites, add hit counters without knowing any programming, and rename pages that FrontPage Server Extensions automatically relink. Web site visitors can fill out forms processed by a built-in form handler. You don’t have to download, buy, or install a separate Common Gateway Interface (CGI)-compatible program to enable each function to work.

FrontPage Server Extensions also play a pivotal security role by working with Microsoft Windows NT Server and Microsoft Internet Information Server (IIS) to check the browsing, authoring, and administering permissions of visitors to a Web site. Based on the results of the check, they either permit or deny the action requested by the visitor.

Note   FrontPage Server Extensions do not work with Windows NT Server security if you use any Web server besides IIS, including the Netscape, O’Reilly WebSite, and FrontPage Personal Web Server (PWS) Web servers.

FrontPage Server Extensions consist of the following dynamic-link library (DLL) files:

• Admin.dll, which handles user requests for administrative actions
• Author.dll, which handles user requests for authoring actions
• Shtml.dll, which handles user requests for browsing actions

You add, modify, upgrade, or remove FrontPage Server Extensions by using any of the FrontPage Server Extensions administration tools: the Fpsrvadm and Fpremadm utilities, the FrontPage snap-in in Microsoft Management Console (MMC), or the FrontPage Server Extensions HTML Administration Forms.

Top

Authenticating users through Windows NT Server

A user can be authenticated and gain access to the system and its resources, such as a FrontPage-extended web, only if the user has a user account on Windows NT Server. Typically, a system administrator creates a user account for each user and group that has access to the system. To gain access, the user supplies a user name and password when logging on to the system. Windows NT Server compares the user’s name and password against the authorized list of user accounts that it maintains.

When an authenticated user runs an application, Windows NT Server forces the application to impersonate the user; that is, to run with the same permissions granted by Windows NT Server to the original user. That way, the application can invoke only other applications or system resources, such as files and folders that contain Web content, for which the original user has permissions.

Impersonation also works remotely. If a user can be authenticated on a remote computer, any application that the user runs on that computer (and has permission to run) impersonates the user. For example, when a user who has permission to author a FrontPage-extended web on a remote computer running Windows NT Server attempts to do so, the FrontPage authoring DLL file, Author.dll, runs as the impersonated user. (After a user is logged on and authenticated locally, the user does not need to log on to the remote computer again.)

To control access to individual files and folders, Windows NT Server, when running on an NTFS file partition, associates an access control list (ACL) with each file and folder. An ACL is a list that specifies which users and groups have access to its associated file or folder, and what permissions those users and groups have. An ACL is not a file, but rather a property of a file or folder.

The security that FrontPage Server Extensions provides is based on ACLs. Because only the NTFS file partition supports ACLs, be sure to use NTFS on a computer running Windows NT Server and not the file allocation table (FAT) file partition. (The FAT file system does not support ACL-based file permissions. Therefore, Windows NT Server cannot provide any security for a Web site on a FAT-partitioned system.)

Top

Mediating authentication through IIS Web server

The IIS Web server is a Windows NT service, which is a special application that starts along with the operating system and runs in the background, without any user interface. IIS is a file and application server for the Internet and for intranets. It supports industry-standard Internet protocol services (such as HTTP protocol services), Web application development, server administration, management and control of Web server content, and security and authentication.

As part of the FrontPage security triad, IIS mediates authentication communication between FrontPage Server Extensions and Windows NT Server. When an authenticated user requests access to a Web resource, IIS impersonates that user. IIS supports four kinds of authentication.

Anonymous authentication   provides access to users who do not have Windows NT Server accounts on the server computer (for example, Web site visitors). IIS creates the anonymous account for Web services, IUSR_computername. When IIS receives an anonymous request, it impersonates the anonymous account.

Basic authentication   is an authentication protocol supported by most Web servers and Web browsers. Although Basic authentication transmits user names and passwords in easily decoded clear text, it has some advantages over more-secure authentication methods in that it works through a proxy server firewall and ensures that a Web site is accessible to almost any Web browser.

Windows NT Server Challenge/Response authentication   encrypts user names and passwords in a multiple transaction interaction between client and server, thus making this method more secure than Basic authentication. Disadvantages are that this method cannot be performed through a proxy server firewall, and some Web browsers (most notably, Netscape Navigator) do not support it. You can, however, enable both this method and Basic authentication at the same time.

Digest Access authentication   is similar to Basic authentication, except that a user’s name and password are transmitted in a more-secure format. This method requires Microsoft Internet Explorer 5 on the client computer.

Top

Applying the iron triangle

The central role of the ACLs — access control lists that specify what actions each authenticated user and group are permitted to perform on a file or folder — becomes clear when you view FrontPage Server Extensions, Windows NT Server, and IIS Web server as an integrated security system.

Windows NT Server creates and sets the initial permissions on the ACLs. But after FrontPage Server Extensions are installed on IIS, you can use administration tools such as Fpsrvadm and Fpremadm to modify the ACLs on FrontPage-extended web files and folders. That is, you can change the permissions on these files and folders. You can also use the FrontPage client Permissions command (Tools menu, Security submenu) to modify the ACLs. When you use this method, FrontPage displays the Windows NT Server user-account list by default.

Note   If the FrontPage Security command is unavailable, make sure that you entered http://webname as the folder name when you opened the Web site, rather than opening the site as a file on your hard disk. You must manage security through IIS, and IIS uses NTFS to set permissions and enforce security settings. When you open a file from your NTFS drive, you bypass the server extensions security features within FrontPage.

The ACL in the root folder of a FrontPage-extended web is especially important. In this ACL, you add and set or modify permissions for users of the FrontPage-extended web. You specify R permission for browsing users, who can only read web files; W permission for authors, who also have R permission and can read and write to web files; and P permission for administrators, who also have W and R permissions and can change permissions by modifying ACLs.

If a user requests an administrative action on the FrontPage-extended web, Admin.dll checks the root folder that the ACL is in to see whether the user has P permission. If a user requests an authoring action, Author.dll checks the ACL to see whether the user has W permission. And if a user requests a browsing action, Shtml.dll checks the ACL to see whether the user has R permission.

The following example uses an author request to show from beginning to end how FrontPage, Windows NT Server, and IIS work together to provide security.

When using FrontPage, a user tries to perform an authoring action on a FrontPage-extended web. The FrontPage client or a Web browser sends a POST request to perform the authoring action on the web. IIS reads the request, interprets it as an authoring request, and directs the request to the FrontPage authoring DLL file, specifically, to Author.dll. Author.dll determines which web the user wants to act on, and then checks to see whether the user has W permission in the ACL of the web’s root folder. If the user is authenticated, Author.dll impersonates the user and tries to access the file or folder specified by the author.

Windows NT Server checks the permissions of the impersonated user against the ACL of the specific file or folder that the user is trying to access. The user might have read, write, or delete permission. If the check is successful, Windows NT Server gives Author.dll access to the file or folder to perform the requested action. If the check fails, FrontPage displays a message specific to the operation that the user is trying to perform, such as “You do not have permission to delete the file.”

Top

See also

You can also use the FrontPage Server Extensions to provide security on UNIX operating systems. For more information, see the Front Page Server Extensions Resource Kit Web site at http://www.microsoft.com/frontpage/wpp/serk/.