У нас возникли проблемы с подключением к нашему SQL Server (2008 R2) через SSPI.
Наша команда недавно перешла от настройки на основе домена к децентрализованной настройке на основе рабочей группы. Каждый разработчик имеет доступ к VPN, которая, в свою очередь, дает им доступ к серверу базы данных, на котором работает SQL Server 2008 R2.
Ранее мы использовали проверку подлинности Windows, входя в систему с компьютеров, подключенных к домену, с помощью нашего DOMAIN\user.name имена пользователей, добавив учетные записи на удаленный сервер SQL (в рабочей группе) с идентичными именами пользователей и паролями (но не доменом) для группы безопасности Windows, и предоставив этой группе разрешения на сервере SQL.
Однако после перехода с нашего домена мы не смогли подключиться с помощью SSPI.
При попытке доступа к базе данных с помощью проверки подлинности Windows через TCP / IP мы получаем следующее сообщение об ошибке:
Ошибка входа. Логин из ненадежного домена и не может использоваться с аутентификацией Windows. (Microsoft SQL Server, ошибка: 18452)
Указание имени входа в SQL Server работает должным образом, но использование SSPI не работает. Проверяя журнал событий на стороне SQL Server, мы видим следующее:
Сбой установления связи SSPI с кодом ошибки 0x8009030c, состояние 14 при установлении соединения со встроенной безопасностью; соединение было закрыто. Причина: сбой AcceptSecurityContext. Код ошибки Windows указывает причину сбоя. [КЛИЕНТ: 192.168.xxx.xxx].
Наш управляемый хостинг-провайдер установил имя рабочей группы на номер - мы сделаем вид, что рабочая группа называется 12345678 (фактическое имя - это номер нашей учетной записи). Я уже пытался изменить местную рабочую группу на тот же номер, но это не решило проблему.
Многие из решений, предложенных другими пользователями, ссылаются на инструмент под названием setspn, и используя этот инструмент для составления списка и поиска имен участников-служб, используемых для наших учетных записей - использование этого не показывает ничего необычного.
Мы работаем над ограничением, используя:
runas /netonly /user:REMOTEPCNAME\user.name "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe"
Мы застряли в использовании этого способа аутентификации?
Одиннадцать лет назад я решил аналогичную проблему, сопоставив букву диска на моей рабочей станции с удаленной машиной и предоставив свои учетные данные на другой машине. Для вас это будет выглядеть примерно так (из оболочки CMD или PSH):
net use x: \\REMOTEPCNAME\c$ /user:REMOTEPCNAME\john.doe
Ясно, что здесь используется «административный ресурс», к которому у вас может не быть доступа. Для меня это не было проблемой, потому что я был членом группы администраторов этого ящика. Если у вас нет доступа администратора, вам, возможно, придется настроить общедоступный общий ресурс (кем-то с достаточными правами) и использовать его, что я верить может работать, хотя я еще не пробовал.
Этот трюк был довольно распространенным занятием тогда, когда домены были более редкими, а AD был в новинку. Несмотря на то, что это уже не очень распространенная вещь, я не припоминаю, чтобы слышал, что Microsoft отказалась от этого обходного пути.
Я никогда не видел, чтобы имена участников-служб использовались ни в одной ситуации, в которой не была бы настроена полноценная Active Directory. IIRC, для имен SPN требуется Kerberos, а для Kerberos нужен домен. Я подозреваю, что руководство SPN - отвлекающий маневр. Удачи.