Dela via

Förstå Active Directory-autentisering för SQL Server i Linux och containrar

  • Artikel

gäller för:SQL Server – Linux

Den här artikeln innehåller information om hur Active Directory-autentisering fungerar för SQL Server som distribueras i Linux eller containrar.

Begrepp

Protokoll för lättviktskatalogåtkomst (LDAP)

LDAP är ett programprotokoll för att arbeta med olika katalogtjänster, inklusive Active Directory. Katalogtjänster lagrar användar- och kontoinformation samt säkerhetsinformation som lösenord. Den informationen krypteras och delas sedan med andra enheter i nätverket.

Mer information om hur du skyddar LDAP finns i Så här aktiverar du LDAP-inloggning i Windows Server.

Kerberos

Kerberos är ett autentiseringsprotokoll som används för att verifiera identiteten för en användare eller värddator. Du kan se det som ett sätt att verifiera klienten och servern.

När du arbetar i en heterogen (blandad) miljö där du har Windows- och icke-Windows-servrar och -klienter finns det två typer av filer som du behöver arbeta med Active Directory-baserade katalogtjänster:

  • Keytab-filer (förkortning för "nyckeltabeller")
  • Kerberos-konfigurationsfiler (krb5.conf eller krb5.ini)

Vad är en nyckelfliksfil?

Serverprocesser i Linux- eller Unix-system kan inte konfigureras för att köra processer med ett Windows-tjänstkonto. När du vill att ett Linux- eller Unix-system automatiskt ska logga in på Active Directory vid start måste du använda en nyckelflik fil.

En nyckelflik är en kryptografisk fil som innehåller en representation av en Kerberos-skyddad tjänst och dess långsiktiga nyckel dess associerade tjänsthuvudnamn i Nyckeldistributionscenter (KDC). Nyckeln är inte själva lösenordet.

Nyckelflikar används för att antingen:

  • autentisera själva tjänsten till en annan tjänst i nätverket, eller
  • dekryptera Kerberos-tjänstbiljetten för en inkommande kataloganvändare till tjänsten.

Vad är en krb5.conf fil?

Den /etc/krb5.conf filen (kallas även krb5.ini) innehåller konfigurationsindata för Biblioteken Kerberos v5 (KRB5) och GNU Simple Authentication and Security Layer API (GSSAPI).

Den här informationen innehåller standarddomänen, egenskaperna för varje domän (till exempel Nyckeldistributionscenter) och standardlivslängden för Kerberos-biljetter.

Den här filen är nödvändig för att Active Directory-autentisering ska fungera. krb5.conf är en INI-fil, men varje värde i nyckel/värde-paret kan vara en undergrupp omgiven av { och }.

Mer information om filen krb5.conf finns i dokumentationen MIT Kerberos Consortium.

Konfigurera Kerberos för SQL Server i Linux

Det här är de värden du behöver på värdservern som kör SQL Server på Linux. Om du har andra (icke-SQL Server)-tjänster som körs på samma värd kan din krb5.conf fil behöva flera poster.

Här är ett exempel krb5.conf fil som referens:

[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 – värdet för default_realm måste finnas. Det här värdet anger den domän som värddatorn tillhör.

  • realms (valfritt) – För varje sfär kan det kdc värdet anges för att ange vilka nyckeldistributionscenter som datorn ska kontakta när du letar upp Active Directory-konton. Om du har angett mer än en KDC kommer KDC för varje anslutning att väljas i tur och ordning.

  • domain_realm (valfritt) – Mappningar för varje sfär kan tillhandahållas. Annars förutsätter SQL Server på Linux att domänen contoso.com mappar till sfären CONTOSO.COM.

Kerberos-autentiseringsprocessen

Precis som med Kerberos-autentisering i Windows är de två första stegen för att få en biljettbeviljande biljett (TGT) desamma:

  • En klient påbörjar inloggningsprocessen genom att skicka sitt användarnamn och lösenord (krypterat) till domänkontrollanten (DC).

  • Efter att användarnamnet och lösenordet har kontrollerats mot dess interna lagring returnerar domänkontrollanten en TGT för användaren till klienten.

SQL Server i Linux använder nyckelfliksfilen för att läsa lösenordet för tjänstens huvudnamn (SPN) och dekrypterar sedan den krypterade bloben, som används för att auktorisera anslutningen. Nästa steg beskriver den här processen.

  • När användaren har TGT startar klienten en anslutning till SQL Server genom att ange värdnamnet och porten för SQL Server-instansen.

  • SQL-klienten skapar internt ett tjänsthuvudnamn i formatet MSSQLSvc/<host>:<port>. Det här är ett hårdkodat format i de flesta SQL Server-klienter.

  • Klienten påbörjar Kerberos-handskakningen genom att begära en sessionsnyckel från domänkontrollanten (DC) för den SPN. Både TGT och SPN skickas till domänkontrollanten.

diagram som visar Active Directory-autentisering för SQL Server i Linux – Ticket-Granting biljett och tjänstens huvudnamn som skickas till domänkontrollanten.

  • När domänkontrollanten har verifierat TGT och SPN skickar den sessionsnyckeln till klienten för att ansluta till SQL Server SPN.

diagram som visar Active Directory-autentisering för SQL Server i Linux – sessionsnyckel som returneras till klienten av domänkontrollanten.

  • Den krypterade bloben från sessionsnyckeln skickas till servern.

diagram som visar Active Directory-autentisering för SQL Server i Linux – sessionsnyckel som skickas till servern.

  • SQL Server läser lösenordet för SPN från dess nyckelflik (mssql.keytab), som är en fil på disk som innehåller krypterade tupplar (SPN, lösenord).

  • SQL Server dekrypterar den krypterade bloben från klienten med det lösenord som den precis har letat upp för att hämta klientens användarnamn.

  • SQL Server letar upp klienten i tabellen sys.syslogins för att kontrollera om klienten har behörighet att ansluta.

  • Anslutningen accepteras eller nekas.

diagram som visar Active Directory-autentisering för SQL Server på Linux – anslutning accepterad eller nekad.

Konfigurera Kerberos för SQL Server-containrar

Active Directory-autentisering för SQL Server i containrar är i stort sett samma som SQL Server i Linux. Den enda skillnaden är SQL Server-värd-SPN. I föregående scenario var SPN MSSQLSvc/<host>:<port> eftersom vi anslöt via SQL Server-värdnamnet. Nu måste vi dock ansluta till containern.

För SQL Server-containrar kan du skapa krb5.conf-filen i containern. Värdnoden som kör containern behöver inte vara en del av domänen, men bör kunna nå den domänkontrollant som containern försöker ansluta till.

Eftersom vi ansluter till en container kan servernamnet i klientanslutningen skilja sig från bara värdnamnet. Det kan vara värdnamnet, containernamnet eller ett annat alias. Dessutom finns det en god chans att den exponerade porten för SQL Server inte är standard 1433.

Du måste använda det SPN som lagras i mssql.keytab för att ansluta till SQL Server-containern. Om SPN i mssql.keytab till exempel är MSSQLSvc/sqlcontainer.domain.com:8000använder du sqlcontainer.domain.com,8000 som anslutningssträng i klienten (inklusive sqlcmd, SQL Server Management Studio och Azure Data Studio).

diagram som visar Active Directory-autentisering för SQL Server-containrar.

Uppdatering av SQL Server-grupp

Du kanske undrar varför det finns ett användarkonto på nyckelfliken om du bara behöver ett tjänsthuvudnamn för att autentisera.

Anta att du har en användare adUser, som är medlem i en grupp adGroup. Om adGroup läggs till som en inloggning till SQL Server innebär det att adUser också har behörighet att logga in på SQL Server-instansen. Även om adUser fortfarande är ansluten till SQL Server kan en domänadministratör ta bort adUser från adGroup. Nu ska adUser inte längre ha behörighet att logga in på SQL Server, men de har redan godkänt Kerberos-autentiseringsprocessen och är anslutna.

Vi kör regelbundet en process som kallas gruppuppdatering för att skydda mot ett scenario där en ansluten användare inte längre tillåts utföra en privilegierad åtgärd (till exempel att skapa en inloggning eller ändra en databas).

SQL Server har ett privilegierat Active Directory-konto som används för gruppuppdatering. Det här kontot konfigureras antingen med hjälp av mssql-conf med inställningen network.privilegedadaccount eller standardinställningen för datorkontot för värddatorn (<hostname>$).

Autentiseringsuppgifterna för det privilegierade kontot i mssql.keytab används för att personifiera klienten (adUser i det här exemplet). SQL Server gör en Kerberos-handskakning med sig själv för att identifiera gruppmedlemskapsinformationen och jämför den med sys.syslogins för att kontrollera om adUser fortfarande har de behörigheter som krävs för att ansluta och köra de begärda Transact-SQL kommandona. Om adUser har tagits bort från adGroupavslutas anslutningen av SQL Server.

Gruppuppdatering kräver följande två villkor:

  • Nätverksanslutning mellan SQL Server-instansen och den lokala Active Directory-domänen.
  • Dubbelriktat förtroende mellan domänen som SQL Server är ansluten till och det lokala nätverkets Active Directory-domän. Mer information finns i Understanding Active Directory.

Relaterat innehåll