Problembehandlung bei der Fehlermeldung "SSPI-Kontext kann nicht generiert werden"


Hinweis Kerberos Configuration Manager ist ein Diagnosetool, das die Behandlung von Kerberos-bezogenen Konnektivitätsproblemen im Zusammenhang mit SQL Server erleichtert. Diese Probleme können Fehler wie zum Beispiel „Der SSPI Kontext kann nicht erstellt werden“ auslösen. Dieses Tool ist jetzt verfügbar und kann unter der folgenden Adresse heruntergeladen werden:

https://www.microsoft.com/de-de/download/details.aspx

Weitere Informationen finden Sie in den folgenden Microsoft Knowledge Base-Artikeln:

Neues Tool: Mit „Microsoft Kerberos Configuration Manager für SQL Server“ können Sie Kerberos-/Konnektivitätsprobleme beheben

Kerberos Configuration Manager für SQL Server ist verfügbar

 

In diesem Abschnitt finden Sie die Hintergrundinformationen dazu, warum die Fehlermeldung "SSPI-Kontext kann nicht generiert werden" auftritt, und wie Sie den Fehler beheben können. Diese Fehlermeldung kann angezeigt werden, wenn die folgenden Bedingungen vorliegen:

  • Sie stellen eine Verbindung zu Microsoft SQL Server her.

  • Sie verwenden die integrierte Sicherheit.

  • Für die Sicherheitsdelegierung wird die Kerberos-Authentifizierung verwendet.

Kerberos-Terminologie und Dienstprinzipalname Der SQL Server-Treiber auf einem Clientcomputer verwendet die integrierte Sicherheit dazu, über das Windows-Sicherheitstoken des Benutzerkontos erfolgreich eine Verbindung mit einem SQL Server-Computer herzustellen. Das Windows-Sicherheitstoken wird vom Client an den SQL Server-Computer delegiert. Der SQL Server-Treiber führt diese Delegierung mit einer der folgenden Konfigurationen durch, wenn das Sicherheitstoken des Benutzers von einem Computer an einen anderen delegiert wird:

  • NTLM über Named Pipes (ohne Security Support Provider Interface [SSPI])

  • NTLM über TCP/IP-Sockets mit SSPI

  • Kerberos-Authentifizierung über TCP/IP-Sockets mit SSPI

Die SSPI-Schnittstelle (SSPI = Security Support Provider Interface) besteht aus mehreren Windows-APIs, die die Delegierung und gegenseitige Authentifizierung über eine beliebige generische Datentransportebene wie z. B. TCP/IP-Sockets ermöglichen. Daher kann ein Computer mit einem Windows-Betriebssystem über SSPI ein Benutzersicherheitstoken sicher von einem Computer an einen anderen delegieren, und zwar über jede Transportebene, die Rohdatenbytes übertragen kann.

Die Fehlermeldung "Der SSPI-Kontext kann nicht generiert werden" wird erzeugt, wenn SSPI die Kerberos-Authentifizierung für die Delegierung über TCP/IP verwendet und Kerberos nicht in der Lage ist, die erforderlichen Vorgänge durchzuführen, um das Benutzersicherheitstoken erfolgreich an den SQL Server-Zielcomputer zu delegieren.

Warum die Security Support Provider-Schnittstelle NTLM- oder-Kerberos-Authentifizierung verwendet Die Kerberos-Authentifizierung verwendet einen Bezeichner namens „Dienstprinzipalname“ (Service Principle Name, SPN). Sie können einen SPN als einen eindeutigen Domänen- oder Gesamtstrukturbezeichner einer Instanz in einer Serverressource betrachten. Ein Webdienst, SQL-Dienst oder SMTP-Dienst kann einen SPN haben. Es sind auch mehrere Webdienstinstanzen auf demselben physischen Computer mit einem eindeutigen SPN möglich.

Ein SPN für SQL Server besteht aus folgenden Elementen:

  • Serviceklasse: Identifiziert die allgemeine Dienstklasse. Für SQL Server ist das immer MSSQLSvc.

  • Host: Vollqualifizierter Domänenname (DNS-Name) des SQL Server-Computers.

  • Port: Nummer des Ports, den der Dienst abhört.

Ein typischer SPN für einen SQL Server-Computer sieht beispielsweise so aus:


MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433

Das Format eines SPN für eine Standardinstanz und das Format eines SPN für eine benannte Instanz unterscheiden sich nicht. Die Portnummer bindet den SPN an eine bestimmte Instanz.

Wenn der SQL Server-Treiber auf einem Client die integrierte Sicherheit verwendet, um eine Verbindung zu SQL Server herzustellen, versucht der Treibercode auf dem Client, den vollqualifizierten DNS-Namen des SQL Server-Computers über die WinSock-Netzwerk-APIs aufzulösen. Für diesen Vorgang ruft der Treibercode die WinSock-APIs gethostbyname und gethostbyaddr auf. Selbst wenn eine IP-Adresse oder ein Hostname als Name des SQL Server-Computers übergeben wird, versucht der SQL Server-Treiber, den vollqualifizierten DNS-Namen des Computers aufzulösen, wenn der Computer die integrierte Sicherheit verwendet.

Wenn der SQL Server-Treiber auf dem Client den vollqualifizierten DNS-Namen des SQL Server-Computers auflöst, wird der entsprechende DNS-Name dazu verwendet, den SPN für diesen Computer zu bilden. Daher können alle Probleme, die mit der Auflösung der IP-Adresse oder des Hostnamens durch WinSock zum vollqualifizierten DNS-Namen zusammenhängen, zur Folge haben, dass der SQL Server-Treiber einen ungültigen SPN für den SQL Server-Computer erstellt.

Beispiele für ungültige SPNs, die der SQL Server-Treiber auf Clientseite als aufgelöste vollqualifizierte DNS-Namen bilden kann:

  • MSSQLSvc/SQLSERVER1:1433

  • MSSQLSvc/123.123.123.123:1433

  • MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433

  • MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433

Wenn der SQL Server-Treiber einen ungültigen SPN erstellt, funktioniert die Authentifizierung trotzdem, da die SSPI-Schnittstelle versucht, den SPN im Verzeichnisdienst des Active Directory zu finden, und dies nicht gelingt. Wenn die SSPI-Schnittstelle den SPN nicht findet, wird keine Kerberos-Authentifizierung durchgeführt. An diesem Punkt wechselt die SSPI-Ebene in einen NTLM-Authentifizierungsmodus, d. h., die NTLM-Authentifizierung wird für die Anmeldung verwendet und ist in der Regel erfolgreich. Wenn der SQL Server-Treiber einen SPN erstellt, der zwar gültig ist, aber nicht dem richtigen Container zugeordnet ist, versucht er vergeblich, den SPN zu verwenden. Dadurch kommt es zu der Fehlermeldung "Der SSPI-Kontext kann nicht generiert werden". Wenn es sich beim SQL Server-Startkonto um ein lokales Systemkonto handelt, ist der Computername der richtige Container. Für jedes andere Konto ist das SQL Server-Startkonto der richtige Container. Da die Authentifizierung versucht, den ersten gefundenen SPN zu verwenden, darf es keine SPNs geben, die falschen Containern zugeordnet sind. Anders ausgedrückt: Jeder SPN darf nur einem einzigen Container zugeordnet sein.

Der Schlüsselfaktor für eine erfolgreiche Kerberos-Authentifizierung ist die DNS-Funktionalität im Netzwerk. Sie können diese Funktionalität auf dem Client und auf dem Server mit dem Befehlszeilenprogramm "Ping" prüfen. Führen Sie auf dem Clientcomputer den folgenden Befehl aus, um die IP-Adresse des Servers zu erhalten, auf dem SQL Server ausgeführt wird (dabei lautet der Name des SQL Server-Computers „SQLServer1“):

ping sqlserver1 Führen Sie den folgenden Befehl aus, um herauszufinden, ob das Hilfsprogramm „Ping“ den vollqualifizierten DNS-Namen von „SQLServer1“ auflöst:

ping -a IP-Adresse Beispiel: C:\>ping SQLSERVER1 Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data: Reply from 123.123.123.123: bytes=32 time<10ms TTL=128 Reply from 123.123.123.123: bytes=32 time<10ms TTL=128 Reply from 123.123.123.123: bytes=32 time<10ms TTL=128 Reply from 123.123.123.123: bytes=32 time<10ms TTL=128 Ping statistics for 123.123.123.123: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms C:\>ping -a 123.123.123.123 Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data: Reply from 123.123.123.123: bytes=32 time<10ms TTL=128 Reply from 123.123.123.123: bytes=32 time<10ms TTL=128 Reply from 123.123.123.123: bytes=32 time<10ms TTL=128 Reply from 123.123.123.123: bytes=32 time<10ms TTL=128 Ping statistics for 123.123.123.123: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms C:\> Wenn der Befehl ping -a IP-Adresse die Adresse in den richtigen vollqualifizierten DNS-Namen des SQL Server-Computers auflöst, ist die clientseitige Auflösung ebenfalls erfolgreich.

Erstellung von SQL Server-Dienstprinzipalnamen Dies ist einer der wichtigen Bestandteile der Interaktion zwischen Kerberos-Authentifizierung und SQL Server. Mit SQL Server können Sie den SQL Server-Dienst unter einem „LocalSystem“-Konto, einem lokalen Benutzerkonto oder einem Domänenbenutzerkonto ausführen. Wenn die SQL Server-Dienstinstanz gestartet wird, versucht sie, mit dem API-Aufruf DsWriteAccountSpn ihren eigenen SPN in Active Directory zu registrieren. Wenn der Aufruf nicht erfolgreich ist, wird die folgende Warnung in der Ereignisanzeige protokolliert: Weitere Informationen zur Funktion DsWriteAccountSpn finden Sie auf der folgenden Microsoft-Website:

http://msdn2.microsoft.com/library/ms676056.aspx

Vereinfachte Erklärung Wenn Sie den SQL Server-Dienst unter dem Konto „LocalSystem“ ausführen, wird der SPN automatisch registriert, und es findet eine erfolgreiche Interaktion zwischen der Kerberos-Authentifizierung und dem SQL Server-Computer statt. Wenn Sie den SQL Server-Dienst jedoch unter einem Domänenkonto oder einem lokalen Konto ausführen, wird der Versuch, den SPN zu erstellen, in den meisten Fällen fehlschlagen, da das Domänenkonto und das lokale Konto nicht berechtigt sind, eigene SPNs festzulegen. Wenn die Erstellung des SPN scheitert, bedeutet dies, dass kein SPN für den SQL Server-Computer festgelegt wird. Wenn Sie mit einem Domänenadministratorkonto als SQL Server-Dienstkonto einen Test durchführen, wird der SPN erfolgreich erstellt, da die Anmeldeinformationen auf Domänenadministratorebene, die Sie für die Erstellung eines SPN benötigen, vorhanden sind.

Da Sie eventuell kein Domänenadministratorkonto zum Ausführen des SQL Server-Dienstes verwenden (um Sicherheitsrisiken zu vermeiden), kann der SQL Server-Computer keinen eigenen SPN erstellen. Daher müssen Sie manuell einen SPN für Ihren SQL Server-Computer erstellen, wenn Sie beim Herstellen einer Verbindung zu einem SQL Server-Computer die Kerberos-Authentifizierung verwenden möchten. Das ist der Fall, wenn Sie SQL Server unter einem Domänenbenutzerkonto oder einem lokalen Benutzerkonto ausführen. Der erstellte SPN muss dem Dienstkonto des SQL Server-Dienstes auf diesem Computer zugeordnet werden. Der SPN kann dem Computercontainer nur dann zugeordnet werden, wenn der SQL Server-Computer mit dem lokalen Systemkonto gestartet wird. Es darf nur einen einzigen SPN geben, der dem richtigen Container zugeordnet werden muss. Dies ist in der Regel das aktuelle SQL Server-Dienstkonto, dies ist jedoch der Computerkontocontainer mit dem lokalen Systemkonto.
 

 

In diesem Abschnitt erfahren Sie, mit welchen Schritte Sie sicherstellen können, dass auf Ihrem Computer keine SSPI-Probleme auftreten.

Überprüfen der Domäne Vergewissern Sie sich, dass die Domäne, an der Sie sich anmelden, mit der Domäne kommunizieren kann, zu der der SQL Server-Computer gehört. Auch muss in der Domäne eine korrekte Namensauflösung stattfinden.

  1. Sie müssen sicherstellen, dass Sie sich mit demselben Domänenkonto und Kennwort wie das Startkonto des SQL Server-Dienstes bei Windows anmelden können. Der SSPI-Fehler kann beispielsweise in den folgenden Situationen auftreten:

    • Das Domänenkonto ist gesperrt.

    • Das Kennwort des Kontos wurde geändert. Sie haben den SQL Server-Dienst nach dem Ändern des Kennworts jedoch nicht neu gestartet.

  2. Wenn Ihre Anmeldedomäne eine andere Domäne ist als die des SQL-Computers, überprüfen Sie die Vertrauensstellung zwischen den Domänen.

  3. Überprüfen Sie, ob die Domäne, zu der der Server gehört, und das Domänenkonto, mit dem Sie die Verbindung herstellen, in derselben Gesamtstruktur liegen. Das ist eine Voraussetzung dafür, dass SSPI funktioniert.

  4. Verwenden Sie beim Starten von SQL Server die Option Konto wird für Delegierungszwecke vertraut in „Active Directory-Benutzer und -Computer“.


    Hinweis Das Recht „Konto wird für Delegierungszwecke vertraut“ ist nur dann erforderlich, wenn Sie Anmeldeinformationen vom SQL-Zielserver an einen SQL-Remoteserver delegieren, z. B. in einem Double-Hop-Szenario mit verteilten Abfragen (verknüpften Serverabfragen), für die die Windows-Authentifizierung verwendet wird.

  5. Verwenden Sie das Dienstprogramm "SetSPN.exe" (Verwaltung von Dienstprinzipalnamen für Konten) im Windows 2000 Resource Kit. Windows 2000- oder Windows Server 2003-Domänenadministratorkonten können mit diesem Dienstprogramm den SPN steuern, der einem Dienst und einem Konto zugewiesen wird. Für SQL Server darf nur ein SPN vorhanden sein. Der SPN muss dem richtigen Container zugeordnet werden, in den meisten Fällen das jeweilige SQL Server-Dienstkonto und das Computerkonto, wenn SQL Server mit dem lokalen Systemkonto gestartet wird. Wenn Sie SQL Server starten und mit dem Konto "LocalSystem" angemeldet sind, wird der SPN automatisch eingerichtet. Wenn Sie SQL Server jedoch mit einem Domänenkonto starten oder das Konto ändern, das zum Starten von SQL Server verwendet wird, müssen Sie "SetSPN.exe" ausführen, um abgelaufene SPNs zu entfernen, und dann einen gültigen SPN hinzufügen. Weitere Informationen finden Sie in der SQL Server 2000-Onlinedokumentation unter "Security Account Delegation" (Delegierung von Sicherheitskonten). Besuchen Sie hierzu die folgende Microsoft-Website:

    http://msdn2.microsoft.com/library/aa905162(SQL.80).aspx Weitere Informationen zu Windows 2000 Ressource-Kits finden Sie auf der folgenden Microsoft-Website:

    http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx?mfr=true

  6. Vergewissern Sie sich, dass die Namensauflösung richtig funktioniert. Methoden für die Namensauflösung können DNS, WINS, HOSTS-Dateien und LMHOSTS-Dateien sein. Weitere Informationen zu Problemen mit der Namensauflösung und zur Problembehandlung finden Sie im folgenden Artikel der Microsoft Knowledge Base:

    169790 Problembehandlung für TCP/IP
     

  7. Weitere Informationen zur Behandlung von Zugriffs- und Firewallproblemen im Zusammenhang mit Active Directory finden Sie in den folgenden Artikeln der Microsoft Knowledge Base:

    291382 Häufig gestellte Fragen zu Windows 2000 DNS und Windows Server 2003 DNS
     

    224196 Einschränken von Active Directory-Replikationsverkehr und Client-RPC-Verkehr an einem bestimmten Anschluss

Konfigurieren des SQL Server-Diensts für die dynamische Erstellung von SPNs für die SQL Server-Instanzen Um den SQL Server-Dienst für die dynamische Erstellung von SPNs zu konfigurieren, müssen Sie die Zugriffssteuerungseinstellungen des Kontos im Active Directory-Verzeichnisdienst ändern. Sie müssen dem SQL Server-Dienstkonto die Berechtigungen „Read servicePrincipalName“ („servicePrincipalName“ lesen) und „Write servicePrincipalName“ („servicePrincipalName“ schreiben) erteilen.

Warnung Wenn Sie das ADSI-Edit-Snap-In (Active Directory Service Interfaces-Editor), das LDP-Hilfsprogramm oder einen anderen LDAP 3-Client verwenden und die Attribute von Active Directory-Objekten nicht ordnungsgemäß ändern, kann dies schwerwiegende Probleme zur Folge haben. Diese Probleme können eine Neuinstallation von Windows Server 2003, Microsoft Windows 2000 Server, Microsoft Exchange Server 2003, Microsoft Exchange 2000 Server oder sowohl von Windows als auch von Exchange erforderlich machen. Microsoft kann nicht dafür garantieren, dass Probleme, die von einer unkorrekten Änderung der Attribute von Active Directory-Objekten herrühren, behoben werden können. Das Ändern dieser Attribute erfolgt auf Ihr eigenes Risiko.

Hinweis Um dem SQL Server-Startkonto die entsprechenden Berechtigungen und Benutzerrechte zu erteilen, müssen Sie als Domänenadministrator angemeldet sein oder Ihren Domänenadministrator bitten, diese Aufgabe auszuführen.

Gehen Sie folgendermaßen vor, um den SQL Server-Dienst darauf zu konfigurieren, SPNs dynamisch zu erstellen:

  1. Klicken Sie auf Start, klicken Sie auf Ausführen, geben Sie Adsiedit.msc ein, und klicken Sie dann auf OK.

  2. Erweitern Sie im ADSI Edit-Snap-In nacheinander Domain [Domänenname], DC= Stammdomänenname und CN=Users. Klicken Sie mit der rechten Maustaste auf CN= Kontoname, und klicken Sie dann auf Eigenschaften.

    Hinweise

    • Domänenname ist ein Platzhalter für den Namen der Domäne.

    • Stammdomänenname ist ein Platzhalter für den Namen der Stammdomäne.

    • Kontoname ist ein Platzhalter für das Konto, das Sie zum Starten des SQL Server-Diensts angeben.

    • Wenn Sie das lokale Systemkonto zum Starten des SQL Server-Diensts angeben, ist Kontoname ein Platzhalter für das Konto, das Sie zum Anmelden bei Microsoft Windows verwenden.

    • Wenn Sie ein Domänenbenutzerkonto zum Starten des SQL Server-Diensts angeben, ist Kontoname ein Platzhalter für das Domänenbenutzerkonto.

  3. Klicken Sie im Dialogfeld Eigenschaften von CN= Kontoname auf die Registerkarte Sicherheit.

  4. Klicken Sie auf der Registerkarte Sicherheit auf Erweitert.

  5. Vergewissern Sie sich im Dialogfeld Erweiterte Sicherheitseinstellungen, dass unter Berechtigungseinträge der Eintrag SELBST aufgelistet ist.

    Wenn SELBST nicht aufgelistet ist, klicken Sie auf Hinzufügen, und fügen Sie SELBST hinzu.

  6. Klicken Sie unter Berechtigungseinträge auf SELBST und anschließend auf Bearbeiten.

  7. Klicken Sie im Dialogfeld Berechtigungseintrag auf die Registerkarte Eigenschaften.

  8. Klicken Sie auf der Registerkarte Eigenschaften auf Nur dieses Objekt in der Liste Anwenden auf. Stellen Sie sicher, dass die Kontrollkästchen für die folgenden Berechtigungen unter Berechtigungen aktiviert sind:

    • Read servicePrincipalName (SPN lesen)

    • Write servicePrincipalName (SPN schreiben)

  9. Klicken Sie dreimal auf OK, und beenden Sie das ADSI Edit-Snap-In.

Wenn Sie Hilfe bei diesem Vorgang benötigen, wenden Sie sich an den Active Directory-Produktsupport, und nennen Sie die Artikelnummer des Microsoft Knowledge Base-Artikels.


Wichtig Wir empfehlen, dem SQL-Dienstkonto nur dann das Recht „WriteServicePrincipalName“ zu gewähren, wenn die folgenden Bedingungen zutreffen:

  • Es sind mehrere Domänencontroller vorhanden.

  • SQL Server läuft auf Clusterserver.

In diesem Szenario kann der SPN für den SQL Server aufgrund von Wartezeiten bei der Active Directory-Replikation gelöscht werden. Dadurch können Konnektivitätsprobleme bei der SQL Server-Instanz auftreten.

Angenommen, Sie verfügen über folgende Konfiguration:

  • Eine virtuelle SQL-Instanz namens Sqlcluster mit zwei Knoten: Knoten A und Knoten B.

  • Knoten A wird von Domänencontroller A authentifziert, und Knoten B wird von Domänencontroller B authentifziert.



Folgendes kann geschehen:

  1. Die Instanz Sqlcluster ist auf Knoten A aktiv und registriert während des Systemstart den SQL-SPN auf Domänencontroller A.

  2. Für die Instanz Sqlcluster wird beim Herunterfahren von Knoten A ein Failover auf Knoten B durchgeführt.

  3. Beim Herunterfahren auf Knoten A hebt die Instanz „Sqlcluster“ die Registrierung ihres SPN auf Domänencontroller A auf.

  4. Der SPN wird vom Domänencontroller A entfernt, aber die Änderung ist noch nicht auf den Domänencontroller B repliziert worden.

  5. Beim Hochfahren auf Knoten B versucht die Instanz Sqlcluster, den SQL-SPN beim Domänencontroller B zu registrieren. Da der SPN noch vorhanden ist, registriert Knoten B den SPN nicht.

  6. Nach einiger Zeit repliziert Domänencontroller A die Löschung des SPN (aus Schritt 3) im Rahmen der Active Directory-Replikation auf Domänencontroller B. Infolgedessen ist in der Domäne keine SPN für die SQL-Instanz mehr vorhanden, und es treten Verbindungprobleme bei der Instanz Sqlcluster auf.


Hinweis Dieses Problem wurde in SQL Server 2012 behoben.

Serverumgebung überprüfen Überprüfen Sie Grundeinstellungen auf dem SQL Server-Computer:

  1. Die Kerberos-Authentifizierung wird auf Windows 2000-basierten Computern, auf denen der Windows-Clusterdienst ausgeführt wird, nicht unterstützt, es sei denn, Sie haben Service Pack 3 (oder eine höhere Version) für Windows 2000 installiert. Daher kann der Versuch fehlschlagen, die SSPI-Authentifizierung bei einer geclusterten Instanz von SQL Server zu verwenden. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:

    235529 Unterstützung der Kerberos-Authentifizierung in Windows 2000-basierten Serverclustern
     

  2. Vergewissern Sie sich, dass auf dem Server Windows 2000 Service Pack 1 (SP1) ausgeführt wird. Weitere Informationen zur Unterstützung der Kerberos-Authentifizierung in Windows 2000-basierten Serverclustern finden Sie im folgenden Artikel der Microsoft Knowledge Base:

    267588 Fehlermeldung „Der SSPI Kontext kann nicht erstellt werden“ beim Herstellen der Verbindung mit SQL Server 2000
     

  3. Wenn sich bei einem Cluster das Konto ändert (z. B. durch eine Kennwortänderung), das Sie zum Starten des SQL Server-, SQL Server-Agent- oder Volltextsuchdiensts verwenden, führen Sie die Schritte aus dem folgenden Microsoft Knowledge Base-Artikel durch:

    239885 Ändern von Dienstkonten für einen geclusterten Computer, auf dem SQL Server ausgeführt wird
     

  4. Stellen Sie sicher, dass das Konto, das Sie zum Starten von SQL Server verwenden, die erforderlichen Berechtigungen hat. Wenn Sie ein Konto verwenden, das nicht Mitglied der lokalen Administratorgruppe ist, finden Sie im Thema „Einrichten von Windows-Dienstkonten“ in der SQL Server-Onlinedokumentation eine detaillierte Liste der Berechtigungen, über die dieses Konto verfügen muss:

    http://msdn2.microsoft.com/library/aa176564(SQL.80).aspx

Überprüfen der Clientumgebung Überprüfen Sie Folgendes auf dem Client:

  1. Stellen Sie sicher, dass der NTLM-Sicherheitsdienst auf dem Client korrekt installiert und aktiviert ist. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:

    269541 Fehlermeldung beim Herstellen der Verbindung mit SQL Server, wenn der Registrierungsschlüssel für den Windows NTLM-Sicherheitsdienst fehlt: „Der SSPI Kontext kann nicht erstellt werden“
     

  2. Stellen Sie fest, ob Sie zwischengespeicherte Zugangsberechtigungen verwenden. Wenn Sie mit zwischengespeicherten Zugangsberechtigungen am Client angemeldet sind, melden Sie sich vom Computer ab, und melden Sie sich anschließend wieder an, wenn Sie eine Verbindung zu einem Domänencontroller herstellen können, um die Verwendung der zwischengespeicherten Zugangsberechtigungen zu verhindern. Weitere Informationen dazu, wie Sie ermitteln können, ob Sie zwischengespeicherte Anmeldeinformationen verwenden, finden Sie im folgenden Artikel der Microsoft Knowledge Base:

    242536 Benutzer wird bei Anmeldung mit zwischengespeicherten Zugangsberechtigungen nicht gewarnt
     

  3. Vergewissern Sie sich, dass das Datum auf Client und Server gültig ist. Wenn die Datumsangaben zu weit auseinander liegen, werden Ihre Zertifikate eventuell als ungültig betrachtet.

  4. SSPI verwendet eine Datei namens "Security.dll". Wenn eine andere Anwendung eine Datei mit diesem Namen installiert, wird eventuell die andere Datei anstelle der jeweiligen SSPI-Datei verwendet. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:

    253577 Fehlermeldung: 80004005 – MS ODBC SQL Server driver cannot initialize SSPI package (Der MS ODBC SQL Server-Treiber kann das SSPI-Paket nicht initialisieren)
     

  5. Wenn das Betriebssystem auf dem Client Microsoft Windows 98 ist, müssen Sie die Komponente "Client für Microsoft-Netzwerke" auf dem Client installieren.

    Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:

    267550 FEHLER: „Assertionsfehler“, wenn Sie über TCP/IP eine Verbindung mit SQL Server herstellen
     

Überprüfen der SQL Server-Clientkonfiguration Die SQL Server-Clientkonfiguration, die im Lieferumfang der Microsoft Data Access Components (MDAC) enthalten ist, wird für die Konfiguration von Verbindungen zu SQL Server-Computern verwendet. Sie können das MDAC-Dienstprogramm "Cliconfg.exe" zum Konfigurieren von Verbindungen verwenden:

  1. Auf der Registerkarte Allgemein werden die Protokolle je nach MDAC-Version unterschiedlich definiert. Bei früheren MDAC-Versionen können Sie ein "Standardprotokoll" auswählen. In den neueren MDAC-Versionen können Sie ein oder mehrere Protokolle aktivieren, wobei eines am Anfang der Liste steht, wenn Sie eine Verbindung zu SQL Server herstellen. Da SSPI nur für TCP/IP gilt, können Sie ein anderes Protokoll wie z. B. Named Pipes verwenden, um den Fehler zu vermeiden.

  2. Überprüfen Sie in der SQL Server-Clientkonfiguration auf der Registerkarte Alias, ob ein Alias für den Server definiert ist, mit dem Sie eine Verbindung herstellen möchten. Wenn ein Serveralias definiert ist, überprüfen Sie, mit welchen Einstellungen dieser Computer für die Verbindung zu SQL Server konfiguriert ist. Sie können dies feststellen, indem Sie den Aliasserver löschen, um herauszufinden, ob sich das Verhalten ändert.

  3. Wenn der Aliasserver in der SQL Server-Clientkonfiguration nicht definiert ist, fügen Sie den Alias für den Server hinzu, zu dem Sie eine Verbindung herstellen möchten. Dabei definieren Sie gleichzeitig auch explizit das Protokoll und optional die IP-Adresse und den Port.

Manuelles Einrichten eines Dienstprinzipalnamen für SQL Server Weitere Informationen zur manuellen Einrichtung des Dienstprinzipalnamens für SQL Server finden Sie im folgenden Artikel der Microsoft Knowledge Base:

319723 Verwenden der Kerberos-Authentifizierung in SQL Server
  Die Security Support Provider-Schnittstelle (SSPI-Schnittstelle) ist die Schnittstelle zur Microsoft Windows NT-Sicherheit, die für die Kerberos-Authentifizierung verwendet wird. Sie unterstützt das Authentifizierungsschema des NTLM-Sicherheitsdiensts. Die Authentifizierung findet bei der Anmeldung an einer Windows-Domäne auf Betriebssystemebene statt. Die Kerberos-Authentifizierung steht nur auf Windows 2000-basierten Computern zur Verfügung, die die Kerberos-Authentifizierung aktiviert haben und Active Directory verwenden.

SSPI wird nur für TCP/IP-Verbindungen verwendet, die über die Windows-Authentifizierung hergestellt werden. Die Windows-Authentifizierung wird auch als "vertrauenswürdige Verbindungen" oder "integrierte Sicherheit" bezeichnet). SSPI wird von Named Pipes oder Multiprotokollverbindungen nicht verwendet. Daher können Sie das Problem vermeiden, indem Sie die Clients für eine Verbindung über ein anderes Protokoll als TCP/IP konfigurieren.

Wenn ein SQL Server-Client versucht, die integrierte Sicherheit über TCP/IP-Sockets für die Verbindung zu einem SQL Server-Remotecomputer zu verwenden, verwendet die SQL Server-Client-Netzwerkbibliothek die SSPI-API für die Sicherheitsdelegierung. Der SQL Server-Netzwerkclient („Dbnetlib.dll“) ruft die Funktion AcquireCredentialsHandle auf und übergibt „negotiate“ für den Parameter pszPackage. Dadurch wird der zu Grunde liegende Sicherheitsanbieter veranlasst, die Delegierung auszuhandeln. "Negotiate" bedeutet in diesem Kontext, dass auf Windows-Computern versucht wird, entweder die Kerberos- oder die NTLM-Authentifizierung zu verwenden. Anders ausgedrückt: Windows verwendet die Kerberos-Delegierung, wenn der SQL-Zielcomputer einen zugehörigen, richtig konfigurierten SPN hat. Andernfalls verwendet Windows die NTLM-Delegierung.

Hinweis Stellen Sie sicher, dass Sie kein Konto namens „SYSTEM“ verwenden, um einen der SQL Server-Dienste (MSSQLServer, SQLServerAgent, MSSearch) zu starten. Das Schlüsselwort SYSTEM kann Konflikte mit dem Schlüsselverteilungscenter (KDC = Key Distribution Center) verursachen.
 

 

Wenn Sie anhand der Problembehandlungsschritte in diesem Artikel die Ursache des Problems nicht ermitteln können, stellen Sie die folgenden Informationen zusammen, und melden Sie das Problem als Supportfall an den Microsoft Customer Support (CSS):

Eine vollständige Liste mit Telefonnummern der Microsoft Customer Support Services und Informationen über die Supportkosten finden Sie auf der folgenden Microsoft-Website:

http://support.microsoft.com/de-de/contactus/?ws=support

  1. Generieren Sie in SQL Server einen Sqldiag-Bericht. Weitere Informationen finden Sie in der SQL Server-Onlinedokumentation unter "Sqldiag Utility".

  2. Erstellen Sie einen Screenshot des Fehlers auf dem Client.

  3. Öffnen Sie auf dem Knoten, der keine Verbindung mit SQL Server herstellen kann, eine Eingabeaufforderung, und geben Sie den folgenden Befehl ein:

    net start > started.txt Dieser Befehl generiert in dem Verzeichnis, in dem Sie den Befehl ausführen, eine Datei namens „Started.txt“.

  4. Speichern Sie die Werte für den Registrierungsschlüssel unter dem folgenden Registrierungsschlüssel auf dem Clientcomputer:

    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO

  5. Ermitteln Sie in einer Clusterumgebung den Wert des folgenden Registrierungsschlüssels für die einzelnen Knoten des Clusters:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel

  6. Ermitteln Sie in einer Clusterumgebung, ob der folgende Registrierungsschlüssel auf den einzelnen Clusterserverknoten vorhanden ist:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTLMSsp

  7. Zeichnen Sie die Ergebnisse auf, wenn Sie die Verbindung vom Client mit SQL Server über einen UNC-Namen (Universal Naming Convention) herstellen (oder in einem Cluster über den SQL-Netzwerknamen).

  8. Zeichnen Sie die Ergebnisse auf, wenn Sie die Verbindung zum Computernamen (oder bei einem Cluster zum SQL-Netzwerknamen) per Ping vom Client aus herstellen.

  9. Speichern Sie den Namen der Benutzerkonten, die Sie zum Starten der einzelnen SQL Server-Dienste (MSSQLServer, SQLServerAgent, MSSearch) verwenden.

  10. Der Supportmitarbeiter muss wissen, ob SQL Server für die gemischte Authentifizierung oder für Nur-Windows-Authentifizierung konfiguriert ist.

  11. Prüfen Sie, ob Sie vom selben Client über die SQL Server-Authentifizierung eine Verbindung zum SQL Server-Computer herstellen können.

  12. Prüfen Sie, ob Sie über das Named Pipes-Protokoll eine Verbindung herstellen können.

Informationsquellen Weitere Informationen zur Funktionsweise der Kerberos-Authentifizierung und der SSPI-Sicherheit finden Sie in den folgenden Artikeln der Microsoft Knowledge Base:

266080 Antworten auf häufig gestellte Fragen zur Kerberos-Authentifizierung
 

231789 Lokaler Anmeldevorgang für Windows 2000
 

304161 Gegenseitige SSPI-Authentifizierung wird auf der Clientseite, aber nicht auf der Serverseite angezeigt
 

232179 Kerberos-Verwaltung in Windows 2000
 

230476 Beschreibung häufiger Fehler im Zusammenhang mit Kerberos in Windows 2000
 

262177 Aktivieren der Kerberos-Ereignisprotokollierung
 

277658 „Setspn“ schlägt fehl, wenn sich der Domänenname von dem NetBIOS-Namen unterscheidet, unter dem der SQL Server-SPN registriert ist

244474 Erzwingen der Verwendung von TCP anstelle von UDP durch Kerberos in Windows Server 2003, Windows XP und Windows 2000
  Ein Whitepaper zur Sicherheit in Microsoft SQL Server 2000 finden Sie auf der folgenden Microsoft-Website:

http://technet.microsoft.com/cc984178.aspx

Benötigen Sie weitere Hilfe?

Ihre Office-Fähigkeiten erweitern
Schulungen erkunden
Neue Funktionen als Erster erhalten
Microsoft Insider beitreten

War diese Information hilfreich?

Vielen Dank für Ihr Feedback!

Vielen Dank für Ihr Feedback. Es klingt, als ob es hilfreich sein könnte, Sie mit einem unserer Office-Supportmitarbeiter zu verbinden.

×