Как должны выглядеть мои записи SPN для каждого экземпляра SQL?

8

Я нахожу противоречивую информацию о том, как именно отформатировать имена участников-служб (имена принципов службы), чтобы получить правильные соединения Kerberos, и сколько мне нужно для каждого экземпляра SQL.

Этот документ MS за 2017 год содержит следующее:

Начиная с SQL Server 2008, формат SPN изменяется для поддержки аутентификации Kerberos по TCP / IP, именованным каналам и общей памяти. Поддерживаются следующие форматы SPN для именованных экземпляров и экземпляров по умолчанию.

  • Именованный экземпляр: MSSQLSvc/FQDN:[port|instancename]
  • Экземпляр по умолчанию: MSSQLSvc/FQDN:port|MSSQLSvc/FQDN

Новый формат SPN не требует номера порта . Это означает, что многопортовый сервер или протокол, который не использует номера портов, может использовать аутентификацию Kerberos.

Я взял этот последний абзац, чтобы означать, что мне нужна только одна запись, одна из следующих:

  • Именованный экземпляр: MSSQLSvc/sqlbox1.mydomain.org/instance2
  • Экземпляр по умолчанию: MSSQLSvc/sqlbox1.mydomain.org

Это противоречит этому более раннему (2011 г.) документу MS не только о номере порта, но и о том, какое имя использовать:

Чтобы создать имя участника-службы, вы можете использовать имя NetBIOS или полное доменное имя (FQDN) SQL Server. Однако необходимо создать имя участника-службы как для имени NetBIOS, так и для полного доменного имени .

Когда я смотрю на имена SPN, которые уже существуют в моей среде, я вижу большое количество комбинаций, некоторые серверы имеют до 4 записей:

  • MSSQLSvc/sqlbox1
  • MSSQLSvc/sqlbox1:1433
  • MSSQLSvc/sqlbox1.mydomain.org
  • MSSQLSvc/sqlbox1.mydomain.org:1433

Кажется, даже собственный менеджер конфигурации Kerberos от MS хочет сгенерировать последние две версии (с соответствующей обфускацией):

введите описание изображения здесь

Аналогично для существующих именованных экземпляров я вижу странное сочетание, некоторые из которых почти наверняка недействительны:

  • MSSQLSvc/sqlbox1:1522
  • MSSQLSvc/sqlbox1:instance2
  • MSSQLSvc/sqlbox1.mydomain.org:1522
  • MSSQLSvc/sqlbox1.mydomain.org:instance2
  • MSSQLSvc/sqlbox1.mydomain.org/instance2
  • MSSQLSvc/sqlbox1.mydomain.org:1522:instance2

Так как же должны выглядеть мои DSN для экземпляров по умолчанию и именованных экземпляров, если я просто использую TCP в своей среде?

Должен ли я включить порт или нет? Или включить один с портом и один без?

Использовать только полное доменное имя или мне нужны записи только с именем Netbios? Или это было бы, только если бы мы использовали именованные каналы (которые мы не являемся)?

(Для контекста мы запускаем SQL 2005–2014, некоторые кластеризованные, другие автономные. Подключение осуществляется только через TCP, именованные каналы отключены в диспетчере конфигурации. Мы будем исправлять / создавать их вручную, а не позволять учетной записи службы SQL создавать их при запуск сервера.)

sql-server  kerberos  spn 
— BradC
источник
1
Есть ли какая-то конкретная причина, по которой вы хотите управлять именами SPN самостоятельно, а не позволять SQL (и его служебной учетной записи) делать это для вас?
— Nic
1
Что касается SPN, если он работает, имеет ли значение формат? Я второй комментарий @Nic
— Боб Климс
@Nic Поскольку это потребовало бы предоставления нескольким десяткам учетных записей служб новых прав Active Directory, наш администратор Active Directory сказал, что однократным ручным добавлением легче управлять. Также были найдены некоторые ссылки, в которых говорится, что забавные вещи могут происходить, когда SPN пытаются синхронизироваться между несколькими контроллерами домена, когда они динамически добавляются / удаляются при запуске / останове / отказе кластера. Все , что сказал, позвольте мне спросить: когда вы делаете позволить учетной записи службы , чтобы добавить SPN при запуске, что же это выглядит? Одиночная запись с полным доменным именем и портом? Или без порта? Или две записи?
— BradC
@BobKlimes Ну, некоторые из них не работают, вот в чем проблема. Я думаю, нет ничего плохого в том, чтобы иметь больше записей, чем необходимо, а просто пытаться понять, какие из них на самом деле делают работу.
— BradC
1
@BradC У меня определенно были проблемы с отказоустойчивостью кластера и несколькими контроллерами домена. Это были мои единственные имена участников-служб, созданные вручную.
— Боб Климс

Ответы:

5

Если вы используете только TCP / IP для подключения к своим экземплярам, ​​вам нужны только указанные порты. Имена экземпляров используются при подключении к экземплярам SQL по протоколам именованных каналов. К сожалению, статья MS не дает права сказать, какой формат требуется для какого протокола, но она получена из (многих тестов в моей среде) и следующей статьи MS :

Для именованных каналов и подключений к общей памяти имя участника-службы в формате MSSQLSvc / FQDN: instancename используется для именованного экземпляра, а MSSQLSvc / FQDN используется для экземпляра по умолчанию.

Что касается полных доменных имен против имен NETBIOS, я буду рекомендовать полные доменные имена, поскольку они не так подвержены проблемам, если вы сталкиваетесь со случайными проблемами DNS-сервера.

Сняли с моего блога по этому вопросу, форматы должны выглядеть следующим образом:

введите описание изображения здесь

Ссылку на источник от MS можно найти здесь .

Теперь, чтобы сделать ваш день администратора сети (например, конфигурация OU, которая позволяет для самостоятельной регистрации SPN)

Ваш сетевой администратор может создать подразделение в домене, которое содержит все ваши учетные записи службы SQL Server, которые можно настроить таким образом, чтобы учетная запись службы могла создавать имя участника-службы для себя и для себя одного. Метод в основном следующий основан на блоге Райана Рейса , но имеет некоторые незначительные изменения, так что чрезмерные гранты не выполняются.

Этот процесс описывает создание OU в домене, который позволяет учетным записям в нем самостоятельно регистрировать свои собственные SPN:

  1. В качестве учетной записи с повышенными правами на домен откройте ADSI Edit (adsiedit из командной строки)
  2. Щелкните правой кнопкой мыши на ADSI Edit -> Connect to ...
  3. Подключиться к контексту именования по умолчанию
  4. Перейдите к / Создать контейнер OU учетные записи служб, которым вы хотите предоставить права SPN
  5. Щелкните правой кнопкой мыши OU -> Свойства
  6. Нажмите на Безопасность Tab
  7. Нажмите Дополнительно кнопку
  8. Выделите SELF и нажмите « Изменить ...» или, если специальный пользователь SELF не отображается в списке имен групп или пользователей, нажмите « Добавить» и введите « SELF» для имени объекта.
  9. Нажмите на вкладку Свойства
  10. Выберите Объекты пользователя Descendant в раскрывающемся списке рядом с Применить к: Примечание. Это небольшая корректировка шагов, описанных в блоге Райана, по причинам, лучше описанным в ServerFault / StackExchange. .
  11. Проверьте Разрешить флажок рядом со следующим:
    • Читайте servicePrincipalName
    • Написать servicePrincipalName
  12. Нажмите Ok (в окне ввода разрешений)
  13. Нажмите Ok (в окне «Дополнительные параметры безопасности»)
  14. Нажмите Ok (в окне свойств OU)
  15. Добавить учетные записи служб служб, на которых запущены SQL Server, в подразделение
  16. (Необязательно) Перезапустите службы SQL Server работающие под указанной учетной записью
  17. Наслаждайтесь лакомствами

После выполнения описанных выше действий соответствующий контейнер OU теперь настроен так, что любая добавленная в него учетная запись сможет регистрировать и удалять имена участников-служб для себя и для себя. Это точно правильное количество разрешений, поскольку эти учетные записи не смогут вытеснить имена участников-служб, зарегистрированные другими учетными записями.

Цель перезапуска SQL Server на шаге 16 - убедиться, что имена участников-служб зарегистрированы должным образом. SQL попытается удалить все зарегистрированные имена участников-служб при завершении работы и добавить их при запуске, поэтому перезапуск действительно нужен только в том случае, если в данный момент не существует имен SPN для указанной службы SQL Server.

Последнее замечание по этому подходу заключается в том, что, если вы запускаете SQL Server в традиционной конфигурации Failover Clustered Instance (FCI), НЕ рекомендуется добавлять учетную запись службы этого экземпляра в это подразделение на каждые 2443457 КБ. .

Мне действительно нужно опубликовать часть 2 моей серии Kerberos ...

— Джон Айсбренер
источник
Это не « Потомки» , а « Потомки» .
— Исаак Клейман
1

Когда служба SQL Server создает имя участника-службы, она создает два для каждого экземпляра. Это формат, который он использует.

Экземпляр по умолчанию:

MSSQLSvc/servername.domain.com
MSSQLSvc/servername.domain.com:1433

Именованный экземпляр:

MSSQLSvc/servername.domain.com:54321
MSSQLSvc/servername.domain.com:instancename

Для именованных экземпляров, если вы создаете SPN вручную, вам потребуется статический порт вместо динамического порта по умолчанию.

— Боб Климс
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.