SQL Serverは「ユーザー 'NT AUTHORITY \ ANONYMOUS LOGON'のログインに失敗しました」というエラーを返します。 Windowsアプリケーションで
問題なく機能していた（約6か月ほどアクティブな開発が行われていない）アプリケーションは、最近データベースへの接続に失敗し始めました。運用管理者は、問題を引き起こす可能性のある変更点を言うことはできません。
クライアントアプリケーションは、Integrated Security = Trueのハードコードされた接続文字列を使用しますが、アプリケーションがデータベースへの接続を作成しようとすると、「ユーザー 'NT AUTHORITY\ANONYMOUS LOGONのログインに失敗しました」というSQLExceptionをスローします。
このアカウントでManagement Studioを使用して問題なくデータベースにログオンできます。この問題で私が見たものはすべてASP.NETプロジェクトに関するものであり、明らかに「ダブルホップの問題」であり、クライアントアプリケーションであることが問題ではないことがよくわかりました。どんな助けも大歓迎です。
編集
クライアントマシンとサーバーマシン、およびユーザーアカウントは同じドメインにあります。これは、Windowsファイアウォールがオフのときに発生します。
主要な理論は次のとおりです。サーバーは約1週間前に再起動され、サービスプリンシパル名（SPN）の登録に失敗しました。 SPNの登録に失敗すると、統合認証がKerberosではなくNTLMにフォールバックする可能性があります。
リンクサーバーに問題がある場合は、いくつかの点を確認する必要があります。
まず、ユーザーは委任を有効にする必要があります。変更されているのが唯一の場合は、そうする可能性があります。それ以外の場合、ADのユーザープロパティである[アカウントは機密で委任できない]チェックボックスをオフにすることができます。
次に、サービスアカウントが委任に対して信頼されている必要があります。サービスアカウントを変更したため、これが原因であると思われます。 （ http://technet.Microsoft.com/en-us/library/cc739474（v = ws.10）.aspx ）
SPNの問題があるかもしれないと言ったので、必ず両方のエンドポイントにSPNを設定してください。そうしないと、ADの委任タブが表示されません。また、「Active Directoryユーザーとコンピューター」の詳細ビューにいることを確認してください。
SPNを修正した後でも委任タブが表示されない場合は、ドメインが2000モードでないことを確認してください。そうであれば、「ドメイン機能レベルを上げる」ことができます。
この時点で、アカウントを委任に対して信頼済みとしてマークできます。
詳細ウィンドウで、委任に対して信頼するユーザーを右クリックし、[プロパティ]をクリックします。
[委任]タブをクリックし、[アカウントは委任に対して信頼されている]チェックボックスをオンにして、[OK]をクリックします。
最後に、すべてのマシンを委任に対して信頼済みとして設定する必要もあります。
これが完了したら、SQLサーバーに再接続して、気に入ったサーバーをテストします。彼らは動作するはずです。
最初に：私の問題はあなたの問題とまったく同じではありませんが、この投稿は、私がこれを書いたときにLogin failed for user 'NT AUTHORITY\ANONYMOUS LOGON'エラーのためにGoogleで最初に出てくるものです。この特定の解決策をオンラインで見つけることができなかったため、このエラーを検索する人々にとってこの解決策が役立つ場合があります。
私の場合、Xampp/ApacheとPHP sqlsrvを使用してWindows認証を使用してMSSQLデータベースに接続しようとし、説明したLogin failed for user 'NT AUTHORITY\ANONYMOUS LOGON'エラーを受け取りました。最終的に、問題は、ログインしたユーザーアカウントではなく、ユーザー "LOCAL SERVICE"で実行されているApacheサービス自体にあることがわかりました。つまり、文字通り匿名アカウントを使用していました。解決策は、services.mscに移動し、Apacheサービスを右クリックして、[プロパティ]に移動し、[ログオン]タブに移動して、ユーザーの資格情報を入力することでした。これは、SPNがドメインの特定のユーザーから実行されるように設定されているため、SPNに関連する問題と一致しています。そのため、正しいSPNが実行されていない場合、Windows認証はデフォルトで間違ったユーザー（おそらく「LOCAL SERVICE」ユーザー）になり、匿名エラーが発生します。
ここがあなたの問題と違うところです。ローカルネットワーク上のコンピューターはいずれもドメイン上に存在せず、ワークグループ上にのみ存在します。ワークグループでWindows認証を使用するには、サーバーを備えたコンピューター（私の場合はMSSQL Server）とデータを要求するサービスを備えたコンピューター（私の場合はApache）の両方に、同じ名前と同じパスワードのユーザーが必要です。
要約すると、両方のケースのLogin failed for user 'NT AUTHORITY\ANONYMOUS LOGON'エラーは、サービスが実行されていないか、適切なユーザーがいないために発生したようです。適切なSPNまたは他のサービスが実行されていることを確認し、適切なユーザーの下で問題の匿名部分を解決する必要があります。
データベースに対する認証に使用されるADグループに何らかの変更があったに違いないと思います。データベースにアクセスできるADグループに、domain\webservername $形式のWebサーバー名を追加します。また、web.config属性を「false」に設定してください。それが役に立てば幸い。
EDIT：編集内容に沿って移動します。SQLServerの認証プロトコルがKerberosからフォールバックしたことを示す可能性が最も高いです（デフォルト、 NTLMへのWindows統合認証を使用していた場合。 Kerberosサービスプリンシパル名（SPN）を使用するには、Active Directoryディレクトリサービスに登録する必要があります。サービスプリンシパル名（SPN）は、サーバーで実行されているサービスの一意の識別子です。 Kerberos認証を使用する各サービスには、クライアントがネットワーク上のサービスを識別できるようにSPNを設定する必要があります。コンピューターアカウントまたはユーザーアカウントのいずれかでActive Directoryに登録されます。 Kerberosプロトコルがデフォルトですが、デフォルトが失敗すると、NTLMを使用して認証プロセスが試行されます。
シナリオでは、クライアントはtcp接続を確立する必要があり、LocalSystemアカウントで実行されている可能性が高く、SQLインスタンスにSPNが登録されていないため、NTLMが使用されますが、LocalSystemアカウントは真のユーザーではなくシステムコンテキストを継承しますベースのコンテキストは、したがって、「匿名ログオン」として失敗しました。
これを解決するには、SQL Serverがドメインユーザーアカウントで実行されている場合、SPNを手動で登録するようドメイン管理者に依頼してください。次のリンクが役立つ場合があります。
http://blogs.msdn.com/b/sql_protocols/archive/2005/10/12/479871.aspx
http://support.Microsoft.com/kb/909801
おそらく、接続文字列にユーザー名とパスワードを入力し、Integrated Security = falseを設定するだけです。
接続文字列に「Integrated Security = False」を設定してみてください。
<add name="YourContext" connectionString="Data Source=<IPAddressOfDBServer>;Initial Catalog=<DBName>;USER ID=<youruserid>;Password=<yourpassword>;Integrated Security=False;MultipleActiveResultSets=True" providerName="System.Data.SqlClient"/>
私のSQLジョブの1つにも同じ問題がありました。あるサーバーから別のサーバーにデータをアップロードする必要がありました。エラーは、SQL Serverエージェントサービスアカウントを使用していたために発生しました。すべてのサーバーに共通のUserId（Window認証を使用）を使用して資格情報を作成しました。次に、この資格情報を使用してプロキシを作成しました。 SQLサーバージョブでプロキシを使用し、正常に動作しています。
FWIW、私たちの場合、IISで実行されている（PHP）Webサイトは、データベースに接続しようとするとこのメッセージを表示していました。
解決策は、そのWebサイトの匿名認証を編集して、アプリケーションプールIDを使用することでした（そして、そのWebサイト用に設計されたサービスアカウントを使用するようにアプリケーションプールエントリを設定します）。