Mike Hedley
Developer Support Engineer
Microsoft Technical Support
April 11, 1997
When you use Active Server Pages (ASP), you’re operating in the client/server world of Microsoft® Internet Information Server (IIS) and the Hypertext Transfer Protocol (HTTP). Many customers who don’t have a firm grasp of this architecture find themselves puzzled by strange errors in what seems to be straightforward code. If you’ve ever been in this situation, don’t fret. The world of ASP and HTTP can be confusing, especially when you’re new to the technology.
Let’s take a look at the sequence of events that occur when a client, such as Microsoft Internet Explorer, requests an ASP page. This discussion does not take into account the complexities of authentication on the ASP page. In our simplified discussion, the following three events take place:
Once the client receives the response, it executes any client-side script code and displays the Web page according to the HTML specification. While this process looks simple, keep in mind that the client and server could be hundreds, or even thousands, of miles apart. Therefore, when a problem arises, you must determine where the error is occurring—on the client or on the server. Equally important is understanding when each operation takes place. After ASP completes its processing in Step 2 and sends the response in Step 3, it moves on to other activities and other clients. The only way the client can recapture the server’s attention is to request another page via the HTTP protocol. In other words, there is no real connection between the client and server. This is a very important concept that must be understood. In the rest of this section, I will describe common types of problems encountered by ASP developers and demonstrate the extra effort that is often required to promote communication between the client and server.
One type of problem occurs when developers try to access server-side scripts or objects from the client or, conversely, client-side objects from the server. As an example of the first scenario, consider client-side code that attempts to access one of ASP’s intrinsics, such as the Session object. This is destined for failure because the code running in Internet Explorer has no way of accessing the object located on the server. A typical error message might appear as follows:
VBS Script Error: Object Required: Session
Now consider the second scenario, where a server-side script attempts to manipulate a client-side object. For example, suppose you use server-side scripting to populate a client-side ActiveX™ list box control. While this seems like a simple task, you must keep in mind that the HTML page, and therefore the list box, does not yet exist when the server-side code is executed. Because the list box control hasn’t been created when the server-side script is run, the following code will generate a similar “Object Required” scripting error:
<% ListBox1.AddItem Value1 %>
To accomplish this task, use server-side code to generate client-side code that will populate the list box. You should put this code in the Window_OnLoad event, where it is guaranteed to be executed by the browser after the window and its child controls are created. The following code segment demonstrates this technique. The server-side scripting code substitutes the values stored in variables Value1, Value2, and Value3 in the AddItem method calls.
<SCRIPT LANGUAGE="VBScript">
<!--
Sub Window_OnLoad()
ListBox1.AddItem "<% = Value1 %>"
ListBox1.AddItem "<% = Value2 %>"
ListBox1.AddItem "<% = Value3 %>"
End Sub
-->
</SCRIPT>
Note that if you use the HTML <SELECT> tag instead of an ActiveX control, the procedure is slightly more direct. Because a list box created with the <SELECT> tag is based on HTML code, you can use server-side scripting to create the <OPTION> tags. The following example fills an <OPTION> tag with data provided by a field in the current record from the rs record set. Since there is no object creation, you do not need to place this code inside the Window_OnLoad event.
<OPTION VALUE= "<%= rs("Name") %>"> <%= rs("Name")%>
Another common problem encountered by ASP developers involves passing client data to the server. Suppose you want users to log on to your Web application by providing his or her name and ID number. To do this, create a simple HTML page with two INPUT items in an HTML form. The user is expected to enter the name and ID and click Submit. After the user submits the requested information, ASP verifies the user’s credentials through a database query. If the information is correct, you allow access; otherwise, this user is denied access to the page. The subtle point often overlooked in this procedure is passing the information provided by the user to ASP. Recall that the only way the client can recapture the server’s attention is to request another page via the HTTP protocol. In this case, the best approach is to POST the HTML form to an ASP page. Posting the form generates an HTTP Request that invokes ASP to process the requested page. During this ASP processing, the server-side script retrieves the posted data by calling Request.Form and performs the database query and other verification logic. The following code demonstrates a simplified version of this procedure. Notice that the user information is actually posted back to the same ASP file that displays the form. This is perfectly valid, and is often more convenient than posting to a second ASP page.
<%@ LANGUAGE="VBSCRIPT" %>
<!-- FILE: login.asp -->
<HTML>
<HEAD>
<TITLE>Login Example</TITLE>
</HEAD>
<BODY>
<% IF IsEmpty(Request.Form("Name")) THEN
Response.Write "Please enter your Name"
%>
<FORM ACTION="login.asp" METHOD=POST>
<INPUT NAME="Name"
TYPE=TEXTBOX MAXLENGTH=20>
<INPUT TYPE="SUBMIT" VALUE="Submit">
</FORM>
<%
ELSE
'User verification code goes here
Response.Write "Welcome " & Request.Form("Name") & "!"
END IF
%>
</BODY>
</HTML>
If you need to pass information from ActiveX controls on the page to the server, you will need to add client-side scripting that reads the values from the controls and stores them in members of a “hidden” form, which is posted to the .asp file. Another variation of this technique is to pass the values to ASP using the query string, although this approach is limited by the length restrictions imposed on the query string by the HTTP specifications for the GET request.
As demonstrated in the preceding examples, ASP development requires a bit of creativity at times. However, keep in mind that many of these hurdles are actually imposed on ASP by the HTTP protocol and the client/server nature of Web development. If you consider some of the alternatives, I think you’ll agree that ASP is well worth the effort.
By far, the largest segment of ASP issues handled in Developer Support involves security and permission problems. In order to avoid these problems, ASP developers must have a firm grasp of IIS authentication and controlling access to pages using NTFS file permissions. Although a thorough discussion of these topics is beyond the scope of this article, I will touch on the basic concepts and highlight the typical problems ASP developers encounter. For more information about securing your ASP application, see "Securing Your ASP Application" in the Active Server Pages Scripting Guide (MSDN Library) included in the ASP online documentation.
Let’s begin with a quick overview of the client authentication types. Internet Information Server 3.0 supports three authentication schemes: anonymous, basic (clear text), and Microsoft Windows NT® Challenge/Response. Each of these authentication methods is enabled or disabled through the WWW Service Properties page in Microsoft Internet Service Manager. A typical IIS configuration has anonymous authentication enabled, as well as either, or both, of the other methods. Anonymous authentication is the least secure method, while basic authentication and Windows NT Challenge/Response authentication provide differing levels of security for your Web pages. The advantage of basic authentication is that it is part of the HTTP specification and is thus supported by most browsers. The disadvantage of basic authentication is that if someone is monitoring packets on your network, they could easily intercept and decipher your password using publicly available algorithms. This is not possible with Windows NT Challenge/Response authentication because the actual password is never sent over the wire. Instead, the browser returns a custom token that satisfies the server’s authentication request.
Although NT Challenge/Response is very secure, it does have a couple of limitations. The first limitation is that only Microsoft browsers support this proprietary scheme. Another limitation is that Windows NT Challenge/Response does not work over HTTP proxy connections. Because of these limitations, Windows NT Challenge/Response may not always be the best choice for an Internet server, however it is often ideal for intranet use. As you can see, choosing an authentication method is a trade-off in security verses flexibility.
Now, let’s discuss the authentication process. Before IIS returns a requested page to a client, it first verifies that the client has permission to view the page. Although you can restrict permission to a page by turning off Read and Execute permissions on its virtual root in IIS, we will assume that both Read and Execute permissions are granted in IIS for the virtual root. The preferred method of restricting access to individual pages is to use the Windows NT File System (NTFS) file permissions to control which users can view the page. Before returning a page to the client, IIS checks the NTFS file permissions on the page to see if the current user is allowed access to the file. In order to know who the current user is, you must understand the authentication process used by IIS. When you configure IIS for anonymous authentication, you must provide a username and password for the anonymous logon account. By default, this account is set to a user called IUSR_MACHINE, where MACHINE is the machine name of the Web server. IIS attempts to authenticate the anonymous logon account by checking to see if the IUSR_MACHINE account has permission to view the file. If the NTFS permissions on the file do not allow IUSR_MACHINE access to the requested page, IIS returns an "HTTP 401 Unauthorized" status code to the browser. At this point, the browser attempts to authenticate the user using one of the other authentication methods. If Windows NT Challenge/Response is used, the browser automatically returns the appropriate information to satisfy the authentication request. The user is not prompted for a username and password unless the server does not recognize the username provided by Windows NT Challenge/Response. If basic authentication is used, the user is prompted for his or her username and password. IIS then checks the user’s credentials against the access permissions on the requested page, and either returns the page to the browser or returns an access denied response.
Now that we have covered the basics of authentication, let’s return to ASP troubleshooting. The important point of this section is that who you are at any given time in your ASP scripts depends on the authentication scheme used. If a user has been authenticated using either the basic or Window NT Challenge/Response scheme, then server-side scripts and components run in the security credentials of the person logged on to the client machine. If the user has been authenticated as the anonymous logon account, which is usually the case, ASP scripts and components run in the security credentials of IUSR_MACHINE, or whichever account you have designated as your anonymous logon account. If you take away only one piece of information from this article, please remember that ASP scripts are typically executed in the security context of the IUSR_MACHINE account. This concept is important because it is the root of many problems ASP developers encounter.
There is a wide range of problems that occur if the authenticated user does not have adequate permissions to complete a given task. This goes beyond having permissions on .asp files. Errors also occur if the authenticated user does not have sufficient permissions on other files such as custom components, system dynamic-link libraries (DLLs), and even registry keys. Unfortunately, these problems can exhibit a wide range of symptoms and error messages, so they are difficult to diagnose. In the following sections, I describe the three most common classifications of permission problems and provide some debugging techniques that you can use to track down these problems.
One of the most common types of problems occurs when ASP attempts to access resources located on remote machines. A good example of this is using ADO to access either Microsoft SQL Server on a remote machine or a Microsoft Access .mdb file located on another Windows NT machine. The problems stem from the fact that ASP is operating in the context of the IUSR_MACHINE account. On servers that are not primary or backup domain controllers, the IUSR_MACHINE account is a local account. Since this local account is not recognized on the remote machine, access is denied to the database.
The two most common workarounds for this problem are:
Note If you later decide to change back to the IUSR_MACHINE account, be sure that the password provided in Internet Service Manager matches the password provided for this account in the User Manager tool. If the passwords do not match, you will encounter "Access Denied" errors.
Note This workaround is not recommended because it involves maintaining two separate accounts. If the passwords get “out of sync” at some point in the future, access will be denied to the database, and errors will occur.
Another type of problem can be attributed to permission settings—when components such as ADO simply don’t function properly. The root of these problems is often restricted NTFS permissions that don’t provide sufficient privileges to the IUSR_MACHINE account. If the same ASP code works on a different machine, or is used to work on the current machine, this is a strong indication of some sort of configuration problem such as restricted permissions. For example, many customers we speak to in Developer Support indicate that their ASP application works fine on their development machine, but does not work on their production Web server. This is due to the fact that most companies like to restrict access to production servers as much as possible. While this is a good practice, care must be taken to ensure that ASP is able to function properly. What typically happens is that NTFS file permissions are restricted on various directories to the point that IUSR_MACHINE cannot access the required files. This is a frequent problem because many administrators don’t realize the important role that the IUSR_MACHINE account plays in the world of ASP. ADO often falls victim to this problem because it depends on many DLLs that are located in various directories on your hard drive. In particular, ADO relies on many Open Database Connectivity (ODBC) DLLs and other database drivers that are located in the WINNT and System32 directories. ADO also depends on certain registry keys that may not be readable by the anonymous logon account if permissions are set incorrectly. In addition, some database drivers attempt to write to the registry, thus requiring write access for the anonymous logon account. The following section provides a few techniques that will assist you in locating the cause of the permissions problem.
Note When you have finished debugging, be sure to remove the IUSR_MACHINE account from the administrators group to minimize the security risk on your server.
Note Although Windows NT includes registry auditing tools, this topic is not discussed here due to the complexity of the procedure and the danger involved with modifying the registry.
Other permission problems occur when ASP tries to create server-side components. The causes, symptoms, and debugging techniques are very similar to the previous discussion. The problems arise because the authenticated user does not have permission to invoke the Component Object Model (COM) object. In the simplest scenario, the authenticated user doesn’t have access to the component’s .dll or .exe file. In many cases, however, the component depends on other DLLs that the authenticated user does not have access to.
While the previous sections only touch on the most common permissions issues, I hope that you have gained an appreciation for the types of problems that are caused by permissions and other security settings. With an understanding of authentication and a few debugging tools at your disposal, you should be able to work through any permissions problem that comes your way.
I hope this article has provided some useful insights that will make troubleshooting ASP applications a bit easier. With persistence and a little patience, I’m sure you’ll quickly locate the problem and move on to more important work, such as finding other exciting ways to use Active Server Pages in your business.
This appendix contains information on using Microsoft Windows NT security auditing, as well as references to other useful ASP information. Please note that security auditing requires the use of NTFS.
Note When you have finished troubleshooting, turn off auditing for best system performance. See the Windows NT online help for more details on auditing.