This is a common question about the user identity that an ISAPI runs with.

Question:

I wanna to connect to the database(sql 2000 server) in my ISAPI.I tried the connection code in a separate vc++ application it works,but when I tried to use this code in ISAPI the web site takes very long time trying to open & it didn't :(

Thx for any help u can offer
Regards,

Answer:

The user identity which runs the VC++ application probably had access to the database on SQL 2000 server, while the user identity which runs the same binary code but as an ISAPI DLL did NOT have access.

The solution is very straight forward. You either:

  1. Configure IIS to run the ISAPI DLL with an user identity that has access to the database on SQL 2000 server
  2. Change the database on SQL 200 server to allow access to the user identity that runs the ISAPI DLL

Many users have the following common misconception about user identity and code execution:

  1. They first login and run as a local system administrator, take a piece of C code, compile it, and they run it on the server commandline and see that it works perfectly.
  2. Then, they take that same piece of code, compile an ISAPI DLL out of it, and use the browser to invoke the ISAPI DLL and see that it fails
  3. Finally, they wonder why the same piece of code works when launched from the commandline but fails from IIS, swearing that it must be an IIS bug since it worked from the commandline.

A problem here is that the user assumes that the user identity which launches interactive programs from the commandline is the same user identity that IIS uses to run ISAPI. More than likely, that assumption is not correct. Remember, HTTP is a stateless client-server protocol, so the user identity running the browser has NO relevance to the user identity running code on the server. It all depends on the identity the server chooses to execute code, and that can depend on how the client authenticates to the server.

  1. In the case of the commandline program, the user identity is likely the interactive logged in user - like the local system administrator - that the shell uses to launch the new commandline program process.
  2. In the case of the ISAPI, it completely depends on the authentication scheme configured in IIS (well, ISAPI Filters/Extensions may alter user identities for custom authentication). I will only consider IIS behavior from this point onward since ISAPI behavior is arbitrary and the system administrator is responsible for knowing and managing its behavior).

If you allow Anonymous authentication in IIS, then IIS will use the configured anonymous user for that URL (default value is IUSR_machinename) to execute the ISAPI DLL. If you use any other IIS authentication protocol, it will be whatever the remote browser negotiated through authentication with IIS. Further explanation is located here: http://blogs.msdn.com/david.wang/archive/2005/06/29/IIS_User_Identity_to_Run_Code_Part_2.aspx

Depending on the authentication protocol and browser configuration, you may/not see a login dialog or you may automatically login with credential selected by the browser. If you want control of the behavior, you have to configure the browser - not the server. Remember, it is the browser that decides whether to auto-login or pop up the login dialog - the server keeps sending back 401 responses if the authentication handshake is incorrect/incomplete.

There are many other security concerns potentially involved, such as delegation, double-hop, RevertToSelf(), worker process identity, etc, but for that discussion, we need more details than a simple question about why calling SQL fails as an ISAPI but works on the commandline.

//David