Устранение неполадок проверки подлинности Active Directory для SQL Server на Linux и контейнеров
Область применения: SQL Server — Linux
В этой статье описаны проблемы с проверкой подлинности служб домен Active Directory с SQL Server на Linux и контейнерами. В статье представлены проверки соблюдения предварительных требований и рекомендации по успешной настройке Active Directory, а также список распространенных ошибок и шаги по устранению неполадок.
Проверка текущей конфигурации
Прежде чем приступить к устранению неполадок, необходимо проверить текущего пользователя, mssql.conf
имя субъекта-службы (SPN) и параметры области.
Получение или продление TGT Kerberos (билет на предоставление билетов) с помощью
kinit
:kinit privilegeduser@CONTOSO.COM
Выполните следующую команду, убедившись, что пользователь, в котором выполняется эта команда, имеет доступ к
mssql.keytab
:/opt/mssql/bin/mssql-conf validate-ad-config /var/opt/mssql/secrets/mssql.keytab
Дополнительные сведения о команде
validate-ad-config
см. в справке с помощью/opt/mssql/bin/mssql-conf validate-ad-config --help
команды.
DNS и обратные просмотры DNS
В результате поисков DNS по доменному имени и имени NetBIOS должен возвращаться один и тот же IP-адрес, который обычно соответствует IP-адресу для контроллера домена (DC). Выполните эти команды с хост-компьютера SQL Server.
nslookup contoso nslookup contoso.com
Если IP-адреса не совпадают, см. статью Присоединение SQL Server на узле Linux к домену Active Directory, чтобы устранить проблемы при операциях поиска DNS и обмене данными с контроллером домена.
Выполните обратный просмотр DNS (rDNS) для каждого IP-адреса, указанного в предыдущих результатах. Не забудьте включить IPv4 и IPv6-адреса, где это применимо.
nslookup <IPs returned from the above commands>
Все команды должны вернуть
<hostname>.contoso.com
. В противном случае проверьте записи типа PTR (указатель), созданные в Active Directory.Возможно, вам придется работать с администратором домена, чтобы получить rDNS. Если невозможно добавить записи типа PTR для всех возвращенных IP-адресов, можно также ограничить SQL Server подмножеством контроллеров домена. Это изменение влияет на любые другие службы, использующиеся
krb5.conf
на узле.Дополнительные сведения о обратных просмотрах DNS см. в разделе Что такое обратная зона DNS.
Проверка файла keytab и разрешений
Убедитесь, что вы создали файл keytab (таблица ключей), и что mssql-conf настроен на использование правильного файла с соответствующими разрешениями. Файл keytab должен быть доступен для учетной записи пользователя
mssql
. Дополнительные сведения см. в статье "Использование adutil" для настройки проверки подлинности Active Directory с помощью SQL Server на Linux.Убедитесь, что вы можете перечислить содержимое keytab и добавить правильные имена субъектов-служб, порт, тип шифрования и учетную запись пользователя. Если при создании имен субъектов-служб и записей keytab неправильно вводить пароли, при попытке входа с помощью проверки подлинности Active Directory возникают ошибки.
klist -kte /var/opt/mssql/secrets/mssql.keytab
Ниже приведен пример рабочего ключа. В примере используются два типа шифрования. Однако вы можете использовать один или несколько типов шифрования в зависимости от того, какие типы шифрования поддерживаются в вашей среде. В этом примере
sqluser@CONTOSO.COM
используется привилегированная учетная запись (которая соответствуетnetwork.privilegedadaccount
параметру в mssql-conf), а имя узла ДЛЯ SQL Serversqllinux.contoso.com
прослушивает порт1433
по умолчанию.$ kinit privilegeduser@CONTOSO.COM Password for privilegeduser@CONTOSO.COM: $ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: privilegeduser@CONTOSO.COM Valid starting Expires Service principal 01/26/22 20:42:02 01/27/22 06:42:02 krbtgt/CONTOSO.COM@CONTOSO.COM renew until 01/27/22 20:41:57 $ klist -kte mssql.keytab Keytab name: FILE:mssql.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 2 01/13/22 13:19:47 MSSQLSvc/sqllinux@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux:1433@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux:1433@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com:5533@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com:5533@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:55 sqluser@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:55 sqluser@CONTOSO.COM (aes128-cts-hmac-sha1-96)
Проверка сведений об области определения приложения в krb5.conf
В
krb5.conf
(расположении по адресу/etc/krb5.conf
), убедитесь, что вы предоставляете значения для области по умолчанию, сведений о области и домене для сопоставления областей. В следующем примере показан примерkrb5.conf
файла. Дополнительные сведения см. в статье "Общие сведения о проверке подлинности Active Directory для SQL Server на Linux и контейнеров".[libdefaults] default_realm = CONTOSO.COM default_keytab_name = /var/opt/mssql/secrets/mssql.keytab default_ccache_name = "" [realms] CONTOSO.COM = { kdc = adVM.contoso.com admin_server = adVM.contoso.com default_domain= contoso.com } [domain_realm] .contoso.com = CONTOSO.COM contoso.com = CONTOSO.COM
Можно настроить ограничение, чтобы SQL Server контактировал с подмножеством контроллеров домена, что полезно, если конфигурация DNS возвращает больше контроллеров домена, чем SQL Server нужно для взаимодействия. SQL Server на Linux позволяет указать список контроллеров домена, которые SQL Server контактирует в режиме циклического перебора при выполнении поиска протокола LDAP.
Вам потребуется выполнить два действия. Сначала измените
krb5.conf
, добавив необходимое количество контроллеров домена с префиксомkdc =
.[realms] CONTOSO.COM = { kdc = kdc1.contoso.com kdc = kdc2.contoso.com .. .. }
Помните, что
krb5.conf
это общий файл конфигурации клиента Kerberos, поэтому любые изменения, внесенные в этом файле, влияют на другие службы в дополнение к SQL Server. Прежде чем вносить какие-либо изменения, обратитесь к администратору домена.Затем можно включить
network.enablekdcfromkrb5conf
параметр с помощью mssql-conf, а затем перезапустить SQL Server:sudo /opt/mssql/bin/mssql-conf set network.enablekdcfromkrb5conf true sudo systemctl restart mssql-server
Устранение неполадок Kerberos
Ознакомьтесь со следующими сведениями, чтобы помочь в устранении неполадок проверки подлинности Active Directory и выявлении определенных сообщений об ошибках.
Трассировка Kerberos
После создания пользователя, имени субъекта-службы и ключей и настройки mssql-conf можно увидеть правильность конфигурации Active Directory для SQL Server на Linux, вы можете отобразить сообщения трассировки Kerberos в консоли (stdout
) при попытке получить или продлить TGT Kerberos с привилегированной учетной записью, используя следующую команду:
root@sqllinux mssql# KRB5_TRACE=/dev/stdout kinit -kt /var/opt/mssql/secrets/mssql.keytab sqluser
Если нет проблем, вы увидите выходные данные, аналогичные следующему примеру. Если нет, трассировка предоставляет контекст, о котором следует проверить.
3791545 1640722276.100275: Getting initial credentials for sqluser@CONTOSO.COM
3791545 1640722276.100276: Looked up etypes in keytab: aes256-cts, aes128-cts
3791545 1640722276.100278: Sending unauthenticated request
3791545 1640722276.100279: Sending request (202 bytes) to CONTOSO.COM
3791545 1640722276.100280: Initiating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100281: Sending TCP request to stream 10.0.0.4:88
3791545 1640722276.100282: Received answer (185 bytes) from stream 10.0.0.4:88
3791545 1640722276.100283: Terminating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100284: Response was from master KDC
3791545 1640722276.100285: Received error from KDC: -1765328359/Additional pre-authentication required
3791545 1640722276.100288: Preauthenticating using KDC method data
3791545 1640722276.100289: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2)
3791545 1640722276.100290: Selected etype info: etype aes256-cts, salt "CONTOSO.COMsqluser", params ""
3791545 1640722276.100291: Retrieving sqluser@CONTOSO.COM from /var/opt/mssql/secrets/mssql.keytab (vno 0, enctype aes256-cts) with result: 0/Success
3791545 1640722276.100292: AS key obtained for encrypted timestamp: aes256-cts/E84B
3791545 1640722276.100294: Encrypted timestamp (for 1640722276.700930): plain 301AA011180F32303231313XXXXXXXXXXXXXXXXXXXXXXXXXXXXX, encrypted 333109B95898D1B4FC1837DAE3E4CBD33AF8XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
3791545 1640722276.100295: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
3791545 1640722276.100296: Produced preauth for next request: PA-ENC-TIMESTAMP (2)
3791545 1640722276.100297: Sending request (282 bytes) to CONTOSO.COM
3791545 1640722276.100298: Initiating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100299: Sending TCP request to stream 10.0.0.4:88
3791545 1640722276.100300: Received answer (1604 bytes) from stream 10.0.0.4:88
3791545 1640722276.100301: Terminating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100302: Response was from master KDC
3791545 1640722276.100303: Processing preauth types: PA-ETYPE-INFO2 (19)
3791545 1640722276.100304: Selected etype info: etype aes256-cts, salt "CONTOSO.COMsqluser", params ""
3791545 1640722276.100305: Produced preauth for next request: (empty)
3791545 1640722276.100306: AS key determined by preauth: aes256-cts/E84B
3791545 1640722276.100307: Decrypted AS reply; session key is: aes256-cts/05C0
3791545 1640722276.100308: FAST negotiation: unavailable
3791545 1640722276.100309: Initializing KCM:0:37337 with default princ sqluser@CONTOSO.COM
3791545 1640722276.100310: Storing sqluser@CONTOSO.COM -> krbtgt/CONTOSO.COM@CONTOSO.COM in KCM:0:37337
3791545 1640722276.100311: Storing config in KCM:0:37337 for krbtgt/CONTOSO.COM@CONTOSO.COM: pa_type: 2
3791545 1640722276.100312: Storing sqluser@CONTOSO.COM -> krb5_ccache_conf_data/pa_type/krbtgt/CONTOSO.COM@CONTOSO.COM@X-CACHECONF: in KCM:0:37337
$ sudo klist
Ticket cache: KCM:0:37337
Default principal: sqluser@CONTOSO.COM
Valid starting Expires Service principal
12/28/2021 20:11:16 12/29/2021 06:11:16 krbtgt/CONTOSO.COM@CONTOSO.COM
renew until 01/04/2022 20:11:16
Включение ведения журнала Kerberos и PAL на основе безопасности
Вы можете включить ведение журнала security.kerberos
и security.ldap
для обнаружения конкретных сообщений об ошибках в PAL (уровень абстракции платформы). logger.ini
Создайте файл со следующим содержимым/var/opt/mssql/
, перезапустите SQL Server, а затем воспроизводите сбой. В журнал записываются сообщения об ошибке Active Directory и отладке /var/opt/mssql/log/security.log
PAL.
[Output:security]
Type = File
Filename = /var/opt/mssql/log/security.log
[Logger]
Level = Silent
[Logger:security.kerberos]
Level = Debug
Outputs = security
[Logger:security.ldap]
Level = debug
Outputs = security
Вам не нужно перезапустить SQL Server, чтобы изменения средства ведения журнала были выбраны из logger.ini
, но ошибки могут возникать во время инициализации службы Active Directory во время запуска SQL Server, которые в противном случае будут незамечены. Перезапуск SQL Server гарантирует, что будут записываться все сообщения об ошибках.
Журнал безопасности продолжает записывать на диск, пока не удалите изменения.logger.ini
Не забудьте отключить security.kerberos
и ведения журнала после выявления и security.ldap
устранения проблемы, чтобы предотвратить отсутствие места на диске.
Средство ведения журнала PAL создает файлы журналов в таком формате:
<DATETIME> <Log level> [<logger>] <<process/thread identifier>> <message>
Например, пример строки из журнала выглядит следующим образом:
12/28/2021 13:56:31.609453055 Error [security.kerberos] <0003753757/0x00000324> Request ticket server MSSQLSvc/sql.contoso.com:1433@CONTOSO.COM kvno 3 enctype aes256-cts found in keytab but cannot decrypt ticket
После включения ведения журнала PAL и воспроизведения проблемы найдите первое сообщение с уровнем Error
журнала, а затем используйте следующую таблицу, чтобы найти ошибку и следуйте инструкциям и рекомендациям по устранению неполадок и устранению этой проблемы.
Распространенные сообщения об ошибках
Сообщение об ошибке: "Вход не выполнен. Имя для входа принадлежит ненадежному домену и не может использоваться в рамках встроенной проверки подлинности."
Возможная причина
Эта ошибка возникает при попытке входа с помощью учетной записи Active Directory после настройки проверки подлинности Active Directory.
Руководство
Это универсальное сообщение об ошибке требует включения ведения журнала PAL для выявления конкретной ошибки.
Ознакомьтесь со следующим списком распространенных ошибок, чтобы определить возможные причины каждой ошибки, а затем следуйте инструкциям по устранению неполадок.
Сообщение об ошибке: пользователь или группа Windows NT "CONTOSO\user" не найден
Возможная причина
Эта ошибка может возникнуть при попытке создать имя входа Windows или во время обновления группы.
Руководство
Чтобы проверить проблему, следуйте указаниям, описанным в статье "Ошибка входа. Имя для входа принадлежит ненадежному домену и не может использоваться в рамках встроенной проверки подлинности. (Microsoft SQL Server, ошибка: 18452)". Включите ведение журнала PAL, чтобы найти конкретную ошибку, и устраните соответствующие неполадки.
Сообщение об ошибке: "Не удалось найти короткое доменное имя из-за ошибки"
Возможная причина
Синтаксис Transact-SQL для создания имени входа Active Directory:
CREATE LOGIN [CONTOSO\user]
FROM WINDOWS;
В команде нужно указать имя NetBIOS (CONTOSO
), но в серверной части при выполнении подключения LDAP необходимо указать FQDN домена (contoso.com
). Чтобы выполнить это преобразование, выполняется поиск CONTOSO
в DNS для разрешения в IP-адрес контроллера домена, который затем можно привязать к запросам LDAP.
Руководство
В сообщении об ошибке "Не удалось найти краткое доменное имя из-за ошибки" предполагается, что команда nslookup
для contoso
не выполнила разрешение в IP-адрес контроллера домена. Ознакомьтесь с разделом DNS и обратные просмотры DNS, чтобы убедиться, что результат nslookup
совпадает для NetBIOS и доменного имени.
Сообщения об ошибках: "Не удалось выполнить поиск rDNS для имени узла <из-за ошибки" или "полное доменное имя> не возвращено запросом rDNS".
Возможная причина
Это сообщение об ошибке обычно указывает, что обратные записи DNS (записи PTR) не существуют для всех контроллеров домена.
Руководство
Просмотрите раздел DNS и обратные просмотры DNS. После выявления контроллеров домена без записей rDNS можно воспользоваться одним из двух вариантов.
Добавление записей rDNS для всех контроллеров домена
Этот параметр не является параметром SQL Server и должен быть настроен на уровне домена. Возможно, вам придется работать с командой администрирования домена, чтобы создать необходимые записи PTR для всех контроллеров домена, возвращаемых при выполнении
nslookup
имени домена.Ограничение SQL Server подмножеством контроллеров домена
Если записи типа PTR невозможно добавить для всех возвращенных контроллеров домена, можно ограничить SQL Server подмножеством контроллеров домена.
Сообщение об ошибке: "Не удалось привязаться к серверу LDAP ldap://CONTOSO.COM:3268: локальная ошибка"
Возможная причина
Эта универсальная ошибка из OpenLDAP обычно означает одну из двух вещей:
- Отсутствие учетных данных
- Проблемы с rDNS
Вот один из таких примеров сообщения об ошибке:
12/09/2021 14:32:11.319933684 Error [security.ldap] <0000000142/0x000001c0> Failed to bind to LDAP server ldap://[CONTOSO.COM:3268]: Local error
Руководство
Отсутствие учетных данных
Другие сообщения об ошибках возникают сначала, если учетные данные не загружаются для подключений LDAP. Вы должны включить ведение журнала PAL и проверить журнал ошибок для сообщений об ошибках перед этим. Если других ошибок нет, скорее всего, проблема не связана с учетными данными. Если такое сообщение об ошибке найдено, исправьте ошибку, сообщение о которой отображается. В большинстве случаев это один из сообщений об ошибках, описанных в этой статье.
Проблемы с rDNS
Просмотрите раздел DNS и обратные просмотры DNS.
При подключении библиотеки OpenLDAP к контроллеру домена предоставляется полное доменное имя (FQDN), которое в этом примере равно
contoso.com
полное доменное имя контроллера домена (kdc1.contoso.com
). После установки подключения (но до возврата сообщения об успешном подключении вызывающей стороне) библиотека OpenLDAP проверяет IP-адрес сервера, к которому она подключена. Затем он выполняет обратный поиск DNS и убедитесь, что имя сервера, подключенного к (kdc1.contoso.com
), соответствует домену, для которому было запрошено подключение (contoso.com
). Если он не соответствует, библиотека OpenLDAP завершается сбоем подключения в качестве функции безопасности. Это часть того, почему параметры rDNS настолько важны для SQL Server на Linux и являются основной частью этой статьи.
Сообщение об ошибке: "Запись таблицы ключей не найдена"
Возможная причина
Эта ошибка указывает на проблемы с доступом к файлу keytab или на отсутствие всех необходимых записей в keytab.
Руководство
Убедитесь, что файл keytab имеет правильный уровень доступа и разрешения. Расположение по умолчанию и имя для файла keytab — /var/opt/mssql/secrets/mssql.keytab
. Чтобы просмотреть текущие разрешения для всех файлов в папке secrets, можно выполнить следующую команду:
sudo ls -lrt /var/opt/mssql/secrets
Задать разрешения и уровень доступа для файла keytab можно с помощью этих команд:
sudo chown mssql /var/opt/mssql/secrets/mssql.keytab
sudo chmod 440 /var/opt/mssql/secrets/mssql.keytab
Дополнительные сведения о перечислении записей keytab и настройке правильных разрешений см. в предыдущем разделе "Проверка файла keytab" и разрешений . Если какие-либо условия в этом разделе не выполнены, вы увидите следующую или эквивалентную ошибку: "Key table entry not found"
Сообщение об ошибке: "Не найдена запись keytab для <principal>"
Возможная причина
При попытке получить учетные данные <principal>
из keytab соответствующие записи не были найдены.
Руководство
Чтобы вывести список всех записей в keytab, следуйте разделу "Проверка файла keytab" и разрешений этой статьи . Убедитесь в наличии <principal>
. В этом случае основная учетная запись обычно network.privilegedadaccount
является учетной записью, в которую регистрируются субъект-службы. Если это не так, добавьте ее с помощью команды adutil. Дополнительные сведения см. в статье "Использование adutil" для настройки проверки подлинности Active Directory с помощью SQL Server на Linux.
Сообщение об ошибке: "Не удалось найти сервер билетов запросов <principal> в keytab (kvno билета <KVNO>)"
Возможная причина
Эта ошибка указывает, что SQL Server не удалось найти запись keytab для запрошенного билета с указанным номером версии ключа (KVNO).
Руководство
Чтобы вывести список всех записей в keytab, следуйте разделу "Проверка файла keytab" и разрешений этой статьи . Если не удается найти сообщение об ошибке, соответствующее <principal>
и KVNO, добавьте эту запись. Для этого обновите файл keytab с помощью инструкций, приведенных в этой статье.
Можно также выполнить приведенную ниже команду, чтобы получить последний ключ KVNO из контроллера домена. Перед выполнением этой команды необходимо получить или продлить TGT Kerberos с помощью команды kinit . Дополнительные сведения см. в статье "Использование adutil" для создания пользователя Active Directory для SQL Server и задания имени субъекта-службы (SPN).
kvno MSSQLSvc/<hostname>
Сообщение об ошибке: "Номер kvno <KVNO> сервера билетов запросов <principal> найден в keytab, но не с типом шифрования <тип_шифрования>"
Возможная причина
Эта ошибка означает, что тип шифрования, запрошенный клиентом, отсутствовал в keytab SQL Server.
Руководство
Чтобы выполнить проверку, узнайте, как получить список всех записей в файле keytab, в разделе Проверка файла и разрешений keytab этого документа. Если не удается найти сообщение об ошибке, соответствующее субъекту, KVNO и типу шифрования, добавьте эту запись. Для этого обновите файл keytab с помощью инструкций, приведенных в этой статье.
Сообщение об ошибке: "Номер kvno <KVNO> сервера билетов запросов <principal> с типом шифрования <тип_шифрования> найден в keytab, но не удается расшифровать билет"
Возможная причина
Эта ошибка означает, что SQL Server не удалось использовать учетные данные из файла keytab для расшифровки входящего запроса на проверку подлинности. Ошибка часто является результатом неправильного пароля.
Руководство
Повторно создайте keytab, используя правильный пароль. Если вы используете adutil, создайте ключ с правильным паролем, выполнив действия, описанные в руководстве. Используйте adutil для настройки проверки подлинности Active Directory с помощью SQL Server на Linux.
Стандартные порты
В этой таблице показаны общие порты, используемые SQL Server на Linux для настройки и администрирования проверки подлинности Active Directory.
Служба Active Directory | Порт |
---|---|
DNS | 53 |
LDAP | 389 |
LDAPS | 636 |
Kerberos | 88 |