Соединения MSSQL Server SPN: Linux к MSSQL Server (setspn, kinit, проверка подлинности kerberos)

После того, как администратор AD добавил имя участника-службы SQL Server с помощью инструмента setspn, сервер Linux не может использовать имя участника-службы с помощью драйвера ODBC MS SQL Server 18 с ошибкой «[HY000] [Microsoft] [Драйвер ODBC 18 для SQL Server] Поставщик SSPI: Сервер не найден в базе данных Kerberos"

У меня есть работающая аутентификация на основе Kerberos для одного сервера (dev), и я пытаюсь реализовать ту же настройку подключения к новому серверу (rel). Чтобы настроить dev, мой администратор AD установил имя участника-службы сервера с помощью инструмента настройки имени участника-службы:

setspn -S MSSQLSvc/dev:dev_sql_port domain\dev_service_user

И мы можем убедиться, что spn был создан с помощью

setspn -Q MSSQLSvc/dev*

В рекламном домене есть много контроллеров домена (около 7, что определяется с помощью команды adcli info domain.org с сервера Linux). Сначала мы не могли подключиться к dev по ODBC, но через несколько месяцев заработала следующая картина:

kinit
Password for [email protected]: ********

Затем следует соединение с использованием строки подключения:

Driver = {ODBC Driver 18 for SQL Server};Server=dev;Trusted_Connection=yes;Encrypt=No;TrustServerCertificate=yes

Администратор AD продублировал все из настройки dev для rel, используя правильную информацию для экземпляра rel sql server. Я могу использовать следующее для инициализации билета kerberos для нового сервера:

kinit -S "MSSQLSvc\rel:rel_port"
Password for [email protected]: ********

Однако шаблон python:

cnxn_str = ("Driver = {ODBC Driver 18 for SQL Server};Server=rel;Trusted_Connection=yes;Encrypt=No;TrustServerCertificate=yes")
cnxn = pyodbc.connect(cnxn_str)

Выдает ошибку:

Error: ('HY000', '[HY000] [Microsoft][ODBC Driver 18 for SQL Server]SSPI Provider: Server not found in Kerberos database (851968) (SQLDriverConnect)')

В конфигурацию krb5.conf внесены минимальные изменения, кроме верхнего раздела:

[libdefaults]
        default_realm = domain.org
        dns_lookup_realm = true
        dns_lookup_kdc = true

У меня есть доступ к соответствующим администраторам для внесения изменений, которые исследуются, однако мы (я) немного в недоумении, почему dev работает, почему для работы dev потребовалось несколько месяцев и почему rel не работает (пока). Прошло 2 недели с тех пор, как мы внесли изменения в отн.

Нужен весь krb5.conf, пожалуйста.

T-Heron 12.11.2022 14:38

Спасибо Ти-Херон. Обновлен krb5.conf, чтобы включить только указанные выше строки без каких-либо изменений в поведении.

Tim Grilley 14.11.2022 16:25
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
1
2
101
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Чтобы исправить это, мы определили, что в исходной инструкции rel setspn была опечатка, и что в списке setspn -L realm\rel_sql_service_account было две опечатки: одна с неправильным портом, а другая без порта. Мы использовали команды


setspn -D MSSQLSvc/rel.domain:wrong_port realm\rel_sql_service_account
setspn -D MSSQLSvc/rel.domain realm\rel_sql_service_account
setspn -S MSSQLSvc/rel.domain:right_port realm\rel_sql_service_account

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

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

T-Heron 20.11.2022 14:29

Другие вопросы по теме