Windows 2000ネットワーク解剖
＞
ドメインツリーとフォレスト
Windows 2000クライアントのトレースとその考察
Windows 2000クライアントは，celica.active.dsl.local.というホスト名である。実際にアクセスするリソースは，otherforest.dsl.local.ドメイン上にあるサーバーw2k-5.otherforest.dsl.local.の共有フォルダ「share」である。接続にあたってはWindows 2000クライアントのコマンドプロンプトから次のように実行し，List5のトレースを取得した。
net use * \\w2k-5.otherforest.dsl.local\share
なお，トレースは見やすいように筆者が一部編集していることをお断りしておく。
クライアントであるcelicaは，最初に接続先のサーバーであるw2k-5のIPアドレスを取得するため，1と2でDNSによる名前解決を実施している。そのあと，3と4でARPを発行してMACアドレスを取得し，ICMPで接続先となるサーバーの生存を確認，7〜13でセッションを確立している。
ここまではフォレスト内で自動的に結ばれた信頼関係を利用する場合と変わらないが，ここから先は非常に興味深い結果となっている。
まず，14と15では，自分の所属するドメインのKDCであるlilyとのあいだでKerberosのTGSを要求し，その応答を受け取っている。だが，異なるフォレスト間ではKerberosの認証が推移しないため，otherforest.dsl.local.ドメインのセッション鍵で応答することはできなかったはずである。クライアントであるcelicaは，接続先のサーバーであるw2k-5とSMBのセッションを確立しようとしているが，SMBの通信はSTATUS_MORE_PROCESSING_REQUIREDというメッセージを受け取っている。このパケットの中身をKerberosのパケットと見比べてみるとわかるが，両者の内容はかなり異なる。どうやら，このSMBの通信はNTLM認証を試みようとしているようである。
そのあとクライアントは，再びセッションを確立すべくSession Setupを実行し，IPC$に接続する。そして，実際に共有フォルダと接続するまえに，自分が所属するドメインのKDCであるlilyとのあいだでTGS要求とその応答をやり取りし，Session Setupを実行している（24）。このときも同様に，SMBの通信はNTLMによる認証を試みているようである。Session Setupの応答でSTATUS_MORE_PROCESSING_REQUIREDを受け取ったあと，再びcelicaからSession Setupを実行している（29）。
30以降で，信頼関係を結んだドメインのドメインコントローラ同士の通信が開始される。この通信は，フォレスト間で信頼関係が結ばれている環境でNTLM認証が発生した場合と同じRPCによる通信シーケンスとなっている。つまり，異なるフォレストに存在するドメイン同士の信頼関係では，Kerberosに基づいた信頼関係は使用されていない。本稿の執筆時点で用いたテスト環境の場合，Kerberos以外に使用できる認証方法はNTLMしかない。そのため，この信頼関係はNTLMによって実現されていると判断できる。
30から始まったドメインコントローラ同士のRPCによる通信が47で終了すると，48〜50で，クライアントであるcelicaと接続先となるサーバーであるW2K-5とのあいだで，セッションが確立される。
 |
16/17 |  |
