DetailPage-MSS-KB

Knowledge Base

Artikel-ID: 811889 - Geändert am: Donnerstag, 3. Oktober 2013 - Version: 23.0

Erläuterung des Problems

Bild minimierenBild vergrößern
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 zu 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 die Kerberos-Authentifizierung verwendet
Die Kerberos-Authentifizierung verwendet eine Kennung namens "Dienstprinzipalname" (Service Principal 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 ist der Name des SQL Server-Computers SQLServer1):
ping sqlserver1
Führen Sie den folgenden Befehl aus, um herauszufinden, ob das Befehlszeilenprogramm "Ping" den vollqualifizierten DNS-Namen von SQLServer1 auflöst:
ping -a IPAddress
Beispiel:
C:\>ping SQLSERVER1

Ping wird ausgeführt für [123.123.123.123] mit 32 Bytes Daten:
	
Antwort von 123.123.123.123: Bytes=32 Zeit<10ms TTL=128 Antwort von 123.123.123.123: Bytes=32 Zeit<10ms TTL=128 Antwort von 123.123.123.123: Bytes=32 Zeit<10ms TTL=128 Antwort von 123.123.123.123: Bytes=32 Zeit<10ms TTL=128
	
Ping-Statistik für 123.123.123.123: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ungefähre Zeitangaben in Millisekunden: Minimum = 0ms, Maximum =  0ms, Mittelwert =  0ms
C:\>ping -a 123.123.123.123
	
Ping wird ausgeführt für SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] mit 32 Bytes Daten:
	
Antwort von 123.123.123.123: Bytes=32 Zeit<10ms TTL=128 Antwort von 123.123.123.123: Bytes=32 Zeit<10ms TTL=128 Antwort von 123.123.123.123: Bytes=32 Zeit<10ms TTL=128 Antwort von 123.123.123.123: Bytes=32 Zeit<10ms TTL=128 Ping-Statistik für 123.123.123.123: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ungefähre Zeitangaben in Millisekunden: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

C:\>
Wenn die Adresse mit dem Befehl ping -a IPAddress in den richtigen vollqualifizierten DNS-Namen des SQL Server-Computers aufgelöst wird, ist die Auflösung auf der Clientseite ebenfalls erfolgreich.
SQL Server-Dienstprinzipalnamen erstellen
Dies ist einer der zentralen Bestandteile der Interaktion zwischen der Kerberos-Authentifizierung und SQL Server. Bei SQL Server können Sie den SQL Server-Dienst unter einem der folgenden Konten ausführen: einem "LocalSystem"-Konto, einem lokalen Benutzerkonto oder einem Domänenbenutzerkonto. Wenn die SQL Server-Dienstinstanz gestartet wird, versucht sie, ihren eigenen SPN mit dem Aufruf DsWriteAccountSpn in Active Directory zu registrieren. Wenn der Aufruf nicht erfolgreich ist, wird die folgende Warnung in der Ereignisanzeige protokolliert:

Quelle: MSSQLServer-Ereigniskennung: 19011 Beschreibung: SuperSocket-Informationen: (SpnRegister): Fehler 8344.

Weitere Informationen zur Funktion DsWriteAccountSpn finden Sie auf der folgenden Microsoft-Website:
http://msdn.microsoft.com/de-de/library/ms676056.aspx (http://msdn.microsoft.com/de-de/library/ms676056.aspx)
Vereinfachte Erklärung
Wenn Sie den SQL Serverdienst 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 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 keine Berechtigung haben, 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.
Bild minimierenBild vergrößern

Beheben des Problems

Bild minimierenBild vergrößern
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). Wechseln Sie hierzu zur folgenden Microsoft-Website:
    http://msdn.microsoft.com/de-de/library/aa905162(SQL.80).aspx (http://msdn.microsoft.com/de-de/library/aa905162(SQL.80).aspx)
    Weitere Informationen zum Windows 2000 Resource Kit finden Sie auf der folgenden Microsoft-Website:
    http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx?mfr=true (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  (http://support.microsoft.com/kb/169790/de/ ) NT 4.0: Problembehandlung bei grundlegenden TCP/IP-Problemen
  7. Weitere Informationen zur Behebung von Zugriffs- und Firewallproblemen im Zusammenhang mit Active Directory finden Sie in den folgenden Artikeln der Microsoft Knowledge Base:
    291382  (http://support.microsoft.com/kb/291382/de/ ) Häufig gestellte Fragen zu Windows 2000 DNS und Windows Server 2003 DNS
    224196  (http://support.microsoft.com/kb/224196/de/ ) Einschränken des Active Directory-Replikationsverkehrs und Client-RPC-Verkehrs auf einen bestimmten Anschluss
Konfigurieren des SQL Server-Dienstes für das dynamische Erstellen von SPNs für die SQL Server-Instanzen
Sie müssen die Zugriffssteuerungseinstellungen des Kontos im Active Directory-Verzeichnisdienst ändern, um den SQL Server-Dienst darauf zu konfigurieren, SPNs dynamisch zu erstellen. Sie müssen dem SQL Server-Dienstkonto die Berechtigungen "Read servicePrincipalName" (SPN lesen) und "Write servicePrincipalName" (SPN schreiben) zuweisen.

Warnung Wenn Sie das ADSI Edit-Snap-In, das LDP-Dienstprogramm 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 Wenn Sie dem SQL Server-Startkonto die entsprechenden Berechtigungen und Benutzerrechte zuweisen möchten, müssen Sie als Domänenadministrator angemeldet sein, oder der Domänenadministrator muss diesen Vorgang für Sie ausführen.

Gehen Sie folgendermaßen vor, um den SQL Server-Dienst darauf zu konfigurieren, SPNs dynamisch zu erstellen:
  1. Klicken Sie auf Start und auf Ausführen, geben Sie adsiedit.msc ein, und klicken Sie 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 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-Dienstes angeben.
    • Wenn Sie das lokale Systemkonto zum Starten des SQL Server-Dienstes 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-Dienstes 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, dass im Dialogfeld Erweiterte Sicherheitseinstellungen unter Berechtigungseinträge der Eintrag SELBST (SELF) 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 in der Liste Übernehmen für auf Nur dieses Objekt, und stellen Sie anschließend sicher, dass unter Berechtigungen die Kontrollkästchen für die folgenden 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 WriteServicePrincipalName-Recht 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. Während des Herunterfahrens hebt die Instanz Sqlcluster die Registrierung ihres SPN auf dem 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.
Überprüfen der Serverumgebung
Überprüfen Sie Grundeinstellungen auf dem SQL Server-Computer:
  1. Kerberos wird auf Computers mit Windows 2000, auf denen Windows Clustering eingesetzt wird, nur dann unterstützt, wenn Service Pack 3 (oder eine höhere Version) für Windows 2000 installiert worden ist. Daher kann der Versuch fehlschlagen, die SSPI-Authentifizierung bei einer gruppierten Instanz von SQL Server zu verwenden. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
    235529  (http://support.microsoft.com/kb/235529/de/ ) Unterstützung für die Kerberos-Authentifizierung auf Windows 2000-basierten Serverclustern
  2. Vergewissern Sie sich, dass der Server mit Windows 2000 Service Pack 1 (SP1) arbeitet. Weitere Informationen zur Unterstützung der Kerberos-Authentifizierung auf Windows 2000-Servern finden Sie im folgenden Artikel der Microsoft Knowledge Base:
    267588  (http://support.microsoft.com/kb/267588/de/ ) Fehlermeldung "Der SSPI-Kontext kann nicht generiert werden" bei 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 Volltextsuchdienstes verwenden, führen Sie die Schritte durch, die im folgenden Artikel der Microsoft Knowledge Base beschrieben werden:
    239885  (http://support.microsoft.com/kb/239885/de/ ) Ä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 Administratorengruppe ist, finden Sie im Thema "Setting up Windows Services Accounts" (Einrichten von Windows-Dienstkonten) in der SQL Server-Onlinedokumentation eine detaillierte Liste der Berechtigungen, über die dieses Konto verfügen muss:
    http://msdn.microsoft.com/de-de/library/aa176564(SQL.80).aspx (http://msdn.microsoft.com/de-de/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  (http://support.microsoft.com/kb/269541/de/ ) Fehlermeldung beim Verbinden mit SQL Server, wenn der Windows NTLM-SSPI-Registrierungsschlüssel fehlt: "Der SSPI-Kontext kann nicht generiert 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 feststellen können, ob Sie zwischengespeicherte Zugangsberechtigungen verwenden, finden Sie im folgenden Artikel der Microsoft Knowledge Base:
    242536  (http://support.microsoft.com/kb/242536/de/ ) Benutzer wird bei Anmeldung mit zwischengespeicherten Zugangsberechtigungen nicht gewarnt
  3. Vergewissern Sie sich, dass Client und Server ein gültiges Datum haben. 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 zu SSPI gehörigen Datei "Security.dll" verwendet. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
    253577  (http://support.microsoft.com/kb/253577/de/ ) Fehler: 80004005 MS ODBC-SQL Server-Treiber kann 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  (http://support.microsoft.com/kb/267550/de/ ) Fehler: "Assertionsfehler",, wenn Sie über TCP/IP eine Verbindung zu 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 unterscheidet sich die Art, wie Protokolle definiert sind, je nach MDAC-Version. 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 auf der Registerkarte Alias in der SQL Server-Clientkonfiguration, ob ein Alias für den Server festgelegt ist, zu 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  (http://support.microsoft.com/kb/319723/de/ ) Verwenden der Kerberos-Authentifizierung in SQL Server
Die SSPI-Schnittstelle ist die Schnittstelle zur Microsoft Windows NT-Sicherheit, die für die Kerberos-Authentifizierung verwendet wird, und unterstützt das Authentifizierungsschema des NTLM-Sicherheitsdienstes. 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.
Bild minimierenBild vergrößern

Sammeln von Informationen zum Öffnen einer Anfrage beim Microsoft Customer Support (CSS)

Bild minimierenBild vergrößern
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/contactus/?ln=de&ws=support#tab0 (http://support.microsoft.com/contactus/?ln=de&ws=support#tab0)
  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. Geben Sie auf dem Knoten, der keine Verbindung zu SQL Server herstellen kann, an der Eingabeaufforderung den folgenden Befehl ein:
    net start > started.txt
    Dieser Befehl erzeugt 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 zu SQL Server über einen UNC-Namen (UNC = Universal Naming Convention) herstellen (oder bei 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  (http://support.microsoft.com/kb/266080/de/ ) Beantwortet häufig gestellte Fragen zur Kerberos-Authentifizierung
231789  (http://support.microsoft.com/kb/231789/de/ ) Lokaler Anmeldevorgang für Windows 2000
304161  (http://support.microsoft.com/kb/304161/de/ ) Gegenseitige SSPI-Authentifizierung wird auf der Clientseite, aber nicht auf der Serverseite angezeigt
232179  (http://support.microsoft.com/kb/232179/de/ ) Kerberos-Verwaltung in Windows 2000
230476  (http://support.microsoft.com/kb/230476/de/ ) Beschreibung von häufigen Kerberos-spezifischen Fehlern in Windows 2000
262177  (http://support.microsoft.com/kb/262177/de/ ) Aktivieren der Kerberos-Ereignisprotokollierung
277658  (http://support.microsoft.com/kb/277658/de/ ) Setspn schlägt fehl, wenn sich der Domänenname von dem NetBIOS-Namen unterscheidet, unter dem der SQL Server-SPN registriert ist
244474  (http://support.microsoft.com/kb/244474/de/ ) So erzwingen Sie, dass Kerberos in Windows Server 2003, Windows XP und Windows 2000 TCP anstelle von UDP verwendet
Ein Whitepaper zur Sicherheit in Microsoft SQL Server 2000 finden Sie auf der folgenden Microsoft-Website:
http://technet.microsoft.com/de-de/cc984178.aspx (http://technet.microsoft.com/de-de/cc984178.aspx)
Bild minimierenBild vergrößern

Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-Bit Edition
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Enterprise Evaluation
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Express with Advanced Services
  • Microsoft SQL Server 2008 R2 Datacenter
  • Microsoft SQL Server 2008 R2 Developer
  • Microsoft SQL Server 2008 R2 Enterprise
  • Microsoft SQL Server 2008 R2 Express
  • Microsoft SQL Server 2008 R2 Express with Advanced Services
  • Microsoft SQL Server 2008 R2 Integration Services
  • Microsoft SQL Server 2008 R2 Standard
  • Microsoft SQL Server 2008 R2 Standard Edition for Small Business
  • Microsoft SQL Server 2008 R2 Web
  • Microsoft SQL Server 2008 R2 Workgroup
  • Microsoft SQL Server 2008 Reporting Services
  • Microsoft SQL Server 2008 Standard
  • Microsoft SQL Server 2008 Standard Edition for Small Business
  • Microsoft SQL Server 2008 Web
  • Microsoft SQL Server 2008 Workgroup
  • Microsoft SQL Server 2012 Developer
  • Microsoft SQL Server 2012 Enterprise
  • Microsoft SQL Server 2012 Express
  • Microsoft SQL Server 2012 Standard
  • Microsoft SQL Server 2012 Web
  • SQL Server 2012 Enterprise Core
Keywords: 
kbsqlsetup kbhowtomaster kbhowto kbsmbportal KB811889
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.
Freigeben
Weitere Supportoptionen
Microsoft Community-Supportforen
Kontaktieren Sie uns direkt
Zertifizierten Partner finden
Microsoft Store
Folgen Sie uns: