Власні веб-служби з підтримкою XML застаріли. У майбутньої версії Microsoft SQL Server ця можливість буде видалена. Уникайте використання цієї можливості в нових розробках і заплануйте зміна існуючих додатків, в яких вона застосовується.
При створенні або зміні кінцевих точок HTTP за допомогою інструкцій CREATE ENDPOINT або ALTER ENDPOINT необхідно вказати тип перевірки автентичності користувачів, що посилають кінцевій точці запити HTTP SOAP. Додаткові відомості див. У розділах CREATE ENDPOINT (Transact-SQL) і ALTER ENDPOINT (Transact-SQL).
Використовуючи інструкції CREATE ENDPOINT і ALTER ENDPOINT, можна налаштувати підтримку перевірки автентичності Kerberos наступними способами:
Якщо заданий параметр AUTHENTICATION = KERBEROS, Kerberos є єдиним засобом перевірки автентичності HTTP.
Якщо заданий параметр AUTHENTICATION = INTEGRATED, для перевірки автентичності HTTP кінцевої точки можна використовувати такі типи перевірок достовірності: NEGOTIATE, KERBEROS і NTLM. Якщо заданий параметр NEGOTIATE, клієнт і сервер намагаються перевірити справжність за допомогою протоколу Kerberos. Якщо клієнт не підтримує протокол Kerberos або переговори неможливі, для перевірки автентичності знову використовується NTLM. Щоб клієнт не буде переходити назад на NTLM при використанні NEGOTIATE, рекомендується встановити для клієнта параметр AUTHENTICATION = KERBEROS на кінцевій точці.
Щоб підтримувати обопільну перевірку достовірності Kerberos, екземпляр SQL Server повинен зв'язати ім'я учасника-служби (SPN) з обліковим записом, від імені якої він буде виконуватися, наприклад з локальної системної обліковим записом або обліковим записом користувача домену. Характерні особливості реєстрації імені учасника-служби екземпляром SQL Server визначаються типом облікового запису служби, під якою він виконується. Якщо SQL Server виконується під локальної системної обліковим записом, імена приватників-служб повинні реєструватися під ім'ям комп'ютера. Якщо SQL Server виконується під обліковим записом користувача домену, імена учасників-служб повинні реєструватися під обліковим записом користувача домену.
Щоб зв'язати ім'я учасника-служби з обліковим записом, від імені якої виконується екземпляр SQL Server, використовуйте засіб підтримки Windows SetSPN.exe. Це засіб додає імена учасників-служб для імені комп'ютера, на якому виконується екземпляр SQL Server під обліковим записом користувача домену Windows, яка зберігається в Active Directory. У цьому сценарії за допомогою програми SetSPN.exe можна додати два імені SPN: одне для імені NetBIOS, а інше для повного імені учасника-служби.
Наприклад, якщо виконати програму SetSPN.exe з примірника SQL Server, запущеного на MyComputer. з обліковим записом, під якою виконується екземпляр SQL Server, будуть пов'язані два імені учасника-служби, які повинні бути додані в каталог:
Нижче перераховані найбільш поширені проблеми, пов'язані з реєстрацією імен SPN для протоколу Kerberos.
Ім'я SPN не з'являлися.
Якщо ім'я SPN не з'являлися, перевірка достовірності Kerberos буде працювати на локальному комп'ютері, на якому виконується екземпляр SQL Server, але не буде пройдена на віддалених комп'ютерах клієнтів.
Ім'я SPN зареєстровано більше одного разу.
Існує кілька ситуацій, коли адміністратор може повторити імена учасників-служб в каталозі домену, що призведе до помилки при перевірці автентичності Kerberos. Ці звіти включають такі відомості.
Зміна облікового запису домену, під якою виконується екземпляр SQL Server
Якщо запустити програму SetSpn.exe, коли екземпляр SQL Server виконується під одним обліковим записом домену (наприклад ДОМЕН \ Пользователь1), а потім змінити обліковий запис SQL Server (наприклад DOMAIN \ Пользователь2), коли SetSPN.exe запускається повторно, одне і теж ім'я учасника -служби буде вставлено в каталог для обох облікових записів.
Установка декількох екземплярів SQL Server, які виконуються під різними обліковими записами
Якщо встановити кілька екземплярів SQL Server, запустити кожний з них під різними обліковими записами і виконати програму SetSpn.exe для кожного екземпляра, в каталог будуть вставлені однакові імена SPN для кожного облікового запису SQL Server. Це відноситься до екземплярів, які виконуються і під обліковим записом користувача домену, і під локальний системний обліковий запис.
Видалення і переустановка примірника SQL Server під іншим користувачем
У кожній з цих ситуацій проблема полягає в тому, що кінцева точка HTTP буде переходити назад на перевірку справжності NTLM, до тих пір поки помилка не буде виправлена. Зазвичай проблему вдається вирішити шляхом виявлення в каталозі повторюваних або старих імен SPN і видалення їх вручну.