Руководство по использованию проверки подлинности 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 необходимо выполнить следующие действия.

Присоединение узла SQL Server к домену Active Directory

Присоедините узел SQL Server на Linux к контроллеру домена Active Directory. Сведения о присоединении к домену Active Directory см. в статье Присоединение узла SQL Server на Linux к домену Active Directory.

Создание пользователя Active Directory для SQL Server и установка имени субъекта-службы

Примечание.

В следующих шагах используется полное доменное имя (FQDN). Если вы находитесь в Azure, перед продолжением необходимо создать полное доменное имя.

  1. На контроллере домена выполните команду 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 и выберите пункт Свойства. Найдите вкладку "Учетные записи" в свойствах и убедитесь, что выбраны два следующих проверка boxes.

    1. Эта учетная запись поддерживает 128-разрядное шифрование Kerberos AES

    2. Данная учетная запись поддерживает 256-битовое шифрование Kerberos AES

  2. Укажите значение 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). В некоторых службах смена паролей может происходить автоматически. Проверьте политики смены паролей для нужных учетных записей и приведите их в соответствие с запланированными действиями по обслуживанию, чтобы избежать непредвиденных простоев.

Записи ключа субъекта-службы

  1. Проверьте номер версии ключа (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, который был описан в предыдущем разделе.

  2. С помощью ktpassдобавьте записи KEYTAB для каждого имени субъекта-службы с помощью следующих команд в командной строке компьютера Windows:

    • <DomainName>\<UserName> — учетная запись пользователя Active Directory
    • @CONTOSO.COM — используйте свое имя домена
    • /kvno <#> — замените <#> номером KVNO, полученным на предыдущем шаге
    • <StrongPassword> — используйте надежный пароль
    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 <StrongPassword>
    
    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 <StrongPassword>
    
    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 <StrongPassword>
    
    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 <StrongPassword>
    
    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 <StrongPassword>
    
    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 <StrongPassword>
    

    Примечание.

    Приведенные выше команды позволяют шифрам шифрования AES и RC4 для проверки подлинности Active Directory. RC4 — это старый метод шифрования, и если требуется более высокая степень безопасности, то можно создать записи KEYTAB только с методом шифрования AES. Последние две записи UserName должны быть в нижнем регистре, иначе проверка подлинности для предоставления разрешений может завершиться сбоем.

  3. После выполнения приведенной выше команды необходимо иметь файл keytab с именем mssql.keytab. Скопируйте файл на компьютер с SQL Server в папке /var/opt/mssql/secrets.

  4. Защитите KEYTAB-файл.

    Любой пользователь, имеющий доступ к KEYTAB-файлу, может олицетворять SQL Server в домене, поэтому необходимо ограничить доступ к файлу так, чтобы только учетная запись mssql имела доступ для чтения:

    sudo chown mssql:mssql /var/opt/mssql/secrets/mssql.keytab
    sudo chmod 400 /var/opt/mssql/secrets/mssql.keytab
    
  5. Для указания учетной записи для доступа к KEYTAB-файлу необходимо задать соответствующий параметр конфигурации с помощью средства mssql-conf.

    sudo mssql-conf set network.privilegedadaccount <username>
    

    Примечание.

    Включайте только имя пользователя, а не имя_домена\имя_пользователя или имя_пользователя@домен. SQL Server сам добавляет имя домена вместе с этим именем пользователя при использовании.

  6. Чтобы настроить использование 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

  1. Подключение в SQL Server и создайте новое имя входа на основе Active Directory:

    CREATE LOGIN [CONTOSO\user] FROM WINDOWS;
    
  2. Убедитесь в том, что имя входа теперь приводится в представлении системного каталога 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, выполните следующую команду ldapsearch -H ldaps://contoso.com:3269bash. Чтобы настроить в 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

Знаете ли вы, что содержимое SQL можно изменить самостоятельно? Это не только улучшит нашу документацию, но и даст вам статус участника в создании этой страницы.

Дополнительные сведения см. в разделе Участие в работе над документацией по SQL Server.