Sdílet prostřednictvím

Principy ověřování Active Directory pro SQL Server v Linuxu a kontejnerech

  • Článek

platí pro:SQL Server – Linux

Tento článek obsahuje podrobnosti o tom, jak funguje ověřování Active Directory pro SQL Server nasazený v Linuxu nebo kontejnerech.

Koncepty

Protokol LDAP (Lightweight Directory Access Protocol)

LDAP je aplikační protokol pro práci s různými adresářovými službami, včetně služby Active Directory. Adresářové služby ukládají informace o uživateli a účtu a informace o zabezpečení, jako jsou hesla. Informace se šifrují a pak sdílí s jinými zařízeními v síti.

Další informace o zabezpečení PROTOKOLU LDAP najdete v tématu Jak povolit přihlašování ldap v systému Windows Server.

Kerberos

Kerberos je ověřovací protokol používaný k ověření identity uživatele nebo hostitelského počítače. Můžete si to představit jako způsob, jak ověřit klienta a server.

Když pracujete v heterogenním (smíšeném) prostředí, kde máte servery a klienty Windows a jiné systémy než Windows, musíte pracovat se dvěma typy souborů, které potřebujete pracovat s adresářovými službami založenými na službě Active Directory:

  • Soubory keytab (zkráceně pro "klíčové tabulky")
  • Konfigurační soubory Kerberos (krb5.conf nebo krb5.ini)

Co je soubor keytab?

Serverové procesy v systémech Linux nebo Unix nelze nakonfigurovat tak, aby spouštěly procesy s účtem služby systému Windows. Pokud chcete, aby se systém Linux nebo Unix automaticky přihlásil ke službě Active Directory při spuštění, musíte použít soubor keytab.

Keytab je kryptografický soubor obsahující reprezentaci služby chráněné protokolem Kerberos a dlouhodobý klíč jejího přidruženého názvu hlavní služby v Centru distribuce klíčů (KDC). Klíč není samotné heslo.

Klávesové zkratky se používají pro:

  • ověřit samotnou službu vůči jiné službě v síti nebo
  • dešifrujte lístek služby Kerberos příchozího uživatele adresáře do služby.

Co je soubor krb5.conf?

Soubor /etc/krb5.conf (označovaný také jako krb5.ini) poskytuje vstupy konfigurace pro knihovny Kerberos v5 (KRB5) a GNU Simple Authentication and Security Layer API (GSSAPI).

Tyto informace zahrnují výchozí doménu, vlastnosti každé domény (například distribuční centra klíčů) a výchozí životnost lístku Kerberos.

Tento soubor je nezbytný k tomu, aby ověřování služby Active Directory fungovalo. krb5.conf je soubor INI, ale každá hodnota v páru klíč-hodnota může být podskupina uzavřená mezi { a }.

Další informace o souboru krb5.conf naleznete v dokumentaci MIT Kerberos Consortium.

Konfigurace protokolu Kerberos pro SQL Server v Linuxu

Jedná se o hodnoty, které potřebujete na hostitelském serveru s SQL Serverem v Linuxu. Pokud máte na stejném hostiteli spuštěné jiné služby (než SQL Server), může váš soubor krb5.conf potřebovat několik dalších položek.

Tady je ukázkový soubor krb5.conf pro referenci:

[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 – musí existovat hodnota default_realm. Tato hodnota určuje doménu, do které patří hostitelský počítač.

  • realms (volitelné) – Pro každou doménu může být hodnota kdc nastavena tak, aby určovala, která Key Distribution Centers má počítač kontaktovat při vyhledávání účtů v Active Directory. Pokud jste nastavili více KDC, bude KDC pro každé připojení vybráno kruhovým dotazováním.

  • domain_realm (volitelné) – Je možné poskytnout mapování pro každou sféru. Pokud ne, SQL Server v Linuxu předpokládá, že doména contoso.com mapuje na sféru CONTOSO.COM.

Proces ověřování protokolem Kerberos

Podobně jako u Kerberos autentizace ve Windows jsou první dva kroky k získání pověřovacího lístku (TGT) stejné:

  • Klient zahájí proces přihlášení odesláním uživatelského jména a hesla (šifrovaného) do řadiče domény (DC).

  • Po kontrole uživatelského jména a hesla vůči internímu úložišti řadič domény vrátí klientovi TGT.

SQL Server v Linuxu používá soubor keytab ke čtení hesla pro hlavní název služby (SPN) a dešifruje šifrovaný objekt blob, který používá k autorizaci připojení. Další kroky popisují tento proces.

  • Jakmile má uživatel TGT, klient spustí připojení k SQL Serveru zadáním názvu hostitele a portu instance SQL Serveru.

  • Klient SQL interně vytvoří instanční název ve formátu MSSQLSvc/<host>:<port>. Jedná se o pevně zakódovaný formát ve většině klientů SQL Serveru.

  • Klient zahájí handshake protokolu Kerberos tím, že požádá o klíč relace z DC pro tento SPN. TGT i SPN se odesílají do řadiče domény.

Diagram znázorňující ověřování Active Directory pro SQL Server na Linuxu – Ticket-Granting Lístek a hlavní název služby byly odeslány na řadič domény.

  • Jakmile řadič domény ověří hlavní název služby (TGT) a hlavní název služby (SPN) klienta, odešle klíč relace klientovi pro připojení k hlavnímu názvu služby (SPN) SQL Serveru.

Diagram znázorňující ověřování Active Directory pro SQL Server v systému Linux – klíč relace vrácený klientovi řadičem domény

  • Šifrovaný blob vytvořený z klíče relace se odešle na server.

diagram znázorňující ověřování Active Directory pro SQL Server v Linuxu – klíč relace odeslaný na server

  • SQL Server přečte heslo hlavního názvu služby ze svého keytabu (mssql.keytab), což je soubor na disku obsahující šifrované dvojice (SPN, heslo).

  • SQL Server dešifruje šifrovaný objekt blob z klienta pomocí hesla, které právě hledal, a získá uživatelské jméno klienta.

  • SQL Server vyhledá klienta v tabulce sys.syslogins a zkontroluje, jestli má klient oprávnění k připojení.

  • Připojení je buď přijato, nebo zamítnuto.

diagram znázorňující ověřování Active Directory pro SQL Server v Linuxu – připojení se přijalo nebo zamítlo.

Konfigurace protokolu Kerberos pro kontejnery SQL Serveru

Ověřování Active Directory pro SQL Server v kontejnerech je v podstatě stejné jako SQL Server v Linuxu. Jediným rozdílem je hlavní název služby hostitele SQL Serveru SPN. V předchozím scénáři byl SPN MSSQLSvc/<host>:<port>, protože jsme se připojovali pomocí názvu hostitele SQL Serveru. Teď se ale musíme připojit k kontejneru.

Pro kontejnery SQL Serveru můžete vytvořit soubor krb5.conf uvnitř kontejneru. Hostitelský uzel, na kterém je spuštěný kontejner, nemusí být součástí domény, ale měl by být schopný se připojit k řadiči domény, ke kterému se kontejner pokusí připojit.

Vzhledem k tomu, že se připojujeme k kontejneru, může se název serveru v připojení klienta lišit od názvu hostitele. Může to být název hostitele, název kontejneru nebo jiný alias. Kromě toho existuje dobrá šance, že vystavený port pro SQL Server nebude výchozí 1433.

Musíte použít hlavní název služby (SPN), který je uložený v mssql.keytab pro připojení k kontejneru SQL Serveru. Pokud je například SPN v mssql.keytabMSSQLSvc/sqlcontainer.domain.com:8000, použili byste v klientovi jako připojovací řetězec sqlcontainer.domain.com,8000 (včetně sqlcmd, SQL Server Management Studio a Azure Data Studio).

diagram znázorňující ověřování active directory pro kontejnery SQL Serveru

Aktualizace skupiny SQL Serveru

Možná vás zajímá, proč je v tabulce klíčů uživatelský účet, pokud k ověření potřebujete jenom hlavní název služby.

Představte si, že máte uživatele adUser, což je člen skupiny adGroup. Pokud adGroup přidáte jako přihlášení k SQL Serveru, znamená to, že adUser má také oprávnění přihlásit se k instanci SQL Serveru. Zatímco adUser je stále připojen k SQL Serveru, správce domény může odebrat adUser z adGroup. Teď by adUser už neměl mít oprávnění k přihlášení k SQL Serveru, ale již prošli procesem ověřování Kerberos a jsou již připojeni.

Pravidelně spouštíme proces označovaný jako aktualizace skupiny k ochraně před scénářem, kdy už připojený uživatel nesmí provádět privilegovanou akci (například vytvoření přihlášení nebo změnu databáze).

SQL Server má privilegovaný účet služby Active Directory, který používá k aktualizaci skupiny. Tento účet je buď nakonfigurovaný pomocí mssql-conf s nastavením network.privilegedadaccount, nebo se jako výchozí používá účet hostitelského počítače (<hostname>$).

Přihlašovací údaje pro privilegovaný účet v mssql.keytab slouží k zosobnění klienta (adUser v tomto příkladu). SQL Server provádí metodu handshake protokolu Kerberos, která identifikuje informace o členství ve skupině, a porovná je s sys.syslogins, aby zkontroloval, jestli adUser stále má oprávnění potřebná k připojení a spuštění požadovaných příkazů Transact-SQL. Pokud adUser byl odebrán z adGroup, připojení je ukončeno SQL Serverem.

Aktualizace skupiny vyžaduje následující dvě podmínky:

  • Síťové připojení mezi instancí SQL Serveru a místní doménou služby Active Directory.
  • Obousměrný vztah důvěryhodnosti mezi doménou, ke které je SQL Server připojený, a místní doménou služby Active Directory. Další informace najdete v tématu Principyslužby Active Directory .

Související obsah