Руководство по использованию проверки подлинности Active Directory с SQL Server на Linux
Область применения: SQL Server — Linux
В этом руководстве объясняется, как настроить SQL Server на Linux для поддержки проверки подлинности Active Directory, также известной как встроенная проверка подлинности. Общие сведения см. в статье Проверка подлинности Active Directory для SQL Server на Linux.
В этом руководстве рассматриваются следующие задачи:
- Присоединение узла SQL Server к домену Active Directory
- Создание пользователя Active Directory для SQL Server и установка имени субъекта-службы
- Настройка keytab службы SQL Server
- защита KEYTAB-файла;
- настройка SQL Server для использования KEYTAB-файла для проверки подлинности Kerberos;
- Создание имен входа на основе Active Directory в Transact-SQL
- Подключение к SQL Server с помощью проверки подлинности Active Directory
Необходимые компоненты
Перед настройкой проверки подлинности Active Directory необходимо выполнить следующие действия.
- Настройка контроллера домен Active Directory (Windows) в сети
- Установка SQL Server
Присоединение узла SQL Server к домену Active Directory
Присоедините узел SQL Server на Linux к контроллеру домена Active Directory. Сведения о присоединении к домену Active Directory см. в статье Присоединение узла SQL Server на Linux к домену Active Directory.
Создание пользователя Active Directory для SQL Server и установка имени субъекта-службы
Примечание.
В следующих шагах используется полное доменное имя (FQDN). Если вы находитесь в Azure, перед продолжением необходимо создать полное доменное имя.
На контроллере домена выполните команду New-ADUser PowerShell, чтобы создать нового пользователя Active Directory с паролем, который никогда не истекает. В приведенном ниже примере используется имя учетной записи
sqlsvc
, однако оно может быть любым. Вы получите запрос на ввод нового пароля для учетной записи.Import-Module ActiveDirectory New-ADUser sqlsvc -AccountPassword (Read-Host -AsSecureString "Enter Password") -PasswordNeverExpires $true -Enabled $true
Примечание.
Рекомендуется использовать выделенную учетную запись Active Directory для SQL Server, чтобы учетные данные экземпляра SQL Server не были общими для других служб, использующих ту же учетную запись. Однако при необходимости можно повторно использовать существующую учетную запись Active Directory, если вы знаете пароль учетной записи (которая требуется для создания файла keytab на следующем шаге). Кроме того, учетная запись должна быть включена для поддержки 128-разрядного и 256-разрядного шифрования Kerberos AES (
msDS-SupportedEncryptionTypes
атрибута) в учетной записи пользователя. Чтобы убедиться в том, что для учетной записи включено шифрование AES, найдите ее в служебной программе Пользователи и компьютеры Active Directory и выберите пункт Свойства. Найдите вкладку "Учетные записи" в свойствах и установите два следующих флажка.Эта учетная запись поддерживает 128-разрядное шифрование Kerberos AES
Данная учетная запись поддерживает 256-битовое шифрование Kerberos AES
Укажите значение ServicePrincipalName (имя субъекта-службы) для этой учетной записи с помощью средства setspn.exe. Формат имени субъекта-службы должен быть в точности таким же, как в приведенном ниже примере. Полное доменное имя хост-компьютера SQL Server можно найти, выполнив на
hostname --all-fqdns
узле SQL Server. TCP-порт должен быть 1433, если вы не настроили SQL Server для использования другого номера порта.setspn -A MSSQLSvc/<fully qualified domain name of host machine>:<tcp port> sqlsvc setspn -A MSSQLSvc/<netbios name of the host machine>:<tcp port> sqlsvc
Примечание.
Если возникнет ошибка
Insufficient access rights
, узнайте у администратора вашего домена, достаточно ли у вас разрешений для задания имени субъекта-службы для этой учетной записи. Для регистрации имени участника-службы потребуетсяWrite servicePrincipalName
учетная запись, используемая для регистрации имени участника-службы. Дополнительные сведения см. в разделе "Регистрация имени субъекта-службы" для подключений Kerberos.Если в будущем вы измените TCP-порт, необходимо будет еще раз выполнить команду setspn с новым номером порта. Кроме того, необходимо будет добавить новое имя субъекта-службы в файл KEYTAB службы SQL Server, выполнив инструкции в следующем разделе.
Дополнительные сведения см. в разделе "Регистрация имени субъекта-службы" для подключений Kerberos.
Настройка keytab службы SQL Server
Для настройки проверки подлинности Active Directory для SQL Server на Linux требуется учетная запись пользователя Active Directory и имя субъекта-службы, созданное в предыдущем разделе.
Внимание
Если пароль учетной записи Active Directory изменен или пароль учетной записи, к которому назначены имена субъектов-служб, необходимо обновить ключ с новым паролем и номером версии ключа (KVNO). В некоторых службах смена паролей может происходить автоматически. Проверьте политики смены паролей для нужных учетных записей и приведите их в соответствие с запланированными действиями по обслуживанию, чтобы избежать непредвиденных простоев.
Записи ключа субъекта-службы
Проверьте номер версии ключа (KVNO) для учетной записи Active Directory, созданной на предыдущем шаге. Обычно это 2, но это может быть еще одно целое число, если вы изменили пароль учетной записи несколько раз. На хост-компьютере SQL Server выполните следующие команды:
- В приведенных ниже примерах предполагается, что
user
находится в домене@CONTOSO.COM
. Измените имя пользователя и домена на свои значения.
kinit user@CONTOSO.COM kvno user@CONTOSO.COM kvno MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM
Примечание.
Распространение имен субъектов-служб в домене может занять несколько минут, особенно если домен большой. Если возникнет ошибка
kvno: Server not found in Kerberos database while getting credentials for MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM
, подождите несколько минут и повторите попытку.
Приведенные выше команды будут работать только в том случае, если сервер был присоединен к домену Active Directory, который был описан в предыдущем разделе.- В приведенных ниже примерах предполагается, что
С помощью ktpassдобавьте записи KEYTAB для каждого имени субъекта-службы с помощью следующих команд в командной строке компьютера Windows:
<DomainName>\<UserName>
— учетная запись пользователя Active Directory@CONTOSO.COM
— используйте свое имя домена/kvno <#>
— замените<#>
номером KVNO, полученным на предыдущем шаге<password>
— Пароль должен соответствовать политике паролей по умолчанию SQL Server. По умолчанию пароль должен быть не короче восьми символов и содержать три вида символов из следующих: прописные буквы, строчные буквы, десятичные цифры, специальные символы. Пароли могут иметь длину до 128 символов. Рекомендуется использовать максимально длинные и сложные пароли.
ktpass /princ MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /out mssql.keytab -setpass -setupn /kvno <#> /pass <password> ktpass /princ MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password> ktpass /princ MSSQLSvc/<netbios name of the host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password> ktpass /princ MSSQLSvc/<netbios name of the host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password> ktpass /princ <UserName>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password> ktpass /princ <UserName>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
Предыдущие команды позволяют шифры шифрования AES и RC4 для проверки подлинности Active Directory. RC4 — это старый метод шифрования, и если требуется более высокая степень безопасности, то можно создать записи KEYTAB только с методом шифрования AES.
Примечание.
Последние две
UserName
записи должны находиться в нижнем регистре, или проверка подлинности при перемеже может завершиться ошибкой.После выполнения предыдущих команд у вас должен быть файл keytab с именем
mssql.keytab
. Скопируйте файл на компьютер с SQL Server в папке/var/opt/mssql/secrets
.Защитите KEYTAB-файл.
Любой пользователь, имеющий доступ к KEYTAB-файлу, может олицетворять SQL Server в домене, поэтому необходимо ограничить доступ к файлу так, чтобы только учетная запись mssql имела доступ для чтения:
sudo chown mssql:mssql /var/opt/mssql/secrets/mssql.keytab sudo chmod 400 /var/opt/mssql/secrets/mssql.keytab
Для указания учетной записи для доступа к KEYTAB-файлу необходимо задать соответствующий параметр конфигурации с помощью средства mssql-conf.
sudo mssql-conf set network.privilegedadaccount <username>
Примечание.
Включайте только имя пользователя, а не имя_домена\имя_пользователя или имя_пользователя@домен. SQL Server сам добавляет имя домена вместе с этим именем пользователя при использовании.
Чтобы настроить использование KEYTAB-файла для проверки подлинности Kerberos при запуске SQL Server, выполните указанные ниже действия.
sudo mssql-conf set network.kerberoskeytabfile /var/opt/mssql/secrets/mssql.keytab sudo systemctl restart mssql-server
Совет
Чтобы повысить производительность, можно отключить подключения UDP к контроллеру домена. Во многих случаях подключения UDP последовательно завершаются сбоем при подключении к контроллеру домена, поэтому можно задать параметры конфигурации для
/etc/krb5.conf
пропуска вызовов UDP. Измените/etc/krb5.conf
и задайте следующие параметры:/etc/krb5.conf [libdefaults] udp_preference_limit=0
На этом этапе вы готовы использовать имена входа на основе Active Directory в SQL Server.
Создание имен входа на основе Active Directory в Transact-SQL
Подключитесь к SQL Server и создайте новое имя входа на основе Active Directory:
CREATE LOGIN [CONTOSO\user] FROM WINDOWS;
Убедитесь в том, что имя входа теперь приводится в представлении системного каталога sys.server_principals:
SELECT name FROM sys.server_principals;
Подключение к SQL Server с помощью проверки подлинности Active Directory
Войдите на клиентский компьютер с помощью учетных данных домена. Теперь вы можете подключиться к SQL Server без повторного ввода пароля с помощью проверки подлинности Active Directory. При создании имени входа для группы Active Directory любой пользователь Active Directory, являющийся членом этой группы, может подключиться таким же образом.
Конкретный параметр строка подключения для клиентов, использующих проверку подлинности Active Directory, зависит от используемого драйвера. Рассмотрим примеры в следующих разделах.
sqlcmd в клиенте Linux, присоединенном к домену
Войдите в присоединенный к домену клиент Linux с помощью SSH и учетных данных домена:
ssh -l user@contoso.com client.contoso.com
Убедитесь в том, что установлен пакет mssql-tools, а затем подключитесь с помощью sqlcmd, не указывая учетные данные:
sqlcmd -S mssql-host.contoso.com
В отличие от SQL Windows проверка подлинности Kerberos работает для локального подключения в SQL Linux. Однако вам по-прежнему необходимо указать полное доменное имя узла LINUX SQL, и проверка подлинности Active Directory не будет работать, если вы пытаетесь подключиться к .
, localhost
и 127.0.0.1
т. д.
SSMS в клиенте Windows, присоединенном к домену
Войдите в присоединенный к домену клиент Windows с помощью учетных данных домена. Убедитесь в том, что установлена среда SQL Server Management Studio, а затем подключитесь к экземпляру SQL Server (например, mssql-host.contoso.com
), выбрав проверку подлинности Windows в диалоговом окне Подключение к серверу.
Проверка подлинности Active Directory с помощью других клиентских драйверов
В приведенной ниже таблице представлены рекомендации для других клиентских драйверов.
Клиентский драйвер | Рекомендация |
---|---|
JDBC | Используйте встроенную проверку подлинности Kerberos для подключения к SQL Server. |
ODBC | Используйте встроенную проверку подлинности. |
ADO.NET | Синтаксис строки подключения. |
Дополнительные параметры конфигурации
Если вы используете сторонние служебные программы, такие как PBIS, VAS или Centrify для присоединения узла Linux к домену Active Directory, и вы хотите принудительно использовать библиотеку OpenLDAP, вы можете настроить disablesssd
этот параметр с помощью mssql-conf следующим образом:
sudo mssql-conf set network.disablesssd true
systemctl restart mssql-server
Примечание.
Существуют такие служебные программы, как область, которая настраивает SSSD, а другие средства, такие как PBIS, VAS и Centrify, не настраивают SSSD. Если программа, используемая для присоединения к домену Active Directory, не настраивает SSSD, следует настроить disablesssd
параметр true
. Хотя это не обязательно, так как SQL Server попытается использовать SSSD для Active Directory, прежде чем вернуться к механизму OpenLDAP, это будет более производительно для настройки, чтобы SQL Server делает вызовы OpenLDAP напрямую обходя механизм SSSD.
Если контроллер домена поддерживает протокол LDAPS, можно настроить принудительное использование LDAPS для всех подключений SQL Server к контроллеру домена. Чтобы проверить, что клиент может связаться с контроллером домена через LDAPS, выполните следующую команду Bash. ldapsearch -H ldaps://contoso.com:3269
Чтобы настроить в SQL Server использование только протокола LDAPS, выполните следующие команды:
sudo mssql-conf set network.forcesecureldap true
systemctl restart mssql-server
Это будет использовать LDAPS по протоколу SSSD, если присоединение домена Active Directory к узлу было выполнено через пакет SSSD и disablesssd
не имеет значения true. Если disablesssd
задано значение true вместе с forcesecureldap
значением true, он будет использовать протокол LDAPS через вызовы библиотеки OpenLDAP, выполняемые SQL Server.
После SQL Server 2017 CU 14
Начиная с SQL Server 2017 (14.x) CU 14, если SQL Server был присоединен к контроллеру домена Active Directory с помощью сторонних поставщиков и настроено использовать вызовы OpenLDAP для общего поиска Active Directory, disablesssd
установив значение true, можно также использовать enablekdcfromkrb5
параметр для принудительного использования SQL Server для поиска KDC вместо обратного поиска DNS для сервера KDC.
Это может быть полезно для сценария, с которым требуется вручную настроить контроллеры домена, с которыми SQL Server пытается взаимодействовать. И вы используете механизм библиотеки OpenLDAP с помощью списка KDC в krb5.conf
.
Сначала установите disablesssd
и установите значение true, enablekdcfromkrb5conf
а затем перезапустите SQL Server:
sudo mssql-conf set network.disablesssd true
sudo mssql-conf set network.enablekdcfromkrb5conf true
systemctl restart mssql-server
Затем настройте список KDC следующим /etc/krb5.conf
образом:
[realms]
CONTOSO.COM = {
kdc = dcWithGC1.contoso.com
kdc = dcWithGC2.contoso.com
}
Хотя это не рекомендуется, можно использовать служебные программы, такие как область, которые настраивают SSSD при присоединении узла Linux к домену, при настройке disablesssd
на значение true, чтобы SQL Server использовал вызовы OpenLDAP вместо SSSD для связанных вызовов Active Directory.
Примечание.
Имя входа SQL Server с помощью полного доменного имени (например, CONTOSO.COM\Username
) не поддерживается. CONTOSO\Username
Используйте формат.
Имена входа SQL Server из локальных групп домена не поддерживаются. Используйте группы глобальных доменов безопасности.
Связанный контент
- Шифрование подключений к SQL Server на Linux
- Общие сведения о проверке подлинности Active Directory для SQL Server на Linux и контейнеров
- Устранение неполадок проверки подлинности Active Directory для SQL Server на Linux и контейнеров
Примите участие в разработке документации по SQL
Знаете ли вы, что содержимое SQL можно изменить самостоятельно? Это не только улучшит нашу документацию, но и даст вам статус участника в создании этой страницы.
Дополнительные сведения см. в разделе Участие в работе над документацией по SQL Server.