Windows 2000ネットワーク解剖
＞
Windows NTドメインコントローラとの混在環境
Windows 2000のドメインコントローラがダウンしている場合のログオン
次に，Windows 2000のドメインコントローラがダウンしている場合のトレースを検証する。
前節の場合と異なり，Windows 2000のドメインコントローラがダウンしているため，Windows 2000クライアントはKerberosによる認証を受けることはできない。このため，Windows 2000クライアントは，Windows NTのBDCを利用して，NTLMによる認証を受けるはずである。
一方，Windows NTクライアントの場合，すべてのWindows 2000のドメインコントローラがダウンしている状態とは，PDCエミュレータがダウンしている状態を意味する。従来のWindows NTドメインの場合，PDCがダウンしていても，BDCを利用してドメインにログオンすることができた。今回のケースでも，Windows 2000のドメインコントローラ（つまりPDCエミュレータ）がダウンしていても，BDCを利用してドメインにログオンすることができるはずである。
［2002/01/17］本稿中では、「Windows NT 4.0クライアントはPDCエミュレータとなっているWindows 2000のドメインコントローラでなければ認証されない」と記述しています。しかし、この点について読者から誤りであるとの指摘がありました。
そこで、Windows 2000のドメインコントローラ2台とWindows NT 4.0（SP6a）を使用して再度検証してみたところ、指摘のとおり、PDCエミュレータとなっているWindows 2000ドメインコントローラがダウンした状態でも、Windows NT 4.0クライアントからドメインにログオンできました。
本稿中では，訂正の履歴を残すために原文をそのまま残し，逐次訂正のコメントを挿入しています。ご注意ください。ご迷惑をおかけしたことをお詫び申し上げます。
●Windows 2000クライアントのトレースとその考察
Windows 2000クライアントは，先のトレースと同様にcelica.active.dsl.local.という名前である。Windows 2000のドメインコントローラがlilyであり，Windows NT 4.0のBDCがNT40SV-2である。この状態で，ドメインコントローラであるlilyの機能を制限した。本来，このサンプル環境におけるlilyは，DNSサーバー，WINSサーバー，ドメインコントローラ（LDAPサーバー兼Kerberosサーバー）として動作している。この環境下でドメインコントローラのみがダウンした状態を作り出すため，lilyがDNSとWINSのパケット以外は受け取らないように，ネットワークを調整した（この調整方法については，別途説明する）。
以上のような環境を構築したあと，celicaからactive.dsl.local.ドメインに実際にログオンしたときのトレースを，List 3として示す。これまで示してきたトレースと同様，トレースの一部を省略および編集しているので注意してほしい。
クライアントであるcelicaは，通常のログオン工程と同様に，まずはLDAPサーバーを検索している。そのあと，LDAPのパケットを送出しているが，lilyはLDAPのパケットを受信しないように設定されているため，応答しない。そこでクライアントは，4番目のパケットと6番目のパケットで，DNSサーバーに問い合わせ，そのほかのLDAPサーバーを検索しているが，このネットワークにはLDAPサーバーがlilyしか存在しないことがわかる（トレース上には示されていないが，DNSの応答にほかのLDAPサーバーの情報が含まれていないことから判断しているはずである）。
するとcelicaは，Windows NT 4.0クライアントでActive Directoryドメインにログオンする場合と同様，“domainname <1C>”というNetBIOS名を照会し，ドメインコントローラのIPアドレスの一覧を取得している。そのあと，やはりWindows NT 4.0クライアントからActive Directoryドメインにログオンする場合と同じように，lilyとローカルネットワークに対して“Netlogon SAM LOGON request”を送出し，NT40SV-2から応答を受け取っている（lilyは，DNSとWINSのパケットしか受け取らないため，応答しない）。
注意してほしいことは，celicaがNT40SV-2のIPC$に接続したあとの動作が，Windows NT 4.0クライアントの場合とは異なっているという点である。通常のログオンシーケンスであれば，Windows NT 4.0クライアントと同じ流れになるはずだが，そうはなっていない。
実はこのあと，Windows 2000クライアントはドメインへのログオンに失敗する。List 3には掲載していないが，39〜51行目のようなシーケンスは，このあとにも現れる。celicaのイベントビューアを確認すると，「イベントID : 3210 ドメイン ACTIVE の Windows NT または Windows 2000 のドメイン コントローラ \\NT40SV-2 で認証に失敗しました。」というエラーメッセージが記録されていた。このエラーは通常，コンピュータの認証に失敗していることを表すものである。そこで筆者は，ドメインに登録されているcelicaというコンピュータを削除してから再度登録したり，netdomコマンドを使用してアカウントをリセットしたりしてみたが，この現象に変化はなかった。つまり，今回の実験によると，Active Directoryドメイン環境にドメインコントローラがBDCしか存在しない場合は，Windows 2000クライアントはドメインにログオンすることができないことになる。
この現象が筆者のテスト環境に依存するものなのか，Active Directoryドメインの仕様なのかは，本稿の執筆時点で調査中である。関連する情報としては，U.S.のサポート技術情報に「グローバルカタログが使用できない場合にログオンが不可能となる」という事例（Q241789）が紹介されている。しかし，残念ながら今回の検証では，このレジストリを変更して追試しているわけではない。
いずれにせよ，上記のような仕様になっているのであれば，Windows NTのBDCを配置する場合には，十分な注意が必要となる。通常，Windows 2000クライアントは，ドメインコントローラが存在しなかった場合，キャッシュされている以前の設定を自動的に利用して，自分自身にログオンする。今回のテスト環境でも，ドメインコントローラに加えてBDCがダウンしていれば，ドメインではなく自分自身にログオンするようになる。しかし，ドメインコントローラはダウンしているがBDCは生存しているという場合には，エラーメッセージが表示され，ドメインにログオンすることはできない。つまり，「従来クライアントの数が多いために，Windows 2000のドメインコントローラを1台設置し，BDCを複数台設置している」というような環境下でWindows 2000のドメインコントローラがダウンした場合には，Windows 2000クライアントはログオンできなくなってしまうおそれがあるのである。なお，Windows 2000クライアントがどのドメインコントローラを利用したのかを確認するには，Windows NTと同様，環境変数LOGONSERVERを確認すればよい。
この実験では，Windows 2000クライアントがBDCを利用できなかったことになる。そこで，同じWindows 2000クライアントからWindows NTドメインへとログオンしてみたところ，こちらは普通にログオンすることができた。具体的には，NT40DOMというWindows NTドメインにNT40SV-1というドメインコントローラを用意し，テストに用いたWindows 2000クライアントからNT40DOMドメインにログオンしてみたところ，Windows 2000クライアントの環境変数LOGONSERVERはNT40SV-1となった。
 |
6/11 |  |
