I have a PHP app that accesses SQL 2000 database via ODBC function calls. It works on my win95 machine, however I have a new 2000 pro machine that has the latest version of php on it (I've tried every other version down to the php4.0.4 which is on my 95 machine.)

When I try to run the app on the 2000 box I get this error:

Warning: SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'., SQL state 28000 in SQLConnect in c:\inetpub\wwwroot\AS400MainQuery.php on line 32

I have the DSN set up the same way as my 95 machine and have tested it with Access and it seems to function correctly. When I test the same script on the 2000 box with it being pointed at an MSSQL 7.0 server it works fine.

If I switch to the mssql functions the script doesn't work on either win2kpro or win95 against the MSSQL2k server but works fine against MSSQL7.0.

It seems that the problem is with the combo of my either the win2kpro or win2kserver as the other combos win95/win2kserver/mssql2k server and win2kpro/winnt4.0/mssql7.0 seem to work fine.

Suggestions?

    Is the 2000 box on the same domain as the SQl server?

    Have you tried using SQL authentication instead of NT?

      Is the 2000 box on the same domain as the SQl server?

      Yes.

      Have you tried using SQL authentication instead of NT?

      Yes, and I get the same result. I suspect it has to do with 'Security Account Delegation' Something to do with my 2000pro IIS as one server and the SQL Server 2000 as another server. I'm not terribly familier with win2k server permissions and it seems as though I ought to be able to just shut this off. However, I am still fighting with the other half of our IS dept for administrator rights on that server so it's hard to experiment with server settings when you have to have someone else do it for you.

      Thanks, though.

        As so often happens after beating my head against the wall for days, I happen upon the solution to my problem and it's relatively simple and obvious. As a reference I'll include it here:

        You must also set up IIS to use the authentication method that you want. Open ISM, then open the properties for the Web site or virtual directory that's hosting the application. On the Directory Security tab, click Edit to display the Authentication Methods dialog box that Figure 4 shows (the box looks slightly different in NT 4.0). Notice in Figure 4 that both the Anonymous access and Integrated Windows authentication check boxes are selected. To turn off anonymous access to the Web site, clear the Anonymous access check box and click OK.

        If you've configured a SQL Server system to use Windows authentication and you don't clear the Anonymous access check box for IIS, users who attempt to access your Web application will receive an error message like the one that Figure 5 shows. This error explains that the user account being used to access the SQL Server database is IUSR_MYSERVER, which is the default anonymous-access account for IIS running on a server named MYSERVER. The IUSR account typically doesn't have permissions to access SQL Server—hence, the error. To prevent this error, you could grant the IUSR account SQL Server permissions. However, prohibiting anonymous access to a Web site is a better solution because it forces users to have a valid Win2K or NT 4.0 account to gain access to the site and to SQL Server.

          2 months later

          I had the same error message as you are. I checked ISM and clear check box of allow anonymous access. But still got the same error message.

          Any suggestion?

            Unfortunately not. I am just running this within our network and I managed to get it working at one point but then some users from another subnet logged in and the whole authentication process died. Every time one of these users logged in it caused an error that generated a dialogue box that required someone on the server to click the 'ok' button. Essentially the whole win2k box was frozen until you clicked that button. Even so, you had to reboot the server because the WWW service was locked and couldn't be stopped.

            Eventually I ran out of hair to pull out, switched the anonymous login back on and went back to my original scheme of providing security from within my PHP application.

              Write a Reply...