Självstudie: Använda Active Directory-autentisering med SQL Server i Linux

gäller för:SQL Server – Linux

I den här självstudien beskrivs hur du konfigurerar SQL Server på Linux för att stödja Active Directory-autentisering, även kallat integrerad autentisering. En översikt finns i Active Directory-autentisering för SQL Server på Linux.

Den här självstudien består av följande uppgifter:

• Anslut SQL Server-värden till en Active Directory-domän
• Skapa Active Directory-användare för SQL Server och ange SPN
• Konfigurera nyckelfliken för SQL Server-tjänsten
• Skydda nyckelfliksfilen
• Konfigurera SQL Server för att använda nyckelfliksfilen för Kerberos-autentisering
• Skapa Active Directory-baserade inloggningar i Transact-SQL
• Ansluta till SQL Server med Hjälp av Active Directory-autentisering

Förutsättningar

Innan du konfigurerar Active Directory-autentisering måste du:

• Konfigurera en Active Directory-domänkontrollant (Windows) i nätverket
• Installera SQL Server
  • snabbstart: Installera SQL Server och skapa en databas på Red Hat
  • snabbstart: Installera SQL Server och skapa en databas på SUSE Linux Enterprise Server
  • Snabbstart: Installera SQL Server och skapa en databas på Ubuntu

Anslut SQL Server-värd till Active Directory-domän

Anslut din SQL Server Linux-värd med en Active Directory-domänkontrollant. Information om hur du ansluter till en active directory-domän finns i Join SQL Server on a Linux host to an Active Directory domain.

Skapa Active Directory-användare för SQL Server och ange SPN

Notera

Följande steg använder ditt fullständigt kvalificerade domännamn (FQDN). Om du använder Azure måste du skapa ett FQDN- innan du fortsätter.

1. Kör kommandot New-ADUser PowerShell på domänkontrollanten för att skapa en ny Active Directory-användare med ett lösenord som aldrig upphör att gälla. I följande exempel namnges kontot sqlsvc, men kontonamnet kan vara vad du vill. Du uppmanas att ange ett nytt lösenord för kontot.

   Import-Module ActiveDirectory
   
   New-ADUser sqlsvc -AccountPassword (Read-Host -AsSecureString "Enter Password") -PasswordNeverExpires $true -Enabled $true
   

   Not

   Det är en säkerhetsmetod att ha ett dedikerat Active Directory-konto för SQL Server, så att autentiseringsuppgifterna för SQL Server-instansen inte delas med andra tjänster med samma konto. Du kan dock återanvända ett befintligt Active Directory-konto om du känner till kontots lösenord (vilket krävs för att generera en nyckelfliksfil i nästa steg). Dessutom bör kontot vara aktiverat för att stödja 128-bitars och 256-bitars Kerberos AES-kryptering (msDS-SupportedEncryptionTypes attribut) för användarkontot. Om du vill verifiera att kontot är aktiverat för AES-kryptering letar du upp kontot i Active Directory- verktyg och väljer Egenskaper. Leta upp fliken Konton i Egenskaperoch kontrollera att följande två kryssrutor är markerade.

   1. Det här kontot stöder Kerberos AES 128-bitarskryptering

   2. Det här kontot stöder Kerberos AES 256-bitarskryptering

2. Ange ServicePrincipalName (SPN) för det här kontot med hjälp av verktyget setspn.exe. SPN måste formateras exakt enligt vad som anges i följande exempel. Du hittar det fullständigt kvalificerade domännamnet för SQL Server-värddatorn genom att köra hostname --all-fqdns på SQL Server-värddatorn. TCP-porten ska vara 1433 om du inte har konfigurerat SQL Server att använda ett annat portnummer.

   setspn -A MSSQLSvc/<fully qualified domain name of host machine>:<tcp port> sqlsvc
   setspn -A MSSQLSvc/<netbios name of the host machine>:<tcp port> sqlsvc
   

   Note

   Om du får ett fel Insufficient access rightskontrollerar du med domänadministratören att du har tillräcklig behörighet för att ange ett SPN för det här kontot. Det konto som används för att registrera ett SPN behöver Write servicePrincipalName behörigheter. För mer information, se Registrera ett tjänsthuvudnamn för Kerberos-anslutningar.

   Om du ändrar TCP-porten i framtiden måste du köra kommandot setspn igen med det nya portnumret. Du måste också lägga till det nya SPN i nyckelfliken SQL Server-tjänsten genom att följa stegen i nästa avsnitt.

För mer information, se Registrera ett tjänsthuvudnamn för Kerberos-anslutningar.

Konfigurera nyckelfliken för SQL Server-tjänsten

För att konfigurera Active Directory-autentisering för SQL Server i Linux krävs ett Active Directory-användarkonto och det SPN som skapades i föregående avsnitt.

Viktig

Om lösenordet för Active Directory-kontot ändras eller lösenordet för det konto som SPN:erna har tilldelats ändras, måste du uppdatera nyckelfliken med det nya lösenordet och nyckelversionsnumret (KVNO). Vissa tjänster kan också rotera lösenorden automatiskt. Granska eventuella principer för lösenordsrotation för de aktuella kontona och anpassa dem till schemalagda underhållsaktiviteter för att undvika oväntade driftstopp.

SPN-nyckelfliksposter

1. Kontrollera nyckelversionsnumret (KVNO) för det Active Directory-konto som skapades i föregående steg. Vanligtvis är det 2, men det kan vara ett annat heltal om du har ändrat kontots lösenord flera gånger. Kör följande kommandon på SQL Server-värddatorn:

   • Exemplen nedan förutsätter att user finns i domänen @CONTOSO.COM. Ändra användaren och domännamnet till ditt användarnamn och domännamn.

   kinit user@CONTOSO.COM
   kvno user@CONTOSO.COM
   kvno MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM
   

   Not

   DET kan ta flera minuter för SPN att spridas via din domän, särskilt om domänen är stor. Om du får felet kvno: Server not found in Kerberos database while getting credentials for MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COMväntar du några minuter och försöker igen. De tidigare kommandona fungerar bara om servern har anslutits till en Active Directory-domän, som beskrevs i ett tidigare avsnitt.

2. Med hjälp av ktpasslägger du till nyckelfliksposter för varje SPN med hjälp av följande kommandon i en kommandotolk för Windows-datorn:

   • <DomainName>\<UserName> – Active Directory-användarkonto
   • @CONTOSO.COM – Använd ditt domännamn
   • /kvno <#> – Ersätt <#> med KVNO som erhölls i ett tidigare steg
   • <password> – Lösenordet bör följa SQL Server-standardprincipen lösenordsprincip. Lösenordet måste som standard vara minst åtta tecken långt och innehålla tecken från tre av följande fyra uppsättningar: versaler, gemener, bas-10 siffror och symboler. Lösenord kan vara upp till 128 tecken långa. Använd lösenord som är så långa och komplexa som möjligt.

   ktpass /princ MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
   
   ktpass /princ MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
   
   ktpass /princ MSSQLSvc/<netbios name of the host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
   
   ktpass /princ MSSQLSvc/<netbios name of the host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
   
   ktpass /princ <UserName>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
   
   ktpass /princ <UserName>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
   

   De tidigare kommandona tillåter både AES- och RC4-krypteringskryptering för Active Directory-autentisering. RC4 är en gammal krypteringsalgoritm och om en högre säkerhetsnivå krävs kan du välja att skapa keytab-posterna med endast AES-krypteringsalgoritmen.

   Note

   De två sista UserName-inläggen måste vara i gemener, annars kan autentiseringen misslyckas.

3. När du har kört föregående kommandon bör du ha en nyckelfliksfil med namnet mssql.keytab. Kopiera filen till SQL Server-datorn under mappen /var/opt/mssql/secrets.

4. Skydda nyckelfliksfilen.

   Alla som har åtkomst till den här nyckelfliksfilen kan personifiera SQL Server på domänen, så se till att du begränsar åtkomsten till filen så att endast mssql-kontot har läsåtkomst:

   sudo chown mssql:mssql /var/opt/mssql/secrets/mssql.keytab
   sudo chmod 400 /var/opt/mssql/secrets/mssql.keytab
   

5. Följande konfigurationsalternativ måste anges med verktyget mssql-conf för att ange det konto som ska användas vid åtkomst till nyckelfliksfilen.

   sudo mssql-conf set network.privilegedadaccount <username>
   

   Not

   Inkludera endast användarnamnet och inte domännamnet\användarnamnet eller username@domain. SQL Server lägger internt till domännamn som krävs tillsammans med det här användarnamnet när det används.

6. Använd följande steg för att konfigurera SQL Server att börja använda nyckelfliksfilen för Kerberos-autentisering.

   sudo mssql-conf set network.kerberoskeytabfile /var/opt/mssql/secrets/mssql.keytab
   sudo systemctl restart mssql-server
   

   Du kan också inaktivera UDP-anslutningar till domänkontrollanten för att förbättra prestandan. I många fall misslyckas UDP-anslutningar konsekvent när du ansluter till en domänkontrollant, så du kan ange konfigurationsalternativ i /etc/krb5.conf för att hoppa över UDP-anrop. Redigera /etc/krb5.conf och ange följande alternativ:

   /etc/krb5.conf
   [libdefaults]
   udp_preference_limit=0
   

Nu är du redo att använda Active Directory-baserade inloggningar i SQL Server.

Skapa Active Directory-baserade inloggningar i Transact-SQL

1. Anslut till SQL Server och skapa en ny Active Directory-baserad inloggning:

   CREATE LOGIN [CONTOSO\user]
       FROM WINDOWS;
   

2. Kontrollera att inloggningen nu visas i systemkatalogvyn sys.server_principals.

   SELECT name
   FROM sys.server_principals;
   

Ansluta till SQL Server med Hjälp av Active Directory-autentisering

Logga in på en klientdator med dina domänautentiseringsuppgifter. Nu kan du ansluta till SQL Server utan att ange lösenordet igen med hjälp av Active Directory-autentisering. Om du skapar en inloggning för en Active Directory-grupp kan alla Active Directory-användare som är medlem i gruppen ansluta på samma sätt.

Den specifika anslutningssträngsparametern för klienter som ska använda Active Directory-autentisering beror på vilken drivrutin du använder. Tänk på exemplen i följande avsnitt.

sqlcmd på en domänansluten Linux-klient

Logga in på en domänansluten Linux-klient med ssh- och dina domänautentiseringsuppgifter:

ssh -l user@contoso.com client.contoso.com

Kontrollera att du har installerat mssql-tools-paketet och anslut sedan med sqlcmd- utan att ange några autentiseringsuppgifter:

sqlcmd -S mssql-host.contoso.com

Utöver SQL Windows fungerar Kerberos-autentisering för lokal anslutning i SQL Linux. Du måste dock fortfarande ange FQDN för SQL Linux-värd, och Active Directory-autentisering fungerar inte om du försöker att ansluta till ., localhost, 127.0.0.1osv.

SSMS på en domänansluten Windows-klient

Logga in på en domänansluten Windows-klient med dina domänautentiseringsuppgifter. Kontrollera att SQL Server Management Studio är installerat och anslut sedan till SQL Server-instansen (till exempel mssql-host.contoso.com) genom att ange Windows-autentisering i dialogrutan Anslut till server.

Active Directory-autentisering med andra klientdrivrutiner

I följande tabell beskrivs rekommendationer för andra klientdrivrutiner:

Klientdrivrutin	Rekommendation
JDBC	Använd Kerberos-integrerad autentisering för att ansluta SQL Server.
ODBC	Använd integrerad autentisering.
ADO.NET	Syntax för anslutningssträng.

Ytterligare konfigurationsalternativ

Om du använder verktyg från tredje part, till exempel PBIS, VASeller Centrify för att ansluta Linux-värden till Active Directory-domänen och du vill tvinga SQL Server att använda OpenLDAP-biblioteket direkt, kan du konfigurera alternativet disablesssd med mssql-conf på följande sätt:

sudo mssql-conf set network.disablesssd true
systemctl restart mssql-server

Not

Det finns verktyg som realmd som konfigurerar SSSD, medan andra verktyg som PBIS, VAS och Centrify inte gör det. Om det verktyg som används för att ansluta till Active Directory-domänen inte konfigurerar SSSD bör du konfigurera alternativet disablesssd till true. Även om det inte krävs eftersom SQL Server försöker använda SSSD för Active Directory innan det återgår till OpenLDAP-mekanismen, skulle det vara mer högpresterande att konfigurera det så att SQL Server gör OpenLDAP-anrop direkt genom att kringgå SSSD-mekanismen.

Om domänkontrollanten stöder LDAPS kan du tvinga alla anslutningar från SQL Server till domänkontrollanterna att vara över LDAPS. Kontrollera att klienten kan kontakta domänkontrollanten via LDAPS genom att köra följande bash-kommando ldapsearch -H ldaps://contoso.com:3269. Om du vill ange att SQL Server endast ska använda LDAPS kör du följande:

sudo mssql-conf set network.forcesecureldap true
systemctl restart mssql-server

Det här använder LDAPS via SSSD om Active Directory-domänanslutningen på värden utfördes med hjälp av SSSD-paketet och disablesssd inte är satt till true. Om disablesssd är inställt på sant och forcesecureldap är inställt på sant, använder SQL Server LDAPS-protokoll genom att använda OpenLDAP-biblioteksanrop.

Post SQL Server 2017 CU 14

Från och med SQL Server 2017 (14.x) CU 14, om SQL Server har anslutits till en Active Directory-domänkontrollant med tredjepartsleverantörer och har konfigurerats för att använda OpenLDAP-anrop för allmän Active Directory-sökning genom att ange disablesssd till sant, kan du också använda enablekdcfromkrb5 alternativ för att tvinga SQL Server att använda krb5-bibliotek för KDC-sökning i stället för omvänd DNS-sökning för KDC-server.

Detta kan vara användbart för scenariot där du vill konfigurera de domänkontrollanter som SQL Server försöker kommunicera med manuellt. Och du använder OpenLDAP-biblioteksmekanismen med hjälp av KDC-listan i krb5.conf.

Ange först disablesssd och enablekdcfromkrb5conf till true och starta sedan om SQL Server:

sudo mssql-conf set network.disablesssd true
sudo mssql-conf set network.enablekdcfromkrb5conf true
systemctl restart mssql-server

Konfigurera sedan KDC-listan i /etc/krb5.conf enligt följande:

[realms]
CONTOSO.COM = {
  kdc = dcWithGC1.contoso.com
  kdc = dcWithGC2.contoso.com
}

Även om det inte rekommenderas är det möjligt att använda verktyg som realmd, vilka konfigurerar SSSD när du ansluter Linux-värden till domänen, samtidigt som du konfigurerar disablesssd till true så att SQL Server använder OpenLDAP-anrop i stället för SSSD för anrop relaterade till Active Directory.

Notera

SQL Server-inloggning med hjälp av ett FQDN (till exempel CONTOSO.COM\Username) stöds inte. Använd formatet CONTOSO\Username.

SQL Server-inloggningar från lokala domängrupper stöds inte. Använd globala säkerhetsdomängrupper i stället.

Relaterat innehåll

• Kryptera anslutningar till SQL Server på Linux
• Förstå Active Directory-autentisering för SQL Server på Linux och containrar
• Felsöka Active Directory-autentisering för SQL Server på Linux och containrar

Bidra till SQL-dokumentation

Visste du att du kan redigera SQL-innehåll själv? Om du gör det hjälper du inte bara till att förbättra vår dokumentation, utan du får även kredit som deltagare på sidan.

Mer information finns i Så här bidrar du till SQL Server-dokumentationen