0

Just have had an interesting situation with a remote database server which I did not think happened.

The setup is server A is a domain controller in the main network, and server B is on a remote network connected back via VPN. Server B has SQL Server 2008 on it. There is an application running on server B that for the purposes of this discussion, just inserts/queries the database every minute.

Today the VPN dropped out for a tad over 30 minutes due to some network problems between the 2. Database queries are done using trusted_connection=sspi; credentials, and worked for maybe the first 20 minutes while the VPN was down. However eventually the queries started failing with the error Cannot generate SSPI context.

I would imply from this that the sql server is caching the credentials are OK and hitting this normally, but invalidating them after some time. Because the connection back to the DC was down, it couldn't refresh the cache and started failing queries.

I would like the remote database to work for as long as required (up to hours) without the VPN or DC being available.

I have tried looking around but not found any information on the situation, so am asking if anyone knows if there is a setting somewhere I can tweak to relax the rules related to this? Or is the only solution to deploy a DC on the remote network too, which seems a little overkill given this scenario would be the only benefit.

1 Answer 1

4

Deploy a domain controller. You need one if you want the services on server B to continue to function if the VPN is down.

Coasting on the lifetime of a kerberos ticket that can't renew, even if you increase the lifetime of that ticket, is not a solution; even if it lasted for a week, you'd have no guarantee that it wouldn't be due to expire 10 minutes after the VPN dropped.

3
  • Thanks for your feedback. Can I install a read-only DC or will it need to be a full DC to remove the reliance back to head office?
    – mike
    Feb 11, 2013 at 0:19
  • @mrnye It should be a full DC to be able to handle user authentication with another DC not available - you can allow some password hashes to be replicated to the RODC for authentication, but for the sake of redundancy you probably want a writable DC. Feb 11, 2013 at 0:22
  • Thanks for that info. The RODC instances sounded interesting, but it is unfortunate they have these limitations. I'll deploy a proper DC instance and hopefully we will see a few improvements on the remote network.
    – mike
    Feb 11, 2013 at 5:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .