Yet another SSPI Error

Yet another SSPI Error

Post by stanwalter » Wed, 12 Nov 2003 07:34:06

I've read the docs on SSPI Errors, but I still can't figure this one
out. We've got laptops running Win2k with SQL Server mobile
installed. On the LAN the server works fine, the ODBC test works
fine, and the App that uses it works fine. When disconnected from the
LAN, all three of these work again, and when disconnected from the LAN
on Broadband Internet, using the VPN client to our corporate network,
all three work fine again. The problem occurs when you are
disconnected (off-LAN) and using the App, then connect to Broadband,
the app stops working with the good old "cannot generate SSPI..." blah
blah. It is as if its happy with local security info when you're not
on a network of any kind, but if you're on a network, it insists on
being able to see our domain controllers from it, and if it can't it
won't let you in.

The primary puzzling issue is that all services are running as
LocalSystem account, and there is no domain activity required for
authentication in the app itself (and obviously none for the ODBC test
utility) but nevertheless, if you connect to a network that DOES NOT
contain our domain controllers, the app which worked minutes before
stops working (as does the test of the associated ODBC profile)

Anyone seen this?

Yet another SSPI Error

Post by stanwalter » Wed, 19 Nov 2003 01:31:52

For anyone else who may have this problem, we have come up with a
workaround. Still looking for a proper solution, but in the

* Create a unique name on your network, put it in
C:\winnt\system32\drivers\etc\hosts with IP address

* Edit the ODBC configuration and replace "(local)" with the name you
created in the hosts file step above

* Click "Apply" then finish and test, it works fine.

This reinforces our theory that some sort of strange name-resolution
problem is at fault here.

Good Luck


Yet another SSPI Error

Post by kevm » Fri, 28 Nov 2003 10:07:35

The SSPI error indicates that we're unable to impersonate the client over
TCP. If you don't have DNS name resolution working properly and/or can't
reach the DC, then we're not going to be able to impersonate the client.
One easy alternative is to switch over to using Named Pipes. Otherwise,
you can tshoot the problem with Netdiag.exe and/or make network traces of
the client attempting a connection. If this is too much, you can open a
support case & we'll assist you.


Kevin McDonnell
Microsoft Corporation

This posting is provided AS IS with no warranties, and confers no rights.