Alexander Gladchenko

Не первый раз встречаюсь с тем, что настройка делегирования для связанных серверов (так в русском BOL принято называть Linked Server) вызывает трудности, которые не так легко разрешимы, как это кажется на первый взгляд. Сама настройка описана в статье Настройка связанных серверов для делегирования, там всё выглядит просто и понятно… Однако, очень часто вместо ожидаемого результата, возвращается сообщение об ошибке:

Сообщение 18456, уровень 14, состояние 1, строка 1
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

Небольшие исследования путём поиска в интернет легко приводят к искомым материалам по разрешению этой проблемы, которые настолько подробны, что отпугивают очень многих…

На самом деле не нужно пугаться, всё решается очень просто. Основной проблемой, о которой как правило забывают, является регистрация т.н. Service Principal Name (SPN) в Active Directory (AD). Дело в том, что в зависимости от этих настроек могут использоваться разные схемы аутентификации, причём, пользователи об этом даже не будут догадываться. Однако, из двух возможных схем, для успешного делегирования подходит только Kerberos, а NTLM сможет обеспечить правильное делегирование только при запуске клиентского приложения непосредственно на том сервере, где настраивается связанный сервер. Нас же интересует такая схема аутентификации, которая изображена на рисунке ниже и которая подразумевает использование базового делегирования Kerberos.

Наверное, свою роль играет ещё и то, что зарегистрировать SPN можно не штатными средствами контроллера домена, а предварительно скачав пакет средств поддержки операционной системы, например тот, который описан в статье базы знаний Майкрософт за номером 892777. Из этого пакета понадобиться только одна утилита, которая называется "Setspn.exe". Из названия очевидно, для чего она предназначена.

Формат вызова утилиты такой: setspn [switches data] computername

Ключи:
   -R = перерегистрация HOST ServicePrincipalName (Пример:    setspn -R computername)
   -A = добавляет произвольный SPN (Пример:   setspn -A SPN computername)
   -D = удаляет произвольный SPN (Пример:  setspn -D SPN computername)
   -L = печатает список зарегистрированных SPN (Пример:  setspn [-L] computername)
Примеры использования:
setspn -R daserver1 (Будет зарегистрирован SPN "HOST/daserver1" и "HOST/{DNS of daserver1}")
setspn -A http/daserver daserver1 (Будет зарегистрирован SPN "http/daserver" для компьютера "daserver1")
setspn -D http/daserver daserver1 (Будет удалён SPN "http/daserver" для компьютера "daserver1")

В статье Troubleshooting Kerberos Delegation очень подробно описаны условия, при которых делегирование возможно и представлены графические схемы, облегчающие понимание всех необходимых требований. Вот схема для нашего случая:

Из этой схемы видно, что SPN нужно зарегистрировать для обоих серверов.

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

1. Убедитесь, что клиент и оба сервера поддерживают протоколы TCP и/или именованные каналы. Кроме того, все они должны входить в один и тот же домен, а имя входа пользователя домена (для которого мы будем настраивать делегирование) должно быть заведено логином на оба сервера, будем их называть SQLSERVER1 (на рисунках это Front-end или Middle Tier) и SQLSERVER2 (Back-end). Кроме того, эта учётная запись и те записи, от имени которых запускаются службы СУБД на обоих серверах, не должны быть помечены, как "Account is sensitive and cannot be delegated".

2. Как это показано в статье Настройка связанных серверов для делегирования, создадим Linked Server:

   EXEC sp_addlinkedserver 'SQLSERVER2', N'SQL Server'
   EXEC sp_addlinkedsrvlogin 'SQLSERVER2', 'true'

   Для проверки можно исполнить следующий запрос:

   SELECT * FROM sys.servers where name=' SQLSERVER2' -- для сервера SELECT uses_self_credential as delegation FROM sys.linked_logins as L, sys.servers as S where S.server_id=L.server_id and S.name=N' SQLSERVER2' -- для проверки делегирования = 1

3. Убедитесь, что с клиента Вы можете подключиться к обоим серверам. Например так:

   osql -E -S SQLSERVER1
   osql -E -S SQLSERVER2

4. Убедитесь, что доменным учётным записям, от имени которых запускаются SQL Server-а на обоих серверах, присвоены SPN. Присвоение показано ниже, на примере SQLSERVER1:

   C:\Program Files\Support Tools>setspn -A MSSQLSvc/ SQLSERVER1.ИМЯДОМЕНА.ru:1433 ИМЯВХОДАСЛУЖБЫСУБД

   В случае успешного результата выдаются следующие сообщения:

   
   Registering ServicePrincipalNames for CN= ИМЯВХОДАСЛУЖБЫСУБД,OU=SQL Server accounts,
   OU=System accounts,DC= ИМЯДОМЕНА,DC=ru
           MSSQLSvc/ SQLSERVER1. ИМЯДОМЕНА.ru:1433
   Updated object
   
   
   
   

   После этого стоит проверить, что аутентификация KERBEROS, а транспорт TCP. Выполните следующий запрос, заменив переменную на соответствующий идентификатор:

   select net_transport, auth_scheme from sys.dm_exec_connections where session_id=@@spid

5. Убедитесь, что при подключении к SQLSERVER1 Вы можете получить выборку для запроса к связанному серверу:

   select * from SQLSERVER2.master.dbo.sysdatabases

Ещё одно руководство по настройке делегирования, автор которого Gregory A. Larsen: Setting Up Delegation for Linked Servers

Другие статьи на эту тему:

Setspn Overview
Устранение неполадок при появлении сообщения об ошибке «Cannot generate SSPI context»
Kerberos and SQL Server interaction with SPNs

Вы, наверное, уже обратили внимание на то, что сегодня стал доступен объявленный ещё в начале месяца CU#3, и уже объявлен выпуск CU#4. Поскольку уже накопилась некоторая статистика выхода кумулятивных наборов заплат, доступных публично или по требованию, можно составить некоторое представление о том, как же работает объявленная не так давно инкрементная модель выпуска заплаток и сервисных пакетов.
Incremental Servicing Model (далее ISM) была введена командой Microsoft SQL Server для улучшения схемы предоставления устраняющих обнаруженные проблемы заплаток. Она распространяется на все коммерческие редакции Microsoft SQL Server 2005, и на все версии Microsoft SQL Server 2000, за исключением (почему то) Workgroup Edition. Описание ISM дано в статье базы знаний Майкрософт за номером: KB935897.
Команда разработчиков SQL Server поставила перед собой цель предоставлять в рамках ISM более высококачественные, чем ранее заплатки и в более приемлемые сроки, которые должны быть известны заранее, в соответствии с публикуемыми заблаговременно сообщениями о графике выпуска заплат. Именно плановостью выпуска заплат новая модель, работу которой мы уже наблюдаем, отличается от прежней приоритетной модели. Кроме того, существующую но ещё не выложенную в открытый доступ заплату можно получить по запросу в течении 8 часов (на практике значительно раньше), что позволяет существенно сократить время устранения критических проблем. Если же политика администрирования серверов баз данных не допускает установки не прошедших полный цикл тестирования заплат, Вы всегда будет знать сроки выхода этой же заплаты, но прошедшей все необходимые тесты и практические испытания. Практика показывает, что сообщения о составе и сроке выхода следующего кумулятивного пакета заплат появляются в виде статьи базы знаний Майкрософт ещё до выхода очередного такого пакета. Т.о. получение и внутреннее тестирование, опытную и промышленную эксплуатации приложений после установки пакета заплат можно планировать заранее, что весьма критично, если система работает в режиме 365х24х7 и технологических окон для проведения подобных работ в году не много.
Механизм поставки заплат для SQL Server достаточно гибок и рассчитан на возможность получения заплат практически сразу после окончания первоначальных внутренних тестов Майкрософт. Смысл простой, чем меньше заплата тестировалась, тем она менее доступна. После окончания тестирования, она попадает в открытый доступ в виде очередного совокупного, кумулятивного набора заплат. Получается, что критическую заплатку можно получить очень быстро и это может быть оправдано, если риски, создаваемые обнаруженной проблемой, превышают возможные проблемы с заплатой, связанные с не полным циклом её тестирования. Кроме того, не всегда проблему легко обойти, а также речь может идти о заплатке, которая была выпущена по инициированному клиентом инциденту. Такие критические исправления, которые можно получить по требованию, называются "Critical on-demand" (COD). Заплатки такого вида могут запрашиваться кем угодно, и если Вы её запросили и получили, то Вы становитесь практически тестером этой заплаты. Однако, команда SQL Server оставляет за собой право решения, давать вам доступ к заплате, или нет, и может затеять с вами переписку по поводу необходимости установки заплат или среды, в которой эти заплаты Вы планируете применять. Кроме того, в доступном для загрузки клиентами пакете может быть не одна, а несколько заплат.
Следующий тип пакетов заплат, это заплатки по требованию: "On-demand" (OD). Суть её та же, сто и у COD, но она не является критической. Поставляется она всем и на тех же условиях, что и COD.
Чаще всего нам приходится иметь дело с кумулятивными наборами заплат, последние из которых на сегодняшний день по размеру скачиваемого файла превышают 117Мб. В терминологии команды SQL Server их принято называть: "Cumulative update" (CU). Они тоже доступны для заказа кому угодно. Однако, для таких пакетов заплат уже заявлена периодичность выпуска, которая не должна быть меньше раза за два месяца. Поскольку пакет кумулятивный, это значит, что он (как и OD) включает в себя все критические и хорошо проверенные заплаты, которые были выпущены со времени выхода продукта и для всех его языковых версий (этим определяется размер файла для скачивания). Периодичность появления новых CU зависит от частоты запросов клиентов новых заплаток. Существуют некие пороговые значения по числу клиентских запросов заплат, после достижения которых "пекут" новый CU, COD или OD.
И последний тип пакета заплат - это обобщающий дистрибутив: "General distribution release" (GDR). Этот вид пакетов заплат не поставляется по запросу, а тиражируется через центр загрузки, Microsoft Update и т.п. Состав пакета определяется командой SQL Server, хотя текущая практика говорит о том, что все включаемые в GDR заплаты были выпущены в составе предшествующих CU или COD.
Пакеты заплат не призваны заменить сервисные пакеты, они выпускаются в качестве дополнений для тех, кому входящие в пакеты заплаты необходимы. Как и сервиспаки, пакеты заплаты могут быть деинсталлированы в любое время.
На представленном ниже рисунке показан пример графика ISM, на котором отмечен выход продукта (Product RTM) и выход первого сервисного пакета (SP1 RTM). Вы можете видеть два цикла поддержки (после выхода и после первого сервиспака), которые образуют непрерывную схему поддержки, чего не позволяла достичь предыдущая схема поставки исправлений. Кроме того, в новая модели практически исключена необходимость сдвига сроков выпуска заплат.

Пример письма, полученного сегодня мной в ответ на заказ CU#3 для платформы х86 (письмо пришло через 3 часа после заполнения формы):

-----Original Message-----
From: nahotfx@microsoft.com [mailto:nahotfx@microsoft.com]
Sent: Tuesday, August 21, 2007 2:59 PM
To: mssqlhelp@rambler.ru
Subject: Hot fix ready for your incident SRX1042395550ID

Hello,

The hot fix for your issue has been packaged and placed on an HTTP site for you to download.

WARNING: This fix is not publicly available through the Microsoft website as it has not gone through full Microsoft regression testing. If you would like confirmation that this fix is designed to address your specific problem, or if you would like to confirm whether there are any special compatibility or installation issues associated with this fix, you are encouraged to speak to a Support Professional in Product Support Services.

The package is password protected so be sure to enter the appropriate password for each package. To ensure the right password is provided cut and paste the password from this mail.

NOTE: Passwords expire every 7 days so download the package within that period to insure you can extract the files. If you receive two passwords it means you are receiving the fix during a password change cycle. Use the second password if you download after the indicated password change date.

Package:
-----------------------------------------------------------
KB Article Number(s): 936081, 936252, 937100, 938086, 938243, 938363, 938712, 938962, 939285, 939537, 939562, 939563, 939564, 939871, 939942, 940126, 940128, 940129, 940140, 940149, 940160, 940210, 940220, 940221, 940223, 940260, 940269, 940281, 940370, 940371, 940372, 940373, 940375, 940376, 940377, 940378, 940379, 940382, 940384, 940386, 940389, 940390, 940545, 940935, 940937, 940939, 940942, 940943, 940944, 940945, 940948, 940949, 940962, 941184
Language: All (Global)
Platform: i386
Location: (http://hotfixv4.microsoft.com/SQL%20Server%202005/sp2/Yukon_SP2_CU3/9.00.3186.00/free/322810_intl_i386_zip.exe)
Password: @_RFC8p

NOTE: Be sure to include all text between '(' and ')' when navigating to this hot fix location!

Thanks!