Устранение неполадок проверки подлинности 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, и что вы добавили правильные SPN, порт, тип шифрования и учетную запись пользователя. Если вы неправильно вводите пароли при создании имен субъектов-служб и записей keytab, возникают ошибки при попытке входа с помощью аутентификации Active Directory.
klist -kte /var/opt/mssql/secrets/mssql.keytabНиже приведен пример рабочего keytab-файла. В примере используются два типа шифрования. Однако вы можете использовать один или несколько типов шифрования в зависимости от того, какие типы шифрования поддерживаются в вашей среде. В этом примере
sqluser@CONTOSO.COMявляется привилегированной учетной записью (которая соответствует параметруnetwork.privilegedadaccountв mssql-conf), а имя узла для SQL Server —sqllinux.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
После создания пользователя, SPN и файлов ключей и настройки 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, а затем воспроизводите сбой. В журнал /var/opt/mssql/log/security.log записываются сообщения об ошибке и отладке Active Directory 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). Чтобы выполнить это преобразование, выполняется запрос в DNS для CONTOSO с целью разрешения в 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, либо FQDN контроллера домена (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"
Сообщение об ошибке: "Не найдена запись в таблице ключей для <principal>"
Возможная причина
При попытке получить учетные данные <principal> из keytab соответствующие записи не были найдены.
Руководство
Чтобы вывести список всех записей в keytab, следуйте разделу «Проверьте файл keytab и разрешения» этой статьи. Убедитесь в наличии <principal>. В этом случае основная учетная запись обычно network.privilegedadaccount, в которой регистрируются SPN. Если это не так, добавьте ее с помощью команды adutil. Дополнительные сведения см. в статье "Использование adutil" для настройки проверки подлинности Active Directory с помощью SQL Server на Linux.
Сообщение об ошибке: "Не удалось найти сервер запроса билетов <principal> в keytab (kvno билета <KVNO>)"
Возможная причина
Эта ошибка указывает, что SQL Server не удалось найти запись в keytab для билета с указанным номером версии ключа (KVNO).
Руководство
Чтобы вывести список всех записей в keytab, следуйте разделу Проверка файла keytab и разрешений этой статьи. Если не удается найти сообщение об ошибке, соответствующее <principal> и KVNO, добавьте эту запись. Для этого обновите файл keytab с помощью инструкций, приведенных в этой статье.
Можно также выполнить приведенную ниже команду, чтобы получить последний ключ KVNO из контроллера домена. Перед выполнением этой команды необходимо с помощью команды kinit получить или продлить Kerberos TGT. Дополнительные сведения см. в статье «Использование adutil для создания пользователя Active Directory для SQL Server и задания имени службы (SPN)».
kvno MSSQLSvc/<hostname>
Сообщение об ошибке: "Запрос на сервер билетов <principal> с kvno <KVNO> найден в keytab, но не с <типом шифрования>"
Возможная причина
Эта ошибка означает, что тип шифрования, запрошенный клиентом, отсутствовал в keytab SQL Server.
Руководство
Чтобы проверить, перечислите все записи в keytab, следуя разделу Проверка файла keytab и разрешений этого документа. Если не удается найти сообщение об ошибке, соответствующее субъекту, KVNO и типу шифрования, добавьте эту запись, обновив файл keytab с помощью шагов, указанных в этом разделе.
Сообщение об ошибке: "Сервер запросов билетов <principal>, kvno <KVNO>, тип шифрования <encryption type> найден в 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 |