前回の記事の最後で、「障害が一過性のものなら大した問題にならない」と書きました。
では、障害が継続し、B-D 間でセキュアチャネルを確立できない状態のままだと、どのような影響が出るのかを具体的に紹介します。
（起こり得ることの全てを網羅できているわけではありません。）
＜1＞ キャッシュログオン
D にドメインユーザーがログオンしようとしても、B に認証してもらうことができません。
では絶対にログオンできないのかというと、必ずしもそうではありません。
過去、B-D 間でちゃんとセキュアチャネルが確立できていた時に D にログオンしたドメインユーザーであれば、D にはその情報が 10 人分キャッシュされています。
なので、その時と同じパスワードを入力すれば、一応ログオンできます。
キャッシュする人数は、セキュリティポリシー「対話型ログオン：キャッシュする過去のログオン数 (ドメインコントローラーが使用できない場合) 」により、0 〜 50 に調節できます。
詳しく知りたい方は、「キャッシュされた資格情報」で検索してみてください。
なお、ログオンしたユーザー自身は、自分が正常にログオンできたのか、キャッシュでログオンしたのか自覚できません。
簡単に調べるためには、コマンドプロンプトで ” whoami /fqdn ” を実行します。
そのドメインユーザーの「完全修飾ドメイン名」をドメインコントローラーから取得しようとするため、セキュアチャネルを確立できない状態ではエラーします。
さて、D にキャッシュログオンしている状態では、C の共有フォルダへアクセスできません。
アクセスが許可されているはずのドメインユーザーであっても、です。
本来ならドメインコントローラーから発行される、「Kerberos のサービスチケット」を持っていないためと考えられます。
資格情報（ユーザー名とパスワード）入力ウィンドウが表示されますので、アクセスが許可されている「C のローカルユーザー」を入力すればアクセスできます。
資格情報入力ウィンドウが表示されない場合は、” net use ” コマンドを使ってセッションを張ることでアクセスできます。
＜2＞ グループポリシー
前回も触れましたが、B から最新のグループポリシーを取得することができません。
グループポリシーを取得するコマンド ” gpupdate ” もエラーします。
そのため、一番最後に正常に取得できていたグループポリシーを使い続けることになります。
D が B からグループポリシーを取得（更新）しようとする動作は、OS の起動時やドメインユーザーのログオン時だけでなく、その後も定期的に発生します。
そのため、セキュアチャネルが確立できていない限り、取得に失敗し続けることとなります。
※ 取得の間隔については、Technet の下記２つの記事が参考になると思います。
・ ヒント: グループ ポリシーの更新を理解して手動で実行する
グループポリシーの取得に失敗すると、D のイベントログには以下に紹介する複数のエラーが記録されます。
これらが定期的に記録され続けている場合、そのコンピューターはずっとセキュアチャネルを確立できずにいる可能性が高いと考えられます。
「システム」に記録されるエラーは「ソース：GroupPolicy (Microsoft-Windows-GroupPolicy) , イベント ID：1129」で、以下のようなメッセージです。
ドメイン コントローラーへのネットワーク接続が存在しないため、グループ ポリシーの処理に失敗しました。これは一時的な状態である可能性があります。コンピューターがドメイン コントローラーに接続され、グループ ポリシーが正しく処理されると成功のメッセージが生成されます。数時間経ってもメッセージが表示されない場合は、管理者に連絡してください。
「Group Policy」フォルダ配下の「Operational」に記録されるエラーは、「ソース：GroupPolicy (Microsoft-Windows-GroupPolicy) , イベント ID：7017, 7320, 7004, 7001」の４種類です。（メッセージは割愛します。）
なお、グループポリシーを取得できた場合は、イベントログに情報が記録されます。
「システム」に記録される情報は「ソース：GroupPolicy (Microsoft-Windows-GroupPolicy) , イベント ID：1500, 1501」の２種類です。（メッセージは割愛します。）
＜3＞ 時刻同期
Active Directory ドメインに参加しているコンピューターは、デフォルトではドメインコントローラーと時刻を同期します。（他の NTP サーバーに変更することも可能です。）
今回検証した環境では、ドメインコントローラーは B 一台だけしかありませんが、複数のドメインコントローラーがある環境では、Windows Time サービスが開始した時点でセキュアチャネルを確立しているドメインコントローラーと同期します。
（現在どのドメインコントローラーとセキュアチャネルを確立しているのかは、” net user /domain ” コマンドや、” nltest /SC_QUERY:<ドメイン名> ” コマンドで判ります。）
時刻同期も決まった間隔で繰り返されるので、セキュアチャネルが確立できていない限り、同期に失敗し続けます。
しかし、グループポリシーとは違って、成功や失敗の度に毎回イベントが記録されるわけではありません。
これはちょっと不親切な仕様だなと思うのですが、少なくとも、OS 起動後初回の時刻同期に失敗した時には「システム」に「ソース：Time-Service , イベント ID：129」のエラーが記録されます。
OS 起動以来、一度も時刻同期ができていない状態では、” w32tm /query /status ” コマンドを実行すると「ソース: Local CMOS Clock」と表示されます。
これは、OS 起動時に マザーボード の時計から時刻を読み込んだのが最後の時刻同期だ、という意味のようです。
その後、初めて時刻同期に成功した時には、「システム」に「ソース：Time-Service , イベント ID：37, 35」の情報が記録されます。
この状態で ” w32tm /query /status ” コマンドを実行すると「ソース: <ドメインコントローラー名>」と表示されます。
なお、Windows の時刻同期の仕組みについて、@IT の記事「Windowsネットワーク時刻同期の基礎とノウハウ（改訂版）」で詳しく解説されています。