Windows 2000ネットワーク解剖
＞
Windows NTドメインコントローラとの混在環境
明示的な信頼関係を結んだWindows NTドメインのリソースにアクセスする場合のトレースとその考察
それでは，実際にWindows NTドメインとActive Directoryドメインとのあいだに信頼関係を結んだ環境下で取得したトレースを例に，考察を進めてみよう。本稿では，Active Directoryドメインに所属しているクライアントから，Windows NTドメインに属するリソースにアクセスした場合の例を示す。
サンプルとなるネットワークは，Active DirectoryドメインとWindows NTドメインから構成されている。前者はactive.dsl.local.ドメインであり，ドメインコントローラはlily.active.dsl.local.である。lilyは，DNSサーバーとWINSサーバーも兼務している。後者は，NT40DOMドメインであり，ドメインコントローラはWindows NT 4.0 Server（SP6a）を使用したNT40SV-1である。クライアントには，Windows 2000 ProfessionalとWindows NT 4.0 Workstation（SP6a）を使用した。このサンプルネットワークを図示すると，次のようになる。
Fig.5 サンプルネットワークの構成（画像をクリックすると拡大可能）
●Windows 2000クライアントのトレースとその考察
Windows 2000クライアントは，celica.active.dsl.local.という名前であり，Active Directoryドメインに属している。実際にアクセスするリソースは，Windows NTドメインであるNT40DOMに所属するサーバー，NT40SV-1の共有フォルダ「share」である。Windows 2000クライアントのコマンドプロンプトから，「net use * \\nt40sv-1\share」を実行した場合のトレースを，List 5に示す。なお，List 5に示したトレースは，見やすいように筆者によって一部編集されている。
クライアントであるcelicaは，まず接続先のサーバーであるNT40SV-1の名前を解決しようとしている。この作業は，1行目と2行目のパケットに現れている。WINSサーバーであるlilyから，NT40SV-1のIPアドレスを取得したあと，ARPによりMACアドレスを取得し，5行目以降でNetBIOSを利用してNT40SV-1への接続を開始している。SMBでNT40SV-1と通信したあと，Active Directoryドメインのドメインコントローラであるlilyを利用して，Kerberosによる認証を実行している。しかし，NT40SV-1とのあいだにはKerberosの推移的な信頼関係が成立しないため，適切なセッションキーは応答されず，エラーとなっているはずである。
そのあと，NT40SV-1.active.dsl.local.というホスト名の名前解決に失敗すると，すぐにSMBのセッションセットアップを開始している。そして，21行目のパケットでcelicaから共有名「share」への接続が要求されると，NT40SV-1はcelicaが所属するACTIVEドメインのドメインコントローラであるlilyとの通信を開始する。NT40SV-1とlilyとのあいだでRPCによる通信が完了し，信頼関係の結ばれたドメインのユーザーであることが確認されると，NT40SV-1からcelicaの接続要求に対する応答が返っている（38行目）。
 |
9/11 |  |
