We are getting the dreaded SSPI error on our laptops when connecting to a broadband network away from the office. We've isolated the circumstances under which this occurs and have narrowed it down (we believe) to some sort of strange name resolution issue. If anyone has resolved anything similar to the situation below we'd be most interested in hearing what was done.

The laptops are running SQL Server v7.0. A locally installed application connects to the SQL database via ODBC TCP/IP configured to dynamically select the port in the ODBC profile.

When logged in attached to the corporate LAN, everything works fine.

When running disconnected from the corporate LAN, everything works fine.

When running disconnected from the corporate LAN, and then the user activates their broadband internet connection, the App no longer functions. This has been identified as an ODBC problem as the ODBC test no longer successfully attaches, and you cannot click "NEXT" past the second configuration screen where you specify the server name because you get the "Cannot generate SSPI Context" error message.

The ODBC profile is configured to use "(local)" in the Server Name box on ODBC configuration screen. If you add an entry to HOSTS, LMHOSTS, or both, with 127.0.0.1 and BOGUSMACHINENAME, you can then specify BOGUSMACHINENAME in the Server Name box and everything works again.

So, it appears there is some security-related name resolution issue at work here, though I can't figure out what is going on exactly. The bogus name thing is an acceptable workaround, but I'm concerned that the non-standard approach will break something in the future (or at least make someone's life miserable until they figure out what we did, when they are supporting the app years from now).

Any info appreciated.

Thanks,
Stan