This is a common question about the user identity that an ISAPI runs with.
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 offerRegards,
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:
Many users have the following common misconception about user identity and code execution:
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.
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.