Назад | Перейти на главную страницу

Зависимость SQL Server от контроллера домена

Просто была интересная ситуация с удаленным сервером базы данных, о которой я не думал.

Настройка такова, что сервер A является контроллером домена в основной сети, а сервер B находится в удаленной сети, подключенной обратно через VPN. На сервере B установлен SQL Server 2008. На сервере B работает приложение, которое для целей этого обсуждения просто вставляет / запрашивает базу данных каждую минуту.

Сегодня VPN отключился чуть более чем на 30 минут из-за некоторых сетевых проблем между 2. Запросы к базе данных выполняются с использованием доверенное_соединение = sspi; учетные данные и проработал, возможно, первые 20 минут, пока VPN не работал. Однако в конце концов запросы начали давать сбой с ошибкой Не удается создать контекст SSPI.

Из этого я бы подразумевал, что сервер sql кэширует учетные данные в порядке и обычно выполняет это, но через некоторое время делает их недействительными. Поскольку обратное соединение с контроллером домена было прервано, он не смог обновить кэш и начал отказывать в запросах.

Я хочу, чтобы удаленная база данных работала столько времени, сколько потребуется (до часов), без доступа к VPN или DC.

Я попытался осмотреться, но не нашел никакой информации о ситуации, поэтому спрашиваю, знает ли кто-нибудь, есть ли где-то параметр, который я могу настроить, чтобы смягчить правила, связанные с этим? Или это единственное решение для развертывания DC в удаленной сети, что кажется немного излишним, учитывая, что этот сценарий был бы единственным преимуществом.

Разверните контроллер домена. Он вам понадобится, если вы хотите, чтобы службы на сервере B продолжали работать, если VPN не работает.

Продление срока действия билета Kerberos, который невозможно продлить, даже если вы увеличите срок его действия, не является решением; даже если бы это длилось неделю, у вас не было бы никаких гарантий, что срок его действия не истечет через 10 минут после отключения VPN.