Проверка подлинности Kerberos не работает со связанными серверами в SQL Server 2012

8

Я настраиваю среду DEV / TEST, используя 2 сервера SQL Server под управлением SQL Server 2012 на Windows Server 2012. Мы переходим с SQL Server 2005 на Windows Server 2008, где у нас уже есть этот корректный запуск.

В SQL Server 2012 аутентификация Kerberos не работает.

Каждый сервер имеет свою собственную учетную запись Active Directory, которая имеет права «Записывать имена участников службы» и «Чтение имен участников службы», предоставляемые через Active Directory - пользователи и компьютеры. Всякий раз, когда я подключаюсь к серверам SQL Server 2005 и запускаю:

SELECT net_transport, auth_scheme 
FROM sys.dm_exec_connections 
WHERE session_id = @@SPID;

Я вижу:

net_transport    auth_scheme
TCP              KERBEROS

Когда я выполняю тот же запрос к моим новым экземплярам SQL Server 2012, я вижу:

net_transport    auth_scheme
TCP              NTLM

Если я использую SetSPN -Q MSSQLSvc/*запрос активного домена для имен основных участников службы, я вижу в списке оба сервера 2005 и 2012 годов, точно так же, как и имя сервера.

Например:

MSSQLSvc/SERVERa2005.domain.inet
MSSQLSvc/SERVERa2005domain.inet:1433
MSSQLSvc/SERVERb2005.domain.inet
MSSQLSvc/SERVERb2005domain.inet:1433
MSSQLSvc/SERVERa2012.domain.inet
MSSQLSvc/SERVERa2012domain.inet:1433
MSSQLSvc/SERVERb2012.domain.inet
MSSQLSvc/SERVERb2012domain.inet:1433

Что еще мне нужно сделать, чтобы включить аутентификацию Kerberos для SQL Server 2012? Похоже, что в Books Online больше нечего сказать, кроме того, что SPN должны быть настроены. Которые, очевидно, они есть. Журналы ошибок SQL Server на обоих компьютерах 2012 года говорят:

2012-12-10 14:55:47.630 The SQL Server Network Interface library 
                            successfully registered the Service Principal Name (SPN)
                            [ MSSQLSvc/SERVERa2012.domain.inet ] for the SQL Server
                            service. 

2012-12-10 14:55:47.630 The SQL Server Network Interface library 
                            successfully registered the Service Principal Name (SPN) 
                            [ MSSQLSvc/SERVERa2012.domain.inet:1433 ] for the SQL 
                            Server service. 

2012-12-10 14:55:47.590 SQL Server is attempting to register a Service 
                            Principal Name (SPN) for the SQL Server service. 
                            Kerberos authentication will not be possible until a 
                            SPN is registered for the SQL Server service. This is an
                            informational message. No user action is required.

— Макс Вернон
источник

2

Мои любимые сбои Kerberos вызваны компьютерами, часы которых разошлись "слишком далеко". Убедитесь, что они синхронизированы с официальным временем домена.

— Дарин пролив

1

Также убедитесь, что часовой пояс правильный.

— Дейв Маркл

8

Работать с Active Directory всегда очень весело. Единственная самая важная вещь здесь - понять, что вы имеете дело с распределенными данными, для распространения которых может потребоваться время.

У рассматриваемых SQL-серверов их имя было изменено как часть процедуры обновления; мы заменили существующую машину (SQL01) под управлением SQL Server 2005 на новую машину (SQL03) под управлением SQL Server 2012. SQL03 - это имя новой машины, когда я первоначально установил ее в домене. В SQL01 существующее имя участника-службы было связано с одной учетной записью домена, которую мы использовали для нескольких серверов SQL Server 2005. Поскольку рекомендуется использовать только одну машину под любой учетной записью домена, я создал новую учетную запись и настроил SQL03 для работы с этой учетной записью. название аккаунта. После вывода исходного SQL01 из строя и переименования SQL03 в SQL01 возник конфликт имен SPN.

Я использовал утилиту SetSPN.exe для удаления конфликтующего имени участника-службы (на старой учетной записи домена) - и он все еще не работал. В этот момент я больше ничего не делал и перешел к другим предметам. Когда я вернулся через 30 минут, аутентификация KERBEROS работала. Мне просто нужно было подождать, пока изменения SPN распространятся среди наших контроллеров домена.

Я использовал SetSPN -L DOMAIN\Accountи сравнивал эти выходные данные, SetSPN -Q MSSQLSvc/Machine.domain.inet:1433чтобы найти дубликаты имен SPN, а затем использовал их SetSPN -D MSSQLSvc/Machine.domain.inet:1433 DOMAIN\Accountдля удаления старых имен SPN.

— Макс Вернон
источник

2

Дополнительную информацию об устранении ошибок Kerberos можно найти по следующим ссылкам

— Питер Вандивье
источник