SQL Server 2008 Windows Auth-Anmeldefehler: Die Anmeldung stammt aus einer nicht vertrauenswürdigen Domäne

Beim Versuch, mit Management Studio eine Verbindung zu einer SQL Server 2008-Instanz herzustellen, wird die folgende Fehlermeldung angezeigt:

Login fehlgeschlagen. Die Anmeldung stammt aus einer nicht vertrauenswürdigen Domäne und kann nicht mit der Windows-Authentifizierung verwendet werden. (Microsoft SQL Server, Fehler: 18452)

Ich kann mich problemlos mit der SQL-Authentifizierung anmelden. Ich habe diesen Fehler plötzlich bekommen. Ich habe die Authentifizierung im gemischten Modus aktiviert.

Hat jemand irgendwelche Erfahrungen damit?

Zusätzliche Informationen: 64-Bit-Version von SQL Enterprise Edition unter Windows 2003 Server

Ein weiterer Grund, warum dies passieren könnte (ist mir gerade passiert) ... ist, dass das Passwort des Benutzers abläuft. Ich habe dies erst bemerkt, als ich versuchte, auf den eigentlichen Server zuzugreifen, und aufgefordert wurde, mein Passwort zu ändern.

Für mich geschah dies, als ich eine leere drivers/etc/hostsDatei bearbeitete und einen Eintrag für eine lokale Website hinzufügte, aber das Hinzufügen versäumte127.0.0.1 localhost

Das Problem wurde durch einen ausgefallenen Active Directory-Server verursacht, der das Windows-Konto natürlich nicht authentifizieren konnte. Vielen Dank für Ihre Hilfe.

Für alle anderen, die darauf stoßen, hatte ich dies in meiner Hosts-Datei:

127.0.0.1   localhost
127.0.0.1   customname

und ich brauchte es so:

127.0.0.1   localhost
127.0.0.1   localhost   customname

"Das Problem wurde durch einen ausgefallenen Active Directory-Server verursacht, der das Windows-Konto natürlich nicht authentifizieren konnte."

Dies ist natürlich nicht der Fall. Wenn AD nicht verfügbar ist, wird die Kerberos-Authentifizierung auf NTLM zurückgesetzt (die Anmeldeinformationen des Domänenkontos werden lokal zwischengespeichert. Sie können sich damit anmelden, auch wenn AD / Kerberos nicht verfügbar ist.) Ich denke, Sie haben möglicherweise 2 gleichzeitige Bedingungen für dieses Versagen:

• SQL Server ist nicht lokal (auf einem anderen Computer)
• Die Vertrauensstellung ist "Nur Kerberos" konfiguriert.

oder andere spezifische Sicherheitsnetzwerk- / Server- / AD- / Maschinenkonfigurationen

Ich hatte dieses Problem für eine Serverinstanz auf meinem lokalen Computer und stellte fest, dass ich auf 127.0.0.1 mit etwas anderem als "localhost" in meiner Hosts-Datei zeigte. In meinem Fall gibt es zwei Möglichkeiten, dieses Problem zu beheben:

1. Löschen Sie den fehlerhaften Eintrag in der Hosts-Datei, der auf 127.0.0.1 verweist
2. Verwenden Sie "localhost" anstelle des anderen Namens in der Hosts-Datei, der auf 127.0.0.1 verweist

* Dies funktionierte nur für mich, als ich die SQL Server-Instanz auf meiner lokalen Box ausführte und versuchte, von demselben Computer aus darauf zuzugreifen.

Stellen Sie sicher, dass Sie nicht mit einem VPN in einer anderen Domäne \ Benutzer verbunden sind . Oder umgekehrt, stellen Sie sicher sind verbunden, wenn es das ist , was erforderlich ist.

Ich habe dieses Problem behoben, als der Computer die Loopback-Check-Einstellung deaktivierte:

1. Bearbeiten Sie die Windows-Registrierung: Start -> Ausführen> Regedit
2. Navigieren Sie zu: HKLM \ System \ CurrentControlSet \ Control \ LSA
3. Fügen Sie einen DWORD-Wert mit dem Namen "DisableLoopbackCheck" hinzu.
4. Setzen Sie diesen Wert auf 1

Versuchen Sie es mit einem anderen gültigen Login mit dem Befehl RUNAS

runas /user:domain\user “C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ssmsee.exe” 

runas /user:domain\user “C:\WINDOWS\system32\mmc.exe /s \”C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC\”" 

runas /user:domain\user isqlw 

Für mich lag es daran, dass ich das Konto nicht hinzugefügt habe, um Rollen zu haben, die ich zur SQL-Datenbank selbst verwenden wollte. Und auch aufgrund eines schlechten Passworts versucht man per Copy Paste das Konto zu sperren.

Okay, ganz da draußen antworte mir. Ich habe diesen Fehler von einer auf VM VirtualBox gehosteten Entwicklungsumgebung erhalten. Drei Server; SharePoint, SQL DB und Domänencontroller. Der SharePoint-Server konnte keine Verbindung zur Konfigurationsdatenbank herstellen. Ich konnte weiterhin eine Verbindung über ODBC für die SQL-Authentifizierung mithilfe eines SA-Kontos herstellen, jedoch nicht über eine Windows-Authentifizierung. Dieser Benutzer würde sich jedoch gerne auf dem SQL-Server selbst bei SSMS anmelden. Ich habe auch eine bessere Fehlermeldung von ODBC erhalten und auch die fehlgeschlagenen Anmeldemeldungen auf dem SQL Server überprüft:

select text from sys.messages where message_id = '18452' and language_id = 1033

Ich kann das nicht gutschreiben, weil ich einen unserer Administratoren für Unternehmenssysteme um Hilfe gebeten habe und er dies in etwa 5 Minuten diagnostiziert hat, nachdem er sich ein paar Screenshots angesehen hat, die ich ihm gesendet habe. Problem war, dass die Uhr des Domänencontrollers falsch eingestellt war! Konnte es nicht glauben. Die Server sind für das Host-Only-Netzwerk eingerichtet, sodass Sie kein Internet haben, mit dem Sie die Uhr synchronisieren können. Dies erklärt auch, warum das Zurücksetzen auf einen früheren Schnappschuss, wenn ich weiß, dass das System funktioniert, das Problem nicht gelöst hat.

Bearbeiten: Durch das Installieren der Guest Additions auf dem Server wird die Gastuhr mit dem Host synchronisiert.

Auf dem jTDS-Treiber gibt es eine Einstellung namens USENTLMV2, die standardmäßig auf false gesetzt ist. Wenn Sie dies in meiner Datenbank-Software (DBVisualizer) auf "true" setzen, wurde das Problem behoben.

Ein anderes Szenario, in dem dies möglicherweise auftritt, ist der Versuch, von einer SSMS-Sitzung, die bereits angemeldet war, während Sie Ihr Kennwort geändert haben, eine Verbindung zu einem anderen SQL Server herzustellen. Die Abfolge der Ereignisse könnte ungefähr so ​​aussehen:

1. RDP an Server-A (Ihren SQL Server), öffnen Sie SSMS und melden Sie sich an
2. RDP zu Server-B in derselben Domäne und ändern Sie Ihr Passwort
3. Kehren Sie auf Server-A zur RDP-Sitzung zurück und versuchen Sie über SSMS, einer vorhandenen AlwaysOn-Verfügbarkeitsgruppe eine weitere Datenbank hinzuzufügen. Beim Herstellen einer Verbindung zu Replikaten wird der Anmeldefehler "nicht vertrauenswürdige Domäne" angezeigt

Zum Auflösen einfach abmelden und wieder anmelden

Sie werden möglicherweise über den Benutzernamen, den Sie lokal verwenden, in die Irre geführt . Das war mein Fall in Windows 10 Home. Wenn ich Benutzer in der Systemsteuerung betrachte , sehe ich den Namen usrpc01 . Wenn ich net config workstationjedoch tippe , scheint der Benutzername spc01 zu sein . Scheint, als hätte jemand den Benutzer umbenannt, aber der interne Name blieb unverändert.

Da C:\Usersich nicht wusste, wie der Windows-Benutzername (und der Ordnername unter , der sich auch auf den ursprünglichen internen Namen bezieht) repariert werden kann, habe ich meinem Datenbankserver einen neuen Benutzerkonto hinzugefügt.

Ich habe versucht, mich von einem Domänenkonto bei einem SQL Server 2008 anzumelden. Der SQL Server 2008 wird auf einem anderen Arbeitsgruppencomputer gehostet, der nicht Teil der Domäne ist. So seltsam es auch klingen mag, auf dem Arbeitsgruppenserver, auf dem SQL Server 2008 ausgeführt wird, musste ich zu Systemeigenschaften | wechseln Computername (Registerkarte) | Ändern (Schaltfläche) | Änderung des Computernamens | Mehr ... (Schaltfläche) und geben Sie das "Primäre DNS-Suffix dieses Computers" ein (es war leer, geben Sie also das gewünschte Suffix für Ihr Netzwerk ein) und aktivieren Sie das Kontrollkästchen "Primäres DNS-Suffix ändern, wenn sich die Domänenmitgliedschaft ändert". Dadurch konnte der Windows-Authentifizierungsprozess abgeschlossen werden, wenn Sie sich bei SQL Server 2008 anmelden.

Ich musste netonly verwenden, damit dies unter modernen Windows funktioniert:

runas /netonly /user:domain\user "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe"

Ein weiterer Grund> jemand hat das Kennwort für den Standard-SQL-Benutzer geändert

Dies ist mir vor ein paar Minuten passiert, als ich zu einem neuen Domänencontroller gewechselt bin ...

Ich hatte einen falschen Eintrag in der Hosts-Datei unter C:\Windows\System32\drivers\etc

[Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Stellen Sie sicher, dass Sie einen Eintrag wie unten haben

127.0.0.1   localhost
127.0.0.1   localhost   servername

Ich habe einen Alias ​​für eine SQL Server-Instanz verwendet, die auf "127.0.0.1" verweist. Das Ändern in "localhost" hat stattdessen den Trick getan.

Wenn Ihr SQL Server auf einem Server ausgeführt wird, der nicht Teil einer Domäne ist, und Sie in der Verbindungszeichenfolge einen vollständig qualifizierten Domänennamen (z. B. xyz.mypc.com) mit Integrated Security = True verwenden, müssen Sie möglicherweise auf die Verwendung von beiden wechseln die IP-Adresse, den Maschinennamen (SERVER01) oder den Punkt (.), falls dieser lokal gehostet wird.

Dies funktionierte bei mir, die Verwendung von fqdn führte zu dem obigen Fehler.

Um die Windows-Authentifizierung zu aktivieren, müssen sich beide Computer in derselben Domäne befinden. Damit Verwaltungsstudios die aktuellen Anmeldeinformationen übergeben und sich im SQL-Feld authentifizieren können

Für mich muss ich die Verbindung zur Domäne trennen (Arbeitsgruppe / Domäne ändern) und erneut verbinden.

Und noch ein möglicher Grund: Für das neu erstellte lokale Konto auf DB Server wurde das Flag "Benutzer muss Kennwort bei nächster Anmeldung ändern" gesetzt.

Folgendes hat es für mich behoben: Eigenschaften der Netzwerkverbindung Klicken Sie auf: "Internet Protocol Version 4 (TCT / IPv4)". Klicken Sie auf die Schaltfläche "Eigenschaften". Klicken Sie auf die Schaltfläche "Erweitert". Wählen Sie die Registerkarte "DNS". Löschen Sie den Text im "DNS-Suffix für diese Verbindung".

Ich konnte auch keine Remoteverbindung zum SQL Server herstellen. Sowohl der SQL Server als auch der Remote Server befanden sich in derselben Domäne. Und ich war einige Tage zuvor um eine Passwortänderung gebeten worden. Das Neustarten des SQL-Servers und des Remote-Servers, von dem aus ich auf den SQL-Server zugreifen wollte, war für mich der Trick.

In unserem Fall war es die Tatsache, dass der Entwickler den Anwendungspool unter seinem eigenen Konto ausführte und sein Kennwort zurückgesetzt hatte, aber vergessen hatte, es im Anwendungspool zu ändern. Duh ...

In meinem Fall war der Server im Domänencontroller deaktiviert. Ich ging in die Organisationseinheit COMPUTERS in Active Directory, klickte mit der rechten Maustaste auf den Server, aktivierte ihn und führte dann ein gpupdate / force vom SQL Server aus. Es dauerte einen Moment, aber es funktionierte schließlich.

In meinem Fall ist in der Hostdatei der Computername mit einer älteren IP-Adresse fest codiert. Ich ersetze die ältere IP durch die neue, das Problem ist behoben.

Speicherort der Hostdatei

WindowsDrive: \ Windows \ System32 \ drivers \ etc \ hosts

Änderungen vorgenommen 159.xx.xx.xxx Maschinenname

Keines der oben genannten hat bei mir funktioniert. Was ich tun musste, war: Wählen Sie in SQL Server Management Studio auf dem Anmeldebildschirm Optionen >> Ändern Sie im Abschnitt Netzwerk das Netzwerkprotokoll in Named Pipes.

Außerdem musste ich <default>das drahtlose Netzwerk deaktivieren , damit es mit der Einstellung funktioniert (das Gerät war auch mit dem kabelgebundenen LAN verbunden).

Mein Fix bestand darin, die Datei web.config so zu ändern, dass sie mit meinem neuen Servernamen für SQL Connection korreliert (IT Security hatte gerade eine Netdom-Umbenennung in meiner Entwicklungsbox vorgenommen.