Использование встроенной проверки подлинности
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.