IIS 7.5でのWindows認証の問題のトラブルシューティング(チャレンジなし)?


21

統合Windows認証をIISで動作させるのに苦労している人々の報告が何千もあることは知っていますが、それらはすべて適用されないWebページまたは既に試したソリューションにつながるようです。私は以前にこのようなサイトを何十も展開したことがあるので、サーバー/構成で何か奇妙なことが起こっているか、あまりにも長い間見ていて明らかなものを見ていません。

簡単に言えば、すべてがローカルマシン上で完全に動作しますが、実稼働サーバー上ではバラバラになります

ローカルマシンで:

  • マシンはWindows 7 Ultimate、Service Pack 1、IIS 7.5を実行しています。
  • IISとVS Web開発サーバーの両方を使用して、サイトは正常にテストされました。
  • IISサイト構成では、Windows認証を除くすべての認証方法が無効になっています。
  • ローカルマシンはどのドメインにもありません。
  • 設定されるプロバイダーは、ネゴシエートおよびNTLMです(ネゴシエート:Kerberosではありません)。
  • 拡張保護はオフです。
  • テストされたすべてのブラウザ(IE、Firefox、Chrome)にチャレンジプロンプトが表示され、(ローカル)Windowsアカウントでローカルホストドメインにログインできます。
  • テストされたすべてのブラウザは、不透明なローカルIPアドレスを使用しても機能します。したがって、ブラウザ自体は、サイトが「ローカル」または「リモート」のどちらであるかを気にしません。
  • 現在ログインしているユーザーを表示する表示行をWebページに追加しました。これには、期待どおりの内容(ログインしているローカルユーザー)が表示されます。

リモートマシンで:

  • サーバーはWindows Server 2008 R2、IIS 7.5を実行しています。
  • Webページをロードすると、すぐに 401.2エラーが発生します。認証ヘッダーが無効なため、このページを表示する権限がありません。 チャレンジプロンプトは表示されません。
  • IISサイト構成では、Windows認証を除くすべての認証方法が無効になっています。
  • リモートマシンはどのドメインにもありません。
  • 設定されるプロバイダーは、ネゴシエートおよびNTLMです(ネゴシエート:Kerberosではありません)。
  • 拡張保護はオフです。
  • リモートマシン(リモートデスクトップセッション)では、ドメインがローカルホストか外部IPアドレスかに関係なく、Internet Explorerに同じエラーが表示されます。
  • ローカルマシンからリモート Webサイトを表示しようとすると、エラーは401のままですが、401が少し異なります。サブコードはなく、次のテキストが含まれています。無効な資格情報によりアクセスが拒否されました。
  • Windows認証 IISの役割機能がされてインストールされています。
  • WindowsAuthenticationモジュールがされ(サーバー・レベルで)追加します。
  • Windows認証をオフにして基本認証を有効にすると、まったく同じエラーが発生します。
  • Windows認証を無効にし、匿名を有効にすると(明らかに)サイト読み込まれます。
  • Microsoftサポートのトラブルシューティング手順のすべてを既に実行しました:IISのHTTP 401エラーのトラブルシューティング
  • 別のマイクロソフトサポートページに表示されている回避策を既に試しました(NTLMを唯一の方法として強制するため)。

最後に大事なことを言い忘れましたが、401.2エラーのFREBを有効にしようとしましたが、結果は何の役に立つものでもないようです。

MODULE_SET_RESPONSE_ERROR_STATUS

ModuleName IIS Web Core
Notification 2
HttpStatus 401
HttpReason Unauthorized
HttpSubStatus 2
ErrorCode 2147942405
ConfigExceptionInfo
Notification AUTHENTICATE_REQUEST
ErrorCodeアクセスが拒否されました。(0x80070005)

...これは、私がすでに知っていることを伝えているだけのようです(資格情報をネゴシエートするのではなく、単にリクエストを拒否しているだけです)。

このトレースはNOTIFY_MODULE_STARTModuleName= WindowsAuthentication(およびその他のさまざまなASP.NETフォローアップイベント-[残念]、興味深いエラーや警告はありません)の行があるため、WindowsAuthenticationモジュールが正しくロードされていることを示しています。

誰も私がここで何が欠けているのか教えてもらえますか?


クイックアップデート:

Wiresharkダンプ全体を送信するとIP、URLなどが明らかになるので少し不快ですが、localhostとFiddlerのリモートサーバーからのHTTP応答を並べて比較しましたが、 -問題が何であるかは明らかです:

ローカルホスト:

HTTP / 1.1 401 Unauthorized
キャッシュ制御:プライベート
コンテンツタイプ:text / html; charset = utf-8
サーバー:Microsoft-IIS / 7.5
WWW認証:ネゴシエート
WWW認証:NTLM
X-Powered-By:ASP.NET
日付:2011年12月17日(土)23:42:34 GMT
コンテンツの長さ:6399
プロキシサポート:セッションベース認証

リモート:

HTTP / 1.1 401 Unauthorized
コンテンツタイプ:text / html
サーバー:Microsoft-IIS / 7.5
X-Powered-By:ASP.NET
日付:2011年12月17日(土)23:43:13 GMT
コンテンツの長さ:1293

cache-controlのような一見重要ではないいくつかの違いは別として、主な違いはリモートサーバーがクライアントにWWW-Authenticateヘッダーを返送しないことです。

だから、私はそれを質問に絞り込むと思いますWindows認証がインストールされ、ロードされ、排他的に有効になっているように見えるとき、なぜIISはWWW-Authenticateヘッダーを送信しないのですか?


認証試行の平文のWiresharkをキャプチャすることを念頭に置いてください(最初にパスワードを使い捨てのものに変更します-ネット上で実際のパスワードハッシュは必要ありません)?18か月ほど前のWindowsパッチにより、HTTP NTLMネゴシエーションにいくつかの変更が加えられました(ちなみに、システムにパッチが完全に適用されますか?)。交渉の会話。
シェーンマッデン

@ShaneMadden:さまざまな情報を公開するので、気にする必要はありませんが、ほぼ同じはずのFiddlerセッションを行うことができ、少なくともIPなどを匿名化することができます-そして実際、すでに説明したとおり、結果は一目瞭然です(サーバーは何も要求していないため、クライアントは資格情報のプロンプトを表示していません)。
アーロンノート

ああ、興味深いことに、誰かがこの問題をStack Overflowでも報告しているようです -残念ながら答えはありません。
アーロンノート

@Aaronaughtクッキングよりも違うユーザー名を取得したのはどうしてですか?この質問を初めて見たとき、それはあなたをだましている人だと思いました。
区-モニカの復職

@ワード:誰でも自分のユーザー名を編集できます。これはプロファイルの一部です。これは私のオリジナルのもので、技術以外のサイトでのみ他のものを使用します。
アーロンノート

回答:


14

問題が解決しました。最終的に、モジュールリストを並べて比較することにしましたが、実際には1つの行方不明がありました。次の2つの Windows認証モジュールがあります。

モジュールリスト

サーバーには、マネージWindowsAuthenticationモジュールがありましたが、WindowsAuthenticationModule上記で強調表示されたネイティブモジュールはありませんでした。そのように構成された理由は誰でも推測できますが、明らかにネイティブモジュールがロードされていない場合、マネージモジュールは快活にロードされ、静かに失敗します。

だから、この問題が発生した任意の将来の読者のために、あなたが持っている作る両方のモジュールがロードされた IISがあるため、警告を表示しませんそれらのいずれかが欠落している場合。


マネージWindowsAuthenticationモジュールは、見た目とは異なります。ASP.NetのWindows IDをサポートし、常にインストールされます(ASP.Netがインストールされている場合)。ただし、Windows認証ネイティブモジュールは、サーバーマネージャーでWindows Authコンポーネントにチェックマークを付けるとインストールされるものであり、その認証オプションが認証GUIに表示されるために必要なものです。
TristanK

@TristanK:この場合、そのコンポーネントはチェックされていますが、モジュールはインストールされていません。(ただし、このオプションは認証GUIに表示されていたため、画面はネイティブモジュールではなくマネージモジュールに依存していると確信しています。)
Aaronaught

構成ファイル(おそらくApplicationHost.config)の改ざんが原因でこのようになったのではないかと考えています。しかし、どうやったらすべてが強打されたのかは関係ないと思います。やった
アーロンノート

まあ、明らかに。Windows Authは、何かがそれを壊さない限り機能しません。この場合、質問は構成が同一であると述べていますが、それは真実ではないことがわかります。そのため、同じようには機能しませんでした。QED。
TristanK

1
このモジュールの欠落の問題は、Windows Server 2012 R2で私に噛みつきました。この状態が発生したときに兆候がないことは信じられないほどです。とにかく、この答えに感謝します。文字通り髪を引き裂いていた!
ロブ・デービス

4

これは、Windows認証で実行されているASP.NETサイトでローカルに作業している開発者の問題を必ずしも解決するものではないことがわかりました。ループバックチェックを無効にするレジストリハックが見つかりました。これはそれを修正しました:-

レジストリキー-HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa

「DisableLoopbackCheck」という値1のDWORDを作成します

設定を有効にするには、マシンを再起動する必要があります


DisableLoopbackCheckを1と0の間で切り替えることができ、変更がすぐに有効になることがわかりました。さらに、イベントログセキュリティイベントログに「アカウントがログオンに失敗しました」というメッセージと共にイベントID 4625が表示されます。
-alastairtree

ありがとうございました!サイトの移行のテスト中にホストファイルを使用してダミーのDNSエントリを作成していたため、IIS認証と.Netバージョンを2日間いじってみました。
JohnLBevan
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.