#sql-server
#sql-server
Вопрос:
У меня возникла некоторая проблема с подключением SQL Server через аутентификацию kerberos. Ниже приведены сведения о моей конфигурации.
У меня есть 2 машины. M1 (контроллер домена) amp; M2 (установлен SQL server)
1) В M1 я установил AD и настроил kerberos.
2) В M2 я установил SQL server 2012 и настроил службу на использование учетной записи домена, которую я создал в AD.
3) Включил TCP / IP и изменил порядок клиентских протоколов на TCP / IP в качестве первого, который следует учитывать
3) Установил Kerberos Configuration Manager на M2 и создал SPN, подобный
MSSQLSvc / полное доменное имя
MSSQLSvc / FQDN:TCPPORT
4) В M1 -> AD -> Для моей учетной записи домена SQL server я добавил SPN, а также добавил делегирование для аутентификации kerberos (для любой службы).
5) В M2 я запускаю этот запрос в SQL Management Studio, и он всегда возвращает результат как NTLM.
выберите auth_scheme из sys.dm_exec_connections, где session_id=@@spid
Кто-нибудь может сообщить мне, где я ошибаюсь и чего мне не хватает. Спасибо за вашу помощь /
Комментарии:
1. Прежде всего, если вы подключаетесь к локальному экземпляру SQL Server (то есть вы локально вошли в систему), схема аутентификации всегда NTLM и никогда Kerberos. Это немного вводит в заблуждение, но по сути это означает, что не нужно связываться с сервером Kerberos для проверки учетных данных. (Именно поэтому такие логины выполняются успешно, даже если SQL Server не настроен должным образом для авторизации в домене.) Попробуйте подключиться с другого компьютера и позаботьтесь о том, чтобы в этом случае использовать фактическое имя компьютера (не TCP-адрес или DNS-псевдоним); при этом должно отображаться
auth_schemeofKERBEROS.2. Обратите внимание, что включение делегирования обычно не требуется — это происходит только при проверке подлинности с несколькими переходами и связанных серверах (иногда). По веским причинам это не включено по умолчанию, и, как правило, это неправильное решение большинства проблем, включая аутентификацию с помощью SQL Server. Даже там, где это есть, к этому нужно относиться с осторожностью.
3. И последнее, но, конечно, не менее важное: обычно нет необходимости заставлять SQL Server использовать учетную запись домена. Если он не будет получать доступ к ресурсам за пределами локального компьютера (наиболее распространенный сценарий), запуск его под локальной учетной записью (например, виртуальной учетной записью ) упрощает управление учетными записями. До тех пор, пока его SPNS настроен должным образом, он сможет выполнять проверку подлинности домена. Использование учетной записи домена, безусловно, имеет свои преимущества, но становится потенциальной проблемой безопасности, если она используется совместно между серверами.
4. Большое спасибо. Проверил соединение с третьего компьютера, и kerberos работает нормально.