Omówienie uwierzytelniania usługi Active Directory dla programu SQL Server w systemie Linux i kontenerach

Dotyczy:programu SQL Server — Linux

Ten artykuł zawiera szczegółowe informacje na temat sposobu działania uwierzytelniania usługi Active Directory dla programu SQL Server wdrożonego w systemie Linux lub kontenerach.

Pojęcia

Lightweight Directory Access Protocol (LDAP), lekki protokół dostępu do katalogów

LDAP to protokół aplikacji do pracy z różnymi usługami katalogowymi, w tym z usługą Active Directory. Usługi katalogowe przechowują informacje o użytkowniku i koncie oraz informacje o zabezpieczeniach, takie jak hasła. Te informacje są szyfrowane, a następnie udostępniane innym urządzeniom w sieci.

Aby dowiedzieć się więcej na temat zabezpieczania protokołu LDAP, zobacz Jak włączyć logowanie LDAP w systemie Windows Server.

Kerberos

Kerberos to protokół uwierzytelniania używany do weryfikowania tożsamości użytkownika lub komputera hosta. Można go traktować jako sposób weryfikacji klienta i serwera.

W przypadku pracy w środowisku heterogenicznym (mieszanym) w którym znajdują się serwery i klienci z systemem Windows i z innym systemem niż Windows, istnieją dwa rodzaje plików, z którymi należy pracować, korzystając z usług katalogowych opartych na usłudze Active Directory.

• Pliki keytab (skrót od "tabel kluczy")
• Pliki konfiguracji protokołu Kerberos (krb5.conf lub krb5.ini)

Co to jest plik keytab?

Nie można skonfigurować procesów serwera w systemach Linux lub Unix do uruchamiania procesów przy użyciu konta usługi systemu Windows. Jeśli chcesz, aby system Linux lub Unix zalogował się automatycznie do usługi Active Directory podczas uruchamiania, musisz użyć pliku .

Keytab jest plikiem kryptograficznym zawierającym reprezentację usługi chronionej przy użyciu protokołu Kerberos oraz długoterminowy klucz skojarzonej nazwy głównej usługi w Key Distribution Center (KDC). Klucz nie jest samym hasłem.

Tabliczki kluczowe są używane do jednego z następujących celów:

• uwierzytelnianie samej usługi w innej usłudze w sieci lub
• Odszyfruj bilet usługowy Kerberos użytkownika katalogu przychodzącego do usługi.

Co to jest plik krb5.conf?

Plik /etc/krb5.conf (nazywany również krb5.ini) zawiera dane wejściowe konfiguracji bibliotek Kerberos v5 (KRB5) i GNU Simple Authentication and Security Layer API (GSSAPI).

Te informacje obejmują domenę domyślną, właściwości każdej domeny (na przykład centra dystrybucji kluczy) i domyślny okres istnienia biletu Kerberos.

Ten plik jest niezbędny do działania uwierzytelniania usługi Active Directory. krb5.conf jest plikiem INI, ale każda wartość w parze klucz-wartość może być podgrupą ujętą w { i }.

Aby uzyskać więcej informacji na temat pliku krb5.conf, zapoznaj się z dokumentacją MIT Kerberos Consortium.

Konfigurowanie protokołu Kerberos dla programu SQL Server w systemie Linux

Są to wartości potrzebne na serwerze hosta z programem SQL Server w systemie Linux. Jeśli masz inne usługi (inne niż SQL Server) uruchomione na tym samym hoście, plik krb5.conf może wymagać kilku wpisów.

Oto przykładowy plik krb5.conf do celów referencyjnych:

[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 — wartość default_realm musi być obecna. Ta wartość określa domenę, do której należy maszyna hosta.

• realms (opcjonalnie) — dla każdego obszaru można ustawić wartość kdc, aby określić, które centra dystrybucji kluczy komputer powinien skontaktować się podczas wyszukiwania kont usługi Active Directory. Jeśli ustawiono więcej niż jedno centrum dystrybucji kluczy, centrum dystrybucji kluczy dla każdego połączenia zostanie wybrane przez działanie okrężne.

• domain_realm (opcjonalnie) — można podać mapowania dla każdego obszaru. Jeśli nie, program SQL Server w systemie Linux zakłada, że domena contoso.com odwzorowuje się na obszar CONTOSO.COM.

Proces uwierzytelniania Kerberos

Podobnie jak przy uwierzytelnianiu Kerberos w systemie Windows, dwa pierwsze kroki uzyskiwania biletu przyznawania dostępu (TGT) są takie same.

• Klient rozpoczyna proces logowania, wysyłając nazwę użytkownika i hasło (zaszyfrowane) do kontrolera domeny (DC).

• Po sprawdzeniu nazwy użytkownika i hasła względem magazynu wewnętrznego kontroler domeny zwraca bilet TGT dla użytkownika do klienta.

Program SQL Server w systemie Linux używa pliku keytab do odczytania hasła dla głównej nazwy usługi (SPN), a następnie odszyfrowuje zaszyfrowany obiekt blob, którego używa do autoryzowania połączenia. W następnych krokach opisano ten proces.

• Gdy użytkownik ma TGT, klient nawiązuje połączenie z programem SQL Server, określając nazwę hosta i port wystąpienia programu SQL Server.

• Klient SQL wewnętrznie tworzy nazwę główną usługi w formacie MSSQLSvc/<host>:<port>. Jest to zakodowany na stałe format w większości klientów programu SQL Server.

• Klient inicjuje uzgadnianie protokołu Kerberos, żądając klucza sesji z kontrolera domeny dla tej konkretnej nazwy SPN. Zarówno TGT, jak i SPN są wysyłane do kontrolera domeny (DC).

• Po zweryfikowaniu biletu TGT i SPN, kontroler domeny wysyła klucz sesji do klienta, aby nawiązać połączenie z SPN SQL Server.

• Zaszyfrowany blob z klucza sesji jest wysyłany do serwera.

• Program SQL Server odczytuje hasło powiązane z SPN z pliku keytab (mssql.keytab), który znajduje się na dysku i zawiera zaszyfrowane krotki (SPN, hasło).

• Program SQL Server odszyfrowuje zaszyfrowany obiekt blob od klienta przy użyciu właśnie wyszukanego hasła, aby uzyskać nazwę użytkownika klienta.

• Program SQL Server wyszukuje klienta w tabeli sys.syslogins, aby sprawdzić, czy klient ma autoryzację do nawiązania połączenia.

• Połączenie jest akceptowane lub odrzucane.

Konfigurowanie protokołu Kerberos dla kontenerów programu SQL Server

Uwierzytelnianie usługi Active Directory dla programu SQL Server w kontenerach jest zasadniczo takie samo jak program SQL Server w systemie Linux. Jedyną różnicą jest nazwa SPN hosta programu SQL Server. W poprzednim scenariuszu nazwa SPN została MSSQLSvc/<host>:<port>, ponieważ łączyliśmy się za pośrednictwem nazwy hosta programu SQL Server. Teraz jednak musimy nawiązać połączenie z kontenerem.

W przypadku kontenerów programu SQL Server można utworzyć plik krb5.conf wewnątrz kontenera. Serwer uruchamiający kontener nie musi być częścią domeny, ale powinien mieć możliwość nawiązania połączenia z kontrolerem domeny, z którym kontener spróbuje się połączyć.

Ponieważ łączymy się z kontenerem, nazwa serwera w połączeniu klienta może być inna niż tylko nazwa hosta. Może to być nazwa hosta, nazwa kontenera lub inny alias. Ponadto istnieje duża szansa, że uwidoczniony port dla programu SQL Server nie będzie domyślnym 1433.

Aby nawiązać połączenie z kontenerem programu SQL Server, musisz użyć nazwy SPN przechowywanej w mssql.keytab. Jeśli na przykład SPN w mssql.keytab jest MSSQLSvc/sqlcontainer.domain.com:8000, należy użyć sqlcontainer.domain.com,8000 jako connection string w kliencie (w tym sqlcmd, SQL Server Management Studio i Azure Data Studio).

Odświeżanie grupy programu SQL Server

Być może zastanawiasz się, dlaczego w pliku keytab znajduje się konto użytkownika, jeśli do uwierzytelniania potrzebny jest tylko Service Principal Name.

Załóżmy, że masz użytkownika adUser, który jest członkiem grupy adGroup. Jeśli adGroup zostanie dodana jako identyfikator logowania do programu SQL Server, oznacza to, że adUser ma również uprawnienia do logowania się do wystąpienia programu SQL Server. Mimo że adUser jest nadal połączony z programem SQL Server, administrator domeny może usunąć adUser z adGroup. Teraz adUser nie powinny już mieć uprawnień do logowania się do programu SQL Server, ale przeszły już proces uwierzytelniania Kerberos i są połączone.

Okresowo uruchamiamy proces o nazwie odświeżania grupy, aby chronić się przed scenariuszem, w którym użytkownik, który jest połączony, przestaje mieć uprawnienia do wykonywania akcji uprzywilejowanej (na przykład tworzenia logowania lub zmiany bazy danych).

Program SQL Server ma uprzywilejowane konto usługi Active Directory używane do odświeżania grup. Konto to jest skonfigurowane za pomocą mssql-conf z ustawieniem network.privilegedadaccount lub domyślnie używa konta komputera hostującej maszyny (<hostname>$).

Poświadczenia konta uprzywilejowanego w mssql.keytab są używane do impersonifikacji klienta (adUser w tym przykładzie). Program SQL Server wykonuje połączenie Kerberos z samym sobą, aby zidentyfikować informacje o członkostwie w grupie, a następnie porównuje je z sys.syslogins, aby sprawdzić, czy adUser nadal ma niezbędne uprawnienia do nawiązania połączenia i wykonania żądanych poleceń Transact-SQL. Jeśli adUser został usunięty z adGroup, połączenie zostanie zakończone przez program SQL Server.

Odświeżanie grupy wymaga następujących dwóch warunków:

• Łączność sieciowa między instancją SQL Server a lokalną domeną usługi Active Directory.
• Dwukierunkowa relacja zaufania między domeną, z którą jest połączony program SQL Server, a lokalną domeną usługi Active Directory. Aby uzyskać więcej informacji, zobacz Understanding Active Directory.

Powiązana zawartość

• Rozwiązywanie problemów z uwierzytelnianiem usługi Active Directory dla programu SQL Server w systemie Linux i kontenerach
• Obracanie plików keytab dla programu SQL Server w systemie Linux
• samouczek : konfigurowanie uwierzytelniania usługi Active Directory za pomocą programu SQL Server w systemie Linux przy użyciu narzędzia adutil w systemie Linux