Felsöka Active Directory-autentisering för SQL Server på Linux och containrar
gäller för:
SQL Server – Linux
Den här artikeln hjälper dig att felsöka problem med Active Directory Domain Services-autentisering med SQL Server i Linux och containrar. Den innehåller nödvändiga kontroller och tips för en lyckad Active Directory-konfiguration och en lista över vanliga fel och felsökningssteg.
Verifiera den aktuella konfigurationen
Innan du börjar felsöka måste du verifiera den aktuella användaren, mssql.conf, TJÄNSTENs huvudnamn (SPN) och sfärinställningar.
Hämta eller förnya Kerberos TGT (biljettbeviljande biljett) med hjälp av
kinit:kinit privilegeduser@CONTOSO.COMKör följande kommando och kontrollera att användaren som du kör det här kommandot under har åtkomst till
mssql.keytab:/opt/mssql/bin/mssql-conf validate-ad-config /var/opt/mssql/secrets/mssql.keytabMer information om kommandot
validate-ad-configfinns i hjälpen med kommandot/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 Active Directory-domän för att åtgärda DNS-sökningar och kommunikation med domänkontrollanten.
Utför en omvänd DNS-sökning (rDNS) för varje IP-adress som anges i föregående resultat. Kom ihåg att 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. Om så inte är fallet, kontrollera PTR-posterna (pekare) som skapas i 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 IP-adresser som returneras kan du också begränsa SQL Server till en delmängd av domänkontrollanter. 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 nyckelfliksfilen (nyckeltabellen) och att mssql-conf har konfigurerats för att använda rätt fil med lämpliga behörigheter. Nyckelfliken måste vara tillgänglig för
mssqlanvändarkonto. Mer information finns i Använd adutil för att konfigurera 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 lösenorden korrekt när du skapar SPN:erna och keytab-posterna uppstår fel när du försöker logga in med hjälp av 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 är
sqluser@CONTOSO.COMdet privilegierade kontot (som matchar inställningennetwork.privilegedadaccounti mssql-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 mssql.keytab Keytab name: FILE: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. Följande är ett exempel på enkrb5.conf-fil. Mer information finns i Förstå 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. Med SQL Server på Linux kan du ange en lista över domänkontrollanter som SQL Server kontaktar i turordning när du utför en LDAP-sökning.
Det finns två steg som du måste slutföra. Ändra först
krb5.confgenom att lägga till valfritt antal domänkontrollanter som du behöver, prefixet medkdc =.[realms] CONTOSO.COM = { kdc = kdc1.contoso.com kdc = kdc2.contoso.com .. .. }Tänk på att
krb5.confär en vanlig Kerberos-klientkonfigurationsfil, så alla ändringar du gör i den här filen påverkar andra tjänster utöver SQL Server. Kontakta domänadministratören innan du gör några ändringar.Du kan sedan aktivera inställningen
network.enablekdcfromkrb5confmed hjälp av mssql-confoch sedan starta om SQL Server:sudo /opt/mssql/bin/mssql-conf set network.enablekdcfromkrb5conf true sudo systemctl restart mssql-server
Att felsöka Kerberos
Se följande information för att hjälpa dig att felsöka Problem med Active Directory-autentisering och identifiera specifika felmeddelanden.
Spåra Kerberos
När du har skapat användaren, SPN och nyckelflikar och konfigurerat mssql-conf för att se att Active Directory-konfigurationen för SQL Server i Linux är korrekt kan du visa Kerberos-spårningsmeddelanden till konsolen (stdout) när du försöker hämta eller förnya Kerberos TGT med det privilegierade kontot med hjälp av det här kommandot:
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. Annars ger spårningen kontext om vilka steg du bör granska.
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
Du kan aktivera security.kerberos och security.ldap loggning för att identifiera specifika felmeddelanden i PAL (Platform Abstraction Layer). Skapa en logger.ini fil med följande innehåll på /var/opt/mssql/, starta om SQL Server och återskapa sedan felet. PAL:s fel- och felsökningsmeddelanden för Active Directory loggas 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
Du behöver inte starta om SQL Server för att loggningsändringarna ska hämtas från logger.ini, men fel kan inträffa under initieringen av Active Directory-tjänsten under SQL Server-start som annars skulle gå obemärkt förbi. Om du startar om SQL Server ser du till att alla felmeddelanden registreras.
Säkerhetsloggen fortsätter att skriva till enheten tills du tar bort ändringarna i logger.ini. Kom ihåg att inaktivera security.kerberos och security.ldap loggning när du har identifierat och löst problemet för att förhindra att utrymmet på enheten tar slut.
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 har aktiverat PAL-loggning och återskapat problemet letar du efter det första meddelandet med en loggnivå på Erroroch använder sedan följande tabell för att hitta felet och följa vägledningen och rekommendationen för att felsöka och lösa problemet.
Vanliga felmeddelanden
Felmeddelande: "Inloggningen misslyckades. Inloggningen kommer från en domän som inte är betrodd och kan inte användas med integrerad autentisering."
Möjlig orsak
Det här felet uppstår när du försöker logga in med ett Active Directory-konto när du har konfigurerat 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
Om du vill verifiera problemet följer du vägledningen som beskrivs för "Inloggningen 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)" 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 Active Directory-inloggning är:
CREATE LOGIN [CONTOSO\user]
FROM WINDOWS;
NetBIOS-namnet (CONTOSO) krävs i kommandot, men i serverdelen när du utför en LDAP-anslutning måste domänens FQDN (contoso.com) anges. 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 "Det gick inte att söka efter ett kort domännamn på grund av fel" tyder på att nslookup för contoso inte matchar domänkontrollantens IP-adress. Du bör granska DNS- och omvända DNS-sökningar för att bekräfta att nslookup för både NetBIOS och domännamnet ska matcha.
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
Det här felmeddelandet anger vanligtvis att de omvända DNS-posterna (PTR-poster) inte finns för alla domänkontrollanter.
Vägledning
Kontrollera DNS- och omvända DNS-sökningar. När domänkontrollanterna som inte har rDNS-poster har identifierats finns det två alternativ:
Lägg till rDNS-poster för alla domänkontrollanter
Den här inställningen är inte en SQL Server-inställning och måste konfigureras 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 returneras när du kör
nslookuppå domännamnet.Begränsa SQL Server till en delmängd domänkontrollanter
Om det inte går att lägga till PTR-poster för alla returnerade domänkontrollanter kan du begränsa SQL Server till en delmängd av domänkontrollanter.
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 utlöses först om autentiseringsuppgifterna inte läses in för LDAP-anslutningar. Du bör aktivera PAL-loggning och kontrollera om det finns felmeddelanden före den här felloggen. Om det inte finns några andra fel är det troligtvis inte ett problem med autentiseringsuppgifterna. Om ett hittas, åtgärda det felmeddelande som du ser. I de flesta fall är det ett av de felmeddelanden som beskrivs i den här artikeln.
rDNS-problem
Kontrollera DNS- och omvända DNS-uppslag.
När OpenLDAP-biblioteket ansluter till en domänkontrollant tillhandahålls antingen det fullständigt kvalificerade domännamnet (FQDN), som i det här exemplet är
contoso.com, eller domänkontrollantens FQDN (kdc1.contoso.com). När anslutningen har upprättats (men innan den returneras till anroparen) kontrollerar OpenLDAP-biblioteket IP-adressen för den server som den är ansluten till. Den utför sedan en omvänd DNS-sökning och kontrollerar att namnet på den server som är ansluten till (kdc1.contoso.com) matchar domänen som anslutningen begärdes för (contoso.com). Om det inte stämmer, misslyckas anslutningen i OpenLDAP-biblioteket som en säkerhetsfunktion. Detta är en del av varför rDNS-inställningarna är så viktiga för SQL Server i Linux och är i fokus för den här artikeln.
Felmeddelande: "Nyckeltabellposten hittades inte"
Möjlig orsak
Det här felet anger åtkomstproblem med nyckelfliksfilen eller att du inte har alla nödvändiga poster i nyckelfliken.
Vägledning
Kontrollera att nyckelfliksfilen har rätt åtkomstnivå och behörigheter. Standardplatsen och namnet på nyckelfliksfilen är /var/opt/mssql/secrets/mssql.keytab. Om du vill visa de aktuella behörigheterna för alla filer under mappen hemligheter kan du köra det här kommandot:
sudo ls -lrt /var/opt/mssql/secrets
Du kan använda dessa kommandon för att ange behörigheter och åtkomstnivå för nyckelfliksfilen:
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 något av villkoren i det avsnittet inte uppfylls visas det här eller motsvarande fel: "Key table entry not found".
Felmeddelande: "Ingen nyckeltabellpost hittades för <huvudnamn>"
Möjlig orsak
När man försökte hämta autentiseringsuppgifterna för <principal> från keytab-filen kunde inga tillämpliga poster hittas.
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 huvudkontot vanligtvis den network.privilegedadaccount som SPN:erna är registrerade i. Om den inte är det lägger du till den med kommandot adutil. Mer information finns i Använd adutil för att konfigurera Active Directory-autentisering med SQL Server på Linux.
Felmeddelande: "Begärandebiljettserver <principal> hittades inte i keytabet (biljett kvno <KVNO>)"
Möjlig orsak
Det här felet anger att SQL Server inte kunde hitta någon nyckelflikspost för den begärda biljetten med det angivna nyckelversionsnumret (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 lägger du till den här posten genom att uppdatera nyckelfliksfilen med hjälp av stegen i det avsnittet.
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 det här kommandot måste du hämta eller förnya Kerberos TGT med hjälp av kommandot kinit. Mer information finns i Använd adutil för att skapa en 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
Det här felet innebär att den krypteringstyp som begärdes av klienten inte fanns i SQL Server-nyckelfliken.
Vägledning
Kontrollera genom att följa avsnittet Kontrollera keytab-fil och behörigheter i det här dokumentet för att lista alla poster i keytaben. Om du inte hittar ett felmeddelande som matchar huvudnamnet, KVNO och krypteringstypen lägger du till den här posten genom att uppdatera nyckelfliksfilen med hjälp av stegen i det avsnittet.
Felmeddelande: "Begäran biljettserver <huvudnamn> kvno <KVNO> enctype <krypteringstyp> hittades i nyckeltabellen men kan inte dekryptera biljetten"
Möjlig orsak
Det här felet anger att SQL Server inte kunde använda en autentiseringsuppgift från nyckelfliksfilen för att dekryptera den inkommande autentiseringsbegäran. Felet beror ofta på ett felaktigt lösenord.
Vägledning
Återskapa nyckelfliken med rätt lösenord. Om du använder adutilskapar du nyckelfliken med rätt lösenord med hjälp av stegen i Självstudie: Använd adutil för att konfigurera Active Directory-autentisering med SQL Server på Linux.
Vanliga portar
Den här tabellen visar de vanliga portar som används av SQL Server i Linux för att konfigurera och administrera Active Directory-autentisering.
| Active Directory-tjänsten | Hamn |
|---|---|
| DNS | 53 |
| LDAP | 389 |
| LDAPS | 636 |
| Kerberos | 88 |