2009-05-13 2 views
15

ich nur SQL Server 2008 Developer Edition installiert haben und ich versuche mit sqlcmd.exe zu verbinden, aber ich bekomme die folgende Fehlermeldung:SQL Server 2008 - Anmeldung fehlgeschlagen. Die Login ist von einer nicht vertrauenswürdigen Domäne und kann nicht mit dem Windows-Authentifizierung verwendet wird

H:\>sqlcmd.exe -S ".\SQL2008" 

Msg 18452, Level 14, State 1, Server DEVBOX\SQL2008, Line 1 

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. 

Die SQL Server-Instanz ist für die Verwendung des SQL Server- und Windows-Authentifizierungsmodus konfiguriert. Wenn ich -U sa angeben, kann ich mich erfolgreich anmelden, aber ich möchte Windows-Authentifizierung verwenden. Verbindung mit SSMS mit Windows-Authentifizierung scheint gut zu funktionieren.

Antwort

6

hatte ich dieses Problem und es war, weil die Maschine der Anwendung ist nicht für die Delegierung auf der Domäne von Active Directory vertrauenswürdig ausgeführt wird. Wenn es sich beispielsweise um eine .net-App handelt, die unter einer DOMAIN_application.environment-Anwendungspoolidentität ausgeführt wird, kann die Identität nur dann auf SQL zugreifen, wenn die Maschine vertrauenswürdig ist.

+0

Ich hatte keine Zeit, dies zu überprüfen, aber dies scheint die wahrscheinlichste Ursache zu sein. –

+46

Wie behebst du das? –

+0

Dies könnte eine ähnliche Lösung sein: http://StackOverflow.com/a/11248883/62072 –

5

Sie vorbei keine Anmeldeinformationen

Also sqlcmd.exe es versucht, Sie zu authentifizieren, die Anmeldeinformationen Windows-Anmeldung verwenden, aber Sie müssen nicht SQL Server-Setup müssen diese Anmeldeinformationen zu akzeptieren ...

Wenn Sie es installieren, würden Sie (für das sa Konto)

Versuchen ...

sqlcmd.exe -U sa -P YOUR_PASSWORD -S ".\SQL2008" 
ein Server-Admin-Passwort zu liefern gehabt haben

als Referenz, Theres mehr Details here ...

+0

Die SQL Server-Instanz ist für die Verwendung des SQL Server- und Windows-Authentifizierungsmodus konfiguriert. Wenn ich -U sa angeben, kann ich mich erfolgreich anmelden, aber ich möchte Windows-Authentifizierung verwenden. Verbindung mit SSMS mit Windows-Authentifizierung scheint gut zu funktionieren. –

0

Geben Sie einen Benutzernamen und ein Passwort für die Anmeldung an? Was genau ist deine komplette Befehlszeile?

Wenn Sie auf Ihrer eigenen Box arbeiten, können Sie entweder einen Benutzernamen/ein Kennwort angeben oder den Parameter -E verwenden, um sich mit Ihren Windows-Anmeldeinformationen anzumelden (sofern diese in Ihrer SQL Server-Installation zulässig sind).

Marc

+0

Die komplette Befehlszeile ist wie in der Frage, nichts anderes. -E scheint keinen Unterschied zu machen, der gleiche Fehler wird geworfen. –

+0

Ist Ihr aktueller Benutzer, unter dem Sie auf Ihrer DEVBOX ausgeführt werden, dem SQL Server als "Login" hinzugefügt worden? –

+0

Ja, das Windows AD-Konto wurde als Serveranmeldung bei allen Serverrollen hinzugefügt. –

1

Ihr Fehler ganz wörtlich sagt, „Sie versuchen, Windows-Authentifizierung zu verwenden, aber Ihre Login ist nicht von einer vertrauenswürdigen Domäne“. Was ist seltsam, weil Sie eine Verbindung mit dem lokalen Computer herstellen.

Vielleicht sind Sie bei Windows mit einem lokalen Konto und nicht mit einem Domänenkonto angemeldet? Stellen Sie sicher, dass Sie sich mit einem Domänenkonto anmelden, das auch ein SQL Server-Prinzipal in Ihrer SQL2008-Instanz ist.

+0

Ich bin in Windows mit einem Domänenkonto angemeldet, das auch ein Serverprinzipal auf der 2008-Instanz ist. –

2

versucht einfach dieses:

H:> "C: \ Programme \ Microsoft SQL Server \ 90 \ Tools \ Binn \ sqlcmd.exe" -S 1>

“\ SQL2008" . und es funktioniert .. (Ich habe das Microsoft SQL Server \ 100 \ Tools \ Binn-Verzeichnis in meinem Pfad).

Immer noch nicht sicher, warum die SQL Server 2008-Version von SQLCMD allerdings nicht funktioniert ..

3

In meinem Fall wurde dieser Fehler durch das Umbenennen meines Client-Computers verursacht. Ich habe einen neuen Namen länger als 13 Zeichen (trotz der Warnung) verwendet, was dazu führte, dass der NETBIOS-Name abgeschnitten wurde und sich vom vollständigen Computernamen unterschied. Nachdem ich den Client in einen kürzeren Namen umbenannt hatte, ging der Fehler weg.

0

Ich bekam diesen Fehler auch, obwohl mein Problem war, dass ich ständig zwischen zwei Unternehmensnetzwerken über meine virtuelle Maschine mit unterschiedlichen Zugangsdaten wechselte. Ich hatte die Eingabeaufforderung auszuführen:

ipconfig /renew 

Danach mein Netzwerk Probleme gelöst wurden, und ich konnte wieder zu SQL verbinden.

0

fand gerade diesen Thread und veröffentlicht eine alternative Antwort (unten kopiert) hier: https://stackoverflow.com/a/37853766/1948625

Speziell auf diese Frage, wenn der Punkt „.“ verwendet im -S Wert der Befehlszeile bedeutet das gleiche wie 127.0.0.1 , dann könnte es das gleiche Problem wie die Verbindungszeichenfolge der anderen Frage sein. Verwenden Sie stattdessen den Hostnamen oder überprüfen Sie Ihre Hosts-Datei.


Alte Frage, und meine Symptome sind etwas anders, aber der gleiche Fehler. Meine Verbindungszeichenfolge war korrekt (integrierte Sicherheit, und ich verfüge nicht über Benutzer und Pwd) mit data source auf 127.0.0.1 festgelegt. Es hat jahrelang gut funktioniert.

Aber vor kurzem habe ich eine Zeile in der statischen Host-Datei für Testzwecke (C:\Windows\System32\drivers\etc\hosts)

127.0.0.1   www.blablatestsite.com 

diese Zeile aus- und der Fehler ist weg.

Ich habe einen Hinweis aus diesem Artikel (https://support.microsoft.com/en-gb/kb/896861), die über Hostnamen und Loopback spricht.

Andere mögliche Lösung (wenn Sie diese Zeile in der Hosts-Datei halten müssen) ist es, die Hostnamen zu verwenden (wie MYSERVER01) statt 127.0.0.1 im data source der Verbindungszeichenfolge.

Verwandte Themen