web-dev-qa-db-ja.com

IIS 7-IPアドレスではなくホスト名による401.2エラー

ネットワーク上のIIS 7アプリケーションで問題が発生しています。問題は次のとおりです:

ユーザーがIPアドレス(http://172.16.10.32/site)アプリケーションは問題なくロードされ、エラーはなく、完全に価値があります。

同じユーザーがホスト名(http://dms-live/site)「Internet ExplorerはWebページを表示できません」というメッセージが表示されます。さらに掘り下げると、実際のエラーコード401.2-不正です。

さらに詳しい情報:

  • これは、外部アクセスがまったくない内部サイトです

  • Internet Explorerは、サイトをイントラネットゾーンに配置するようにグループポリシーで設定されています

  • アプリケーションでは、「匿名認証」(IUSRを使用)、「ASP.NET偽装」(認証済みユーザーに設定)、「基本認証」(デフォルトのドメインまたはレルムが指定されていない)、および「Windows認証」(カーネルモード認証が有効)

  • ユーザーは、正しいIPアドレス172.16.10.32を返すdms-liveにpingを実行できます

  • ユーザーは両方を閲覧できますhttp://172.16.10.32およびhttp://dms-live問題なく、デフォルトのIIS 7スプラッシュスクリーンが表示されます。

  • ホスト名「dms-live」は、172.16.10.32を指すDNSで指定された追加のAレコードです

  • サーバーの実際のホスト名は「accserver16」です。これを「dms-live」の代わりに使用すると、まったく同じ結果が得られます(401.2エラー)

  • 短いホスト名の代わりにFQDNを使用しても同じ結果が得られます(401.2エラー)

  • Webサイトには、dms-live、accserver16および172.16.10.32に加えて、関連するFQDNへのバインディングがあります。

  • 私たちのネットワークには、2つのフォレストに2つのドメインがあります。フォレストAのドメインAとフォレストBのドメインBです。すべてのユーザーとワークステーションはドメインAにあり、IISサーバーはドメインBにあります。2つあります。ドメインAとドメインBの間に構成された双方向の信頼。

  • 両方のドメインに独自のDNSサーバーがあります

この問題は、非常に具体的なDNSの変更が1つ加えられた後に、最近発生しました。もともとドメインBのDNSゾーンはドメインBのDNSサーバーによってホストされていて、ドメインAのDNSサーバーからの要求を転送するように条件付きフォワーダーエントリが設定されていました。復元力のために、ドメインAのDNSサーバーがドメインBゾーン用に設定されたセカンダリフォワードゾーンとリバースゾーンを持つように変更されました。

セカンダリゾーンは正常に読み込まれ、変更を適切に複製し、pingおよびnslookup要求に正しいDNSレコードを返します。

もう1つの奇妙な情報-ネットワーク上の一部のPCはhttp://dms-live/site問題なし。 PCが機能するパターンと機能しないパターンはあまりないようです。

ユーザー(2つの異なるPCの同じユーザーが必ずしも同じ結果を得るとは限りません)、ブラウザー(これはIE8とIE9でテストされ、結果に一貫性がない)、またはオペレーティングシステム(問題はWindowsかどうかに依存しないようです) XPまたはWindows 7が使用されている)。

これまでに試したトラブルシューティング:

  • 一度に単一の認証形式を有効にする
  • カーネルモード認証の無効化
  • DMS-LIVEおよび関連するFQDNのSPNレコードの設定
  • IE試行間のキャッシュをクリアする
  • PCの再起動
  • Ipconfig/flushdnsを使用してDNSキャッシュをフラッシュする
  • "DisableStrictNameChecking"レジストリキーを1に設定してサーバーを再起動する
  • アプリケーションディレクトリのNTFSアクセス許可にACCSERVER16 $およびIIS_IUSRSを追加する

ページのロードに失敗したPCで、Fiddlerは、401エラーを返す単一の要求が行われたことを示しています。ページを正常にロードするPCで、Fiddlerは、同じ401エラーの後に302が続き、その後に200が続きます。

セカンダリゾーンが削除され、Conditional Forwardersエントリが戻されると、問題は解消されます。

何らかの理由で、条件付きフォワーダーの代わりにセカンダリゾーンを使用して別のフォレストのホスト名を解決すると、一部のPCでは認証が失敗しますが、すべてではありませんが、なぜこれが当てはまらないのかわかりません。誰か助けてもらえますか?

3
Ian

何度も調べたところ、ようやく問題の原因がわかりました。

他のいくつかの関連する問題に気付いた後、私たちはそれを追跡しました。 accserver16の共有を参照しようとすると、ユーザーに資格情報ボックスと次のエラーメッセージが表示されます。

システムは、セキュリティを危険にさらす可能性のある試みを検出しました。認証したサーバーに接続できることを確認してください。

適切な資格情報の入力は機能しましたが、これは必要ではありませんでした。

また、フォレストBからドメインコントローラーの信頼を検証しようとすると、次のエラーメッセージが表示されました。

ドメインdomainb.localからドメインdomaina.localへのActive Directoryドメインコントローラー\ accserver04.domainb.localでのセキュリティで保護されたチャネル(SC)のリセットは、エラーで失敗しました:現在、ログオン要求を処理できるログオンサーバーがありません。

これは、問題の原因として、他のフォレストでドメインコントローラーを検索できないことを示しています。

DNS内では、各ドメインの前方参照ゾーンの下に、「_ msdcs」という名前の委任ゾーンがあります。これには、そのドメインのネームサーバーを指す静的なNSレコードが含まれている必要があります。

ドメインAとドメインBの両方で、これは正しく構成されていません。ドメインAでは、リストされている唯一のネームサーバーが降格されており、ドメインBでは、ネットワーク上に存在しなくなったサーバーを指しています。

どうやら、これは内部DNSクエリに問題を引き起こさず、条件付き転送が使用されている限り、フォレスト間のクエリに影響を与えませんでした。ただし、条件付き転送がセカンダリゾーンに置き換えられるとすぐに、フォレスト間の信頼は失われました。

各ドメインの_msdcs委任ゾーンのネームサーバーレコードを修正して、正しいネームサーバーを指すようにすると、問題が解決しました。

2
Ian

私はここで同じ問題について誰かと協力しました: http://forums.iis.net/p/1175219/2023646.aspx 。まだ完全には解決していませんが、受動的に取り組んでいます。 CNAMEではなくAレコードを使用した彼らの場合はそれを解決しましたが(一時的な修正)、すでにAレコードを使用しているため、それはうまくいきません。

ドメイン名のホストレコードを作成するとどうなるでしょうか。これにより、ADはほとんど方程式から外れます。また、IEイントラネットゾーンを試してみてください。また、別のブラウザでアクセスしてみてください。

問題はおそらくSPNに関連していますが、レコードを設定したと述べました。

また、一部のコンピューターでは機能するが他のコンピューターでは機能しないと述べたので、コンピューターのSPN設定と信頼設定も調べます。

失敗したページはパスワードで保護されていると思いますか?そうでない場合は、Authentication/Anonymousを設定して、常にアプリプールIDとして実行することができます。その後、IIS_IUSRSユーザーは使用されず、アプリプールIDに使用しているものでテストするだけで済みます。

1