Der Name des Zielprinzips ist falsch. SSPI-Kontext kann nicht generiert werden

94

Ich habe Probleme, eine SQL Server-Verbindung von Computer A zu Computer B herzustellen, auf dem der SQL Server ausgeführt wird.

Ich habe ausgiebig gegoogelt und all die Dinge, die ich gefunden habe, haben nicht funktioniert. Sie führen Sie auch nicht Schritt für Schritt durch den Lösungsprozess.

Wir verwenden kein Kerberos, aber NTLM wurde konfiguriert.

Geben Sie hier die Bildbeschreibung ein

Die beteiligten Maschinen sind (xx wird verwendet, um einen Teil des Maschinennamens aus Sicherheitsgründen zu verschleiern):

  • xxPRODSVR001 - Windows Server 2012-Domänencontroller
  • xxDEVSVR003 - Windows Server 2012 (Dieser Computer generiert den Fehler)
  • xxDEVSVR002 - Windows Server 2012 (Auf diesem Computer wird SQL Server 2012 ausgeführt.)

Die folgenden SPNs sind auf dem DC registriert (xxPRODSVR001). Ich habe die Domain aus Sicherheitsgründen mit yyy verdeckt:

Registrierte ServicePrincipalNames für CN = xxDEVSVR002, CN = Computer, DC = JJJ, DC = lokal:

            MSSQLSvc/xxDEVSVR002.yyy.local:49298

            MSSQLSvc/xxDEVSVR002.yyy.local:TFS

            RestrictedKrbHost/xxDEVSVR002

            RestrictedKrbHost/xxDEVSVR002.yyy.local

            Hyper-V Replica Service/xxDEVSVR002

            Hyper-V Replica Service/xxDEVSVR002.yyy.local

            Microsoft Virtual System Migration Service/xxDEVSVR002

            Microsoft Virtual System Migration Service/xxDEVSVR002.yyy.local

            Microsoft Virtual Console Service/xxDEVSVR002

            Microsoft Virtual Console Service/xxDEVSVR002.yyy.local

            SMTPSVC/xxDEVSVR002

            SMTPSVC/xxDEVSVR002.yyy.local

            WSMAN/xxDEVSVR002

            WSMAN/xxDEVSVR002.yyy.local

            Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/xxDEVSVR002.yyy.local

            TERMSRV/xxDEVSVR002

            TERMSRV/xxDEVSVR002.yyy.local

            HOST/xxDEVSVR002

            HOST/xxDEVSVR002.yyy.local

Registrierte ServicePrincipalNames für CN = xxDEVSVR003, CN = Computer, DC = JJJ, DC = lokal:

            MSSQLSvc/xxDEVSVR003.yyy.local:1433

            MSSQLSvc/xxDEVSVR003.yyy.local

            Hyper-V Replica Service/xxDEVSVR003

            Hyper-V Replica Service/xxDEVSVR003.yyy.local

            Microsoft Virtual System Migration Service/xxDEVSVR003

            Microsoft Virtual System Migration Service/xxDEVSVR003.yyy.local

            Microsoft Virtual Console Service/xxDEVSVR003

            Microsoft Virtual Console Service/xxDEVSVR003.yyy.local

            WSMAN/xxDEVSVR003

            WSMAN/xxDEVSVR003.yyy.local

            TERMSRV/xxDEVSVR003

            TERMSRV/xxDEVSVR003.yyy.local

            RestrictedKrbHost/xxDEVSVR003

            HOST/xxDEVSVR003

            RestrictedKrbHost/xxDEVSVR003.yyy.local

            HOST/xxDEVSVR003.yyy.local

Wenn nur die SQL Server-Fehlermeldung aussagekräftiger wäre und mir sagen würde, mit welchem ​​Hauptnamen eine Verbindung hergestellt werden soll, kann ich dies möglicherweise diagnostizieren.

Kann mich jemand durch die Lösung dieses Problems führen oder können Sie etwas in dem, was ich bereitgestellt habe, sehen, das falsch ist?

Gerne generiere ich weitere Debug-Informationen. Sagen Sie mir einfach, was Sie brauchen.

Die Kante
quelle
Wir betreiben keinen internen DNS-Server. Aber um dies als Problem zu beseitigen, sagen Sie, ich sollte "ping -a xxxx" oder gibt es eine andere Möglichkeit, um festzustellen, ob es Duplikate gibt?
TheEdge
Ich bin kein Experte, aber ich dachte, SPNs und SSPI wären eine Kerberos-Sache? Sind Sie sicher, dass Sie Kerberos nicht verwenden?
Dylan Smith
@ DylanSmith Nicht, dass ich sehen könnte ..... Als ich SP in SQL Server ausführte (Name jetzt vergessen), wurde alles als NTLM angezeigt. Weißt du, wie ich überprüfe?
TheEdge
Ich weiß, dass die Frage alt ist, also sparen Sie Zeit und führen Sie dieses Tool aus: microsoft.com/en-us/download/…
Eduardo

Antworten:

58

Ich hatte dieses Problem mit einer ASP.NET MVC-App, an der ich arbeitete.

Mir wurde klar, dass ich kürzlich mein Passwort geändert hatte, und ich konnte es beheben, indem ich mich ab- und wieder anmeldete.

Slothario
quelle
1
Das war mein Problem. Passwort geändert. Auf meinem Konto wurde der App-Pool ausgeführt.
Dragos Durlut
Als ich dieses Problem hatte, habe ich mich abgemeldet und wieder angemeldet. Das Problem wurde behoben.
Shary.sharath
Ähnliches Problem. Dies half mir, auf meine Handlungen zurückzublicken. TQ
Reddy
25

Ich habe diesen Fehler beim Herstellen einer Verbindung über SQL Server Management Studio mithilfe der Windows-Authentifizierung erhalten. Mein Passwort war abgelaufen, aber ich hatte es noch nicht geändert. Nach dem Ändern musste ich mich abmelden und wieder anmelden, damit der Computer mit meinen neuen Anmeldeinformationen funktionierte.

Matt Shepherd
quelle
23

Versuchen Sie Integrated Security=true, diesen Parameter aus der Verbindungszeichenfolge zu entfernen.


WICHTIG: Als Benutzer @Auspex kommentierte,

Durch das Entfernen der integrierten Sicherheit wird dieser Fehler verhindert, da der Fehler auftritt, wenn Sie versuchen, sich mit Ihren Windows-Anmeldeinformationen anzumelden. Leider möchten Sie sich die meiste Zeit mit Ihren Windows-Anmeldeinformationen anmelden können

Anatoljewitsch
quelle
Wie entfernen Sie das, wenn die Verbindung über SSMS erfolgt?
Geoff Dawdy
24
Durch klares Entfernen Integrated Security wird dieser Fehler verhindert, da der Fehler auftritt, wenn Sie versuchen, sich mit Ihren Windows-Anmeldeinformationen anzumelden. Leider möchten Sie sich die meiste Zeit mit Ihren Windows-Anmeldeinformationen anmelden können!
Auspex
2
@GeoffDawdy meine Antwort unten kann helfen? Es lag an einem abgelaufenen Passwort, bei dem ich mein Passwort ändern, mich abmelden und wieder anmelden musste und dann alles wie gewohnt funktionierte.
Matt Shepherd
3
Sparen Sie sich Zeit und führen Sie dieses Tool aus: microsoft.com/en-us/download/…
Eduardo
15

Beim Versuch der Windows-Authentifizierung wurde der gleiche Fehler angezeigt. Klingt lächerlich, aber nur für den Fall, dass es jemand anderem hilft: Es lag daran, dass mein Domain-Konto irgendwie gesperrt wurde, während ich noch angemeldet war (!). Durch das Entsperren des Kontos wurde das Problem behoben.

Abubakar Mehmood
quelle
12

Ich habe mich mit einer PIN anstelle eines Kennworts bei Windows 10 angemeldet. Ich habe mich stattdessen mit meinem Kennwort abgemeldet und wieder angemeldet und konnte über Management Studio auf SQL Server zugreifen.

Don
quelle
Das ist lächerlich. Und es hat funktioniert. Ich habe so viel Zeit damit verschwendet. Vielen Dank!
mcb2k3
2
Ups, das war es nicht. SSMS hat mich eingeschaltet, als ich nicht gesucht habe, und ist zu meinem SQL Server-Konto zurückgekehrt. Aber ich habe endlich versucht, von einem Microsoft-Konto zur lokalen Anmeldung zu einem lokalen Konto zu wechseln. Das hat den Trick gemacht und es scheint jetzt zu funktionieren, auch wenn ich mich mit meiner PIN anmelde.
mcb2k3
Yup mit dem Passwort anstelle der PIN hat auch bei mir funktioniert. +1 für Microsoft.
BrunoMartinsPro
OH MEIN GOTT! Ich kann nicht glauben, dass dies tatsächlich einen Unterschied gemacht hat!
Arni
9

Der SSPI-Kontextfehler zeigt definitiv an, dass eine Authentifizierung mit Kerberos versucht wird .

Da die Kerberos-Authentifizierung die Windows-Authentifizierung von SQL Server auf Active Directory basiert, für das eine Push-Beziehung zwischen Ihrem Computer und Ihrem Netzwerkdomänencontroller erforderlich ist, sollten Sie zunächst diese Beziehung überprüfen.

Sie können diese Beziehung mithilfe des folgenden Powershell-Befehls Test-ComputerSecureChannel schnell überprüfen .

Test-ComputerSecureChannel -verbose

Geben Sie hier die Bildbeschreibung ein

Wenn False zurückgegeben wird , müssen Sie den sicheren Active Directory-Kanal Ihres Computers reparieren, da ohne diesen Fehler keine Überprüfung der Domänenanmeldeinformationen außerhalb Ihres Computers möglich ist.

Sie können Ihren Computer Secure Channel mit dem folgenden Powershell- Befehl reparieren :

Test-ComputerSecureChannel -Repair

Überprüfen Sie die Sicherheitsereignisprotokolle. Wenn Sie Kerberos verwenden, sollten Anmeldeversuche mit dem Authentifizierungspaket Kerberos angezeigt werden.

Die NTLM-Authentifizierung schlägt möglicherweise fehl, und daher wird ein Kerberos-Authentifizierungsversuch durchgeführt. Möglicherweise wird in Ihrem Sicherheitsereignisprotokoll auch ein NTLM-Anmeldeversuch fehlgeschlagen.

Sie können die Kerberos-Ereignisprotokollierung in dev aktivieren, um zu debuggen, warum das Kerberos fehlschlägt, obwohl es sehr ausführlich ist.

Mit dem Kerberos Configuration Manager für SQL Server von Microsoft können Sie dieses Problem möglicherweise schnell diagnostizieren und beheben.

Hier ist eine gute Geschichte zu lesen: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/

Sarah
quelle
Dies hat das Problem für mich behoben. SPNs wurden auf dem falschen Benutzerobjekt in Active Directory registriert. Der Kerberos Configuration Manager für SQL Server hat zwei Klicks behoben!
Craig - MSFT
8

Nur um eine weitere mögliche Lösung für diesen mehrdeutigen Fehler hinzuzufügen The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider):

Stellen Sie sicher, dass die IP-Adresse, die beim Pingen des SQL Servers aufgelöst wird, mit der im Configuration Manager übereinstimmt. Öffnen Sie zur Überprüfung SQL Server Configuration Manager und gehen Sie dann zu SQL Server-Netzwerkkonfiguration> Protokolle für MSSQLServer> TCP / IP.

Stellen Sie sicher, dass TCP / IP aktiviert ist, und stellen Sie auf der Registerkarte IP-Adressen sicher, dass die IP, in die der Server beim Ping aufgelöst wird, dieselbe ist. Das hat diesen Fehler für mich behoben.

Alex
quelle
6

Das Problem scheint ein Problem mit Windows-Anmeldeinformationen zu sein. Ich habe den gleichen Fehler auf meinem Arbeitslaptop mit einem VPN erhalten. Ich bin angeblich als meine Domain / mein Benutzername angemeldet, was ich erfolgreich verwende, wenn ich eine direkte Verbindung herstelle, aber sobald ich zu einem VPN mit einer anderen Verbindung wechsle, erhalte ich diesen Fehler. Ich dachte, es sei ein DNS-Problem, da ich den Server anpingen könnte, aber es stellte sich heraus, dass ich SMSS explizit als mein Benutzer an der Eingabeaufforderung ausführen musste.

zB runas / netonly / user: YourDoman \ YourUsername "C: \ Programme (x86) \ Microsoft SQL Server Management Studio 18 \ Common7 \ IDE \ Ssms.exe"

user685590
quelle
Ich hatte ein ähnliches Problem (iMac vpn mit einer Windows-VM). Ich habe es gelöst, indem ich die DNS-Server meiner Arbeit zu den Wi-Fi-Netzwerkeinstellungen meines Mac hinzugefügt habe. Ich vermute, es gibt einen besseren Weg, aber das hat es für mich zum Laufen gebracht.
Erik Pearson
5

Melden Sie sich sowohl bei Ihrer SQL Box als auch bei Ihrem Client an und geben Sie Folgendes ein:

ipconfig /flushdns
nbtstat -R

Wenn das nicht funktioniert, erneuern Sie Ihr DHCP auf Ihrem Client-Computer ... Dies funktioniert für 2 PCs in unserem Büro.

Frank.Germain
quelle
hat Ihre Antwort auf meinem Client-Computer und SQL Box Plus ipconfig/releaseund ipconfig/renewauf meinem Client-Computer und es hat bei mir nicht funktioniert; (
AlbatrossCafe
4

Ich bin gerade darauf gestoßen und habe es durch zwei Dinge behoben:

  1. Erteilen von Lese- / Schreibberechtigungen für servicePrincipalName für das Dienstkonto mithilfe von ADSI Edit, wie unter https://support.microsoft.com/en-us/kb/811889 beschrieben
  2. Entfernen der SPNs, die zuvor auf dem SQL Server- Computerkonto (im Gegensatz zum Dienstkonto) vorhanden waren, mithilfe von

    setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAME
    

    Dabei war 1234 die von der Instanz verwendete Portnummer (meine war keine Standardinstanz).

EM0
quelle
Ich habe eine MS SQL Server-Instanz von "Ausführen mit" NT Service\MSSQLSSERVERals "Verwaltetes Dienstkonto" umgestellt. Danach konnte SSMS eine lokale Verbindung zur Datenbank auf dem Server herstellen, jedoch nicht remote von meinem Laptop aus. Durch das Beheben der SPNs wurde das Problem behoben.
Hydrargyrum
4

In meinem Fall wurde das Problem durch einen Neustart von SQL Server 2014 (auf meinem Entwicklungsserver) behoben.

mxasim
quelle
Ditto SQL Server 2016.
youcantryreachingme
4

Ich habe IPv6 auf einem PC-Cluster in einem isolierten Netzwerk getestet und bin auf dieses Problem gestoßen, als ich IPv4 zurückgesetzt habe. Ich habe im Active Directory, DNS und DHCP gespielt, habe also keine Ahnung, was ich veranlasst habe, das Kerberos-Setup zu brechen.

Ich habe die Verbindung außerhalb meiner Software mit diesem nützlichen Tipp erneut getestet, um die gefundene Remoteverbindung herzustellen.

https://blogs.msdn.microsoft.com/steverac/2010/12/13/test-remote-sql-connectivity-easily/

Nach einer kurzen Suche wurde dies auf der Microsoft-Website https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message gefunden .

Führen Sie das Tool auf dem SQL Server aus, um festzustellen, ob ein Problem vorliegt, wenn der Status "Fehler" lautet, und klicken Sie dann auf die angezeigte Schaltfläche "Beheben".

Dies löste das Problem für mich.

Graham Walker
quelle
3

Dies ist normalerweise auf fehlende, falsche oder doppelte Service Principle Names (SPNs) zurückzuführen.

Zu lösende Schritte:

  1. Bestätigen Sie, welches AD-Konto SQL Server verwendet
  2. Führen Sie den folgenden Befehl in Powershell oder CMD im Administratormodus aus (das Dienstkonto sollte die Domäne nicht enthalten).
setspn -L <ServiceAccountName> | Select-String <ServerName> | select line
  1. Stellen Sie sicher, dass die zurückgegebene Ausgabe einen SPN enthält, der vollständig qualifiziert ist, nicht vollständig qualifiziert, mit einem Port und ohne Port.

    Erwartete Ausgabe:

    Registered ServicePrincipalNames for CN=<ServiceAccountName>,OU=CSN Service Accounts,DC=<Domain>,DC=com: 
    MSSQLSvc/<ServerName>.<domain>.com:1433
    MSSQLSvc/<ServerName>:1433                                           
    MSSQLSvc/<ServerName>.<domain>.com
    MSSQLSvc/<ServerName>
    
  2. Wenn Sie nicht alle oben genannten Informationen sehen, führen Sie den folgenden Befehl in PowerShell oder CMD im Administratormodus aus (stellen Sie sicher, dass Sie den Port ändern, wenn Sie nicht die Standardeinstellung 1433 verwenden).

SETSPN -S  MSSQLSvc/<ServerName> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>:1433 <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain>:1433 <Domain>\<ServiceAccountName>
  1. Sobald dies abgeschlossen ist, dauert die DNS-Weitergabe normalerweise einige Minuten

Wenn Sie eine Meldung über gefundene doppelte SPNs erhalten, möchten Sie diese möglicherweise löschen und neu erstellen

Nate S.
quelle
2

Ich hatte dieses Problem beim Zugriff auf die Webanwendung. Es könnte daran liegen, dass ich kürzlich ein Windows-Passwort geändert habe.

Dieses Problem wurde behoben, als ich das Kennwort für den App-Pool aktualisiert habe, in dem ich die Webanwendung gehostet habe.

Ramki
quelle
2

Überprüfen Sie, ob Ihre Uhr zwischen Client und Server übereinstimmt.

Wenn ich diesen Fehler zeitweise hatte, funktionierte keine der oben genannten Antworten. Dann stellten wir fest, dass die Zeit auf einigen unserer Server abgelaufen war. Sobald sie erneut synchronisiert wurden, verschwand der Fehler. Suchen Sie nach w32tm oder NTP, um zu sehen, wie die Uhrzeit unter Windows automatisch synchronisiert wird.

Daniel Bailey
quelle
1

Da ich hier gelandet bin, um nach einer Lösung für mein eigenes Problem zu suchen, werde ich meine Lösung hier teilen, falls auch andere hier landen.

Ich stellte eine gute Verbindung zu SQL Server her, bis mein Computer in ein anderes Büro in einer anderen Domäne verschoben wurde . Dann, nach dem Wechsel, bekam ich diesen Fehler bezüglich des Zielprinzipalnamens. Was behoben wurde, war die Verbindung unter Verwendung eines vollständig qualifizierten Namens wie: server.domain.com . Sobald ich mich auf diese Weise mit dem ersten Server verbunden habe, kann ich nur mit dem Servernamen (ohne die vollständige Qualifikation) eine Verbindung zu anderen Servern herstellen, aber Ihr Kilometerstand kann variieren.

Greg
quelle
Dieses Problem ist mir nur passiert, als ich der SQL-Verbindung ein Zertifikat hinzugefügt habe. Das Zertifikat wurde an den FQDN ausgestellt. Wenn ich also eine Verbindung zum FQDN \ Instance herstelle, hat es funktioniert.
Slogmeister Extraordinaire
1

Ich bin heute darauf gestoßen und wollte mein Update teilen, da dieses einfach übersehen wird und leicht zu beheben ist.

Wir verwalten unser eigenes rDNS und haben kürzlich unser Servernamensschema überarbeitet. Als Teil davon hätten wir unser rDNS aktualisieren und vergessen sollen, dies zu tun.

Ein Ping ergab den richtigen Hostnamen, ein Ping -a gab jedoch den falschen Hostnamen zurück.

Einfache Lösung: Ändern Sie den rDNS, führen Sie eine ipconfig / flushdns durch, warten Sie 30 Sekunden (nur etwas, was ich tue), führen Sie einen weiteren Ping -a durch, sehen Sie, wie der richtige Hostname aufgelöst wird, verbinden Sie ... profit.

CrainBramp
quelle
1

Ich bin auf eine neue gestoßen: SQL 2012, die auf Server 2012 gehostet wird. Wurde beauftragt, einen Cluster für SQL AlwaysOn zu erstellen.
Cluster wurde erstellt, jeder erhielt die SSPI-Nachricht.

Um die Probleme zu beheben, wurde folgender Befehl ausgeführt:

setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService

DomainNamerunningSQLService== das Domänenkonto, das ich für SQL festgelegt habe Ich brauchte einen Domänenadministrator, um den Befehl auszuführen. Nur ein Server im Cluster hatte Probleme.

Dann SQL neu gestartet. Zu meiner Überraschung konnte ich mich verbinden.

Fragen101
quelle
Ich hatte das gleiche Problem, aber es war nicht in einem Cluster. Ich hatte die Anmeldung für den SQL Engine-Dienst in ein Domänenkonto geändert. Ich musste die MSSQLSvc/SERVER_FQNName:*SPNs vom Computerkonto entfernen und sie dann dem Benutzerkonto hinzufügen, auf dem der Dienst ausgeführt wird.
Slogmeister Extraordinaire
1

Ich habe versucht, von meinem Laptop in einer Visual Studio 2015-Konsolen-App aus eine Verbindung zu einer VM herzustellen, auf der SQL Server 2015 ausgeführt wird. Ich starte meine App am Abend zuvor und es ist in Ordnung. Am Morgen versuche ich, die App zu debuggen und erhalte diesen Fehler. Ich habe versucht ipconfig/flushund release+ renewund eine Menge anderen Müll, aber am Ende ...

Starten Sie Ihre VM neu und starten Sie den Client neu. Das hat es für mich behoben. Ich hätte es wissen müssen, jedes Mal neu starten.

AlbatrossCafe
quelle
Ähnliche Erfahrung, SQLServer 2016 auf VM. Ich bin mir nicht sicher, warum Verbindungen fehlschlugen. Der Neustart der VM hat das Problem behoben, ohne dass der Client neu gestartet werden muss.
youcantryreachingme
1

Ich hatte dieses Problem auf meinem SQL Server. Ich habe setspn -D mssqlsvc \ Hostname.domainname Hostname dann gestoppt und meinen SQL Server-Dienst gestartet.

Ich denke, dass das Stoppen und Starten meines SQL-Dienstes dies getan hätte.

Jeff
quelle
Dies habe ich nach dem Vergleich setspn -L <Hostname>mit einem funktionierenden Server getan . Es stellte sich heraus, dass alle funktionierenden Instanzen keinen SPN registriert hatten. Ich weiß nicht wirklich, was ich tue, aber anscheinend kann NTLM ohne diese registrierten SPNs verwendet werden. Vielen Dank!
BenderBoy
Beachten Sie, dass dies keine wirkliche Lösung ist, wenn Sie Kerberos anstelle von NTLM verwenden möchten, wie Sie anscheinend sollten: serverfault.com/a/384721 . Tatsächlich deaktiviert diese Lösung die Kerberos-Authentifizierung.
BenderBoy
1

Ich hatte das gleiche Problem, aber das Sperren und Entsperren der Maschine funktionierte für mich. Manchmal führen Firewall-Probleme zu Fehlern.

Ich bin mir nicht sicher, ob es für Sie funktionieren wird oder nicht, ich teile nur meine Erfahrungen.

somu
quelle
1

Ich habe alle Lösungen hier ausprobiert und keine davon hat bisher funktioniert. Eine Problemumgehung besteht darin, auf Verbinden zu klicken , den Servernamen einzugeben und Optionen, Registerkarte Verbindungseigenschaften auszuwählen. Stellen Sie das "Netzwerkprotokoll" auf "Named Pipes". Auf diese Weise können Benutzer mithilfe ihrer Netzwerkanmeldeinformationen eine Remoteverbindung herstellen. Ich werde ein Update veröffentlichen, wenn ich einen Fix bekomme.

Julie
quelle
Ich habe meine tatsächlich auf "TCP / IP" gesetzt. Ich weiß nicht, ob die Änderung das Problem oder die spezifische Einstellung für meine Netzwerksituation
behoben hat
1

In meinem Fall bestand das Problem darin, DNS über das WLAN einzurichten. Ich entfernte die Einstellungen, ließ sie leer und arbeitete.

Como ficou minha configurationação do DNS

kbral
quelle
1

Stellen Sie sicher, dass "Named Pipes" in "SQL Server Configuration Manager" aktiviert sind. Das hat bei mir funktioniert.

  1. Öffnen Sie "SQL Server Configuration Manager".
  2. Erweitern Sie "SQL Server-Netzwerkkonfiguration" in der Liste links.
  3. Wählen Sie "Protokolle für [Ihren Instanznamen]".
  4. Klicken Sie in der Liste rechts mit der rechten Maustaste auf "Named Pipes".
  5. Wählen Sie "Aktivieren"
  6. Starten Sie Ihren Instanzdienst neu.
S3minaki
quelle
1
Ich hatte die gleiche Nachricht. Ich habe versucht, eine Verbindung mit IP herzustellen , also habe ich dies als stackoverflow.com/users/8568873/s3minaki getan , dh die Schritte 1 bis 6, aber ich habe TCP / IP anstelle von Named Pipes aktiviert. Auch unter IPALL habe ich den dynamischen TCP-Port gelöscht und stattdessen den TCP-Port festgelegt. Stellen Sie sicher, dass keine andere Instanz diesen Port ausführt, da sonst die Instanz nicht neu gestartet wird. Ich brauchte auch einen SQL-Benutzer, Windows-Authentifizierung funktioniert nicht. In SQL Manager stellen Sie eine Verbindung mit xxxx \ instancename, portnr her. dh 127.0.0.1 \ SQLEXPRESS, 1433
Tomas Hesse
1

In meiner Situation habe ich versucht, mithilfe der integrierten Sicherheit eine Verbindung von einem PC zu SQL Server auf einem anderen PC in einem Netzwerk ohne Domäne herzustellen. Auf beiden PCs habe ich mich mit demselben Microsoft-Konto bei Windows angemeldet . Ich habe auf beiden PCs zu einem lokalen Konto gewechselt, und SQL Server stellt jetzt eine erfolgreiche Verbindung her.

Michael Csikos
quelle
1

In meinem Fall hatte jemand den Domänencontroller heruntergefahren, da ich in meiner Entwicklungsumgebung arbeitete, und Windows-Anmeldeinformationen konnten nicht authentifiziert werden. Nach dem Einschalten des Domänencontrollers verschwand der Fehler und alles funktionierte einwandfrei.

El_01
quelle
1

Eine weitere Nische zu diesem Problem, die durch Netzwerkverbindungen verursacht wird. Ich verbinde mich über einen Windows VPN-Client und dieses Problem trat auf, als ich von Wifi zu einer Kabelverbindung wechselte. Die Lösung für meine Situation bestand darin, die Adaptermetrik manuell anzupassen.

Verwenden Sie in Powershell Get-NetIPInterface, um alle Metrikwerte anzuzeigen. Die niedrigeren Zahlen sind kostengünstiger und werden daher von Fenstern bevorzugt. Ich habe das Ethernet und das VPN gewechselt und die Anmeldeinformationen wurden dort angezeigt, wo sie sein mussten, damit SSMS zufrieden war.

So konfigurieren Sie die automatische Metrikfunktion: Doppelklicken Sie in der Systemsteuerung auf Netzwerkverbindungen. Klicken Sie mit der rechten Maustaste auf eine Netzwerkschnittstelle, und wählen Sie dann Eigenschaften aus. Klicken Sie auf Internetprotokoll (TCP / IP) und wählen Sie dann Eigenschaften. Wählen Sie auf der Registerkarte Allgemein die Option Erweitert aus. Um eine Metrik anzugeben, deaktivieren Sie auf der Registerkarte IP-Einstellungen das Kontrollkästchen Automatische Metrik und geben Sie die gewünschte Metrik in das Feld Schnittstellenmetrik ein.

Quelle: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/automatic-metric-for-ipv4-routes

user2442020
quelle
0

Ich bin auf eine Variante dieser Ausgabe gestoßen, hier sind die Merkmale:

  • Der Benutzer konnte erfolgreich eine Verbindung zu einer benannten Instanz herstellen, z. B. waren Verbindungen zu Server\Instanceerfolgreich
  • Der Benutzer konnte keine Verbindung zur Standardinstanz herstellen, z. B. Verbindungen, Serverdie mit dem Screenshot des OP zu SSPI fehlgeschlagen sind
  • Der Benutzer konnte keine Standardinstanz mit einem vollständig qualifizierten Namen verbinden, z. B. Verbindungen zu Server.domain.comfehlgeschlagen (Zeitüberschreitung).
  • Der Benutzer konnte keine IP-Adresse ohne benannte Instanz verbinden, z. B. 192.168.1.134fehlgeschlagene Verbindungen
  • Andere Benutzer, die sich nicht in der Domäne befinden (z. B. Benutzer, die eine VPN-Verbindung zum Netzwerk herstellen), aber Domänenanmeldeinformationen verwenden, konnten erfolgreich eine Verbindung zur Standardinstanz und IP-Adresse herstellen

Nach vielen Kopfschmerzen beim Versuch herauszufinden, warum dieser einzelne Benutzer keine Verbindung herstellen konnte, haben wir folgende Schritte unternommen, um die Situation zu beheben:

  1. Sehen Sie sich den Server in der SPN-Liste mit
    setspn -l Server
    a an. In unserem Fall hieß esServer.domain.com
  2. Fügen Sie der Hosts-Datei in einen Eintrag hinzu C:\Windows\System32\drivers\etc\hosts(führen Sie Notepad als Administrator aus, um diese Datei zu ändern). Der Eintrag, den wir hinzugefügt haben, war
    Server.domain.com Server

Danach konnten wir erfolgreich eine Verbindung über SSMS zur Standardinstanz herstellen.

Sauerampfer
quelle
0

Auch ich hatte dieses Problem unter SQL Server 2014 während der Protokollierung mit Windows-Authentifizierung. Um das Problem zu beheben, habe ich meinen Server einmal neu gestartet und dann versucht, mich anzumelden. Es hat bei mir funktioniert.

Harikrishna Puppala
quelle