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

Скачать драйвер ODBC

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

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

Использование встроенной проверки подлинности для подключения к 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 от имени пользователей, отличных от системной учетной записи, приложение должно использовать Transact-SQLEXECUTE AS.

Для повышения производительности приложение может использовать организацию пулов соединений со встроенной проверкой подлинности и аудитом. Однако совмещение организации пулов соединений, встроенной проверки подлинности и аудита создает угрозу безопасности, так как диспетчер драйверов 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 является ошибкой.

Поддерживаемый синтаксис SPN, зарегистрированного сервером SQL Server

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

Проверка подлинности компьютера 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