認証に使用されるドメインコントローラーを決定する方法
Windows Server2003とWindowsServer 2008の両方でIISを使用していくつかのWebサイトを実行しています。これらのWebサイトは、NTLMオプションのみが指定された（Kerberosなし）Windows認証を使用しています。
これらのサーバーは両方とも同じActiveDirectoryドメイン、機能レベルのWindows Server2003のメンバーです。WindowsServer2008とWindowsServer2012の両方を実行しているドメインコントローラーがあります。
ドメインは、独自のフォレスト内の別のActiveDirectoryドメインとの双方向の信頼を持っています。
信頼できるドメインのユーザーアカウントを使用すると、ユーザーがIIS Webサイトに認証できない場合があります。ブラウザから資格情報の入力を繰り返し求められ、数回試行すると空白のページが表示されます。資格情報トラブルシューティングの手順として、信頼されたドメインからテストアカウントにローカルでWebサーバーにログオンする権限を付与し、そのアカウントを使用してWebサーバーにログオンすると同時にIIS =ユーザーが同じ資格情報でログオンすることを許可しません。
この問題はすべてのWebサーバーで同時に発生するわけではなく、1つが影響を受け、他のサーバーは信頼できるドメインからのログイン要求を正常に処理し続けます。
ワークステーションサービスを再起動すると、問題が解決します（サーバー全体を再起動することもできます）。
私の質問は次のとおりです。
IIS for：のログイン要求を処理しているActive Directoryドメインコントローラーを特定するには、どうすればよいですか：a：プライマリドメインb：信頼されたドメイン
信頼されたドメインへのログイン要求がIISによって受信された場合、その要求はどのように処理されますか？具体的には、要求はプライマリドメインまたはセカンダリドメインのドメインコントローラーに送信されますか？特定のドメインコントローラーはどのように選択されますか？
おかげで、
最初に2番目の質問に答えるには：
まだNTLMを使用しているので、 マルチドメイン環境でのNTLMのフロー について読むと、これが少し役立つかもしれません。 IISは、そのドメインのドメインコントローラー（DC）に接続し、次に、信頼されたドメインのDCに接続します。
信頼するDCは、信頼できるドメインの名前に対してDNSルックアップを実行し、そのクエリによって返されるすべてのDCにLDAPおよびNetBIOS要求を送信します。最初に応答するDCが「勝ち」ます。これが、おそらくあなたがこのプロセスでいくつかの非決定論が見られます。DNSを使用してモンキーを作成することで、このプロセスに影響を与えることができます。
認証中のDC=を見つけるには、認証トラフィックをキャプチャするか、認証が行われている可能性のあるすべてのDCのセキュリティイベントログを監視する必要があります。