Problembehandlung für Active Directory-Authentifizierung für SQL Server für Linux und Container
Gilt für:
SQL Server – Linux
In diesem Artikel erfahren Sie, wie Sie Active Directory Domain Services-Authentifizierungsprobleme bei SQL Server unter Linux und in Containern beheben. Er enthält Voraussetzungsprüfungen und Tipps für eine erfolgreiche Active Directory-Konfiguration sowie eine Liste mit häufigen Fehlern und Problembehandlungsschritten.
Validieren der aktuellen Konfiguration
Bevor Sie mit der Problembehandlung beginnen, müssen Sie die aktuellen Einstellungen für Benutzer, mssql.conf, Dienstprinzipalname und Bereich validieren.
Verwenden Sie
kinit, um das Kerberos-TGT (Ticket-Granting Ticket) abzurufen oder zu erneuern:kinit privilegeduser@CONTOSO.COMFühren Sie den folgenden Befehl aus, und stellen Sie sicher, dass der Benutzer, unter dem Sie diesen Befehl ausführen, Zugriff auf
mssql.keytabhat:/opt/mssql/bin/mssql-conf validate-ad-config /var/opt/mssql/secrets/mssql.keytabWeitere Informationen zum Befehl
validate-ad-configkönnen Sie in der Hilfe mit dem Befehl/opt/mssql/bin/mssql-conf validate-ad-config --helpanzeigen.
DNS- und Reverse-DNS-Lookups
DNS-Lookups für den Domänennamen und den NetBIOS-Namen sollten dieselbe IP-Adresse zurückgeben, die normalerweise mit der IP-Adresse für den Domänencontroller (DC) identisch ist. Führen Sie die folgenden Befehle auf dem SQL Server-Hostcomputer aus:
nslookup contoso nslookup contoso.comWenn die IP-Adressen nicht übereinstimmen, finden Sie weitere Informationen unter Join SQL Server on a Linux host to an Active Directory domain (Hinzufügen von SQL Server auf einem Linux-Host zu einer Active Directory-Domäne), um DNS-Lookups und die Kommunikation mit dem Domänencontroller zu beheben.
Führen Sie eine Reverse-DNS-Suche (rDNS) für jede IP-Adresse aus, die in den vorherigen Ergebnissen aufgeführt ist. Dies schließt IPv4- und ggf. IPv6-Adressen ein.
nslookup <IPs returned from the above commands>Alle sollten
<hostname>.contoso.comzurückgeben. Wenn dies nicht der Fall ist, überprüfen Sie die PTR-Einträge (Zeiger), die in Active Directory erstellt werden.Möglicherweise müssen Sie mit Ihrem Domänenadministrator zusammenarbeiten, damit rDNS funktioniert. Wenn Sie keine PTR-Einträge für alle zurückgegebenen IP-Adressen hinzufügen können, können Sie SQL Server auf eine Teilmenge von Domänencontrollern einschränken. Diese Änderung wirkt sich auf alle anderen Dienste aus, die
krb5.confauf dem Host verwenden.Weitere Informationen zu Reverse-DNS finden Sie unter Was ist Reverse-DNS?
Überprüfen der Schlüsseltabellendatei und der Berechtigungen
Vergewissern Sie sich, dass Sie die Schlüsseltabellendataei erstellt haben und dass mssql-conf für die Verwendung der richtigen Datei mit den entsprechenden Berechtigungen konfiguriert ist. Die Schlüsseltabelle muss für das Benutzerkonto
mssqlzugänglich sein. Weitere Informationen dazu finden Sie unter Verwenden von adutil zum Konfigurieren der Active Directory-Authentifizierung mit SQL Server für Linux.Stellen Sie sicher, dass Sie den Inhalt der Schlüsseltabelle auflisten können und die richtigen Dienstprinzipalnamen (SPNs), Ports, Verschlüsselungstypen und Benutzerkonten hinzugefügt haben. Wenn Sie die Kennwörter beim Erstellen der SPNs und Schlüsseltabelleneinträge nicht richtig eingeben, treten beim Versuch der Anmeldung mithilfe der Active Directory-Authentifizierung Fehler auf.
klist -kte /var/opt/mssql/secrets/mssql.keytabNachfolgend finden Sie ein Beispiel für eine funktionierende Schlüsseltabelle. Im Beispiel werden zwei Verschlüsselungstypen verwendet, aber Sie können je nach den in Ihrer Umgebung unterstützten Verschlüsselungstypen nur einen oder mehrere verwenden. Im Beispiel ist
sqluser@CONTOSO.COMdas privilegierte Konto (das der Einstellung network.privilegedadaccount in mssql-conf entspricht), und der Hostname für SQL Server istsqllinux.contoso.com, der am Standardport 1433 lauscht.$ 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)
Überprüfen von Bereichsinformationen in krb5.conf
Überprüfen Sie in
krb5.conf(unter/etc/krb5.conf), ob Sie Werte für den Standardbereich, die Bereichsinformationen und die Domänen-zu-Bereich-Zuordnung angegeben haben. Das folgende Beispiel ist eine Datei namenskrb5.conf. Weitere Informationen dazu finden Sie unter Grundlegendes zur Active Directory-Authentifizierung für SQL Server für Linux und Container.[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.COMSie können SQL Server so einschränken, dass nur eine Teilmenge der Domänencontroller kontaktiert wird. Dies ist nützlich, wenn Ihre DNS-Konfiguration mehr Domänencontroller zurückgibt, als von SQL Server kontaktiert werden müssen. Mit SQL Server können Sie unter Linux eine Liste von Domänencontrollern angeben, die beim Ausführen einer LDAP-Suche von SQL Server mit der Roundrobinmethode kontaktiert werden.
Dazu müssen Sie zwei Schritte ausführen. Ändern Sie zunächst
krb5.conf, indem Sie eine beliebige Anzahl von benötigten Domänencontrollern mit dem Präfixkdc =hinzufügen.[realms] CONTOSO.COM = { kdc = kdc1.contoso.com kdc = kdc2.contoso.com .. .. }Beachten Sie, dass es sich bei
krb5.confum eine allgemeine Konfigurationsdatei für den Kerberos-Client handelt, sodass sich alle Änderungen, die Sie in dieser Datei vornehmen, nicht nur auf SQL Server, sondern auch auf andere Dienste auswirken. Bevor Sie Änderungen vornehmen, beraten Sie sich mit Ihrem Domänenadministrator.Anschließend können Sie die Einstellung network.enablekdcfromkrb5conf mithilfe von mssql-conf aktivieren und SQL Server neu starten:
sudo /opt/mssql/bin/mssql-conf set network.enablekdcfromkrb5conf true sudo systemctl restart mssql-server
Kerberos-Problembehandlung
Sehen Sie sich die folgenden Details an, die Sie bei der Behandlung von Problemen bei der Active Directory-Authentifizierung und beim Identifizieren bestimmter Fehlermeldungen unterstützen können.
Kerberos-Ablaufverfolgung
Nachdem Sie den Benutzer, die SPNs und Schlüsseltabellen erstellt und mssql-conf so konfiguriert haben, dass die Active Directory-Konfiguration für SQL Server unter Linux korrekt ist, können Sie die Kerberos-Ablaufverfolgungsmeldungen in der Konsole (stdout) anzeigen, wenn Sie versuchen, das Kerberos-TGT mit dem privilegierten Konto abzurufen oder zu erneuern. Verwenden Sie dazu den folgenden Befehl:
root@sqllinux mssql# KRB5_TRACE=/dev/stdout kinit -kt /var/opt/mssql/secrets/mssql.keytab sqluser
Wenn keine Probleme auftreten, sollte eine Ausgabe ähnlich dem folgenden Beispiel angezeigt werden. Falls nicht, stellt die Ablaufverfolgung Kontext zu den Schritten zur Verfügung, die Sie überprüfen sollten.
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
Aktivieren der Kerberos- und sicherheitsbasierten PAL-Protokollierung
Sie können security.kerberos- und security.ldap-Protokollierung aktivieren, um bestimmte Fehlermeldungen in der PAL (Platform Abstraction Layer) zu identifizieren. Erstellen Sie eine Datei vom Typ logger.ini mit dem folgenden Inhalt unter /var/opt/mssql/. Starten Sie SQL Server neu, und reproduzieren Sie dann den Fehler. Die Active Directory-Fehler- und die Debugmeldungen der PAL werden in /var/opt/mssql/log/security.log protokolliert.
[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
Sie müssen SQL Server nicht neu starten, damit die Protokollierungsänderungen aus logger.ini abgerufen werden. Doch während der Initialisierung des Active Directory-Dienstes oder während des Starts von SQL Server können Fehler auftreten, die andernfalls unbemerkt blieben. Durch einen Neustart von SQL Server wird sichergestellt, dass alle Fehlermeldungen erfasst werden.
Das Sicherheitsprotokoll schreibt weiterhin auf das Laufwerk, bis Sie die Änderungen in logger.ini entfernen. Denken Sie daran, die security.kerberos- und security.ldap-Protokollierung zu deaktivieren, nachdem Sie das Problem identifiziert und behoben haben, um eine Erschöpfung des Speicherplatzes auf dem Laufwerk zu vermeiden.
Die PAL-Protokollierung generiert Protokolldateien im folgenden Format:
<DATETIME> <Log level> [<logger>] <<process/thread identifier>> <message>
Nachfolgend sehen Sie etwa eine Beispielzeile aus dem Protokoll:
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
Nachdem Sie die PAL-Protokollierung aktiviert und das Problem reproduziert haben, suchen Sie nach der ersten Meldung mit dem Protokolliergrad Error. Verwenden Sie dann die folgende Tabelle, um den Fehler zu finden, und befolgen Sie die Anweisungen und Empfehlungen zum Beheben und Lösen des Problems.
Häufige Fehlermeldungen
Fehlermeldung: „Fehler bei der Anmeldung. Die Anmeldung erfolgt aus einer nicht vertrauenswürdigen Domäne und kann nicht mit der integrierten Authentifizierung verwendet werden“.
Mögliche Ursache
Dieser Fehler tritt auf, wenn Sie versuchen, sich mit einem Active Directory-Konto anzumelden, nachdem Sie die Active Directory-Authentifizierung konfiguriert haben.
Anleitungen
Dies ist eine generische Fehlermeldung, und Sie müssen die PAL-Protokollierung aktivieren, um die spezifische Fehlermeldung zu bestimmen.
Sie können sich auf diese Liste mit häufigen Fehlern beziehen, um die mögliche Ursache für jeden Fehler zu ermitteln. Befolgen Sie dann die Anleitung zur Problembehandlung, um das Problem zu beheben.
Fehlermeldung: Der Windows NT-Benutzer oder die Gruppe ‚CONTOSO\user‘ wurde nicht gefunden
Mögliche Ursache
Dieser Fehler kann auftreten, wenn Sie versuchen, die Windows-Anmeldung zu erstellen, oder während der Gruppenaktualisierung.
Anleitungen
Zum Überprüfen des Problems befolgen Sie die Anleitung unter „Fehler bei der Anmeldung. Die Anmeldung erfolgt aus einer nicht vertrauenswürdigen Domäne und kann nicht mit der integrierten Authentifizierung verwendet werden. (Microsoft SQL Server, Fehler: 18452)“ Aktivieren Sie die PAL-Protokollierung, um den spezifischen Fehler zu identifizieren und die entsprechende Problembehandlung durchzuführen.
Fehlermeldung: „Der kurze Domänenname konnte aufgrund eines Fehlers nicht nachgeschlagen werden“
Mögliche Ursache
Die Transact-SQL-Syntax zum Erstellen einer Active Directory-Anmeldung lautet:
CREATE LOGIN [CONTOSO\user] FROM WINDOWS;
Der NetBIOS-Name (CONTOSO) ist im Befehl erforderlich, aber im Back-End muss beim Herstellen einer LDAP-Verbindung der FQDN der Domäne (contoso.com) angegeben werden. Für diese Konvertierung wird eine DNS-Suche für CONTOSO ausgeführt, um zur IP-Adresse eines Domänencontrollers aufzulösen, die dann für Bindungen von LDAP-Abfragen zur Verfügung steht.
Anleitungen
Die Fehlermeldung „Der kurze Domänenname konnte aufgrund eines Fehlers nicht nachgeschlagen werden“ deutet darauf hin, dass nslookup für contoso nicht in die IP-Adresse des Domänencontrollers aufgelöst werden kann. Überprüfen Sie DNS- und Reverse-DNS-Lookups, um zu bestätigen, dass nslookup sowohl für den NetBIOS- als auch für den Domänennamen übereinstimmen sollte.
Fehlermeldungen: „Aufgrund eines Fehlers konnte keine rDNS-Suche für den Host <hostname> durchgeführt werden“ oder „Von der rDNS-Suche wurde kein FQDN zurückgegeben“
Mögliche Ursache
Diese Fehlermeldung weist meistens darauf hin, dass die Reverse-DNS-Einträge (PTR-Einträge) nicht für alle Domänencontroller vorhanden sind.
Anleitungen
Überprüfen Sie die DNS- und Reverse-DNS-Suchen. Nachdem die Domänencontroller ohne rDNS-Einträge identifiziert wurden, gibt es zwei Optionen:
Hinzufügen von rDNS-Einträgen für alle Domänencontroller
Dies ist keine SQL Server-Einstellung und muss auf Domänenebene konfiguriert werden. Möglicherweise müssen Sie mit Ihrem Domänenverwaltungsteam zusammenarbeiten, um die erforderlichen PTR-Einträge für alle Domänencontroller zu erstellen, die beim Ausführen von
nslookupfür den Domänennamen zurückgegeben werden.Beschränken von SQL Server auf eine Teilmenge von Domänencontrollern
Wenn das Hinzufügen von PTR-Einträgen für alle zurückgegebenen Domänencontroller nicht möglich ist, können Sie SQL Server auf eine Teilmenge von Domänencontrollern einschränken.
Fehlermeldung: „Fehler beim Binden an den LDAP-Server ldap://CONTOSO.COM:3268: Lokaler Fehler“
Mögliche Ursache
Dies ist ein generischer Fehler von OpenLDAP, aber normalerweise bedeutet er eins von zwei Dingen:
- Keine Anmeldeinformationen
- rDNS-Probleme
Hier sehen Sie ein solches Beispiel für die Fehlermeldung:
12/09/2021 14:32:11.319933684 Error [security.ldap] <0000000142/0x000001c0> Failed to bind to LDAP server ldap://[CONTOSO.COM:3268]: Local error
Anleitungen
Keine Anmeldeinformationen
Andere Fehlermeldungen werden zuerst ausgelöst, wenn Anmeldeinformationen für LDAP-Verbindungen nicht geladen werden. Sie sollten die PAL-Protokollierung aktivieren und das Fehlerprotokoll auf Fehlermeldungen vor dieser Fehlermeldung überprüfen. Wenn keine weiteren Fehler vorhanden sind, handelt es sich wahrscheinlich nicht um ein Problem mit Anmeldeinformationen. Wenn Sie eine Fehlermeldung finden, arbeiten Sie an der Problembehebung der angezeigten Fehlermeldung. In den meisten Fällen handelt es sich um eine der in diesem Artikel behandelten Fehlermeldungen.
rDNS-Probleme
Überprüfen Sie die DNS- und Reverse-DNS-Suchen.
Wenn die OpenLDAP-Bibliothek eine Verbindung mit einem Domänencontroller herstellt, wird entweder der Domänen-FQDN (
contoso.com) oder der FQDN des Domänencontrollers (kdc1.contoso.com) angegeben. Sobald die Verbindung hergestellt wurde (aber bevor der Erfolg an den Aufrufer zurückgemeldet wird), überprüft die OpenLDAP-Bibliothek die IP-Adresse des Servers, mit dem sie verbunden ist. Anschließend wird ein Reverse-DNS-Lookup durchgeführt, und es wird überprüft, ob der Name des Servers, mit dem (kdc1.contoso.com) verbunden ist, mit der Domäne übereinstimmt, für die die Verbindung angefordert wurde (contoso.com). Wenn dies nicht übereinstimmt, verwirft die OpenLDAP-Bibliothek als Sicherheitsfeature die Verbindung. Dies sind einige der Gründe, warum die rDNS-Einstellungen für SQL Server unter Linux so wichtig sind und den Schwerpunkt dieser Dokumentation bilden.
Fehlermeldung: „Schlüsseltabelleneintrag nicht gefunden“
Mögliche Ursache
Dieser Fehler weist auf Zugriffsprobleme mit der Schlüsseltabellendatei oder auf die Unvollständigkeit der erforderlichen Einträge in der Schlüsseltabellendatei hin.
Anleitungen
Vergewissern Sie sich, dass die Schlüsseltabellendatei die richtige Zugriffsebene und die richtigen Berechtigungen aufweist. Der Standardspeicherort und der Name für die Schlüsseltabellendatei lautet /var/opt/mssql/secrets/mssql.keytab. Zum Anzeigen der aktuellen Berechtigungen für alle Dateien im Ordner mit den Geheimnissen können Sie den folgenden Befehl ausführen:
sudo ls -lrt /var/opt/mssql/secrets
Sie können diese Befehle verwenden, um die Berechtigungen und die Zugriffsebene für die Schlüsseltabellendatei festzulegen:
sudo chown mssql /var/opt/mssql/secrets/mssql.keytab
sudo chmod 440 /var/opt/mssql/secrets/mssql.keytab
Weitere Informationen zum Auflisten der Schlüsseltabelleneinträge und zum Festlegen der korrekten Berechtigungen finden Sie im vorherigen Abschnitt Überprüfen der Schlüsseltabellendatei und der Berechtigungen. Wenn eine der Bedingungen in diesem Abschnitt nicht erfüllt ist, wird dieser oder ein entsprechender Fehler angezeigt: "Key table entry not found".
Fehlermeldung: „In der Schlüsseltabelle wurde kein Eintrag für <principal> gefunden“
Mögliche Ursache
Beim Versuch, die Anmeldeinformationen von <principal> aus der Schlüsseltabelle abzurufen, wurden keine zutreffenden Einträge gefunden.
Anleitungen
Befolgen Sie den Abschnitt Überprüfen der Schlüsseltabellendatei und der Berechtigungen in diesem Dokument, um alle Einträge in der Schlüsseltabelle aufzulisten. Stellen Sie sicher, dass <principal> vorhanden ist. In diesem Fall stellt das Prinzipalkonto in der Regel das Konto network.privilegedadaccount dar, bei dem die SPNs registriert sind. Wenn dies nicht der Fall ist, fügen Sie es mit dem Befehl adutil hinzu. Weitere Informationen dazu finden Sie unter Verwenden von adutil zum Konfigurieren der Active Directory-Authentifizierung mit SQL Server für Linux.
Fehlermeldung: „Der Anforderungsticketserver <principal> wurde in der Schlüsseltabelle nicht gefunden (Schlüsselversionsnummer des Tickets <KVNO>)“
Mögliche Ursache
Dieser Fehler weist darauf hin, dass SQL Server für das angeforderte Ticket mit der angegebenen Schlüsselversionsnummer (Key Version Number, KVNO) keinen Eintrag in der Schlüsseltabelle gefunden hat.
Anleitungen
Befolgen Sie den Abschnitt Überprüfen der Schlüsseltabellendatei und der Berechtigungen in diesem Dokument, um alle Einträge in der Schlüsseltabelle aufzulisten. Wenn Sie keine Fehlermeldung finden, die mit <principal> und KVNO übereinstimmt, fügen Sie diesen Eintrag hinzu, indem Sie die Schlüsseltabellendatei mit den in diesem Abschnitt beschriebenen Schritten aktualisieren.
Sie können auch den folgenden Befehl ausführen, um die neueste KVNO vom DC abzurufen. Bevor Sie diesen Befehl ausführen, müssen Sie das Kerberos-TGT mit dem kinit-Befehl abrufen oder erneuern. Weitere Informationen dazu erfahren Sie unter Verwenden von adutil zum Erstellen eines Active Directory-Benutzers für SQL Server und Festlegen des Dienstprinzipalnamens (Service Principal Name, SPN).
kvno MSSQLSvc/<hostname>
Fehlermeldung: „Der Anforderungsticketserver <principal> mit Schlüsselversionsnummer <KVNO> wurde in der Schlüsseltabelle gefunden, jedoch nicht mit dem Verschlüsselungstyp <encryption type>“
Mögliche Ursache
Dieser Fehler bedeutet, dass der vom Client angeforderte Verschlüsselungstyp in der Schlüsseltabelle von SQL Server nicht vorhanden war.
Anleitungen
Befolgen Sie zur Überprüfung den Abschnitt Überprüfen der Schlüsseltabellendatei und der Berechtigungen in diesem Dokument, um alle Einträge in der Schlüsseltabelle aufzulisten. Wenn Sie keine Fehlermeldung finden, die mit dem Prinzipal, der KVNO und dem Verschlüsselungstyp übereinstimmt, fügen Sie diesen Eintrag hinzu, indem Sie die Schlüsseltabellendatei mit den in diesem Abschnitt beschriebenen Schritten aktualisieren.
Fehlermeldung: „Der Anforderungsticketserver <principal> mit Schlüsselversionsnummer <KVNO> mit dem Verschlüsselungstyp <encryption type> wurde in der Schlüsseltabelle gefunden, aber das Ticket kann nicht entschlüsselt werden“
Mögliche Ursache
Dieser Fehler weist darauf hin, dass SQL Server die eingehende Authentifizierungsanforderung nicht mithilfe von Anmeldeinformationen aus der Schlüsseltabellendatei entschlüsseln konnte. Der Fehler wird häufig durch ein falsches Kennwort verursacht.
Anleitungen
Erstellen Sie die Schlüsseltabelle mit dem richtigen Kennwort neu. Wenn Sie adutil verwenden, führen Sie die Schritte unter Verwenden von adutil zum Konfigurieren der Active Directory-Authentifizierung mit SQL Server für Linux aus, um die Schlüsseltabelle mit dem richtigen Kennwort zu erstellen.
Allgemeine Ports
In dieser Tabelle sehen Sie die allgemeinen Ports, die von SQL Server unter Linux zum Konfigurieren und Verwalten der Active Directory-Authentifizierung verwendet werden.
| Active Directory-Dienst | Port |
|---|---|
| DNS | 53 |
| LDAP | 389 |
| LDAPS | 636 |
| Kerberos | 88 |
Zugehöriger Inhalt
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für