it-swarm.com.de

SQL Server gibt Fehler zurück "Anmeldung für Benutzer" NT AUTHORITY\ANONYMOUS LOGON "fehlgeschlagen." in der Windows-Anwendung

Eine Anwendung, die problemlos funktioniert hat (und in der in etwa 6 Monaten keine aktive Entwicklung ausgeführt wurde), konnte vor kurzem keine Verbindung zur Datenbank herstellen. Operations-Admins können nicht sagen, was sich geändert haben könnte, um das Problem zu verursachen.

Die Clientanwendung verwendet eine fest codierte Verbindungszeichenfolge mit Integrated Security = True. Wenn die Anwendung jedoch versucht, eine Verbindung zur Datenbank herzustellen, wird eine SQLException mit der Meldung "Anmeldung für Benutzer" NT AUTHORITY\ANONYMOUS LOGON "fehlgeschlagen.

Ich kann mich mit diesem Konto problemlos über Management Studio bei der Datenbank anmelden. Alle Dinge, die ich für dieses Problem gesehen habe, beziehen sich auf ASP.NET-Projekte. Es ist anscheinend das "Double-Hop-Problem", bei dem es sich um eine Client-Anwendung handelt, die nicht besser ist, kein Problem zu sein. Jede Hilfe wäre sehr dankbar.

Bearbeiten

Der Client-Computer und der Server-Computer sowie die Benutzerkonten befinden sich in derselben Domäne .. Dies tritt auf, wenn die Windows-Firewall deaktiviert ist.

Die führende Theorie lautet: Der Server wurde vor etwa einer Woche neu gestartet und konnte den Service Principal Name (SPN) nicht registrieren. Wenn Sie einen SPN nicht registrieren, kann die integrierte Authentifizierung auf NTLM statt Kerberos zurückgreifen.

59
CodeWarrior

Wenn Ihr Problem mit verknüpften Servern zusammenhängt, müssen Sie einige Punkte prüfen. 

Erstens müssen Ihre Benutzer die Delegierung aktiviert haben, und wenn sich das einzige, was sich geändert hat, wahrscheinlich ändern wird. Andernfalls können Sie die Markierung des Kontrollkästchens "Konto ist vertraulich und kann nicht delegiert" aufheben, und zwar in den Benutzereigenschaften in AD.

Zweitens müssen Ihre Dienstkonten für die Delegierung vertrauenswürdig sein. Da Sie Ihr Dienstkonto regelmäßig geändert haben, vermute ich, dass dies der Täter ist. ( http://technet.Microsoft.com/de-de/library/cc739474(v=ws.10).aspx

Sie haben erwähnt, dass möglicherweise einige SPN-Probleme vorliegen. Stellen Sie also sicher, dass Sie den SPN für beide Endpunkte festlegen. Andernfalls können Sie die Registerkarte "Delegierung" in AD nicht sehen. Stellen Sie außerdem sicher, dass Sie sich in der erweiterten Ansicht unter "Active Directory-Benutzer und -Computer" befinden. 

Wenn die Delegierungsregisterkarte auch nach dem Korrigieren Ihres SPN immer noch nicht angezeigt wird, stellen Sie sicher, dass sich Ihre Domäne nicht im 2000-Modus befindet. Wenn dies der Fall ist, können Sie "die Funktionsebene der Domäne erhöhen". 

An dieser Stelle können Sie das Konto jetzt als vertrauenswürdig für die Delegierung kennzeichnen:

Klicken Sie im Detailbereich mit der rechten Maustaste auf den Benutzer, dem Sie vertrauen möchten Delegierung, und klicken Sie auf Eigenschaften.

Klicken Sie auf die Registerkarte Delegierung, und wählen Sie das Konto ist für die Delegierung vertrauenswürdig Aktivieren Sie das Kontrollkästchen und klicken Sie auf OK.

Schließlich müssen Sie auch alle Maschinen als vertrauenswürdig für die Delegierung festlegen. 

Wenn Sie dies getan haben, verbinden Sie sich erneut mit Ihrem SQL-Server und testen Sie Ihre bevorzugten Server. Sie sollten funktionieren. 

20
Code Magician

Zunächst einmal: Mein Problem ist nicht dasselbe wie bei Ihnen, aber dieser Beitrag ist das erste, was in Google für den Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'-Fehler zum Zeitpunkt der Erstellung dieses Artikels auftaucht. Die Lösung kann für Leute hilfreich sein, die nach diesem Fehler suchen, da ich diese spezifische Lösung nirgendwo online gefunden habe.

In meinem Fall habe ich Xampp/Apache und PHP sqlsrv verwendet, um eine Verbindung zu einer MSSQL-Datenbank mithilfe der Windows-Authentifizierung herzustellen, und ich habe den von Ihnen beschriebenen Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'-Fehler erhalten. Ich fand schließlich das Problem, dass der Apache-Dienst selbst unter dem Benutzer "LOCAL SERVICE" statt des Benutzerkontos ausgeführt wurde, bei dem ich angemeldet war. Mit anderen Worten, es wurde buchstäblich ein anonymes Konto verwendet. Die Lösung bestand darin, in services.msc zu gehen, mit der rechten Maustaste auf den Apache-Dienst zu klicken, auf Eigenschaften zu gehen, auf die Registerkarte Anmelden zu gehen und die Anmeldeinformationen für den Benutzer einzugeben. Dies entspricht Ihrem Problem im Zusammenhang mit SPNs, da Ihre SPNs so eingerichtet sind, dass sie von einem bestimmten Benutzer in der Domäne ausgeführt werden. Wenn also nicht der richtige SPN ausgeführt wird, verwendet die Windows-Authentifizierung standardmäßig den falschen Benutzer (wahrscheinlich der Benutzer "LOCAL SERVICE") und gibt den anonymen Fehler aus.

Hier unterscheidet es sich von Ihrem Problem. Keiner der Computer im lokalen Netzwerk befindet sich in einer Domäne, sondern nur in einer Arbeitsgruppe. Um die Windows-Authentifizierung mit einer Workgroup zu verwenden, müssen sowohl der Computer mit dem Server (in meinem Fall MSSQL Server) als auch der Computer mit dem Dienst, der Daten anfordert (in meinem Fall Apache) einen Benutzer mit einem identischen Namen und einem identischen Kennwort haben.

Zusammenfassend lässt sich sagen, dass der Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'-Fehler in beiden Fällen auf einen Dienst zurückzuführen ist, der nicht ausgeführt wird und/oder nicht der richtige Benutzer ist. Wenn Sie sicherstellen, dass der richtige SPN oder ein anderer Dienst ausgeführt wird und der richtige Benutzer verwendet wird, sollte der anonyme Teil des Problems gelöst werden.

6
Caboosetp

Ich denke, es muss eine Änderung in der AD-Gruppe stattgefunden haben, die zur Authentifizierung bei der Datenbank verwendet wird. Fügen Sie der AD-Gruppe, die Zugriff auf die Datenbank hatte, den Webservernamen im Format Domäne\Webservername $ hinzu. Versuchen Sie außerdem, das Attribut web.config auf "false" zu setzen. Ich hoffe es hilft. 

EDIT: Geht nach dem, was Sie bearbeitet haben. Wahrscheinlich weist dies darauf hin, dass das Authentifizierungsprotokoll Ihres SQL Servers von Kerberos (standardmäßig, wenn Sie die integrierte Windows-Authentifizierung verwendet haben) auf NTLM zurückgegangen ist. Für die Verwendung des Kerberos-Dienstes muss der Principal Name (SPN) im Active Directory-Verzeichnisdienst registriert sein. Service Principal Name (SPNs) sind eindeutige Bezeichner für Dienste, die auf Servern ausgeführt werden. Für jeden Dienst, der die Kerberos-Authentifizierung verwendet, muss ein SPN festgelegt sein, damit Clients den Dienst im Netzwerk identifizieren können. Es ist in Active Directory entweder unter einem Computerkonto oder einem Benutzerkonto registriert. Obwohl das Kerberos-Protokoll der Standard ist, wird der Authentifizierungsprozess mit NTLM versucht, wenn der Standardwert fehlschlägt. 

In Ihrem Szenario muss der Client eine TCP-Verbindung herstellen. Er wird höchstwahrscheinlich unter dem Konto LocalSystem ausgeführt, und es ist kein SPN für die SQL-Instanz registriert. Daher wird NTLM verwendet. Das Konto LocalSystem erbt jedoch von einem Systemkontext anstelle eines echten Benutzers -basierter Kontext schlug daher als "ANONYMOUS LOGON" fehl. 

Um dieses Problem zu beheben, bitten Sie Ihren Domänenadministrator, den SPN manuell zu registrieren, wenn Ihr SQL Server unter einem Domänenbenutzerkonto ausgeführt wird .. __ Die folgenden Links können Ihnen mehr helfen:
http://blogs.msdn.com/b/sql_protocols/archive/2005/10/12/479871.aspx
http://support.Microsoft.com/kb/909801

5
Saurabh R S

Sie müssen wahrscheinlich nur einen Benutzernamen und ein Kennwort in Ihrer Verbindungszeichenfolge angeben und Integrated Security = false festlegen

2
shabber

Einer meiner SQL-Jobs hatte das gleiche Problem. Dabei wurden Daten von einem Server auf einen anderen hochgeladen. Der Fehler ist aufgetreten, weil ich SQL Server Agent-Dienstkonto verwendet habe. Ich habe ein Credential mit einer UserId (die die Windows-Authentifizierung verwendet) für alle Server erstellt. Dann wurde ein Proxy mit diesem Berechtigungsnachweis erstellt. Verwendet den Proxy in SQL Server-Job und es läuft gut.

2
Vipul

FWIW, in unserem Fall zeigte eine (PHP-) Website, die auf IIS lief, diese Meldung beim Versuch, eine Verbindung zu einer Datenbank herzustellen.

Die Lösung bestand darin, die anonyme Authentifizierung auf dieser Website so zu bearbeiten, dass sie die Identität des Anwendungspools verwendet (und den Anwendungspooleintrag so einzurichten, dass ein für diese Website entwickeltes Dienstkonto verwendet wird).

0

Stellen Sie in der Verbindungszeichenfolge "Integrierte Sicherheit = False" ein.

<add name="YourContext" connectionString="Data Source=<IPAddressOfDBServer>;Initial Catalog=<DBName>;USER ID=<youruserid>;Password=<yourpassword>;Integrated Security=False;MultipleActiveResultSets=True" providerName="System.Data.SqlClient"/>
0
Ummer Irshad