I'm working with a laptop at the moment that needs to connect to a SQL server at our school. Basically, our school has a domain and is a high school [duh], but we also have another part of the school, the International Student Program office, not really a part of the school, but part of the district as a whole, they just happen to have their offices at the school I'm running the network for. So I also purchased and built them their own server [currently not their own domain, they still are a member of our schools domain to make things easier for them to use our services etc.]
So at the moment, they have MS SQL Express installed on there, and because our firewall is covering our network, but that one needs to run external services and have it's own IP address, it's just behind our external switch. One network interface in the server is connected to the switch, getting a real world IP address, and one network interface is connected to the internal high school network. The external interface is protected via a software firewall installed on the server.
So the connection they need [if you're following me so far ] is a connection between their MS Access frontend on their laptops they use in the office [and now take home, which is where the problem is], and the servers. So at the moment, they use integrated authentication with Windows, so they only have to log into Windows, boot up the program, and it works and allows them into the main login screen for the program. SQL connection made in the background. Even when they're inside, I have their ODBC driver for SQL Server 2005 pointing to EXTERNAL.IP.ADDRESS\SQLEXPRESS,PORT. So in theory, their connection goes outside the high school network, U-Turning at the switch, and going into the external port on the server. Makes sense? Good, because it works. When they're in the building. When they LEAVE the building, it also works, using cached credentials. Or at least....it did. Up until last week. Nothing on the server has changed, except for the recent Windows Security updates applied, otherwise the settings are the exact same.
I'm actually at home right now, with one of the receptionists laptops from the international student program, since I manage their IT too, and I have the laptop here, and I logged in as OUR_SCHOOL_DOMAIN\Her Account, and logging into Windows worked of course, because of cached credentials, but when I go to test the ODBC connection in ODBC Data Source Administrator, I can't connect using Integrated Authentication. But I CAN log in if I change the authentication to SQL, and enter a temp SQL account I've made for testing, tests complete successfully and I can view the databases. So that's not an issue. When I try to use Integrated Windows Authentication though, here's what I get:
SQL Network Interfaces: The Local Security Authority cannot be contacted.
Cannot Generate SSPI Context.
These are apparently very common, and I've googled around and found a lot of information on them, including one from Microsoft saying I shouldn't use cached credentials. But why did it work before? I had it working for a good 4 months, and it suddenly stopped. She was able to go home, do her work, log in via cached credentials, connect to the SQL server, with no problems. Any ideas of what may have changed or gone wrong? I can't think of anything else besides maybe an update securing something with credentials. Not sure. Also, we don't have a VPN so we can't route the laptop through that. It's just using a port forward right now. Again, it's always worked before now.
Thanks for any suggestions!
:: EDIT ::
I ended up making her a SQL account, it works inside, we'll see if it works from home without prompting her for extra passwords, it shouldn't since it's built into her DSN file now.
Last edited by link470; 3rd February 2009 at 06:05 PM.
There are currently 1 users browsing this thread. (0 members and 1 guests)