Ескертпе
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Жүйеге кіруді немесе каталогтарды өзгертуді байқап көруге болады.
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Каталогтарды өзгертуді байқап көруге болады.
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.