72

問題なく動作している（そして約6か月ほどアクティブな開発が行われていない）アプリケーションは、最近データベースへの接続に失敗し始めました。運用管理者は、問題の原因となる可能性のある変更点を言うことができません。

クライアントアプリケーションは、Integrated Security = Trueのハードコードされた接続文字列を使用しますが、アプリケーションがデータベースへの接続を作成しようとすると、「ユーザー'NT AUTHORITY \ANONYMOUSLOGONのログインに失敗しました」というSQLExceptionがスローされます。

このアカウントでManagementStudioを介してデータベースに問題なくログオンできます。この問題で私が目にしたことはすべてASP.NETプロジェクトに関するものであり、クライアントアプリケーションであることが問題ではないというのは明らかに「ダブルホップの問題」です。どんな助けでも大歓迎です。

編集

クライアントマシンとサーバーマシン、およびユーザーアカウントは同じドメインにあります。これは、Windowsファイアウォールがオフの場合に発生します。

主要な理論は次のとおりです。サーバーは約1週間前に再起動され、サービスプリンシパル名（SPN）の登録に失敗しました。SPNの登録に失敗すると、統合認証がKerberosではなくNTLMにフォールバックする可能性があります。

4

9 に答える 9

31

リンクサーバーに問題がある場合は、いくつかの点を確認する必要があります。

まず、ユーザーは委任を有効にする必要があります。変更されたのが唯一の場合は、そうなる可能性があります。それ以外の場合は、ADのユーザープロパティである[アカウントは機密であり、委任できません]チェックボックスをオフにすることができます。

次に、サービスアカウントは委任に対して信頼されている必要があります。最近サービスアカウントを変更したので、これが原因だと思います。（http://technet.microsoft.com/en-us/library/cc739474(v=ws.10).aspx）

SPNに問題がある可能性があるとのことですが、必ず両方のエンドポイントにSPNを設定してください。そうしないと、ADに[委任]タブが表示されません。また、「ActiveDirectoryユーザーとコンピューター」で詳細表示されていることを確認してください。

SPNを修正しても[委任]タブが表示されない場合は、ドメインが2000モードになっていないことを確認してください。そうである場合は、「ドメイン機能レベルを上げる」ことができます。

この時点で、アカウントを委任に対して信頼できるものとしてマークできます。

詳細ウィンドウで、委任について信頼するユーザーを右クリックし、[プロパティ]をクリックします。

[委任]タブをクリックし、[アカウントは委任に対して信頼されている]チェックボックスをオンにして、[OK]をクリックします。

最後に、すべてのマシンを委任に対して信頼できるものとして設定する必要もあります。

これを行ったら、SQLサーバーに再接続し、気に入ったサーバーをテストします。彼らは働くはずです。

于 2012-09-18T03:00:30.880 に答える
10

最初に：私の問題はあなたの問題とまったく同じではありませんが、この投稿は、Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'私がこれを書いたときにエラーのためにグーグルで最初に出てくるものです。この特定の解決策はオンラインのどこにも見つからなかったため、この解決策はこのエラーを検索する人々に役立つ可能性があります。

私の場合、Xampp /ApacheとPHPsqlsrvを使用してWindows認証を使用してMSSQLデータベースに接続しようとしましたが、Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'説明したエラーが表示されました。ついに問題は、ログインしたユーザーアカウントではなく、ユーザー「LOCALSERVICE」で実行されているApacheサービス自体にあることがわかりました。言い換えれば、それは文字通り匿名のアカウントを使用していました。解決策は、services.mscに移動し、Apacheサービスを右クリックして、[プロパティ]に移動し、[ログオン]タブに移動して、ユーザーの資格情報を入力することでした。これは、SPNがドメイン上の特定のユーザーから実行されるように設定されているため、SPNに関連する問題と一致します。したがって、正しいSPNが実行されていない場合、Windows認証はデフォルトで間違ったユーザー（「ローカルサービス」ユーザーなど）になり、匿名エラーが発生します。

ここがあなたの問題とは違うところです。ローカルネットワーク上のどのコンピューターもドメイン上になく、ワークグループ上にのみ存在します。ワークグループでWindows認証を使用するには、サーバーを備えたコンピューター（私の場合はMSSQLサーバー）とデータを要求するサービスを備えたコンピューター（私の場合はApache）の両方に、同じ名前と同じパスワードを持つユーザーが必要でした。

要約するとLogin failed for user 'NT AUTHORITY\ANONYMOUS LOGON'、両方の場合のエラーは、サービスが実行されていないか、適切なユーザーにないことが原因であると思われます。適切なSPNまたは他のサービスが実行されており、適切なユーザーの下で問題の匿名部分を解決する必要があります。

于 2015-07-10T15:01:02.237 に答える
6

データベースに対する認証に使用されるADグループに何らかの変更があったに違いないと思います。データベースにアクセスしたADグループに、domain \webservername$の形式でWebサーバー名を追加します。さらに、web.config属性を「false」に設定してみてください。それが役に立てば幸い。

編集：編集した内容を確認します。SQLServerの認証プロトコルがKerberos（Windows統合認証を使用している場合はデフォルト）からNTLMにフォールバックしたことを示している可能性があります。Kerberosサービスを使用するには、プリンシパル名（SPN）をActiveDirectoryディレクトリサービスに登録する必要があります。サービスプリンシパル名（SPN）は、サーバーで実行されているサービスの一意の識別子です。Kerberos認証を使用する各サービスには、クライアントがネットワーク上のサービスを識別できるように、SPNを設定する必要があります。これは、コンピューターアカウントまたはユーザーアカウントのいずれかでActiveDirectoryに登録されます。Kerberosプロトコルがデフォルトですが、デフォルトが失敗した場合、認証プロセスはNTLMを使用して試行されます。

シナリオでは、クライアントはtcp接続を確立している必要があり、LocalSystemアカウントで実行されている可能性が高く、SQLインスタンスにSPNが登録されていないため、NTLMが使用されますが、LocalSystemアカウントは実際のユーザーではなくシステムコンテキストを継承しますしたがって、ベースのコンテキストは「ANONYMOUSLOGON」として失敗しました。

これを解決するには、SQL Serverがドメインユーザーアカウントで実行されている場合は、ドメイン管理者にSPNを手動で登録するように依頼してください。次のリンクがさらに役立つ場合があります：http：
//blogs.msdn.com/b/sql_protocols/archive/2005/10/12/479871.aspx
http://support.microsoft.com/kb/909801

于 2012-09-17T16:10:49.130 に答える
4

おそらく、接続文字列にユーザー名とパスワードを入力し、Integrated Security=falseを設定する必要があります。

于 2017-05-22T06:11:36.150 に答える
2

私のSQLジョブの1つに同じ問題がありました。これには、あるサーバーから別のサーバーへのデータのアップロードが含まれていました。SQLServerエージェントサービスアカウントを使用していたためにエラーが発生しました。すべてのサーバーに共通のUserId（ウィンドウ認証を使用）を使用して資格情報を作成しました。次に、この資格情報を使用してプロキシを作成しました。SQL Serverジョブでプロキシを使用し、正常に実行されています。

于 2015-08-12T14:42:02.873 に答える
1

接続文字列に「IntegratedSecurity=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"/>
于 2018-12-17T06:32:11.220 に答える
1

FWIW、この場合、IISで実行されている（PHP）Webサイトは、データベースに接続しようとするとこのメッセージを表示していました。

解決策は、そのWebサイトの匿名認証を編集してアプリケーションプールIDを使用することでした（そして、そのWebサイト用に設計されたサービスアカウントを使用するようにアプリケーションプールエントリを設定しました）。

于 2019-06-07T02:19:07.243 に答える
1

同様のケースが解決しました：

この例では、cnamesを使用し、ログインの現在のセキュリティコンテキストを使用してリンクサーバーを設定する必要がありました。

すべての順序で、SQL Serverを実行しているサービスアカウントに適切なspnが設定されていること、およびADオブジェクトが委任に対して信頼されていることを確認しました。ただし、cnameに直接接続することはできましたが、そのcnameでリンクサーバーを呼び出す際に問題が発生しました。Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

使用したcnameがAレコード[A]用であり、それ自体のドメインADレベルではなく、より高いdnsレベルに設定されていることに気付くのに時間がかかりすぎました。元々、cnameは[A] .example.comに向けられていましたが、[A] .domain.ad.example.comには向けられていませんでした（必要な場合）。

もちろん、匿名ログオンに関してこれらのエラーが発生しました。

于 2021-02-05T15:50:22.287 に答える
0

とった！SQLServerのセキュリティセッションでユーザープロパティを変更する問題を解決しました。SQL Server Managementで、[セキュリティ]->[ログオン]->[DB接続に使用するユーザーを選択]に移動し、そのユーザーのプロパティに移動します。[Securators]タブに移動し、[Connect SQL]の行を探し、[Grant]オプションをマークして、試してみてください。わたしにはできる！

よろしく

于 2020-09-14T19:50:42.697 に答える