SQL Server gibt den Fehler "Anmeldung für Benutzer 'NT AUTHORITY \ ANONYMOUS LOGON'." In der Windows-Anwendung fehlgeschlagen
Einer Anwendung arbeiten, ohne problem (und hat keine aktive Entwicklung gemacht, auf der in etwa 6 Monate oder so) fing vor kurzem an, nicht, um eine Verbindung zur Datenbank. Operations admins kann nicht sagen, was verändert haben könnte, dass würde das problem verursachen.
Verwendet die client-Anwendung eine Feste Verbindung Zeichenfolge mit Integrated Security=True, aber wenn die Anwendungen, die versucht, zu erstellen eine Verbindung zur Datenbank, es wirft eine SQLException, die sagen "Login fehlgeschlagen für Benutzer" NT-AUTORITÄT\ANONYMOUS-ANMELDUNG".
Kann ich die Anmeldung bei der Datenbank über das Management Studio auf dieses Konto ohne problem. All die Dinge, die ich gesehen habe für dieses Problem sind für ASP.NET Projekte und es ist scheinbar das "Double Hop "Problem", die als client-Anwendung, die verdammt gut besser kein problem sein. Jegliche Hilfe würde sehr geschätzt werden.
Bearbeiten
Dem client-Computer und server-Computer als auch die Benutzer-Konten in der gleichen Domäne.
Dies tritt auf, wenn Windows-Firewall deaktiviert ist.
Führende Theorie ist:
Server neu gestartet wurde, etwa eine Woche oder so vor, und nicht registriert (Service Principal Name, SPN). Fehler beim registrieren eines SPN möglicherweise die integrierte Authentifizierung zu fallen zurück auf NTLM statt Kerberos.
InformationsquelleAutor der Frage CodeWarrior | 2012-09-17
Du musst angemeldet sein, um einen Kommentar abzugeben.
Wenn Ihr Problem mit verknüpften Servern, die Sie benötigen, zu betrachten, ein paar Dinge.
Ersten, die Ihre Benutzer benötigen, um die Delegierung aktiviert, und wenn die einzige Sache, die geändert wird, ist es ' wahrscheinlich, dass Sie tun. Ansonsten können Sie deaktivieren Sie das Kontrollkästchen "Konto ist vertraulich und kann nicht delegiert werden" checkbox ist die Benutzereigenschaften in der AD.
Zweiten, Ihrem service account(s) muss für Delegierungszwecke vertraut werden. Da Sie recetly verändert Ihr service-Konto, das ich vermute, das ist der Täter. (http://technet.microsoft.com/en-us/library/cc739474(v=ws.10).aspx)
Sie erwähnt, dass Sie vielleicht einige SPN Fragen, so stellen Sie den SPN für beide Endpunkte, da Sie sonst nicht in der Lage, um zu sehen, die Registerkarte Delegierung in AD. Auch stellen Sie sicher, dass Sie in der erweiterten Ansicht in "Active Directory-Benutzer und-Computer."
Wenn Sie immer noch nicht sehen, die Registerkarte Delegierung, auch nach der Korrektur Ihrer SPN, stellen Sie sicher, dass Ihre domain nicht im 2000-Modus. Wenn es ist, können Sie "raise domain-function-level."
An dieser Stelle können Sie nun markieren Sie das Konto als vertrauenswürdig für die Delegierung:
Schließlich werden Sie auch brauchen, um all die Maschinen als vertrauenswürdig für die Delegierung.
Sobald Sie dies getan haben, verbinden Sie zu Ihrem sql server und testen Sie Ihr gefiel Server. Sie arbeiten sollten.
InformationsquelleAutor der Antwort Code Magician
Vorneweg: Mein problem ist nicht genau das gleiche wie deins, aber dieser Beitrag ist die erste Sache, die kommt von google für die
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'Fehler zu der Zeit als ich dies schrieb. Die Lösung kann nützlich sein für die Menschen auf der Suche nach diesem Fehler, da ich nicht finden, diese spezifische Lösung überall online.In meinem Fall, ich benutzte Xampp/Apache und PHP sqlsrv, um zu versuchen, um eine Verbindung zu einer MSSQL-Datenbank die Windows-Authentifizierung verwenden und erhalten die
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'- Fehler, den Sie beschrieben. Ich endlich das problem gefunden zu sein, die den Apache-Dienst selbst läuft unter dem Benutzer "LOKALER DIENST" anstelle der Benutzer-account ich angemeldet war, als. In anderen Worten, es wurde buchstäblich mit einem anonymen Konto. Die Lösung: gehen Sie in Dienste.msc, Recht-klicken Sie den Apache-service, gehen Sie auf Eigenschaften, gehen Sie Auf die Registerkarte Anmelden, und geben Sie die Anmeldeinformationen für den Benutzer. Dieses fällt in übereinstimmung mit deinem problem im Zusammenhang mit SPN als Ihre SPN eingerichtet sind zum ausführen von einem bestimmten Benutzer in der Domäne. Also, wenn die richtige SPN wird nicht ausgeführt, windows-Authentifizierung wird standardmäßig an den falschen Benutzer (wahrscheinlich der "LOCAL SERVICE" - Benutzer) und geben Sie den Anonymen Fehler.Hier, wo es anders ist als Ihr problem. Keiner von den Computern im lokalen Netzwerk werden auf einer Domain, Sie sind nur in einer Arbeitsgruppe. Verwendung der Windows-Authentifizierung mit einer Arbeitsgruppe, sowohl die computer mit dem server (in meinem Fall MSSQL-Server) und den Rechner mit der service-anfordern von Daten (in meinem Fall Apache) benötigt, um einen Benutzer mit identischem Namen und identischen Passwort.
Zusammenfassen, Die
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'Fehler in beiden Fällen scheint verursacht zu werden durch ein Dienst nicht ausgeführt werden und/oder nicht an den richtigen Benutzer. Sicherstellung der richtigen SPN oder anderen Dienst ausgeführt wird, und unter dem richtigen Benutzer lösen sollte der anonyme Teil des Problems.InformationsquelleAutor der Antwort Caboosetp
Ich denke, es müssen einige Veränderung in der AD-Gruppe verwendet für die Authentifizierung gegenüber der Datenbank. Fügen Sie die web-server-Namen im format Domäne\webservername$, um die AD-Gruppe war, die Zugriff auf die Datenbank. Darüber hinaus werden auch versuchen, die web -.config Attribut auf "false". Hoffe, es hilft.
BEARBEITEN: Gehen durch das, was Sie bearbeitet haben.. es wird wahrscheinlich darauf hinweisen, dass das Authentifizierungs-Protokoll des SQL-Server-gefallen zurück von Kerberos(Standardeinstellung, wenn Sie mithilfe der integrierten Windows-Authentifizierung) auf NTLM. Für die Verwendung von Kerberos-Dienstprinzipalnamen (service principal name, SPN) registriert werden, müssen in den Active Directory-Verzeichnisdienst. Service Principal Name(SPn) sind eindeutige Bezeichner für Dienste laufen auf Servern. Jeder Dienst, der Kerberos-Authentifizierung verwenden muss, um einen SPN für die ihm, so dass Kunden erkennen können den Dienst auf dem Netzwerk. Es registriert ist im Active Directory unter computer-oder Benutzerkonto. Obwohl das Kerberos-Protokoll ist der Standard, wenn der Standard versagt, Authentifizierungs-Prozess wird versucht werden, mithilfe von NTLM.
In Ihrem Szenario, client muss tcp-Verbindung, und es ist den meisten wahrscheinlich unter dem LocalSystem-Konto, und es gibt keine registrierten SPN für die SQL-Instanz, daher NTLM verwendet wird, jedoch LocalSystem-Konto erbt von System-Kontext anstelle eines echten Nutzer-basierten-Kontext, also nicht wie 'ANONYMOUS-ANMELDUNG'.
Zur Behebung dieses bitten Sie Ihren domain-administrator, um manuell registrieren, SPN, wenn Ihr SQL-Server läuft unter einem Domänen-Benutzer account.
Folgende links könnten Ihnen helfen, mehr:
http://blogs.msdn.com/b/sql_protocols/archive/2005/10/12/479871.aspx
http://support.microsoft.com/kb/909801
InformationsquelleAutor der Antwort Saurabh R S
Einer meiner SQL jobs hatte das gleiche Problem. Es beteiligten uploadaing Daten von einem server zum anderen. Der Fehler trat auf, da war ich mit der sql Server-Agent-Dienstkonto. Ich erstellte eine Berechtigung mit einer Benutzer-id (verwendet das Fenster Authentifizierung) allgemein für alle Server. Dann erstellt einen Proxy mithilfe dieser Berechtigung. Verwendet die Proxys in sql server-job, und es läuft gut.
InformationsquelleAutor der Antwort Vipul
Werden Sie wahrscheinlich brauchen, um einen Benutzernamen und ein Passwort im connectionstring und setzen Integrated Security=false
InformationsquelleAutor der Antwort shabber