Использование встроенной проверки подлинности

Статья
06/02/2023

Microsoft ODBC Driver for SQL Server на Linux и macOS поддерживает соединения, использующие встроенную проверку подлинности Kerberos. Он поддерживает центр распространения ключей (KDC) Kerberos MIT и работает с общим API служб безопасности (GSSAPI) и библиотеками Kerberos версии 5.

По состоянию на версию 17.6 драйвер также поддерживает встроенную проверку подлинности с идентификатором Microsoft Entra (ранее Azure Active Directory), используя федеративную учетную запись, ограничения системной библиотеки. Дополнительные сведения см. в разделе "Использование идентификатора записи Майкрософт".

Использование встроенной проверки подлинности для Подключение в SQL Server из приложения ODBC

Вы можете включить встроенную проверку подлинности Kerberos, указав Trusted_Connection=yes в строке подключения для SQLDriverConnect или SQLConnect. Например:

Driver='ODBC Driver 18 for SQL Server';Server=your_server;Encrypt=yes;Trusted_Connection=yes

При подключении с использованием имени DSN можно также добавить Trusted_Connection=yes в запись имени DSN в файле odbc.ini.

Задать встроенную проверку подлинности можно также с помощью параметра -E команды sqlcmd и параметра -T команды bcp. Дополнительные сведения см. в статьях Соединение с помощью sqlcmd и Соединение с помощью bcp.

Убедитесь, что субъект-клиент, который собирается подключиться к SQL Server, уже прошел проверку подлинности с помощью KDC Kerberos.

ServerSPN и FailoverPartnerSPN не поддерживаются.

Развертывание приложения драйвера ODBC для Linux или macOS, предназначенного для запуска в качестве службы

Системный администратор может развернуть приложение для запуска в качестве службы, которая использует проверку подлинности Kerberos для подключения к SQL Server.

Сначала необходимо настроить Kerberos в клиенте, а затем убедиться в том, что приложение может использовать учетные данные Kerberos субъекта по умолчанию.

Убедитесь в том, что вы используете kinit или PAM (подключаемый модуль проверки подлинности) для получения и кэширования TGT для субъекта, используемого соединением, одним из следующих способов:

Запустите kinit, передав имя и пароль субъекта.
Запустите kinit, передав имя субъекта и расположение файла keytab, который содержит ключ субъекта, созданный ktutil.
Убедитесь в том, что вход в систему был выполнен с помощью PAM Kerberos (подключаемый модуль проверки подлинности).

Когда приложение запускается в виде службы, обновляйте учетные данные Kerberos, чтобы обеспечить постоянную доступность службы, так как учетные данные намеренно имеют срок действия. Драйвер ODBC не обновляет учетные данные. Убедитесь в том, что имеется задание cron или скрипт, которые периодически выполняют обновление учетных данных до истечения срока их действия. Чтобы избежать запроса пароля для каждого обновления, можно использовать файл keytab.

СтатьяКонфигурация и использование Kerberos содержит сведения о способах применения Kerberos для служб в Linux.

Отслеживание доступа к базе данных

Администратор базы данных может создать путь аудита доступа к базе данных при использовании системных учетных записей для доступа к SQL Server с помощью встроенной проверки подлинности.

Вход в SQL Server использует системную учетную запись и нет функций в Linux для олицетворения контекста безопасности. Таким образом, для определения пользователя требуется нечто большее.

Для аудита действий в SQL Server от имени пользователей, отличных от системной учетной записи, приложение должно использовать инструкцию EXECUTE AS Transact-SQL.

Для повышения производительности приложение может использовать организацию пулов соединений со встроенной проверкой подлинности и аудитом. Однако совмещение организации пулов соединений, встроенной проверки подлинности и аудита создает угрозу безопасности, так как диспетчер драйверов unixODBC позволяет различным пользователям повторно использовать подключения из пула. Дополнительные сведения см. в статье Организация пулов соединений ODBC.

Перед повторным использованием приложение должно сбросить соединения в пуле, выполнив sp_reset_connection.

Использование Active Directory для управления удостоверениями пользователей

Системный администратор приложения не должен управлять отдельными наборами учетных данных входа для SQL Server. Можно настроить Active Directory в качестве центра распространения ключей (KDC) для встроенной проверки подлинности. Дополнительные сведения см. в статье Microsoft Kerberos.

Использование связанного сервера и распределенных запросов

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

Пользователь входит на клиентский компьютер и выполняет проверку подлинности для сервера приложений.
Сервер приложений проходит проверку подлинности в виде другой базы данных и подключается к SQL Server.
SQL Server проходит проверку подлинности в качестве пользователя базы данных в другой базе данных (SQL Server).

После настройки встроенной проверки подлинности учетные данные передаются связанному серверу.

Встроенная проверка подлинности и sqlcmd

Чтобы получить доступ к SQL Server с помощью встроенной проверки подлинности, используйте -E параметр sqlcmd. Убедитесь в том, что учетная запись, используемая для запуска sqlcmd, сопоставлена с субъектом клиента Kerberos по умолчанию.

Встроенная проверка подлинности и bcp

Чтобы получить доступ к SQL Server с помощью встроенной проверки подлинности, используйте -T параметр bcp. Убедитесь в том, что учетная запись, используемая для запуска bcp, сопоставлена с субъектом клиента Kerberos по умолчанию.

Использование параметра -T с параметром -U или -P является ошибкой.

Поддерживаемый синтаксис для имени субъекта-службы, зарегистрированного SQL Server

В именах субъектов-служб в атрибутах или строке подключения применяется следующий синтаксис:

Синтаксис	Description
MSSQLSvc/fqdn:port	Сформированное поставщиком имя участника-службы для экземпляра по умолчанию, когда используется протокол TCP. port — номер TCP-порта. fqdn — полное доменное имя.

Проверка подлинности компьютера Linux или macOS с помощью Active Directory

Чтобы настроить Kerberos, введите данные в файле krb5.conf. krb5.conf находится в папке /etc/, но можно сослаться на другой файл, используя такой синтаксис: export KRB5_CONFIG=/home/dbapp/etc/krb5.conf. Ниже представлен пример файла krb5.conf.

[libdefaults]  
default_realm = YYYY.CORP.CONTOSO.COM  
dns_lookup_realm = false  
dns_lookup_kdc = true  
ticket_lifetime = 24h  
forwardable = yes  
  
[domain_realm]  
.yyyy.corp.contoso.com = YYYY.CORP.CONTOSO.COM  
.zzzz.corp.contoso.com = ZZZZ.CORP.CONTOSO.COM

Если на компьютере Linux или macOS настроено использование протокола DHCP, причем DHCP-сервер Windows предоставляет DNS-серверы для использования, можно использовать dns_lookup_kdc=true. Теперь можно использовать Kerberos для входа в домен с помощью команды kinit alias@YYYY.CORP.CONTOSO.COM. kinit Передаваемые параметры чувствительны к регистру, и компьютер SQL Server, настроенный для входа в домен, должен быть добавлен для alias@YYYY.CORP.CONTOSO.COM входа. Теперь вы можете использовать доверительные соединения (Trusted_Connection=YES в строке подключения, bcp -T или sqlcmd -E).

Время на компьютере Linux или macOS и время в центре распространения ключей Kerberos (KDC) не должны слишком сильно различаться. Убедитесь в том, что системное время задано правильно, например с помощью протокола NTP.

При сбое проверки подлинности Kerberos драйвер ODBC в Linux или macOS не использует проверку подлинности NTLM.

Дополнительные сведения о проверке подлинности компьютера Linux или macOS с помощью Active Directory см. в статье Проверка подлинности клиентов Linux с помощью Active Directory. Дополнительные сведения о настройке Kerberos см. в документации MIT Kerberos.

См. также

Указания по программированию

Заметки о выпуске

Использование идентификатора Microsoft Entra