Sie sind zurzeit offline. Es wird auf die erneute Herstellung einer Internetverbindung gewartet.

Informationen erhalten Sie eine "Warnung SuperSocket Info" Warnung beim SQL Server-Dienstkonto ein Domänenbenutzer ist

Wichtig: Dieser Artikel wurde maschinell übersetzt und wird dann möglicherweise mithilfe des Community Translation Framework (CTF) von Mitgliedern unserer Microsoft Community nachbearbeitet. Weitere Informationen zu CTF finden Sie unter http://support.microsoft.com/gp/machine-translation-corrections/de.

303411
FEHLER #: 232774 (SHILOH_BUGS)
Problembeschreibung
Startet SQL Server auf einem Computer, auf dem Microsoft SQL Server 2000 oder Microsoft SQL Server 2005 ausgeführt wird, versucht das Programm SQL Server immer, den virtuellen Server in Active Directory registrieren. Das folgende Ereignis kann im Ereignisprotokoll protokolliert:

SuperSocket-Informationen: (SpnRegister): Fehler 8344 SuperSocket-Information: (SPNRegister): Fehler 1355 SuperSocket-Informationen: SpnUnRegister(): Fehler beim 8344.

Hinweis Fehler 1355 entspricht ERROR_NO_SUCH_DOMAIN. Fehler 8344 entspricht unzureichende Berechtigungen für die Registrierung durchzuführen. Dies ist eine Warnung für die SPNRegister -Funktion sowie Fehler für die Funktion SpnUnRegister dargestellt.

Diese Meldung ist keine Fehlermeldung. Dieser Text ist nur eine Warnung, dass SQL Server eine Dienstprinzipalnamen (SPN) registrieren kann. Dies bedeutet, dass der Sicherheitsmechanismus verwendet wird Microsoft Windows NT Challenge\Response (NTLM)-Authentifizierung statt Kerberos-Authentifizierung.

Diese Nachrichten sollten nur ein Problem betrachtet, wenn die SQL Server-Installation Kerberos-Authentifizierung erfordert oder Netzwerk-Sicherheitsrichtlinien verhindern auf NTLM-Aushandlung. Andernfalls können diese Nachrichten ignoriert werden.
Ursache
Die Meldung wird normalerweise angezeigt, weil das SQL Server-Dienstkonto als Domänenbenutzer ausgeführt wird, nicht erforderliche Berechtigungen zum Registrieren von SPNs verfügt. Mit Microsoft Windows 2000 Service Pack 3 (SP3) können Sie die Kerberos-Authentifizierung auf Serverclustern aktivieren. Eine Anleitung hierzu finden Sie im folgenden Artikel der Microsoft Knowledge Base:
319723 Informationen zu SQL Server 2000 Kerberos unterstützen, einschließlich SQL Server virtueller Server in Serverclustern
Lösung
Sie können das Konto Access Control Settings Berechtigungen in Active Directory-Verzeichnisdienst ServicePrincipalName Leseberechtigung aktivieren und ServicePrincipalName Schreibberechtigungen für das Dienstkonto von SQL bearbeiten.

Warnung Wenn Sie das Active Directory Service Interfaces (ADSI) Edit-Snap-in, das LDP-Dienstprogramm oder andere LDAP Version 3 Clients, und die Attribute von Active Directory-Objekten falsch ändern, kann 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 Sie dieser Attribute auf Ihr eigenes Risiko.
Abhilfe
Diese Nachrichten schreiben und der SQL Server-Dienst SPNs für die SQL Server-Instanzen dynamisch zu erstellen, bitten Sie die entsprechenden Berechtigungen und Benutzerrechte, die Startkonten des SQL Server hinzufügen.

Gehen Sie folgendermaßen vor, um SQL Server-Dienstkonto, SPNs korrekte beim Start zu aktivieren:
  1. Klicken Sie auf Startund auf Ausführen, geben Adsiedit.msc, und klicken Sie dann auf OK.
  2. Erweitern Sie im ADSI EditDomäne [Domänenname], erweitern Sie DC =<b00> </b00> Stammdomänenname, erweitern Sie CN = Users, mit der rechten Maustaste CN =Kontoname, und klicken Sie dann auf Eigenschaften.

    Hinweise
    • Domänenname Gibt den Namen der Domäne.
    • Stammdomänenname ist ein Platzhalter für den Namen der Stammdomäne.
    • Kontoname Stellt das Konto, das Sie zum Starten des SQL Server-Dienstes angeben.
    • Wenn Sie Lokales System zum Starten des SQL Server-Dienstes angegeben haben Kontoname Stellt das Konto, mit dem Microsoft Windows anmelden.
    • Wenn Sie ein Domänenbenutzerkonto für den SQL Server-Dienst angegeben haben Kontoname Stellt das Domänenbenutzerkonto.
  3. In der CN =Kontoname Dialogfeld "Eigenschaften" auf die Registerkarte Sicherheit .
  4. Klicken Sie auf der Registerkarte Sicherheit auf Erweitert.
  5. Stellen Sie im Dialogfeld Erweiterte Sicherheitseinstellungen sicher, dass der Benutzer selbst unter Berechtigungseinträgeaufgeführt ist. Wenn Benutzer selbst nicht aufgeführt ist, klicken Sie auf Hinzufügen, und fügen Sie selbst Benutzer.
  6. Unter Berechtigungseinträgeselbstauf und klicken Sie dann auf Bearbeiten.
  7. Klicken Sie im Dialogfeld Berechtigungseintrag auf der Registerkarte Eigenschaften .
  8. Auf der Registerkarte Eigenschaften auf nur dieses Objekt in der Liste Übernehmen und stellen Sie sicher, dass unter Berechtigungendie folgenden Berechtigungen aktiviert sind:
    • Read servicePrincipalName
    • Schreiben des servicePrincipalName
  9. Klicken Sie dreimal auf OK , und schließen Sie das Fenster ADSI Edit .
Erhalten Sie Hilfe dabei Active Directory-Produktsupport. Finden Sie Microsoft Knowledge Base-Artikel, wenn Sie Produktsupport.

Bei dieser Lösung vermeiden Sie Probleme SPN für neue Installationen oder Installationen, die die TCP/IP-Port oder Domain Name geändert.

Wichtig Wir empfehlen, dass Sie nicht WriteServicePrincipalName bis SQL Service-Konto gewähren, wenn Folgendes zutrifft:
  • Mehrere Domänencontroller sind vorhanden.
  • SQL Server-Cluster.
In diesem Szenario kann der SPN für SQL Server aufgrund von Wartezeiten bei der Active Directory-Replikation gelöscht werden. Dadurch kann Verbindungsprobleme mit der SQL Server-Instanz.

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


Die folgenden auftreten:
  1. Cluster-Instanz auf Knoten A und registriert SQL SPN in Domänencontroller A beim Start einrichten...
  2. Cluster-Instanz ein Failover zu Knoten B wenn Knoten A normal heruntergefahren wird.
  3. Die Cluster-Instanz aufgehoben von Domänencontroller A einen SPN während des Herunterfahrens auf Knoten a
  4. Der SPN von Domänencontroller A entfernt, aber die Änderung wurde noch nicht auf Domänencontroller b repliziert
  5. Beim Starten auf Knoten B, versucht die Cluster-Instanz SQL SPN registrieren Domänencontroller B. Da der SPN bleibt Knoten B den SPN nicht registriert.
  6. Nach einiger Zeit repliziert Domänencontroller ein SPN (aus Schritt 3) auf Domänencontroller B als Teil des Active Directory-Replikation. Das Endergebnis ist, dass kein gültiger SPN für den SQL-Instanz in der Domäne vorhanden ist und daher Probleme mit der Cluster-Instanz angezeigt.

Hinweis Dieses Problem wird in SQL Server 2012 behoben.

Status
Microsoft hat bestätigt, dass dieses Problem in SQL Server 2000 und SQL Server 2005.
Informationsquellen
Klicken Sie für weitere Informationen auf die folgenden Artikelnummer, um die betreffende Artikel in der Microsoft Knowledge Base anzuzeigen:
235529 Kerberos-Unterstützung auf Windows 2000-basierten Servercluster
269229 Das Clusterdienstkonto manuell neu erstellen

Warnung: Dieser Artikel wurde automatisch übersetzt

Eigenschaften

Artikelnummer: 303411 – Letzte Überarbeitung: 10/04/2015 11:38:00 – Revision: 3.0

  • 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
  • kbbug kbpending kbmt KB303411 KbMtde
Feedback