B – D 間でセキュアチャネルが確立されるまでの流れを、導入編に書きました。
どれか一つでも処理が失敗したら、本エラーが記録されると考えてよいでしょう。
なお、本エラーについてはマイクロソフトのサポートサイトでも、以下の技術情報が公開されています。
ドメインのメンバーを起動するとイベント ID 5719 がログに記録されます。
（機械翻訳なので、日本語が不自然です。英語の原文を読みたい場合は、URL の中の /ja-jp/ を /en-us/ に書き換えます。）
上記のページで幾つかの発生条件とその対処策が列挙されていますが、ちょっと注意が必要です。
間違っても、「これさえ読めば、全ての発生条件が網羅されている。」などと誤解してはいけません。
マイクロソフトが公開している技術文書の多くに共通することなのですが、「この条件に当てはまる環境なら、この現象が発生しても不思議ではない。」と言っているにすぎません。
決して、「この現象は、他の条件や原因によって発生することは無い。」とは言っていないのです。
上記のページに書かれている幾つかの発生条件には、共通点があります。
それは、D が起動してから、ネットワーク通信が可能になるまでの時間がかかり過ぎ、それより早いタイミングで B へ接続を試みたということです。
当然 B へ接続できるはずもなく、セキュアチャネルを確立できずに本エラーが記録されるわけです。
今回は、それ以外の障害が原因で本エラーが記録された場合について記載します。
＜1＞ 名前解決の障害
D は、ドメインコントローラーを探すために DNS サーバーへ 問い合わせる必要があります。
そのため、名前解決に失敗すれば本エラーが記録されます。
本エラー以外にも、同じく「システム」に「ソース： DNS Client Events , イベント ID：1014」という警告が記録されます。
この警告のメッセージは以下のようなものです。
名前 _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.ad.test.domain. の名前解決は、構成されたどの DNS サーバーからも応答がなく、タイムアウトしました。
DNS サーバーで該当するレコードを確認すれば、D が解決しようとしたのはドメインサービスの SRV レコードだということがわかります。
なお、D 自身の hosts ファイルにドメインコントローラーのホスト名と IP アドレスを記載しても回避策になりません。
hosts ファイルは、SRV レコードの名前解決には用いられないからです。
名前解決に失敗する主な原因としては、以下のような障害が考えられます。
・ DNS サーバー A 自体がダウンしている。
・ A の DNS Server サービスが停止ないし一時停止している。
・ A が高負荷で処理が滞っている。
・ A – D 間のどこかでネットワークが断たれている。（A や D の NIC の障害も含みます。）
ちなみに、名前解決に成功した場合、「システム」には特に何も記録されません。
「DNS Client Events」フォルダ配下の「Operational」を予め有効化しておけば、情報として記録されます。
詳細なイベントが多く記録されるので、やや見にくいのですが。
＜2＞ ドメインコントローラーの障害
D は名前解決に成功した後に B へセキュアチャネルの確立を要求しますが、B から応答が無ければ結局本エラーが記録されます。
このケースの特徴的なエラーや警告は特に無いようですが、イベントログの「システム」に名前解決の失敗を示す前述の警告が記録されていない場合は、このケースに該当する可能性が高いと考えられます。
ドメインコントローラーから応答が返ってこない主な原因としては、以下のような障害が考えられます。
・ ドメインコントローラー B 自体がダウンしている。
・ B の NETLOGON サービスが停止ないし一時停止している。
・ B が高負荷で処理が滞っている。
・ B – D 間のどこかでネットワークが断たれている。（B や D の NIC の障害も含みます。）
・ A から回答された IP アドレスが間違っている。
なお、イベントログとは別に、D 自身の NETLOGON サービスの詳細なログを出力することで、より詳しい調査が可能になります。
このログはデフォルトで無効なので、まず有効化するために ” nltest /DBFLAG:2080FFFF ” コマンドを実行します。
すると「C:¥Windows¥debug¥netlogon.log」にログが出始めます。
より詳しい事は、以下のマイクロソフトのサポートサイトを参照してください。
Netlogon サービスのログ出力のデバッグを有効にします。
仮に ＜1＞ のケースで A から回答を得られなかった場合、このログに「No data returned from DnsQuery.」と記録されます。
A から回答を得た場合は、B へ接続しようとしたことを示す「Sent UDP ping to <B の IP アドレス>」が記録されますが、B から応答が返ってこなかった場合は「site specific SRV records done.」が記録されます。
その他にも、B 自体がダウンしている場合には「NetpDcGetNameIp returned 121」が記録され、B の NETLOGON サービスが一時停止状態である場合には「Netlogon is paused on the server.」が記録されます。
しかし、B の NETLOGON サービスが停止している場合に特徴的なログは無いようです。
おわり