Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för:
SQL Server i Linux
Den här artikeln hjälper dig att felsöka problem med Doménové služby Active Directory-autentisering med SQL Server i Linux och containrar. Den innehåller nödvändiga kontroller och tips för en lyckad služba Active Directory-konfiguration och en lista över vanliga fel och felsökningssteg.
Verifiera den aktuella konfigurationen
Innan du börjar felsöka, validera den aktuella användaren, mssql.conf, Service Principal Name (SPN) och realm-inställningarna.
Skaffa eller förnya Kerberos TGT (biljettgivande biljett) med
kinit:kinit privilegeduser@CONTOSO.COMKör följande kommando och se till att användaren som kör det har tillgång till
mssql.keytab:/opt/mssql/bin/mssql-conf validate-ad-config /var/opt/mssql/secrets/mssql.keytabFör mer information om kommandot
validate-ad-config, kör/opt/mssql/bin/mssql-conf validate-ad-config --help.
DNS- och omvända DNS-sökningar
DNS-sökningar på domännamnet och NetBIOS-namnet ska returnera samma IP-adress, som normalt matchar IP-adressen för domänkontrollanten (DC). Kör dessa kommandon från SQL Server-värddatorn.
nslookup contoso nslookup contoso.comOm IP-adresserna inte matchar kan du läsa Ansluta SQL Server på en Linux-värd till en služba Active Directory-domän för att åtgärda DNS-sökningar och kommunikation med domänkontrollanten.
Utför en omvänd DNS (rDNS) sökning för varje IP-adress från tidigare resultat. Inkludera IPv4- och IPv6-adresser där det är tillämpligt.
nslookup <IPs returned from the above commands>Alla bör returnera
<hostname>.contoso.com. Annars, kontrollera PTR-posterna (pekaren) i služba Active Directory.Du kan behöva arbeta med domänadministratören för att få rDNS att fungera. Om du inte kan lägga till PTR-poster för alla returnerade IP-adresser kan du också begränsa SQL Server till en delmängd domänkontroller. Den här ändringen påverkar andra tjänster som använder
krb5.confpå servern.Mer information om omvänd DNS finns i Vad är omvänd DNS?
Kontrollera nyckelflikens fil och behörigheter
Kontrollera att du har skapat keytab (nyckeltabellen) och att du konfigurerat
mssql-confatt använda rätt fil med lämpliga behörigheter. Nyckelfliken måste vara tillgänglig förmssqlanvändarkonto. Mer information finns i Använd adutil för att konfigurera služba Active Directory-autentisering med SQL Server på Linux.Se till att du kan lista innehållet i nyckelfliken och att du har lagt till rätt SPN, port, krypteringstyp och användarkonto. Om du inte skriver in lösenorden korrekt när du skapar SPN:er och keytab-poster stöter du på fel när du försöker logga in med služba Active Directory-autentisering.
klist -kte /var/opt/mssql/secrets/mssql.keytabEtt exempel på en fungerande nyckelflik följer. I exemplet används två krypteringstyper, men du kan bara använda en eller flera beroende på vilka krypteringstyper som stöds i din miljö. I exemplet
sqluser@CONTOSO.COMär det privilegierade kontot (som matcharnetwork.privilegedadaccountinställningen imssql-conf) och värdnamnet för SQL Serversqllinux.contoso.comlyssnar på standardporten1433.$ kinit privilegeduser@CONTOSO.COM Password for privilegeduser@CONTOSO.COM: $ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: privilegeduser@CONTOSO.COM Valid starting Expires Service principal 01/26/22 20:42:02 01/27/22 06:42:02 krbtgt/CONTOSO.COM@CONTOSO.COM renew until 01/27/22 20:41:57 $ klist -kte /var/opt/mssql/secrets/mssql.keytab Keytab name: FILE:/var/opt/mssql/secrets/mssql.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 2 01/13/22 13:19:47 MSSQLSvc/sqllinux@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux:1433@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux:1433@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com:5533@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com:5533@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:55 sqluser@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:55 sqluser@CONTOSO.COM (aes128-cts-hmac-sha1-96)
Verifiera domäninformation i krb5.conf
I
krb5.conf(finns på/etc/krb5.conf) kontrollerar du att du anger värden för standardsfär, sfärinformation och domän till sfärmappning. Gå igenom följande exempelfilkrb5.conf. Mer information finns i Förstå služba Active Directory-autentisering för SQL Server på Linux och containrar.[libdefaults] default_realm = CONTOSO.COM default_keytab_name = /var/opt/mssql/secrets/mssql.keytab default_ccache_name = "" [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.COMDu kan begränsa SQL Server till att kontakta en delmängd domänkontrollanter, vilket är användbart om DNS-konfigurationen returnerar fler domänkontrollanter än vad SQL Server behöver kontakta. SQL Server on Linux låter dig specificera en lista över domänkontrollanter som SQL Server kontaktar i en rund-robin-metod när du utför en Lightweight Directory Access Protocol (LDAP)-uppslagning.
Slutför dessa två steg. Först, ändra
krb5.confgenom att lägga till de domänkontrollanter du behöver, med prefixetkdc =.[realms] CONTOSO.COM = { kdc = kdc1.contoso.com kdc = kdc2.contoso.com .. .. }Filen
krb5.confär en vanlig Kerberos-klientkonfigurationsfil, så alla ändringar du gör i denna fil påverkar andra tjänster utöver SQL Server. Innan du gör några ändringar, rådgör du med din domänadministratör.Aktivera inställningen
network.enablekdcfromkrb5confmedmssql-conf, och starta sedan om SQL Server:sudo /opt/mssql/bin/mssql-conf set network.enablekdcfromkrb5conf true sudo systemctl restart mssql-server
Att felsöka Kerberos
Följande detaljer hjälper dig att felsöka autentiseringsproblem i služba Active Directory och identifiera specifika felmeddelanden.
Spåra Kerberos
Efter att du skapat användaren, SPN:erna och keytabs, och konfigureratmssql-conf, verifiera služba Active Directory-konfigurationen.
För att verifiera konfigurationen för SQL Server on Linux, använd det privilegierade kontot för att hämta eller förnya Kerberos TGT. Kör detta kommando för att visa Kerberos-spårningsmeddelandena i konsolen (stdout):
root@sqllinux mssql# KRB5_TRACE=/dev/stdout kinit -kt /var/opt/mssql/secrets/mssql.keytab sqluser
Om det inte finns några problem bör du se utdata som liknar följande exempel. Om inte, ger spårningen kontext om vilka steg som ska granskas.
3791545 1640722276.100275: Getting initial credentials for sqluser@CONTOSO.COM
3791545 1640722276.100276: Looked up etypes in keytab: aes256-cts, aes128-cts
3791545 1640722276.100278: Sending unauthenticated request
3791545 1640722276.100279: Sending request (202 bytes) to CONTOSO.COM
3791545 1640722276.100280: Initiating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100281: Sending TCP request to stream 10.0.0.4:88
3791545 1640722276.100282: Received answer (185 bytes) from stream 10.0.0.4:88
3791545 1640722276.100283: Terminating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100284: Response was from master KDC
3791545 1640722276.100285: Received error from KDC: -1765328359/Additional pre-authentication required
3791545 1640722276.100288: Preauthenticating using KDC method data
3791545 1640722276.100289: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2)
3791545 1640722276.100290: Selected etype info: etype aes256-cts, salt "CONTOSO.COMsqluser", params ""
3791545 1640722276.100291: Retrieving sqluser@CONTOSO.COM from /var/opt/mssql/secrets/mssql.keytab (vno 0, enctype aes256-cts) with result: 0/Success
3791545 1640722276.100292: AS key obtained for encrypted timestamp: aes256-cts/E84B
3791545 1640722276.100294: Encrypted timestamp (for 1640722276.700930): plain 301AA011180F32303231313XXXXXXXXXXXXXXXXXXXXXXXXXXXXX, encrypted 333109B95898D1B4FC1837DAE3E4CBD33AF8XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
3791545 1640722276.100295: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
3791545 1640722276.100296: Produced preauth for next request: PA-ENC-TIMESTAMP (2)
3791545 1640722276.100297: Sending request (282 bytes) to CONTOSO.COM
3791545 1640722276.100298: Initiating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100299: Sending TCP request to stream 10.0.0.4:88
3791545 1640722276.100300: Received answer (1604 bytes) from stream 10.0.0.4:88
3791545 1640722276.100301: Terminating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100302: Response was from master KDC
3791545 1640722276.100303: Processing preauth types: PA-ETYPE-INFO2 (19)
3791545 1640722276.100304: Selected etype info: etype aes256-cts, salt "CONTOSO.COMsqluser", params ""
3791545 1640722276.100305: Produced preauth for next request: (empty)
3791545 1640722276.100306: AS key determined by preauth: aes256-cts/E84B
3791545 1640722276.100307: Decrypted AS reply; session key is: aes256-cts/05C0
3791545 1640722276.100308: FAST negotiation: unavailable
3791545 1640722276.100309: Initializing KCM:0:37337 with default princ sqluser@CONTOSO.COM
3791545 1640722276.100310: Storing sqluser@CONTOSO.COM -> krbtgt/CONTOSO.COM@CONTOSO.COM in KCM:0:37337
3791545 1640722276.100311: Storing config in KCM:0:37337 for krbtgt/CONTOSO.COM@CONTOSO.COM: pa_type: 2
3791545 1640722276.100312: Storing sqluser@CONTOSO.COM -> krb5_ccache_conf_data/pa_type/krbtgt/CONTOSO.COM@CONTOSO.COM@X-CACHECONF: in KCM:0:37337
$ sudo klist
Ticket cache: KCM:0:37337
Default principal: sqluser@CONTOSO.COM
Valid starting Expires Service principal
12/28/2021 20:11:16 12/29/2021 06:11:16 krbtgt/CONTOSO.COM@CONTOSO.COM
renew until 01/04/2022 20:11:16
Aktivera Kerberos och säkerhetsbaserad PAL-loggning
För att identifiera specifika felmeddelanden i PAL (Platform Abstraction Layer), aktivera security.kerberos och security.ldap logga. Skapa en logger.ini fil med följande innehåll vid /var/opt/mssql/, och starta sedan om SQL Server för att fånga eventuella initialiseringsfel. Återskapa misslyckandet. PAL loggar služba Active Directory-fel- och felsökningsmeddelanden till /var/opt/mssql/log/security.log.
[Output:security]
Type = File
Filename = /var/opt/mssql/log/security.log
[Logger]
Level = Silent
[Logger:security.kerberos]
Level = Debug
Outputs = security
[Logger:security.ldap]
Level = Debug
Outputs = security
SQL Server registrerar loggerändringar utan logger.ini omstart, men fel under služba Active Directory-tjänstinitiering vid SQL Server-start går annars obemärkt förbi. Omstart av SQL Server fångar alla felmeddelanden.
Säkerhetsloggen fortsätter att skriva till enheten tills du tar bort ändringarna i logger.ini. Inaktivera security.kerberos och security.ldap logga när du identifierat och löst problemet, för att undvika att få slut på utrymme på disken.
PAL-loggaren genererar loggfiler i följande format:
<DATETIME> <Log level> [<logger>] <<process/thread identifier>> <message>
Till exempel följer en exempelrad från loggen:
12/28/2021 13:56:31.609453055 Error [security.kerberos] <0003753757/0x00000324> Request ticket server MSSQLSvc/sql.contoso.com:1433@CONTOSO.COM kvno 3 enctype aes256-cts found in keytab but cannot decrypt ticket
När du aktiverar PAL-loggning och återskapar problemet, leta efter det första meddelandet med en loggnivå på Error. Använd följande tabell för att hitta felet och följ instruktionerna och rekommendationerna för att felsöka och lösa problemet.
Vanliga felmeddelanden
Felmeddelande: "Inloggningen misslyckades. Inloggningen kommer från en icke betrodd domän och kan inte användas med integrerad autentisering"
Möjlig orsak
Du stöter på detta fel när du försöker logga in med ett služba Active Directory-konto efter att du konfigurerat služba Active Directory-autentisering.
Vägledning
Det här allmänna felmeddelandet kräver att du aktivera PAL-loggning för att identifiera det specifika felet.
Se följande lista över vanliga fel för att identifiera den möjliga orsaken till varje fel, och följ sedan felsökningsguiden för att lösa problemet.
Felmeddelande: Windows NT-användaren eller gruppen "CONTOSO\user" hittades inte
Möjlig orsak
Du kan stöta på det här felet när du försöker skapa Windows-inloggningen eller under gruppuppdatering.
Vägledning
För att validera problemet, följ instruktionerna för "Inloggning misslyckades. Inloggningen kommer från en domän som inte är betrodd och kan inte användas med integrerad autentisering. (Microsoft SQL Server, fel: 18452)" och aktivera PAL-loggning för att identifiera det specifika felet och felsöka därefter.
Felmeddelande: "Det gick inte att söka efter ett kort domännamn på grund av fel"
Möjlig orsak
Den Transact-SQL syntaxen för att skapa en služba Active Directory-inloggning är:
CREATE LOGIN [CONTOSO\user]
FROM WINDOWS;
NetBIOS-namnet (CONTOSO) krävs i kommandot, men domänens FQDN (contoso.com) måste anges i backend vid en LDAP-anslutning. För att göra den här konverteringen utförs en DNS-sökning på CONTOSO för att matcha till IP-adressen för en domänkontrollant, som sedan kan bindas till för LDAP-frågor.
Vägledning
Felmeddelandet "Kunde inte slå upp kort domännamn på grund av fel" antyder att nslookup för contoso inte löses till domänkontrollantens IP-adress. Granska DNS och omvända DNS-uppslagningar för att bekräfta att nslookup både NetBIOS och domännamn stämmer överens.
Felmeddelanden: "Det gick inte att utföra rDNS-sökning efter värd <värdnamn> på grund av fel" eller "FQDN returneras inte av rDNS-sökning"
Möjlig orsak
Dessa felmeddelanden indikerar vanligtvis att reverse DNS-poster (PTR-poster) inte finns för alla domänkontrollanter.
Vägledning
Kontrollera DNS- och omvända DNS-sökningar. Efter att du identifierat domänkontrollerna som inte har rDNS-poster har du två alternativ:
Lägg till rDNS-poster för alla domänkontrollanter
Denna inställning är inte en SQL Server-inställning, och du måste konfigurera den på domännivå. Du kan behöva samarbeta med ditt domänadministrationsteam för att skapa de nödvändiga PTR-posterna för alla domänkontrollanter som
nslookupreturnerar för domännamnet.Begränsa SQL Server till en delmängd domänkontrollanter
Om du inte kan lägga till PTR-poster för alla returnerade domänkontrollanter kan du begränsa SQL Server till en delmängd av domänkontroller.
Felmeddelande: "Det gick inte att binda till LDAP-servern ldap://CONTOSO.COM:3268: Lokalt fel"
Möjlig orsak
Det här allmänna felet från OpenLDAP innebär normalt en av två saker:
- Inga autentiseringsuppgifter
- rDNS-problem
Här är ett exempel på felmeddelandet:
12/09/2021 14:32:11.319933684 Error [security.ldap] <0000000142/0x000001c0> Failed to bind to LDAP server ldap://[CONTOSO.COM:3268]: Local error
Vägledning
Inga autentiseringsuppgifter
Andra felmeddelanden dyker upp först om inloggningsuppgifter inte laddas för LDAP-anslutningar. Aktivera PAL-loggning och kontrollera felloggen för felmeddelanden före denna. Om det inte finns några andra fel är det troligtvis inte ett problem med autentiseringsuppgifterna. Om du hittar ett fel, åtgärda det innan du går vidare. I de flesta fall är det ett av felmeddelandena som denna artikel behandlar.
rDNS-problem
Kontrollera DNS- och omvända DNS-sökningar.
När OpenLDAP-biblioteket ansluter till en domänkontrollant tillhandahåller det antingen det fullt kvalificerade domännamnet (FQDN), vilket i detta exempel är
contoso.com, eller DC:ns FQDN (kdc1.contoso.com). Efter att anslutningen har upprättats (men innan framgången returnerats till anroparen) kontrollerar OpenLDAP-biblioteket IP-adressen på servern den anslutit sig till. Den utför sedan en omvänd DNS-uppslagning och kontrollerar att namnet på servern den anslutit sig till (kdc1.contoso.com) matchar den begärda domänen (contoso.com). Om det inte stämmer, misslyckas anslutningen i OpenLDAP-biblioteket som en säkerhetsfunktion. Denna mismatch är en del av varför rDNS-inställningarna är viktiga för SQL Server on Linux, och är fokus för denna artikel.
Felmeddelande: "Nyckeltabellposten hittades inte"
Möjlig orsak
Detta fel indikerar åtkomstproblem med keytab-filen eller saknade poster i keytab.
Vägledning
Kontrollera att nyckelfliksfilen har rätt åtkomstnivå och behörigheter. Standardplatsen och namnet på keytab-filen är /var/opt/mssql/secrets/mssql.keytab. För att se de aktuella behörigheterna för alla filer under mappen hemligheter, kör detta kommando:
sudo ls -lrt /var/opt/mssql/secrets
Använd dessa kommandon för att ställa in behörigheter och åtkomstnivå på keytab-filen:
sudo chown mssql /var/opt/mssql/secrets/mssql.keytab
sudo chmod 440 /var/opt/mssql/secrets/mssql.keytab
Mer information om hur du listar nyckelfliksposterna och anger rätt behörigheter finns i föregående Kontrollera nyckelfliksfil och behörigheter avsnittet. Om du inte uppfyller något av villkoren i den sektionen ser du detta fel eller ett motsvarande fel: "Key table entry not found".
Felmeddelande: "Ingen nyckeltabellpost hittades för <huvudnamn>"
Möjlig orsak
När du försöker hämta inloggningsuppgifterna från <principal> keytabben hittar du inga relevanta poster.
Vägledning
Om du vill visa en lista över alla poster i nyckelfliken följer du avsnittet Kontrollera nyckelfliksfil och behörigheter i den här artikeln. Kontrollera att <principal> finns. I det här fallet är det vanligtvis huvudkontot network.privilegedadaccount som du registrerar SPN:arna på. Om det inte är det, lägg till det med kommandot adutil . Mer information finns i Använd adutil för att konfigurera služba Active Directory-autentisering med SQL Server på Linux.
Felmeddelande: "Begärandebiljettserver <principal> hittades inte i keytabet (biljett kvno <KVNO>)"
Möjlig orsak
Detta fel indikerar att SQL Server inte kan hitta en keytab-post för det begärda ärendet med det angivna Key Version Number (KVNO).
Vägledning
Om du vill visa en lista över alla poster i nyckelfliken följer du avsnittet Kontrollera nyckelfliksfil och behörigheter i den här artikeln. Om du inte hittar ett felmeddelande som matchar <principal> och KVNO, uppdatera keytab-filen för att lägga till denna post och följ stegen i den sektionen.
Du kan också köra följande kommando för att hämta den senaste KVNO:en från domänkontrollanten. Innan du kör detta kommando, skaffa eller förnya Kerberos TGT med kommandot kinit . Mer information finns i Använd adutil för att skapa en služba Active Directory-användare för SQL Server och ange tjänstens huvudnamn (SPN).
kvno MSSQLSvc/<hostname>
Felmeddelande: "Begäran biljettserver <huvudbetrodd> kvno <KVNO> finns i nyckeltabell men inte med krypteringstyp <krypteringstyp>."
Möjlig orsak
Detta fel innebär att SQL Server:s keytab inte innehåller den krypteringstyp som klienten begär.
Vägledning
För att validera, följ avsnittet Kontrollera keytab-fil och behörigheter i denna artikel för att lista alla poster i keytabben. Om du inte hittar ett felmeddelande som matchar principal, KVNO och krypteringstyp, uppdatera keytab-filen för att lägga till denna post, enligt stegen i den sektionen.
Felmeddelande: "Begäran biljettserver <huvudnamn> kvno <KVNO> enctype <krypteringstyp> hittades i nyckeltabellen men kan inte dekryptera biljetten"
Möjlig orsak
Detta felmeddelande indikerar att SQL Server inte kan använda en legitimation från keytab-filen för att dekryptera den inkommande autentiseringsförfrågan. Ett felaktigt lösenord orsakar ofta detta fel.
Vägledning
Skapa om keytabben med rätt lösenord. Om du använder adutil, skapa keytab med rätt lösenord och följ stegen i Tutorial: Använd adutil för att konfigurera služba Active Directory-autentisering med SQL Server on Linux.
Vanliga portar
Denna tabell visar de vanliga portarna som SQL Server on Linux använder för att konfigurera och administrera služba Active Directory-autentisering.
| služba Active Directory-tjänsten | Hamn |
|---|---|
| DNS | 53 |
| LDAP | 389 |
| LDAPS | 636 |
| Kerberos | 88 |