Проверка подлинности Active Directory для SQL Server на Linux и в контейнерах

Применимо к: даSQL Server (все поддерживаемые версии) — Linux

В этой статье содержатся сведения о том, как работает проверка подлинности AD (Active Directory) для развертывания SQL Server на Linux или в контейнерах.

Основные понятия

Протокол LDAP

LDAP — это протокол приложений для работы с различными службами каталогов, включая Active Directory (AD). В службах каталогов хранятся сведения о пользователях и учетных записях, а также сведения о безопасности (например, пароли). Эти сведения шифруются, а затем передаются на другие устройства в сети.

Дополнительные сведения о том, чем протокол LDAPS отличается от LDAP, см. в статье Сертификат LDAPS.

Дополнительные сведения о защите LDAP см. в статье Включение входа LDAP в Windows Server.

Kerberos

Kerberos — это протокол проверки подлинности, который используется для идентификации пользователя или главного компьютера. Это можно считать способом проверки клиента и сервера.

При работе в разнородной (смешанной) среде, где есть серверы и клиенты на базе Windows и других ОС, существует два типа файлов, которые требуются для работы со службами каталогов на основе AD:

  • файлы keytab (сокращение от key tables — "таблицы ключей");
  • файлы конфигурации Kerberos (krb5.conf или krb5.ini).

Что такое файл keytab?

Серверные процессы в системах Linux или Unix нельзя настроить для запуска процессов с учетной записью службы Windows. Если вы хотите, чтобы система Linux или Unix при запуске автоматически выполняла вход в Active Directory (AD), необходимо использовать файл keytab.

Keytab — это криптографический файл, содержащий представление службы, защищенной протоколом Kerberos, и долгосрочного ключа связанного с ним имени субъекта-службы в центре распространения ключей (KDC). Ключ — это не сам пароль.

Файлы keytab используются для одной из следующих целей:

  • проверка подлинности самой службы в другой службе в сети;
  • расшифровка билета службы Kerberos для входящего в службу пользователя каталога.

Дополнительные сведения см. в статье Active Directory: использование файлов keytab в Kerberos для интеграции систем, отличных от Windows.

Что такое файл krb5.conf?

Файл /etc/krb5.conf (который также может называться krb5.ini) предоставляет входные данные конфигурации для библиотек Kerberos v5 (KRB5) и GNU Simple Authentication and Security Layer API (GSSAPI).

Это такие сведения, как домен по умолчанию, свойства каждого домена (например, центры распространения ключей) и время существования билета Kerberos по умолчанию.

Этот файл необходим для работы проверки подлинности AD. krb5.conf — INI-файл, но каждое значение в паре "ключ — значение" может быть подгруппой, заключенной в фигурные скобки ({ и }).

Дополнительные сведения о файле krb5.conf см. в документации по MIT Kerberos Consortium.

Настройка Kerberos для SQL Server на Linux

В этом разделе приведены значения, которые нужно указать для сервера узла, где выполняется SQL Server на Linux. При наличии на том же узле других (отличных от SQL Server) служб, для файла krb5.conf может потребоваться несколько дополнительных записей.

Вот пример файла krb5.conf для справки:

[libdefaults]
default_realm = CONTOSO.COM

[realms]
CONTOSO.COM = {
  kdc = adVM.contoso.com
  admin_server = adVM.contoso.com
  default_domain = contoso.com
}

[domain_realm]
.contoso.com = CONTOSO.COM
contoso.com = CONTOSO.COM
  • libdefaults. Должно присутствовать значение default_realm. Это значение указывает домен, к которому принадлежит главный компьютер.

  • realms (необязательно). Для каждой области определения приложения можно задать значение kdc, чтобы указать, к каким центрам распространения ключей будет обращаться компьютер при поиске учетных записей AD. Если вы задали несколько KDC, центр распространения ключей для каждого подключения будет выбираться методом циклического перебора.

  • domain_realm (необязательно). Можно указать сопоставления для каждой области определения приложения. В противном случае SQL Server на Linux предполагает, что домен contoso.com соответствует области определения приложения CONTOSO.COM.

Процесс проверки подлинности Kerberos

Первые два шага по получению билета предоставления билета (TGT) такие же, как и при проверке подлинности Kerberos в Windows:

  • Клиент начинает процесс входа в систему, отправляя свои имя пользователя и пароль (в зашифрованном виде) контроллеру домена (DC).

  • После проверки имени пользователя и пароля во внутреннем хранилище контроллер домена возвращает клиенту TGT для пользователя.

SQL Server на Linux использует файл keytab для считывания пароля имени субъекта-службы, а затем расшифровывает зашифрованный BLOB-объект, который используется для авторизации подключения. Этот процесс включает следующие шаги.

  • После получения TGT пользователем клиент запускает подключение к SQL Server, указывая имя узла и порт экземпляра SQL Server.

  • Клиент SQL изнутри создает имя субъекта-службы в формате MSSQLSvc/<host>:<port>. У большинства клиентов SQL Server это жестко заданный формат.

  • Клиент запускает подтверждение Kerberos, запрашивая у контроллера домена ключ сеанса для этого имени субъекта-службы. TGT и имя субъекта-службы отправляются контроллеру домена.

Проверка подлинности Active Directory для SQL Server на Linux — отправка билета предоставления билета и имени субъекта-службы контроллеру домена

  • Когда контроллер домена проверит TGT и имя субъекта-службы, он отправит клиенту ключ сеанса для подключения к имени субъекта-службы SQL Server.

Проверка подлинности Active Directory для SQL Server на Linux — контроллер домена возвращает клиенту ключ сеанса

  • Зашифрованный большой двоичный объект из ключа сеанса отправляется на сервер.

Проверка подлинности Active Directory для SQL Server на Linux — ключ сеанса отправляется на сервер

  • SQL Server считывает пароль для имени субъекта-службы из соответствующего файла keytab (mssql.keytab), который представляет собой файл на диске, содержащий зашифрованные кортежи (имя субъекта-службы, пароль).

  • SQL Server расшифровывает зашифрованный большой двоичный объект от клиента с помощью только что найденного пароля, чтобы получить имя пользователя клиента.

  • SQL Server ищет клиент в таблице sys.syslogins, чтобы проверить, есть ли у него разрешение на подключение.

  • Подключение либо принимается, либо отклоняется.

Проверка подлинности Active Directory для SQL Server на Linux — подключение принимается или отклоняется

Настройка Kerberos для контейнеров SQL Server

Проверка подлинности Active Directory для SQL Server в контейнерах в целом такая же, как и для SQL Server на Linux. Единственное отличие — имя субъекта-службы узла SQL Server. В предыдущем сценарии имя субъекта-службы было MSSQLSvc/<host>:<port>, так как подключение осуществлялось через имя узла SQL Server. Но теперь нам нужно подключиться к контейнеру.

Для контейнеров SQL Server файл krb5.conf можно создать внутри контейнера. Главный узел, на котором выполняется контейнер, не обязательно должен входить в состав домена, но должен иметь возможность подключения к контроллеру домена, к которому будет пытаться подключиться контейнер.

Так как мы подключаемся к контейнеру, имя сервера в подключении клиента может отличаться от имени узла. Это может быть имя узла, имя контейнера или другой псевдоним. Кроме того, существует большая вероятность того, что открытый для SQL Server порт не будет используемым по умолчанию портом 1433.

Для подключения к контейнеру SQL Server необходимо использовать имя субъекта-службы, которое хранится в mssql.keytab. Например, если имя субъекта-службы в mssql.keytab имеет значение MSSQLSvc/sqlcontainer.domain.com:8000, то в качестве строки подключения на клиенте (включая sqlcmd, SQL Server Management Studio и Azure Data Studio) следует использовать sqlcontainer.domain.com,8000.

Проверка подлинности Active Directory для контейнеров SQL Server

Обновление группы SQL Server

Возможно, вас интересует, почему в файле keytab указана учетная запись пользователя, если для проверки подлинности требуется только имя субъекта-службы.

Представьте себе, что у вас есть пользователь adUser, который входит в группу adGroup. Если adGroup добавляется в качестве имени входа в SQL Server, то adUser также имеет разрешение на вход в экземпляр SQL Server. Хотя пользователь adUser по-прежнему подключен к SQL Server, администратор домена может удалить adUser из adGroup. Теперь у пользователя adUser больше не должно быть разрешения на вход в SQL Server, но он уже прошел процесс проверки подлинности Kerberos и подключился.

Мы периодически выполняем процесс, называемый обновлением группы, чтобы избежать ситуации, когда подключенному пользователю больше не разрешено выполнять привилегированное действие (например, создание имени входа или изменение базы данных).

В SQL Server есть привилегированная учетная запись AD, которая используется для обновления группы. Эта учетная запись либо настраивается с помощью mssql-conf с параметром network.privilegedadaccount, либо по умолчанию используется учетная запись главного компьютера (<hostname>$).

Учетные данные привилегированной учетной записи в mssql.keytab используются для олицетворения клиента (в этом примере — adUser). SQL Server выполняет подтверждение Kerberos с самим собой для определения сведений о членстве в группе и сравнивает их с sys.syslogins, чтобы проверить, имеет ли adUser все необходимые разрешения для подключения и выполнения запрашиваемых команд Transact-SQL. Если пользователь adUser удален из adGroup, SQL Server завершает подключение.

Дальнейшие действия