Security Topics for Visual InterDev 1.0

Article
07/12/2006

Martin Sonntag
Visual InterDev Program Management
Microsoft Corporation

March 1997

Summary: This article contains technical information on all aspects of security for users of Microsoft Visual InterDev. It assumes a working knowledge of Visual InterDev. (14 printed pages)

Introduction

Microsoft® Visual InterDev® (VID) uses the Microsoft FrontPage® extensions on a Web server to manage Web security, in the same way that FrontPage does. In fact, although the VID user interface in general differs from that of FrontPage, VID exposes the same user interface as FrontPage does for managing security. The FrontPage extensions, in turn, simply use the existing security features of Microsoft Windows NT® and the Internet Information Server (IIS) to manage Web security. Thus users of Visual InterDev (VID) need to be familiar with the security features of FrontPage, Internet Information Server (IIS), and Windows NT. This paper provides concise coverage of these topics and pointers to more in-depth reading. VID users also need to be familiar with the security models of any ODBC databases, such as Microsoft Access or SQL Server, used by their Web applications. Specific database security models are not addressed in this paper.

Note The full set of security features described here is only available on servers running Windows NT 4.0 with the NTFS file system. Use of the FAT file system, whether on a Microsoft Windows® 95 or Windows NT server, greatly reduces the security features available. This is due to the fact that only the NTFS file system provides per-file Access Control Lists (ACLs). See "Problems and Limitations, FAT File System" below for further information.

Basic Security Concepts

Security is a complex topic. However, there are two concepts so central to all discussions of security that they need to be addressed first. These concepts are identity and permissions. An overview of these two concepts will provide a foundation for your understanding of the remainder of this paper.

Identity

Identity answers the question: Who are you? In order for any security system to work, there must be a way for users to identify themselves to the system and a way for the system to verify that identity.

VID, FrontPage, and IIS all participate in the Windows NT domain model of security. Under this model, a user's identity is established by defining a user account in a Windows NT domain. Windows NT domains can span multiple computers or be local to a single machine; thus a user account can be valid across multiple machines or be restricted to a single machine, depending on the domain in which it is defined.

When users begin a session on a computer that participates in a Windows NT domain, they identify themselves by providing a user name and a password at a system logon prompt. The system verifies their identity by finding a user account that corresponds to the user name entered and checking that the password entered by the user is the correct one for the account. Once the user's identity has been verified, all the operations that the user initiates in that session are run in the context of that individual's user account. It is this context, together with the permissions assigned to resources, which determines what resources a user can and cannot access.

Anonymity

On the World Wide Web, many sites permit users to browse their content anonymously, that is, without any identity. How is this reconciled with the need for an identity in the Windows NT domain model? The Internet Information Server bridges this gap by defining a special user account, which is referred to as the "anonymous user." Whenever IIS receives an anonymous request to browse a Web, it actually processes that request in the user context of the anonymous user account. This scheme permits Web site owners as much control over security for anonymous users as they exercise over identified users. In addition, it simplifies security management by consolidating all anonymous access under a single user account.

A more thorough discussion of IIS security is presented in the section below titled "IIS Run-Time Security."

Permissions

Permissions complement identity as the other cornerstone of security. Once a way of identifying users has been established, individual users can be given specific permissions on system resources. The primary resources of concern here are files and directories. An individual user can be given permissions to read, write, execute, delete, change permissions on, or take ownership of a file. These are the individual permissions defined by Windows NT. The meanings of these individual permissions should be obvious. In addition, Windows NT defines some standard permissions that combine one or more individual permissions. It is these standard permissions that are usually assigned to files or directories. For instance, having change permission is equivalent to having read, write, execute, and delete individual permissions. Having full control is equivalent to having all the individual permissions. Having the standard read permission is equivalent to having individual read and execute permissions. (Yes, this is a potential source of confusion, but context usually makes it clear whether individual or standard permissions are being referred to.) In this document, standard permissions are used unless otherwise noted.

For convenience, Windows NT permits the definition of named collections of users, called "groups." Once a group has been defined and users have been added to it, each user in the group can be granted or denied access to a resource by changing the group's permissions on that resource.

Access

Identity and permissions together determine a user's access to resources. The entire set of permissions assigned to a resource, for example, a file or directory, is called an Access Control List (ACL). The operating system checks the ACL of a resource whenever a user attempts to access that resource in order to verify that the user has the proper permissions for the type of access being attempted. For instance, if a user who has read permission only on a file foo.bar attempts to delete foo.bar, that user will be denied access.

Here is a simple example: How would a Web site manager use security to protect a single file on the site, say foo.bar, from being read by users browsing the site anonymously? She would simply change the permissions on foo.bar so that the anonymous user account did not have read permissions on foo.bar.

Web Permissions

VID exposes the security model defined by FrontPage for Webs hosted on a server running the FrontPage Server Extensions. This model is summarized here, and described in more detail in Using the FrontPage 97 Server Extensions with the Microsoft Internet Information Server. (See Further Readings below.) It extends to Webs the permissions model discussed above for files and directories.

Levels of Access

FrontPage defines three levels of access for a Web. An individual user, or an entire group of users, is either assigned one of these three levels, or has no access. Access is defined on a per-Web basis. The operation of defining access on a Web is referred to as "setting Web permissions." The three levels of access are administer, author, and browse. These are described below.

Administer

Users with administer access to the root Web on a server may create or delete Webs on that server. A user with administer access to a Web may change permissions on that Web. Finally, users with administer access also have author and browse access.

Author

Users with author access to a Web may open and modify that Web, including adding or deleting content. They also have browse access to the Web.

Browse

Users with browse access to a Web are allowed to view the content of that Web through a browser. By default, all users have browse access to FrontPage Webs when they are created. However, a Web may be set to restrict browsing to users who have browse access to the Web.

Unique vs. Inherited Permissions

While access is defined on a per-Web basis, it can be time-consuming to set permissions on every Web. To alleviate this task, FrontPage allows sub-Webs to inherit their permissions from the root Web. Any changes in root Web permissions apply to all sub-Webs that inherit from the root Web. An administrator may not change permissions directly on a sub-Web until the Web is set to have its own, unique permissions.

Setting Web Permissions

Visual InterDev provides the same Web Permissions dialog box that FrontPage does. See Managing Web Projects—Setting Web Permissions in the Visual InterDev User's Guide for a step-by-step description of setting and changing Web permissions in the Web Permissions dialog box. Briefly, an administrator first selects a Web on which to set permissions by setting the active Web project. Then, the administrator invokes the dialog box, selects registered users or groups from any available Windows NT domain or the Web server, and specifies one of the three access levels for them on the selected Web.

Note On IIS servers without FrontPage Extensions, Web access is typically managed by manually changing file and directory permissions on Web content through the Windows Explorer. Once FrontPage Extensions are installed on a server, you may use the Web Permissions dialog box of VID or FrontPage to manage access. When changing permissions through this dialog box, the FrontPage Extensions change the file and directory permissions on the server, assuring that these changes are applied correctly and consistently. While you can still manually change file and folder ACLs in FrontPage Webs, unless you are very familiar with the FrontPage security model, that is, have read and understood the contents of this paper, you should make use of the Web Permissions dialog box.

Initial Permissions

Installation

When the FrontPage Extensions are installed on a server for the first time, any existing Web content on that server is put under FrontPage control. All content found under IIS' home virtual directory is included in the root Web. FrontPage grants the local Windows NT Administrators group on the server administer access to the root Web. In addition, during installation FrontPage requests a user name for an initial administrator account. The name must identify an existing Windows NT domain user account. This user account is also granted administer access to the root Web.

Note Because the Administrators group is granted administer access to the root Web, it is important to regulate membership in this group on a server with FrontPage Extensions. In particular, it is imperative to keep the anonymous IIS user out of this group.

It is easy to give a user full access to all the Webs on a server by adding them to the Administrators group of the server; however, this grants that user rights on the server that go well beyond Web administration, and may not be desirable. See Simplifying Design-Time Security for suggestions on security management.

FrontPage does not change any existing read permissions on Web content during setup. IIS assigns read permission to the anonymous IIS user on all Web content during its installation. The net result is that, following a default installation of FrontPage and IIS, any user can read (browse) the content of existing Webs on that server, that is, browsing is not restricted to registered users.

New sub-Webs

When a new sub-Web is first created, it inherits its permissions from the root Web.

Copied Webs

Whenever a new sub-Web is created by a Copy Web operation, it inherits its permissions from the root Web. Any unique permissions assigned to the source Web are not copied to the new destination Web.

Design-Time Security

To secure a Web application while it is under development, VID authors use design-time security. Design-time security is managed by controlling which users and groups of users are granted administer and/or author access to Webs. The section below, "Design-Time Security Implementation Details," describes exactly how this works.

To give a user full design-time access to a Web, the user should be granted administer access to that Web. If you want a user to be able to create new Webs on a server, the user needs administer privileges on the root Web of that server. To give a user enough access to fully modify an existing Web, but not to delete it, the user should be granted author access to the Web.

Simplifying Design-Time Security

There is a relatively simple way to manage design-time security with minimal effort. With this technique, you modify Web permissions only once and then use the Windows NT User Manager utility for subsequent security changes.

First use the Windows NT User Manager on your Web server to create two new local groups of users:

FP_Admins
FP_Authors

Next, invoke the Web Permissions****dialog boxon the root Web of the server. On the Groups tab, add the group FP_Admins with administer access. Add the FP_Authors group with author access.

When you create new sub-Webs on this server, keep their default setting of inheriting permissions from the root Web.

From this point on, you can easily grant new users administer or author access to the Webs on this server by simply adding their name to the appropriate group using the Windows NT User Manager, without re-invoking the Web Permissions dialog box. However, if you want to maintain a single sub-Web with different permissions than the other Webs on the server, you must set it up to have unique permissions and then manage its users and groups separately.

Design-Time Security Implementation Details

The FrontPage Extensions manage design-time Web permissions using the underlying security model of the host operating system on the server. Here we consider only the case where this operating system is Windows NT 4.0 with the NTFS file system.

FrontPage manages administer and author access to a Web using the same technique. In the Web's root directory, FrontPage creates a directory named _vti_bin. Within this directory it creates two sub-directories, _vti_adm and _vti_aut. Within _vti_adm FrontPage places a file, admin.dll, and within _vti_aut it places two files, author.dll and dvwssr.dll. These DLLs are ISAPI extensions. During design-time, client requests arrive over HTTP at the server and are routed to one of these ISAPI DLLs. A request to perform an administrative function, for example, change permissions on a Web, is handled by that Web's admin.dll. A request to perform an authoring function, for example, open a Web, is handled by that Web's author.dll. A request to fetch the source code for an ASP file without processing, for example, to view the links in that file, is handled by that Web's dvwssr.dll.

In the request, the client provides credentials that identify the user who is logged in to the client workstation. This user must have read permission (equivalent to read and execute individual permissions) for the DLL handling the request, otherwise the request is denied. Thus FrontPage restricts who may perform a given request by controlling read permission on the directories in _vti_bin. Whenever a change is made to a Web's permissions via the Web Permissions dialog box, the FrontPage Extensions on the server modify the ACLs on the directories _vti_adm and _vti_aut in that Web's _vti_bin directory accordingly.

Note FrontPage does not change ACLs on content files to manage design-time security; it only changes ACLs on the directories that contain the gatekeeper files admin.dll, author.dll, and dvwssr.dll. FrontPage manipulates content file ACLs to manage run-time security, which is the topic of the next section.

Run-Time Security

After a default installation of IIS and FrontPage extensions, Webs on a FrontPage server may be read anonymously by any browser that can make an HTTP request to the server. To secure their Web applications from such unrestricted access, VID authors use run-time security.

As part of the development process, authors routinely test their Web applications by using a Web browser of their choice to read their Web pages. For this reason, authors must be aware of run-time security considerations even while authoring.

**Note **Webs authored on a FrontPage server may be placed into production, that is, normal use by end-users, in place. In this case run-time security becomes production security. However, if a Web is put into production on a different server, its security settings on the production server should be reviewed and adjusted as necessary. If the production server has FrontPage Extensions and the Web was Web Copied to it, security settings will need to be reestablished through VID or FrontPage. If the production server is an IIS server without FrontPage Extensions, then the security should be established using Windows Explorer to manage file and directory ACLs on the Web's content.

Run-time security is managed, first, by controlling whether all users or only registered users are permitted to browse a Web, and, second, by controlling which users are granted browse access to those Webs that only permit registered browsers.

Browsing Permissions

The FrontPage security model facilitates the use of two access levels for end users: unrestricted browsing and restricted browsing. These are described below.

Unrestricted browsing

Unrestricted browsing is the default setting for new Webs. All users may read (browse) the content of a Web that permits unrestricted browsing. End-user requests to read Web pages are satisfied anonymously; that is, end-users are not required to identify themselves before fetching pages.

**Note **Since end-users are never required to identify themselves, it makes no difference whether they have browse access to the Web. For an explanation of how the unrestricted browsing state is implemented using the Allow Anonymous setting of IIS, see "Run-Time Security Implementation Details."

Restricted browsing

Using the Web Permissions dialog box, any root Web or sub-Web may be set to restrict browsing to registered users only. The FrontPage Extensions remove read access for the anonymous user from all the content files of the Web when browsing is restricted to only registered users. (For details, see "Run-Time Security Implementation Details" below.) An anonymous end-user's request to read a page of that Web is then rejected by IIS. End-users must authenticate their identity in the Windows NT domain, and the authenticated user account must have browse access to the Web before the request will be satisfied. When a user is given browse access to a Web, the FrontPage Extensions grant the user account read access to all the content files of that Web. (See "Run-Time Security Implementation Details.")

For complete control over who can browse a Web, restrict the Web so that only registered users can browse it, and then give specific users and/or groups browse access to the Web.

Simplifying Run-Time Security

As was the case with design-time security, you can simplify the task of managing run-time security by creating a local group, say FP_Readers, on the Web server, and giving the group browse access to the root Web. Be sure to restrict the root Web so that only registered users can browse it. When new sub-Webs are created, keep their default setting of inheriting permissions from the root Web.

Now the task of permitting a new user to browse the Webs on this server is reduced to simply adding the new user's name to the FP_Readers group using the Windows NT User Manager.

Run-Time Security Implementation Details

The FrontPage Extensions manage run-time Web permissions using the underlying security model of the WWW server software. Here we consider only the case where this is IIS 3.0 running on Windows NT 4.0 with the NTFS file system. Security on non-IIS servers is beyond the scope of this paper. Security features on non-NTFS file systems are severely limited. (See the section below titled "Problems and Limitations, FAT File System.")

FrontPage run-time security

FrontPage manages run-time security differently than design-time security. This is because run-time HTTP requests to read pages are not directed to ISAPI DLLs, as are design-time requests. IIS goes directly to the file being requested and attempts to read it, as described below. For this reason FrontPage directly alters the ACLs on content files in a Web in order to control run-time security.

When a Web is set to allow unrestricted browsing, FrontPage grants the anonymous user account standard read access to all the content files in that Web.

When a Web is set to allow only registered users to browse it, FrontPage removes all anonymous user account permissions from the Web's content files. Since IIS impersonates the anonymous user during all requests that do not contain user credentials (when Allow Anonymous is checked), this causes such requests to fail, initiating the authentication process described above.

The next section provides a detailed account of how IIS run-time security works.

IIS run-time security

Mention has already been made of the IIS anonymous user, which is only a part of the complete IIS security model. Here we consider more of the details of that model.

When IIS installs, it defines a special user account on the machine where it is being installed. This user is referred to as the "anonymous IIS user," or sometimes simply the "anonymous user." IIS assigns the user name IUSR_<MACHINENAME> to this account, where <MACHINENAME> is replaced by the name of the machine on which IIS is being installed. IIS generates a random password string for this account. IIS assigns Log on Locally rights to this account and adds it to the Guests group on the server.

**Note **If the IIS server is a Primary Domain Controller (PDC) or Backup Domain Controller (BDC), the anonymous user account is defined at the domain level and has access to resources across the domain. If the IIS server is neither a PDC nor a BDC, then the anonymous user is a local account on that server.

**Note **The anonymous IIS user account is different than the Guest account defined by Windows NT.

On the Properties page of the WWW service in Internet Service Manager, the section labeled Anonymous Logon specifies which user account IIS uses for anonymous requests. By default, IIS uses the anonymous user account IUSR_<MACHINENAME>.

On the same Properties page of the WWW service in Internet Service Manager, there is a section labeled Password Authentication. In this section there is a check box labeled Allow Anonymous. When this box is checked, which is the default setting, IIS processes anonymous HTTP requests, that is, HTTP requests that do not include user credentials, in the context of the user account specified in the Anonymous Logon section.

The net result is that IIS, in its default configuration, processes anonymous requests in the user context of the anonymous IIS user, IUSR_<MACHINENAME>. If the anonymous IIS user has sufficient access to a requested file, IIS satisfies the request. Otherwise, IIS rejects the request, returning an error to the client and informing the client of the authentication methods that IIS supports. At this point the client may initiate a process called authentication, which is described next.

**Note **IIS allows you to change the account and password it uses for anonymous logon, but you should do this with caution. First of all, it is important that the password IIS uses for the anonymous account match the password assigned to the account in the Windows NT User Manager. Secondly, it is important that the anonymous user account has the correct rights. These are already set correctly for the user account IUSR_<MACHINENAME> by IIS. If you change the user account used by IIS for anonymous access to a different account, you run the risk of granting anonymous users too much access to server resources.

Authentication

The authentication process allows a server to verify the identity of a user at a client and then impersonate that user on the server. IIS supports two authentication methods: Basic and Windows NT Challenge/Response (often referred to as NTLM, for Windows NT LAN Manager). The authentication process and the options that control it are both described completely in Securing Your Site Against Intruders. (See "Further Reading" at the end of this article.) Here we briefly describe the essential features.

On the Properties page of the WWW service in Internet Service Manager, in the section labeled Password Authentication, you check Basic and/or Windows NT Challenge/Response to determine which authentication method(s) IIS will offer to clients. Checking only one of the two options forces clients to use that option. If you select only NTML and a client does not support it, that client will be unable to authenticate its users. If you check both options, IIS will offer both options to clients, in the order NTLM followed by Basic. Clients that support both will then select NTLM, while clients that do not support NTLM will use Basic. If you uncheck both Basic and Windows NT Challenge/Response, then IIS will not be able to authenticate any clients, and so requests that cannot be satisfied as the anonymous user will always fail.

In Basic authentication, the client displays a dialog box to the user, who enters a user name and password. If the user's account is in a different domain than the server, the user must enter the user name in the form DOMAIN\USERNAME. The client sends these credentials (the name/password pair) to the server. The server then attempts to validate them against its local accounts and accounts defined in any trusted domains.

In NTLM authentication, IIS uses an encrypted challenge/response handshake with the client in order to validate the user who is logged in to the current session on the client machine. The user is not prompted for a name and password, which also means that the user cannot enter a different name than the one they used to log in to the client session.

The consequence of a successful authentication, whether achieved by the Basic or NTLM method, is that IIS impersonates the authenticated user while processing the request. This means that IIS processes the remainder of the request in the context of the authenticated user rather than the anonymous user. After successful authentication, all access to resources during the processing of a request will be based on the access rights of the authenticated user. The request will succeed if the user has sufficient access rights to the resource being requested; otherwise it will fail.

**Note **Remember that IIS will not perform authentication if Allow Anonymous is on and the anonymous user has sufficient access rights to the resource(s) that are required to satisfy a request.

Differences between Basic and NTLM authentication

There are several significant differences between Basic and NTLM authentication that Web authors must keep in mind.

Vulnerability to snooping Basic authentication sends the user's credentials (name/password pair) to the server unencrypted, making it vulnerable to snooping. NTLM encrypts the user's credentials to protect them from snooping. Using an SSL connection during Basic authentication can eliminate this potential security weakness.
Transport path between client and server Basic authentication takes place over HTTP, which means the client and server communicate over TCP/IP. Thus Basic authentication can take place between any client/server pair on the Internet, and can pass through proxy servers and firewalls. NTLM authentication requires that the client and server both be on a Windows NT LAN.
Availability of user credentials In Basic authentication, the client sends the user's name and password to the server for validation. In NTLM, the user logged in to the client workstation is authenticated without a transfer of credentials. Thus, after Basic authentication, the server has the user's credentials, while after NTLM authentication, it does not. This has implications for the degree of impersonation possible on the server. When impersonating a user on the server, there are operations that cannot be performed without the user's credentials. Some of the problems that this causes are described in the "Problems and Limitations" section below.

Recommended authentication for VID

VID supports NTLM authentication and it is recommended that you enable NTLM authentication on your Web server. NTLM does require that both client and server be on a Windows NT LAN, so if you are authoring over an HTTP-only link, you must enable Basic authentication. If you enable both Basic and NTLM, clients that support NTLM will use it; clients that don't will use Basic authentication.

Read and Execute access

IIS introduces another security setting on the virtual roots that it manages: read and/or execute access. These are different from the individual and standard permissions described previously, which are assigned to files and directories. These are access levels assigned to the virtual directories defined by IIS. Each virtual directory may be assigned read access, execute access, both read and execute, or neither. IIS will only satisfy read requests for files, for example, HTML files, if their virtual root permits read access. IIS will only process executable files, for example, ASP files, if they are directly contained within a virtual directory with execute access. IIS enforces this security independently of the ACLs on the underlying real files and directories, and independently of the user making the request.

When VID creates a new sub-Web, it creates a new corresponding virtual root with both read and execute access. Thus for new Webs, IIS will not deny any requests due to virtual root access settings. This turns out to be the right thing to do for typical VID-style Webs which use Active Server Pages for their server-side processing, because IIS will never satisfy a request to read an ASP file without processing it first, so no end-user can fetch an unprocessed ASP file and examine its source code. (However, see the "Problems and Limitations" section below for a bug related to this.) If you use other types of files, for example, CGI scripts, for server-side processing, it is a good idea to place these into a separate virtual directory with only execute access.

**Note **By default, IIS permits read, but not execute, access to the root Web of a server. Installation of VID and the FrontPage Extensions will not alter this setting. If you plan to use ASP pages in the root Web, you must use the Internet Service Manager to add execute access to the root Web.

SSL

SSL (Secure Sockets Layer) is a protocol that is used to protect HTTP transmissions from unwanted eavesdropping. VID supports the optional use of SSL over the client/server link at design-time and when performing a Web Copy operation. You choose to use an SSL connection when you create a new Web project or initiate a Web Copy operation. When an SSL connection is in use, all HTTP requests and replies are encrypted before transmission and decrypted after receipt. Except for this encryption/decryption step, all VID operations take place exactly as they would over a non-SSL connection. You must obtain and install an SSL certificate on your Web server before you can initiate an SSL connection. For more information on obtaining and installing an SSL certificate on an IIS server, see Securing Your Site Against Intruders in "Further Reading" below.

Problems and Limitations

FAT File System

It should be clear from the proceeding sections that the FrontPage security model relies heavily on the ability to assign ACLs to files and directories on the server. Of the file systems available on Windows systems, only one supports file-level ACLs. Windows NT 4.0 can be used on NTFS (New Technology File System) or on FAT (File Allocation Table). NTFS supports file-level ACLs; FAT does not. Windows 95 uses only the FAT file system, while Windows OSR2 uses FAT or FAT32, a variant of FAT. Neither supports file-level ACLs. The obvious recommendation in light of this is to use Windows NT with NTFS for your Web server.

Using the FAT file system on your Web server will mean that you have no design-time security. When using Windows NT with IIS or the Peer Web Server (a variant of IIS for Windows NT Workstation), all server operations will be accomplished impersonating the anonymous user. This means that all file modifications and Microsoft Visual SourceSafe™ operations will be attributed to the anonymous user when you examine the File Property page in VID. It also means that exclusive editing will not be enforced on projects under source control, since all files are checked out to a single user, the anonymous user. When using Windows 95 and the Personal Web Server, all server operations will be performed as the user logged into the Windows 95 workstation. (The Personal Web Server cannot run without a user being logged on.)

Using the FAT file system means that you cannot restrict browsing to only registered users, thus eliminating fine-grained run-time security. However, both the Personal Web Server for Windows 95 and Peer Web Server for Windows NT Workstation permit some coarse-grained control of security by setting share-level access on virtual directories.

Anonymous Global.asa Processing

VID supports Web applications that make full use of Active Server Pages. One of the features of an Active Server Page is the automatic processing of an application's Global.asa file, if present, at the start of a new session with that application. As described previously, with anonymous browsing permitted for the WWW service in IIS, IIS first attempts to satisfy HTTP requests as the anonymous user, and if that fails, only then does it proceed as an authenticated user. Due to a bug in ASP processing, an access failure during Global.asa processing does not trigger authentication. In this case, any script contained in Global.asa is not executed. The implication of this problem is that the anonymous user account must have read access to Global.asa in order to assure that the scripts in it are executed.

As mentioned, FrontPage removes read access from all the files in a Web when that Web is set to allow only registered users browse access. The only work-around in this case is to use the Windows NT Explorer to manually change the ACLs on Global.asa, granting the anonymous user read access.

Lack of Credentials

As discussed above, after authenticating a user using the Windows NT Challenge/Response protocol (NTLM), the server does not have a copy of a user's credentials (name/password pair). This limits the degree to which the server can impersonate the user. The limitation of most importance to VID authors concerns access to network resources, that is, resources located on other servers.

Connecting to a SQL Server database using network named pipes requires credentials, and so will fail if anonymous access is disabled and NTLM is used for authentication.

There are two relatively easy workarounds:

If SQL Server is running on the same machine as IIS, you can use a local named pipe connection instead of a network named pipe connection. This makes Windows NT not care about the switch to an impersonated user context when accessing the pipe. To do so, in the SQL Server connection string of the Global.asa file, change the keyword "SERVER=machinename" to "SERVER=(local)." The server name "(local)" with parenthesis is a special keyword to the SQL Server ODBC driver.
You can use a non-authenticated protocol between IIS and SQL Server, such as TCP/IP sockets. This will work when SQL Server is running on either the same machine or a different machine than IIS. To do so, you must configure both the SQL Server and the SQL Server client on the IIS machine.

a) To configure SQL Server to listen on TCP/IP sockets as well as named pipes, run SQL Setup. From the Microsoft SQL Server 6.5—Options screen, select Change Network Support and Continue. Check the entry for TCP/IP Sockets (leave Named Pipes also checked) and then click OK. Accept the default Named Pipe name and TCP/IP Socket number. Exit SQL Setup. Stop and restart SQL Server.

b) To configure the SQL Server client on the IIS machine (it doesn't matter if it is the same or a different machine as SQL Server), select SQL Client Configuration Utility. Select the Net Library tab and choose "TCP/IP Sockets" as the Default Network. Press Done. IIS should now use TCP/IP sockets when connecting to SQL Server.

Fetching Unprocessed ASP Files

The shipped version of IIS 3.0 exposes a potential security breach. Appending a trailing dot to the file name in a request for an ASP file delivers the file unprocessed, if the file is in a virtual directory with read access enabled. There is a patch available for downloading from the Microsoft Web site that fixes this problem (ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postSP2/iis-fix/).

VSS Issues

VID supports the use of Visual SourceSafe (VSS) on a FrontPage Web server to safeguard Web content and manage file contention during Web authoring. The way this works has some security implications.

When VSS is installed on a server along with the FrontPage Extensions, FrontPage detects the presence of the VSS COM interface and provides some basic source control operations, for example, check in and check out, to clients. The way these are exposed in the VID and FrontPage client user interface differs, but the way they are accomplished on the server is the same. When a client requests an operation, such as check out, the FrontPage Extensions call into VSS via the COM interface. At this point the FrontPage Extensions are impersonating the user who is logged in at the client. Thus that user must have proper access rights to perform the VSS operation.

VSS does not participate in the Windows NT domain security model; it keeps its own private list of users and their access rights for each VSS database (one per server). For this reason, it is imperative that the name of each user who can perform VID or FrontPage authoring operations against any Web on a server be entered into the VSS user list for that server's database. This is done using the Visual SourceSafe 5.0 Admin program, which is installed when VSS is installed. Each user's Windows NT domain name should be entered with Read-Write rights and no password, using the Add User command. In addition, the name assigned to the anonymous user account, which is by default ISUR_<MACHINENAME>, should be added to the VSS user list with Read-Write rights and no password.

If the proper user accounts have not been added to the VSS user list on a server, VID users will see two typical symptoms:

For Webs on the server that are not under source control, the Enable Source Control command will be disabled.
For Webs already under source control, all the files of the Web will appear to be individually not under source control.