Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:
SQL Server unter 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 Fehlersuche beginnen, überprüfen Sie den aktuellen Benutzer, mssql.confden Service Principal Name (SPN) und die Realm-Einstellungen.
Erwerben oder erneuern Sie das Kerberos TGT (Ticket-Granting Ticket) mit
kinit:kinit privilegeduser@CONTOSO.COMFühren Sie folgenden Befehl aus und stellen Sie sicher, dass der Benutzer Zugriff auf die
mssql.keytabhat:/opt/mssql/bin/mssql-conf validate-ad-config /var/opt/mssql/secrets/mssql.keytabFür weitere Informationen über den
validate-ad-configBefehl führe/opt/mssql/bin/mssql-conf validate-ad-config --help.
DNS- und Reverse-DNS-Abfragen
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 für jede IP-Adresse aus den vorherigen Ergebnissen eine Reverse DNS (rDNS)-Suche durch. Geben Sie IPv4- und IPv6-Adressen an, wo anwendbar.
nslookup <IPs returned from the above commands>Alle sollten
<hostname>.contoso.comzurückgeben. Ansonsten überprüfen Sie die PTR-(Zeiger-)Datensätze in Active Directory.Möglicherweise müssen Sie mit Ihrem Domänenadministrator zusammenarbeiten, damit rDNS funktioniert. Wenn du für alle zurückgegebenen IP-Adressen keine PTR-Einträge hinzufügen kannst, kannst du SQL Server auch auf eine Teilmenge von Domänencontrollern beschrä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?
Keytab-Datei und Berechtigungen überprüfen
Überprüfe, ob du die Keytab-Datei (Keytable) erstellt hast und dass du die korrekte Datei mit den entsprechenden Berechtigungen verwendet
mssql-confhast. Die Schlüsseltabelle muss für das Benutzerkontomssqlzugä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 SPNs, Ports, Verschlüsselungstypen und Benutzerkonten hinzugefügt haben. Wenn Sie die Passwörter beim Erstellen der SPNs und Keytab-Einträge nicht korrekt eingeben, stoßen Sie auf Fehler, wenn Sie versuchen, sich mit Active Directory-Authentifizierung anzumelden.
klist -kte /var/opt/mssql/secrets/mssql.keytabIm Folgenden finden Sie ein Beispiel für eine funktionsfähige Keytab-Datei. 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 (was der Einstellungnetwork.privilegedadaccountinmssql-confentspricht), und der Hostname für SQL Server istsqllinux.contoso.com, der am Standardport1433lauscht.$ 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)
Realm-Informationen in krb5.conf validieren
Ü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. Überprüfen Sie die folgende Beispieldateikrb5.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 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.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. SQL Server für Linux ermöglicht es, eine Liste von Domänencontrollern anzugeben, die SQL Server bei einer Lightweight Directory Access Protocol (LDAP)-Abfrage im Round-Robin-Verfahren kontaktiert.
Erledigen Sie diese beiden Schritte. Zuerst modifizieren
krb5.confSie, indem Sie die benötigten Domänencontroller hinzufügen, mit dem Präfix .kdc =[realms] CONTOSO.COM = { kdc = kdc1.contoso.com kdc = kdc2.contoso.com .. .. }Die
krb5.confDatei ist eine gängige Kerberos-Client-Konfigurationsdatei, daher beeinflussen alle Änderungen in dieser Datei neben dem SQL Server auch andere Dienste. Bevor Sie Änderungen vornehmen, konsultieren Sie Ihren Domain-Administrator.Aktivieren Sie die Einstellung
network.enablekdcfromkrb5confmitmssql-confund starten Sie dann den SQL Server neu:sudo /opt/mssql/bin/mssql-conf set network.enablekdcfromkrb5conf true sudo systemctl restart mssql-server
Beheben von Kerberos-Problemen
Die folgenden Details helfen Ihnen, Active Directory-Authentifizierungsprobleme zu beheben und spezifische Fehlermeldungen zu identifizieren.
Kerberos nachverfolgen
Nachdem Sie Benutzer, SPNs und Keytabs erstellt und mssql-confkonfiguriert haben, überprüfen Sie die Active Directory-Konfiguration.
Um die Konfiguration für SQL Server für Linux zu überprüfen, verwenden Sie das privilegierte Konto, um das Kerberos TGT abzurufen oder zu erneuern. Führe diesen Befehl aus, um die Kerberos-Trace-Nachrichten in der Konsole anzuzeigen (stdout):
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, liefert die Spur Kontext darüber, welche Schritte überprüft werden 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 Sie die Kerberos- und sicherheitsbasierte PAL-Protokollierung
Um spezifische Fehlermeldungen im PAL (Platform Abstraction Layer) zu identifizieren, aktivieren security.kerberos und security.ldap protokollieren. Erstellen Sie eine logger.ini Datei mit folgendem Inhalt bei /var/opt/mssql/, und starten Sie dann den SQL Server neu, um eventuelle Initialisierungsfehler zu erkennen. Reproduzieren Sie den Fehler. Das PAL protokolliert Active Directory-Fehler- und Debugg-Nachrichten auf ./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
Der SQL Server erkennt Logger-Änderungen logger.ini ohne Neustart, aber Fehler während der Initialisierung des Active Directory-Dienstes beim Start des SQL Server bleiben ansonsten unbemerkt. Ein Neustart von SQL Server erfasst alle Fehlermeldungen.
Das Sicherheitsprotokoll schreibt weiterhin auf das Laufwerk, bis Sie die Änderungen in logger.ini entfernen. Deaktiviere security.kerberos und security.ldap logge, sobald du das Problem identifiziert und behoben hast, um zu verhindern, dass der Speicherplatz auf der Festplatte ausgeht.
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
Sobald du PAL-Logging aktiviert und das Problem reproduziert hast, suche nach der ersten Nachricht mit einem Log-Level von Error. Verwenden Sie die folgende Tabelle, um den Fehler zu finden, und folgen Sie den Anweisungen und Empfehlungen, um das Problem zu beheben und zu beheben.
Häufig auftretende Fehlermeldungen
Fehlermeldung: „Fehler bei der Anmeldung. Der Login stammt von einer nicht vertrauenswürdigen Domain und kann nicht mit integrierter Authentifizierung verwendet werden."
Mögliche Ursache
Sie stoßen auf diesen Fehler, wenn Sie versuchen, sich nach der Konfiguration der Active Directory-Authentifizierung mit einem Active Directory-Konto anzumelden.
Leitlinien
Diese generische Fehlermeldung erfordert, dass Sie die PAL-Protokollierung aktivieren, um den spezifischen Fehler zu identifizieren.
Sehen Sie sich die folgende Liste häufiger Fehler an, um die mögliche Ursache jedes Fehlers zu identifizieren, und folgen Sie dann den Fehlerbehebungshinweisen, 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.
Leitlinien
Um das Problem zu überprüfen, befolgen Sie die Anleitung für "Login fehlgeschlagen. Die Anmeldung stammt aus einer nicht vertrauenswürdigen Domäne und kann nicht mit der integrierten Authentifizierung verwendet werden. (Microsoft SQL Server, Fehler: 18452)" und PAL-Logging aktivieren, um den spezifischen Fehler zu identifizieren und entsprechend zu beheben.
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 der FQDN der Domäne (contoso.com) muss im Backend angegeben werden, wenn eine LDAP-Verbindung durchgeführt wird. Für diese Konvertierung wird eine DNS-Abfrage für CONTOSO durchgeführt, um die IP-Adresse eines Domänencontrollers zu ermitteln, mit dem dann für LDAP-Abfragen eine Bindung hergestellt werden kann.
Leitlinien
Die Fehlermeldung "Konnte den kurzen Domainnamen wegen Fehlers nicht suchen" deutet darauf hin, dass nslookup für contoso nicht auf die IP-Adresse des Domänencontrollers aufgelöst wird. Überprüfen Sie DNS und umgekehrte DNS-Lookups , um zu bestätigen, dass nslookup sowohl NetBIOS als auch Domain übereinstimmen.
Fehlermeldungen: „Aufgrund eines Fehlers konnte kein rDNS-Lookup für den Host <Hostname> durchgeführt werden“ oder „Vom rDNS-Lookup wurde kein FQDN zurückgegeben“
Mögliche Ursache
Diese Fehlermeldungen deuten in der Regel darauf hin, dass die Reverse-DNS-Datensätze (PTR-Datensätze) nicht für alle Domänencontroller existieren.
Leitlinien
Überprüfen Sie die DNS- und Reverse-DNS-Suchen. Nachdem du die Domänencontroller identifiziert hast, die keine rDNS-Einträge haben, hast du zwei Möglichkeiten:
Hinzufügen von rDNS-Einträgen für alle Domänencontroller
Diese Einstellung ist keine SQL Server-Einstellung, und Sie müssen sie auf Domänenebene konfigurieren. Du musst vielleicht mit deinem Domain-Administrationsteam zusammenarbeiten, um die erforderlichen PTR-Datensätze für alle Domänencontroller zu erstellen, die
nslookupfür den Domainnamen zurückgegeben werden.Beschränken von SQL Server auf eine Teilmenge von Domänencontrollern
Wenn du für alle zurückgegebenen Domänencontroller keine PTR-Einträge hinzufügen kannst, kannst du den SQL Server auf eine Teilmenge von Domänencontrollern beschränken.
Fehlermeldung: „Fehler beim Binden an den LDAP-Server ldap://CONTOSO.COM:3268: Lokaler Fehler“
Mögliche Ursache
Dieser generische Fehler von OpenLDAP bedeutet normalerweise eines von zwei Dingen:
- Keine Anmeldeinformationen
- rDNS-Probleme
Hier sehen Sie ein 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
Leitlinien
Keine Anmeldeinformationen
Weitere Fehlermeldungen erscheinen zuerst, wenn die Zugangsdaten für LDAP-Verbindungen nicht geladen werden. Aktiviere PAL-Logging und überprüfe das Fehlerprotokoll auf Fehlermeldungen vor dieser hier. Wenn keine weiteren Fehler vorhanden sind, handelt es sich wahrscheinlich nicht um ein Problem mit Anmeldeinformationen. Wenn du einen Fehler findest, korrigiere ihn, bevor du weitermachst. In den meisten Fällen ist es eine der Fehlermeldungen, die dieser Artikel behandelt.
rDNS-Probleme
Überprüfen Sie die DNS- und Reverse-DNS-Suchen.
Wenn die OpenLDAP-Bibliothek mit einem Domänencontroller verbunden wird, stellt sie entweder den vollständig qualifizierten Domainnamen (FQDN), der in diesem Beispiel ist
contoso.com, oder den FQDN des DCs (kdc1.contoso.com). Nachdem die Verbindung hergestellt wurde (aber bevor der Erfolg an den Anrufer zurückgegeben wurde), überprüft die OpenLDAP-Bibliothek die IP des Servers, mit dem sie verbunden war. Anschließend führt es eine umgekehrte DNS-Abfrage durch und prüft, ob der Name des Servers, mitkdc1.contoso.comdem es verbunden war, mit der angeforderten Domain übereinstimmt (contoso.com). Wenn er nicht übereinstimmt, verwirft die OpenLDAP-Bibliothek als Sicherheitsfeature die Verbindung. Diese Diskrepanz ist ein Teil des Grundes, warum die rDNS-Einstellungen für SQL Server für Linux wichtig sind und im Mittelpunkt dieses Artikels stehen.
Fehlermeldung: „Eintrag in der Schlüsseltabelle nicht gefunden“
Mögliche Ursache
Dieser Fehler weist auf Zugriffsprobleme mit der Keytab-Datei oder fehlende Einträge im Keytab hin.
Leitlinien
Vergewissern Sie sich, dass die Schlüsseltabellendatei die richtige Zugriffsebene und die richtigen Berechtigungen aufweist. Der Standardstandort und Name der Keytab-Datei ist /var/opt/mssql/secrets/mssql.keytab. Um die aktuellen Berechtigungen aller Dateien unter dem Ordner Secrets anzuzeigen, führen Sie diesen Befehl aus:
sudo ls -lrt /var/opt/mssql/secrets
Verwenden Sie diese Befehle, um die Berechtigungen und die Zugriffsstufe der Keytab-Datei 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 Sie keine der Bedingungen in diesem Abschnitt erfüllen, sehen Sie diesen Fehler oder einen entsprechenden Fehler: "Key table entry not found".
Fehlermeldung: „In der Schlüsseltabelle wurde kein Eintrag für <principal> gefunden“
Mögliche Ursache
Wenn du versuchst, die Zugangsdaten vom <principal> Keytab abzurufen, findest du keine relevanten Einträge.
Leitlinien
Wenn Sie alle Einträge in der Schlüsseltabelle auflisten möchten, folgen Sie dem Abschnitt Überprüfen der Schlüsseltabellendatei und der Berechtigungen in diesem Artikel. Stellen Sie sicher, dass <principal> vorhanden ist. In diesem Fall ist das Hauptkonto in der Regel das, auf das network.privilegedadaccount Sie die SPNs eintragen. Wenn nicht, füge es mit dem adutil Befehl 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 <Prinzipal> wurde in der Schlüsseltabelle nicht gefunden (Schlüsselversionsnummer des Tickets <KVNO>)“
Mögliche Ursache
Dieser Fehler zeigt an, dass SQL Server keinen Keytab-Eintrag für das angeforderte Ticket mit der angegebenen Key Version Number (KVNO) finden kann.
Leitlinien
Wenn Sie alle Einträge in der Schlüsseltabelle auflisten möchten, folgen Sie dem Abschnitt Überprüfen der Schlüsseltabellendatei und der Berechtigungen in diesem Artikel. Wenn du keine Fehlermeldung findest, die mit dem und <principal> KVNO übereinstimmt, aktualisiere die Keytab-Datei, um diesen Eintrag hinzuzufügen, und folge den Schritten in diesem Abschnitt.
Sie können auch den folgenden Befehl ausführen, um die neueste KVNO vom DC abzurufen. Bevor du diesen Befehl ausführst, erhalte oder erneuere das Kerberos-TGT mit diesem kinit Befehl. 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 <Prinzipal> mit Schlüsselversionsnummer <KVNO> wurde in der Schlüsseltabelle gefunden, jedoch nicht mit dem Verschlüsselungstyp <Verschlüsselungstyp>“
Mögliche Ursache
Dieser Fehler bedeutet, dass das Keytab von SQL Server nicht den vom Client angeforderten Verschlüsselungstyp enthält.
Leitlinien
Zur Validierung folgen Sie dem Abschnitt "Keytab"-Datei und Berechtigungen prüfen , um alle Einträge im Keytab aufzulisten. Wenn Sie keine Fehlermeldung finden, die mit dem Principal, KVNO und Verschlüsselungstyp übereinstimmt, aktualisieren Sie die Keytab-Datei, um diesen Eintrag hinzuzufügen, und folgen Sie den Schritten in diesem Abschnitt.
Fehlermeldung: „Der Anforderungsticketserver <Prinzipal> mit Schlüsselversionsnummer <KVNO> mit dem Verschlüsselungstyp <Verschlüsselungstyp> wurde in der Schlüsseltabelle gefunden, aber das Ticket kann nicht entschlüsselt werden“
Mögliche Ursache
Diese Fehlermeldung zeigt an, dass SQL Server keine Zugangsdaten aus der Keytab-Datei verwenden kann, um die eingehende Authentifizierungsanfrage zu entschlüsseln. Ein falsches Passwort verursacht diesen Fehler oft.
Leitlinien
Erstelle den Keytab mit dem richtigen Passwort neu. Wenn Sie adutilverwenden, erstellen Sie den Keytab mit dem richtigen Passwort und folgen Sie den Schritten im Tutorial: Verwenden Sie adutil, um die Active Directory-Authentifizierung mit SQL Server für Linux zu konfigurieren.
Gängige Ports
Diese Tabelle zeigt die gängigen Ports, die SQL Server für Linux zur Konfiguration und Verwaltung der Active Directory-Authentifizierung verwendet.
| Active Directory-Dienst | Hafen |
|---|---|
| DNS | 53 |
| LDAP | 389 |
| LDAPS | 636 |
| Kerberos | 88 |