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

  • Статья

Применимо к:SQL Server — Linux

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

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

Протокол LDAP

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

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

Kerberos

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

Если вы работаете в разнородной (смешанной) среде, где у вас есть серверы и клиенты, отличные от Windows, есть два типа файлов, необходимых для работы со службами каталогов на основе Active Directory:

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

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

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

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

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

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

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

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

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

Этот файл необходим для работы проверки подлинности Active Directory. 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 какие центры распространения ключей компьютер должен связаться при поиске учетных записей Active Directory. Если вы задали несколько KDC, центр распространения ключей для каждого подключения будет выбираться методом циклического перебора.

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

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

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

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

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

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

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

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

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

Diagram showing Active Directory authentication for SQL Server on Linux - Ticket-Granting Ticket and Service Principal Name sent to Domain Controller.

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

Diagram showing Active Directory authentication for SQL Server on Linux - session key returned to client by DC.

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

Diagram showing Active Directory authentication for SQL Server on Linux - session key sent to server.

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

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

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

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

Diagram showing Active Directory authentication for SQL Server on Linux - connection accepted or denied.

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

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

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

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

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

Diagram showing Active Directory authentication for SQL Server Containers.

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

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

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

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

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

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

Для обновления группы требуются следующие два условия:

  • Сетевое подключение между экземпляром SQL Server и доменом локальная служба Active Directory.
  • Двустороннее доверие между доменом, к которому подключен SQL Server, и доменом локальная служба Active Directory. Дополнительные сведения см. в разделе "Общие сведения о Active Directory".

Связанный контент