Eine Warnmeldung "Warning SuperSocket Info"-Informationen erhalten, wenn ein SQL Server-Dienstkonto ein Domänenbenutzer ist

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 303411 - Produkte anzeigen, auf die sich dieser Artikel bezieht
# FEHLER: 232774 (SHILOH_BUGS)
Alles erweitern | Alles schließen

Problembeschreibung

Beim Starten von SQL Server auf einem Computer, auf dem ausgeführt wird Microsoft SQL Server 2000 oder Microsoft SQL Server 2005, versucht das SQL Server-Programm immer, registrieren der virtuelle Server in Active Directory. Das folgende Ereignis kann im Ereignisprotokoll protokolliert:

SuperSocket-Information: (SpnRegister): Error 8344 SuperSocket Info: (SPNRegister): Error 1355 SuperSocket Info: SpnUnRegister(): Fehler 8344.

HinweisFehler 1355 ist gleich ERROR_NO_SUCH_DOMAIN. Fehler 8344 ist nicht genügend Berechtigungen zum Ausführen des Vorgangs Registrierung gleich. Dies wird als Warnung für die SPNRegister -Funktion und als Fehler für die SpnUnRegister -Funktion gezeigt.

Diese Nachricht ist keine Fehlermeldung angezeigt. Dieser Text ist nur ein Warnung, dass SQL Server einen Service principal Name (SPN) registrieren kann. Dies bedeutet, dass der Sicherheitsmechanismus, der verwendet wird Microsoft Windows NT Herausforderung/Rückmeldung (NTLM)-Authentifizierung Kerberos-Authentifizierung.

Diese Nachrichten sollten nur ein Problem angesehen, wenn die SQL Server-Installation Kerberos-Authentifizierung erfordert oder die Netzwerk-Sicherheitseinstellungen verhindern fallback auf NTLM-Aushandlung. Andernfalls können dieser Meldungen ignoriert werden.

Ursache

Die Nachricht wird in der Regel angezeigt, da der SQL Server-Dienst Konto als Domänenbenutzer ausgeführt wird, die nicht über die erforderliche Berechtigungen, um verfügt Registrieren von SPNs. Mit Microsoft Windows 2000 Service Pack 3 (SP3) können Sie aktivieren Kerberos-Authentifizierung auf Serverclustern. Anleitungen hierzu finden Sie im folgenden Artikel der Microsoft Knowledge Base:
319723 Informationen zu SQL Server 2000 Kerberos unterstützen, einschließlich SQL Server-virtuelle Server in Serverclustern

Lösung

Sie können auch das Konto Zugriffseinstellungen Berechtigungen im Active Directory-Verzeichnisdienst So aktivieren Sie die Leseberechtigung ServicePrincipalName und die ServicePrincipalName Schreibberechtigung für das SQL-Dienstkonto bearbeiten.

Warnung Wenn Sie das Active Directory Service Interfaces (ADSI) Edit-Snap-in, das LDP-Dienstprogramm oder jede andere LDAP-Clients der Version 3 verwenden und die Attribute von Active Directory-Objekten falsch ändern, können Sie schwerwiegende Probleme verursachen. Diese Probleme erfordern möglicherweise eine Neuinstallation von Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003 oder sowohl Windows und Exchange. Microsoft kann nicht garantieren, dass Probleme, die von einer unkorrekten Änderung von Active Directory-Objektattribute verursacht, behoben werden können. Ändern dieser Attribute erfolgt auf eigene Gefahr.

Abhilfe

Um diese Nachrichten Typ auflösen und aktivieren Sie den Dienst SQL Server SPN für SQL Server-Instanzen dynamisch erstellen, bitten Sie Ihren Domänenadministrator bitten, die entsprechenden Berechtigungen und Benutzerrechte für die Startkonten des SQL Server hinzufügen.

Gehen Sie folgendermaßen vor, um das SQL Server-Dienstkonto, SPNs korrekte beim Start zu aktivieren:
  1. Klicken Sie auf Start, klicken Sie auf Ausführen, Typ "Adsiedit.msc", und klicken Sie dann auf OK.
  2. In der ADSI-Bearbeitung Fenster erweitern Domain [Domänenname], erweitern Sie DC = Stammdomänenname, erweitern Sie CN = Benutzer, mit der rechten Maustaste CN =Kontoname, und klicken Sie dann auf Eigenschaften.

    Hinweise
    • Domänenname Stellt den Namen der Domäne.
    • Stammdomänenname ist ein Platzhalter für den Namen der Stammdomäne.
    • Kontoname Stellt dar, das Konto, das Sie zum Starten des SQL Server-Dienstes angeben.
    • Wenn Sie Lokales System zum Starten des Dienstes SQL Server angegeben haben Kontoname Stellt das Konto, das Sie verwenden, um die Anmeldung bei Microsoft Windows dar.
    • Wenn Sie ein Domänenbenutzerkonto für den SQL Server-Dienst angegeben haben Kontoname Stellt das Domänenbenutzerkonto dar.
  3. In der CN =Kontoname Eigenschaften Klicken Sie im Dialogfeld klicken Sie auf die Sicherheit Registerkarte.
  4. Auf der Sicherheit Registerkarte, klicken Sie auf Erweiterte.
  5. In der Erweiterte Sicherheitseinstellungen Dialog box, stellen Sie sicher, dass der Benutzer selbst unter aufgeführt ist Berechtigungseinträge. Wenn der Benutzer selbst nicht aufgeführt ist, klicken Sie auf Hinzufügen, und fügen Sie dann den Benutzer selbst .
  6. Klicken Sie unter Berechtigungseinträge, klicken Sie auf SELBST, und klicken Sie dann auf Bearbeiten.
  7. In der Berechtigungseintrag Klicken Sie im Dialogfeld klicken Sie auf die Eigenschaften Registerkarte.
  8. Auf der Eigenschaften Registerkarte, klicken Sie auf Nur dieses Objekt Klicken Sie im Dialogfeld Übernehmen Liste, und stellen Sie sicher, dass unter die folgenden Berechtigungen ausgewählt sind Berechtigungen:
    • Read servicePrincipalName
    • ServicePrincipalName schreiben
  9. Klicken Sie auf OK dreimal, und schließen Sie dann die ADSI-Bearbeitung Fenster.
Wenden Sie sich an Active Directory-Produktsupport, um Hilfe bei diesem Prozess. Finden Sie in diesem Microsoft Knowledge Base-Artikel, wenn Sie die Produkt-Support wenden.

Wenn Sie diese Problemumgehung durchführen, verhindern Sie, dass SPN-bezogene Probleme für neue Installationen oder Installationen, die den TCP/IP-Port oder Domänennamen Namen geändert haben.

Wichtig: Es wird empfohlen, dass Sie nicht WriteServicePrincipalName Recht auf das SQL-Dienstkonto gewähren, wenn die folgenden Bedingungen erfüllt sind:
  • Mehrere Domänencontroller sind vorhanden.
  • SQL Server-Cluster ist.
In diesem Szenario kann der SPN für den SQL Server aufgrund der Wartezeit im Active Directory-Replikation gelöscht werden. Dadurch können Konnektivitätsprobleme zu SQL Server-Instanz.

Genommen Sie an, Sie über Folgendes verfügen:
  • Eine virtuelle SQL-Instanz mit dem Namen Cluster mit zwei Knoten: Knoten A und Knoten B.
  • Knoten A ist von Domänencontroller A authentifiziert und Knoten B von Domänencontroller b authentifiziert


Folgendes kann auftreten:
  1. Die Cluster-Instanz auf Knoten A aktiv ist und registriert SQL SPN im Domänencontroller A beim Start einrichten...
  2. Die Instanz Sqlcluster Failover auf Knoten B Wenn Knoten A normal heruntergefahren wird.
  3. Die Cluster-Instanz aufgehoben ihren SPN von Domänencontroller A während des Herunterfahrens auf Knoten a
  4. Der SPN wird von Domänencontroller A entfernt, aber die Änderung wurde noch nicht auf Domänencontroller b repliziert
  5. Wenn auf Knoten B zu starten, versucht die Cluster-Instanz zur Registrierung des SQL-SPN mit Domänencontroller B. Da der SPN noch vorhanden ist Knoten B registriert den SPN nicht.
  6. Nach einiger Zeit wird von Domänencontroller A das Löschen des SPN (aus Schritt 3) auf Domänencontroller B als Teil der Active Directory-Replikation repliziert. Das Endergebnis ist, dass kein gültiger SPN für den SQL-Instanz in der Domäne vorhanden ist und daher Sie Verbindungsprobleme auf die Cluster-Instanz sehen.

Hinweis Dieses Problem wurde in SQL Server 2012 behoben.

Status

Microsoft hat bestätigt, dass dies ein Problem in SQL Server 2000 und SQL Server 2005 ist.

Informationsquellen

Für weitere Informationen klicken Sie auf die folgenden Artikelnummern, um die Artikel der Microsoft Knowledge Base anzusehen:
235529Kerberos-Unterstützung auf Windows 2000-basierten Servercluster
269229 Manuelles Neuerstellen das Cluster-Dienstkonto

Eigenschaften

Artikel-ID: 303411 - Geändert am: Sonntag, 7. April 2013 - Version: 2.0
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 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2000 Personal Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 Workgroup Edition
  • Microsoft SQL Server 2000 Developer Edition
  • Microsoft SQL Server 2000 Enterprise Edition
Keywords: 
kbbug kbpending kbmt KB303411 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 303411
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.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com