When you use Active Server Pages (ASP) with ActiveX Data Objects (ADO), you’re operating in the client/server world of Internet Information Server (IIS) and the HyperText Transfer Protocol (HTTP) as well as using database APIs such as ODBC and OLE DB. Let’s take a look at the sequence of events that occur when a client, such as Internet Explorer, requests an ASP page. This discussion at this point does not take into account the complexities of authentication on the ASP page.
1. Internet Explorer (or other browser) requests an ASP page by sending an HTTP Request message to IIS.
2. IIS recognizes that the requested page is an ASP page because it has an .asp file extension, and sends the asp file to asp.dll for processing.
3. ASP parses the server-side script and loads ADO via a call to Server.CreateObject(…) which invokes the ADO COM interfaces and associated DLLs.
4. ADO in turn processes the ADO commands in the script and while doing so can connect to various database resources using both the ODBC/OLE DB database API’s.
5. ODBC/OLE DB will connect to database resources (either files or connections to running servers) using various drivers to provide the database information to ADO.
6. Database driver/provider returns data to ODBC/OLE DB.
7. ADO returns the requested database information to ASP.
8. ASP returns the completely parsed server-side script to IIS in HTML format.
9. IIS returns raw HTML to client.
10. Internet Explorer (or other browser) parses HTML and runs any client-side scripting code and displays result to the user.
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 talk, 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 An ASPApplication in the IIS online documentation ( http://YourServerName/iishelp ).
Let’s begin with a quick overview of the client authentication types. Internet Information Server supports three authentication schemes: Anonymous, Basic (Clear Text), and Windows NT® Challenge/Response. Each of these authentication methods is enabled or disabled through the Default Web Site or virtual root Properties page in the Internet Information Server “Snap-In” in Microsoft Management Console (MMC). A typical IIS configuration has Anonymous enabled, as well as either, or both, of the other methods. Anonymous authentication is the least secure method, while Basic and Windows NT Challenge/Response 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 Internet Explorer supports 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 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 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.
· Microsoft OLE DB Provider for ODBC Drivers error '80004005' when attempting to open an ADO connection.
· ASP code that worked fine when the database was located on the IIS Server no longer works when the SQL or Access database is moved to a remote machine.
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 SQL Server on a remote machine or an 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.
1. Change the Anonymous Logon account on the IIS server from IUSR_MACHINE to a domain account that is recognized by both machines and has sufficient permissions to the resource. In addition, be sure that this account has the log on locally user right on the IIS machine. Recall that the Anonymous Logon account is configured through Internet Service Manager. 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.
2. Add a local account to the remote machine that exactly matches the username and password of the IUSR_MACHINE account on the IIS machine, and give this account access to the database. 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.
· ASP 0115 – A Trappable error has occurred when attempting to use ADO. (Note: This is only one of the possible causes of the ASP 0115 error.)
· ASP pages that use ADO or other components suddenly no longer function properly.
· ASP pages that work on a development machine don’t work properly on a production Web server.
Another type of problem can be attributed to permission settings, where 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 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 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 Debugging Techniques section that follows provides a few techniques that will assist you in locating the cause of the permissions problem.
1. The first step is to determine if you really are seeing a permissions problem. A good test is to temporarily add the Anonymous Logon account (IUSR_MACHINE) to the administrators group using User Manager. This gives the IUSR_MACHINE account administrative privileges on the machine. If this causes ASP to function properly, you are almost certainly dealing with a permissions issue. 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.
2. Another useful technique is to attempt to use ADO or the component in question from some other environment such as Visual Basic. This produces nearly the same effect as the first technique because Visual Basic operates in the security context of the user logged on to the workstation. If the component works from Visual Basic but not from ASP, a permissions problem is likely.
3. Once you have concluded that you are dealing with a permissions problem, you need to locate the files that don’t have adequate permissions. This consists of systematically searching the directory tree to locate the problem files. Some users choose to give full control to the entire directory tree, and then work backwards to tighten down security until the error occurs. Since you can’t easily undo this change, consider creating a temporary account to use for this test. Set this account as the Anonymous Logon account and give it Full Control to the entire tree. Once you’ve located the problem, you can simply remove the account without affecting the permissions of the other user accounts on this machine.
4. Another approach for locating files that do not have sufficient permissions is to use the security auditing functions provided by Windows NT. (This technique is explained in more detail in the Appendix.)
5. If you believe you are dealing with a permissions problem in the registry, you can use Regedt32.exe to examine permissions on the various registry keys. In particular, you may want to look at ODBC, Jet, ADO, and other keys that are relevant to the problem. If you have a machine that is working properly, try comparing key permissions between the two machines. 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.
· Server.CreateObject fails with an ASP 0177: Server.CreateObject Failed error.
· The component works fine on the same machine from Visual Basic or from some other tool.
· The component works fine with ASP on other machines.
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 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 which the authenticated user does not have access to.
1. Although giving the IUSR_MACHINE account administrative permissions is useful in this scenario, a better first step is to invoke the component from some other tool such as Visual Basic. This approach is preferred because it checks for permission problems, as well as verifying that the component is registered properly on the server. If the component cannot be created from Visual Basic, you are probably not dealing with a permissions problem at all.
2. If you believe you are dealing with a permissions problem, check permissions on the component and any dependent files such as other DLLs.
3. If you still are unable to track down the problem, you may need to resort to other means such as a systematic permissions search, or Windows NT File and Object Auditing.
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.
Here is a list of great troubleshooting tools which are great for file and registry access issues.
FileMon - Filemon for Windows NT is a Windows NT device driver/GUI combination for NT 3.51 and NT 4.0 that together log and display all file system activity on a Windows NT system. The device driver is a type of driver known as a filter driver. It layers itself above the file system drivers so that it can see I/O requests pass down to, and return from, file systems such as NTFS, FASTFAT, CDFS, NWRDR, RAM drives and any other type of file system driver that has an associated drive letter.
Download from http://www.sysinternals.com
RegMon - Regmon for Windows NT is a device driver/GUI combination for NT 3.51 and NT 4.0 that displays all registry activity taking place on a Windows NT System. It is a demonstration of the power and utility of a new technique we've developed called kernel-mode system call hooking. This technique allows for many internal NT operations to be monitored and altered. An article describing this technique was published in the January 1997 issue of Dr. Dobb's Journal.
Download from http://www.sysinternals.com
NTHandleEx - Ever wondered which program has a particular file or directory open? Now you can find out. HandleEx is a GUI/device driver combination that together show you information about which handles and DLLs processes have opened or loaded. Its display consists of two sub-windows. The top always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that HandleEx is in: if it is in handle mode you’ll see the handles that the process selected in the top window has opened; if it is in DLL mode you’ll see the DLLs that the process has loaded. HandleEx also has a powerful search capability that will quickly show you which processes have particular handles opened or DLLs loaded.
Download from http://www.sysinternals.com
1. Start User Manager. From Start|Run this is usrmgr <machinename>.
2. On the User menu, click Select Domain. Select the domain for the local machine by entering the name of the local domain.
3. Enable auditing by clicking Audit… on the Policies menu. Select Audit These Events and then check the Failure box for File and Object Access.
4. Next you need to tell Windows NT which directories and files you want to audit. Open the properties dialog for the specified directory or file in Windows Explorer, click the Security tab, and click the Auditing… button. Now use the Add... button to add the name of the user you want to audit (in this case IUSR_MACHINE). Next, pick the desired combination of Replace Auditing on Subdirectories and Replace Auditing on Existing Files. Finally, select Failure for the desired events.
5. Using Internet Explorer, attempt to view the ASP pages that cause the permissions violation to occur.
6. Open the Windows NT Event Viewer and choose Security from the Log menu. The security log should show all failed attempts by the specified account to any files that have auditing enabled.
Note: When you have finished troubleshooting, turn off auditing for best system performance. See the Windows NT online help for more details on auditing.
At setup, IIS creates an anonymous account for unauthenticated Web connections. When file security is not required, the request is processed by the server in the security context of this anonymous user account. The anonymous user account can access only files and applications for which permission has been granted.
Files and applications can be restricted to access only by specific users or groups. This requires obtaining and verifying the user name. IIS can be configured to require basic HTTP authentication. Users are prompted for a name and password, which are compared to accounts in the Windows NT Server directory. However, the name and password in basic authentication are passed as clear text over the network, and can potentially be intercepted by a network packet sniffer.
IIS also provides support for Windows NT Challenge/Response (NTLM) authentication, which uses a cryptographic technique to authenticate the password; the actual password is never sent across the network. Since every connection is mapped directly to a Windows NT user account, Internet users also get the benefit of a single logon to all servers and services in the Windows NT domain, just as they do on an Intranet.
Additionally, IIS supports using X.509 certificates for access control. A certificate verifies a user’s identity in much the same way as a driver’s license or corporate identification card does. They are issued by a trusted certificate authority, either within an organization or a public company like Verisign.
IIS provides a set of open APIs that developers can use to create filters that authenticate users based on custom rules. This gives administrators the flexibility to control access using any authentication scheme or external directories.
On the Internet, each server and client (or proxy for a group of clients) has a specific Internet address called the "IP address." IIS can be configured to grant or deny access to specified IP addresses. This gives the administrator the ability to exclude users by denying access from a particular IP address, or prevent entire networks from accessing the server. Conversely, administrators can choose to allow only specific IP addresses to have access to the service.
The Windows NT File System (NTFS) was designed to provide security features required for high-end Web servers in both intranet and Internet scenarios. The NTFS file system supports discretionary access control and ownership privileges that are important for the integrity of critical business data. NTFS allows administrators to assign permission to individual files, not just to folders and directories. By using the NTFS file system for the content made available by IIS, administrators can help ensure only the right individuals have access to individual files on the Web server.
Once the user's IP address restrictions are satisfied, the user name or password is validated, and the service's virtual directory permissions are completed, IIS will then attempt to access the specified resource (based on the URL) using the security context of the authenticated user. This allows Windows NT Server to enforce access control based on NTFS permissions on the resources, offering administrators extremely granular control over sensitive resources and data.
Windows NT identifies each user by a globally unique security identification (SID), not by user name. This SID is mapped in the background to the user’s account name, so file permissions and group accounts are managed using a friendly name but applied using the SID. When an account is deleted, all ACLs and group assignments for the account are also removed. SIDs and synchronization ensures that an account later created with the same user name cannot inherit permission to the old account.
Impersonation
IIS accesses all files and runs all applications in the security context of the user requesting the file, restricting what can be accessed. This is either the anonymous user account specified in the server administration, or an authenticated user account. This means that a CGI application or component in a user directory cannot access data or services restricted to other users or the server administrator. Moreover, application developers have much more flexibility in developing applications than they would if all codes were required to run in the security context of the server itself.
Internet Information Server allows the administrator to set read-only or execute-only permissions on the virtual directories. For every request, IIS examines the URL and type of request and ensures that the permissions set on the virtual directory or virtual root are honored. This will ensure that users cannot read files with execute-only permission or execute files with read-only permissions.
