Microsoft ネットワークを解剖する

第5回「ドメインと認証機構」

前回まででMicrosoftネットワークのトラブルの温床といえる、名前解決とブラウジング機能に付いての解説を終えた。今回はドメインを中心としたMicrosoftネットワーク特有の認証機構とその仕組みについてネットワーク上を流れる通信に焦点を絞って解説する。各種管理ツールの利用方法やドメインの概要等に付いては市販の書籍などを読んで勉強しておいて欲しい。

実際のところ、Microsoftネットワークのトラブルシューティングは、これまでに記述したブラウジングと名前解決の問題に集約されるといっても過言ではないが、コンピュータが*見えない*というブラウジングのトラブルには及ばないものの、ドメインにログオン出来ない、アクセスできないというトラブルも無視できない。
大半の原因は名前解決の問題であるが、その切り分けの過程でドメイン構成を維持している通信に付いての理解も必要な場合が少なくない。特にWindows 95/98とWindows NT/2000が混在した環境では、両者の認証機構の違いを正しく認識していないと、無用の混乱を招く場合が少なくない。
以下、こうした際の切り分けを行なうのに必要な認証機構に関する動作に付いてネットワーク上をどのようなパケットが流れるかを中心に説明を行なっていく。プロトコルとしてはNBTを前提とするが、他のNetBIOSインタフェースを備えたプロトコル(NetBEUI,IPX/SPX)においても全く同様の機構が動作していると考えてよい。
なお、特にドメイン構成での認証については明記してある資料が少なく、今回の記事の執筆は困難を極めた。結論として各パケットの内容に付いて踏み込んだ解説を行っていないのは、そのためである。またパケットの内容に付いて、筆者の推測によるところも大きいことを予めお断りしておく。
以下、Windows NT/2000マシンの場合に付いて説明を行なっていく。ただしWindows 2000がドメインコントローラの場合に構築されるActive Directoryは従来のMicrosoftネットワークの範疇を越える機能であるため、今回のセミナでは対象としない。
また、管理ツールの利用方法や各種用語については、ネットワーキングガイド(注0)などを参照してほしい。

注0: 本記事で単に「ネットワーキングガイド」と記述した場合、Windows NT Server 4.0 リソースキットに含まれる「ネットワーキングガイド」を示すものとする。

基本的な認証の仕組み

セミナ第1回図4で記述したように、Microsoftネットワークにおけるセッション層のプロトコルはSMB(Server Message Block)と称する(注1)、今回取り上げる認証を伴う通信は、すべてSMBプロトコル上で行なわれるため、まずはSMBプロトコルでのセッション(以下SMBセッションと呼称する)を例にとり、基本的な認証の仕組みについて解説していくことにする。

注1: 図4の右側にあるOSIレイヤの記述は、ミスがあり、NBTはTCPと同じく第4層、SMBは第5層である。陳謝するとともに訂正しておく。

写真1はワークグループに所属するマシンSALAMANDER_SV41からマシンMONYO93D に対して、以下のコマンドを発行したときのパケットをキャプチャ結果である。

NET USE Z: \\MONYO93D\TEMP
NET USE Z: /D

写真1: 認証時の動き

(*)このキャプチャは、TCP以外のパケット(ARP等)をフィルタしている。

フレーム1から3までTCPの3wayハンドシェイクがあり(注2)、ついで実際の通信が開始される。フレーム4のSession Requestでは送信元のNetBIOS名(今回はSALAMANDER_SV41<00>)と送信先のNetBIOS名(今回はMONYO93D<20>)が指定されており、これに対して通常はフレーム5のようにPositive Session Responseが返却される。ただし、セミナ初回の冒頭で記述した送信先として指定されたNetBIOS名が登録されていない等の原因で、この時点で写真2のようにNegative Session Responseというエラーが返却されることもある。

注2: TCPレベルの通信については、別途参考書などを参照のこと。

写真2: セッション確立の拒否
Session Requestで指定した宛先NetBIOS名を送信先が登録していないため、フレーム2ではCalled Name Not Present というエラー内容でNegative Session Requestが返却されている。

(*)このキャプチャはNBT以外のパケットをフィルタしている

注: パケットのフィルタリング
前号までは特に明示しないままに、筆者の判断で不要なカテゴリのパケットを適宜フィルタリングしたものを表示していた。
Microsoftのネットワークモニタでは、以下のようにカテゴリ毎にフィルタリングを行なうことが可能である。また下位プロトコルは上位プロトコルを含むため、例えば「NBT以外のパケットをフィルタする」という指示を行なっても、その上位にあたるSMBやBROWSERはフィルタされない。
セミナ第1,2回では主にNBT 以外のパケットをフィルタしたもの、3,4回では、主にBROWSER以外のパケットをフィルタしたものを中心に提示してあるが、実際は写真xx1で示したように、NBT層の通信開始に先立ち、TCPレベルの3wayハンドシェイク等も行なわれている。フィルタを行なう際の代表的なカテゴリを図xx1に示す。

図xx1: フィルタリングのカテゴリ
上位層->

IP |TCP | NBT - SMB - BROWSER
   |UDP |             MSRPC   - NETLOGON
   

図xx1に示した以外にも様々なカテゴリでフィルタが可能であるが、本セミナに関係するカテゴリはこれらがほぼすべてである。またパケットの内容ではなく、「特定マシン間のパケットのみ」といったフィルタも適宜行なっている。
今後キャプチャを提示する場合、どのようなカテゴリのフィルタを行なったものかについて明示する。ただし、関係ないマシンからのパケットを排除するためのフィルタに付いては今後も適宜行なっていくことをご了解頂きたい。
最後になるが、一部の読者の混乱を招いてしまったことは、深くお詫びする。

次いでフレーム6ではnegotiate, Dialectというパケットが送信されているが、これは利用するSMBプロトコルのバージョン(Dialect = 方言)を決定するプロセスである。現在の所、バージョンは写真xx1の下に表示されているPC NETWORK PROGRAM 1.0からNT LM 0.12 まで8種類が選択可能だが(注xx)、最も上位のプロトコルが選択されるため、現在利用されるのはNT LM 0.12だけである。

注xx: 後述するように、Windows 9x系マシンでは、選択可能なプロトコル種類はもっと少ない。

このフレーム中でセッションを要求した側は、写真xx1のように自分が利用可能なプロトコルのバージョンを列挙して送信する。それに対して、フレーム7では「# = 7」という記述でこのセッションで使用するプロトコルを通知する。これは送信されたプロトコルに0から順に番号を付与したとき、7番目のプロトコルを選択したという意味である。従って、写真xx1では8番目のNTLM 0.12 が選択されたということが分かる。
プロトコルバージョンのネゴシエーションが終了すると、フレーム8でユーザ名とパスワード及び接続先のリソース名(ここでは\\MONYO93D\TEMP)の情報が送出され、フレーム9で応答が返却される(注xx)。

注xx: 後述するように、実際はフレーム8では"所属ドメイン"の情報も送信されている。しかし、今回のように接続先がドメインに所属していないマシンの場合は、"所属ドメイン"の情報を用いたログオンが内部的に失敗するため、結果として接続先では、自分のコンピュータ(MONYO93D)上のユーザ(この場合はxxxxx)だとみなして認証を行うことになる。

ここまでで認証部分の通信は完了し、以後フレーム10から15まで、具体的なリソースへの接続作業関連のパケット(TCPのACK(注xx2)を含む)が送受信される。なお接続先のリソース名は、写真xx1のようにユーザが意識して接続を行なおうとしている共有リソースの場合もあるが、システムが内部的に利用する仮想的なリソースの場合もある。 仮想的なリソースとして良く使われるのがIPC$である。 例えば写真xx2のようなマシンの共有リソース一覧を取得する際も写真1と同様の認証が行なわれた上NetShareEnum()関数を呼び出す実際の通信が行なわれるが、この時点ではどの共有リソースとも実際には接続されていない。こうした場合にIPC$が用いられるのである。またIPC$(注xx4)を用いて認証を行なうことが可能な管理ツールも少なくない。他にも様々の仮想的なリソースが存在する。

写真xx2: マシンの共有一覧

注xx4: 詳細については、日経Windows NT1999年1月号P.233からの筆者の記事を参照されたい。

最後に

NET USE Z: /D
が発行されると、フレーム16〜19でセッションの切断処理が行なわれ、最後にフレーム20〜22でTCPレベルの終了処理が行なわれることで、一連のSMBセッションが終了する。
これがファイル共有などの際に用いられるSMBプロトコルを用いた通信の基本的な流れになる。
なお、説明ペインでCから始まっている通信は、呼び出し(CALL)でRから始まっている通信は応答(Response)を表している。覚えておくと解析時に何かと便利であろう。

SMBセッションはマシン単位

ここで注意すべき点としてSMBセッションの認証はマシン単位で行なわれるという点がある。例えば図xx2のようにPC1からPC2に対して、既にUser1というユーザでSMBセッションが開始されている時に、別のセッションではPC2に対してUser2として接続するようなことは出来ない(注xx5)。行なおうとすると、写真xx3のように「既存の資格証明のセットと一致しませんでした」というエラーが発生する(注xx6)。

図xx2:

  PC1               PC2
       --User1-->

       --User2--X

注xx5: ただし既にコンピュータ名を指定して接続しているときに、更にそのマシンのIPアドレスを指定してアクセスすることで、別のユーザとして物理的に同一マシンにセッションを確立することは可能である。

注xx6: J040370 [NT]Err: 入力証明が、既存の資格証明のセットと一致しませんでした も参照のこと

写真xx3:

この問題はATコマンドでジョブを実行した場合や、コラムで説明したように、一時的に管理者権限で接続を行なおうとした場合などに発生することが多い。
逆に一度何らかのユーザで認証されると、SMBレベルでログオフが行なわれるまで、その認証情報がその後そのマシンに対するすべてのセッションで流用される。
これを活用することで管理の効率化を図ることも可能であるため(注xx4)、いろいろ工夫して欲しい。

NULLアカウントとNULLセッション

写真xx1のフレーム8のように、ユーザ名とパスワードを入力することで認証を行ない、実際のリソースに接続するのがSMB接続の基本である。しかし、実際はNULLアカウントという特殊なアカウントを利用することで、パスワードなしで接続することが可能になっている(注xx7)。NULLアカウントを用いて認証されたセッションをNULLセッションと呼ぶ。
写真xx3.5にMONYO93DというマシンからLDというマシンにNULLアカウントを用いて接続を行なった場合のパケットの例を示す。フレーム3,4 がNULL アカウントでの認証要求とその応答になる。

注xx7: 関連するKBとして Q143474: Restrict Information Available to Anonymous Logon Users などを参照されたい。アクセスを禁止する方法に付いても記載がある。

写真3.5: NULLアカウントによる接続

フレーム1,2は写真xx1の通り。フレーム3,4がNULLアカウントによる接続とその応答である。ユーザ名が Username = と空欄になっているところに注意して欲しい。なお、フレーム5,6をみると、\wkssvcという仮想的なリソースへ接続していることが分かる。
(*) SMB でキャプチャを行なっている

コマンドラインからは以下のようにすることで、NULLアカウントでの接続が可能である。一つ目の "" はパスワードが空であることを示し、二つ目の "" はユーザ名が空であることを示す。

NET USE \\MACHINE\IPC$ "" /USER:""
NULLアカウントを用いたアクセスとして代表的なものにはマシンの共有一覧の表示があげられる。Windows NT 4.0 SP3以降ではこの接続を禁止することも可能である(注xx7)が、ユーザからみたサービスは低下する。 前号で述べたブラウズリストの交換をはじめ、NULLセッションは認証情報自体の交換のためのSMBセッションなど各所で用いられている。

認証に関する注意点

認証について何点か補足する。まず基本的なことだが「認証」と「認可」との違いについて理解しておく必要がある。実際のリソースへのアクセス時には、ここで説明した機構により「認証」されたアカウント情報を用いて、リソースへのアクセスが「認可」されているかどうか、具体的にはアクセス権の有無が確認されて、はじめてリソースへのアクセスが行なわれる。認可の機構にも興味深いものがあるが、Microsoft ネットワークと直接の関わりはないため、ネットワーキングガイド等の関係情報を参照してほしい。
また、本来認証時のセキュリティについても語るべきところではあるが、Microsoft の幾重にもわたる場当たり的な対応の結果、このテーマだけで充分1月分の紙面を構成できるだけの内容を持ってしまっているため、今回は「認証」に絞って解説を行うこととし、認証時のセキュリティについては、今後紙面(および筆者の時間)があったら解説することにしたい。

ワークグループと認証

ネットワーキングガイドをはじめとするMicrosoftネットワークに関する話題を扱う書籍や雑誌等ではよく対比する概念として「ドメイン」と「ワークグループ」がとりあげられる。しかし、実際のところ「ワークグループ」は認証とは無関係である。
ネットワーキングガイドを始めとする技術情報で記述されているように、ワークグループ構成をとっている場合、認証は各マシン毎に独自のSAMデータベース(以下SAM)中に格納されたアカウント情報を用いて行なわれる。従って、例えば図xx3のようにWG1とWG2にPC1〜PC4というマシンが所属している場合、PC1のログオンしているユーザがPC2にアクセスすれば、PC2のSAMを用いて認証が行なわれ、PC3にアクセスすれば同様にPC3のSAMが用いられる。認証の際のパケットの動きに関しては前述した写真1の通りである。なお、当然のことだがユーザがPC1自体にログオンする時点では、PC1のSAMが用いられる。
これは、PC1〜PC4が同じワークグループに所属していても、あるいは4台がすべて異なったワークグループに所属していても同様である。

図xx3: ワークグループ構成の例
ワークグループ構成は認証と無関係である。
  ====  WG1  =====
  +-----+    +-----+
  | PC1 |--→| PC2 |
  +-----+    +-----+
   SAM|       SAM
      |
  ====↓  WG2  =====
  +-----+    +-----+
  | PC3 |    | PC4 |
  +-----+    +-----+
   SAM        SAM
   

前号で解説したブラウジング機構により、例えばPC1上でネットワークコンピュータをクリックすると、写真xx4のようにPC1とPC2が一緒に表示される。このため、PC1とPC2に認証上も関係があるかのように誤解されがちであるが、これはあくまでもブラウジング機能という表示上の話である。認証機能においてワークグループという概念はそもそも存在しない。「ワークグループ」とはあくまでブラウジング上の概念なのである。

写真xx4: ワークグループの表示例

ドメイン構成

「ワークグループ」と異なり、「ドメイン」はMicrosoftネットワークの認証において重要な役割を果たしている。ドメイン(注xx10)を一言で言うと、図xx4のようにドメインコントローラ(注xx13)上に保持されるSAMを用いてドメインに所属するマシンにアクセスする際の認証を一元的に行なうシステムであるといえよう。

注xx10: もちろん、ここでいうドメインは、DNSのドメインとは全く関係がない。通常はDNSのドメインと区別する意味で、筆者は「NTドメイン」という呼称を良く使うが、今回はMicrosoftネットワークに特化した話題のため、単に「ドメイン」と呼称する。

図xx4: ドメイン構成

ワークグループ構成では、SAMを個別のマシン毎に保持せざるを得ないため、マシンの数が増えるに従って、SAMの維持管理が困難になって行くが、ドメイン構成ではドメインで保持するSAMを利用して、同一、もしくは信頼関係を結んだドメイン内の各マシンへアクセスすることが可能となるため、ドメインのSAMやLSA(注xx10.5)を維持管理するだけで各マシンへの認証を一元的に管理することが可能である(注xx11)。

注xx10.5: 以下ドメインのSAMと称した場合、LSAとBuiltinというデータベースも含む場合がある。違いについては以下の表を参照して欲しい。
データベース名内容
SAMユーザーアカウント、コンピュータアカウント、グローバルグループ等、ドメインコントローラ以外のマシンに対する認証で利用されうる情報
Builtinローカルグループなど。ドメインコントローラ上での認証にのみ利用される情報
LSA コンピュータアカウント、信頼関係のアカウント、アカウントポリシーなど
なお、本論を大きく外れてしまうため、ここでは詳細についての説明は省略することをご了承頂きたい。

注xx11: 図xx4でも示したが、ドメインに所属するマシンでも、ドメインコントローラ以外はマシン毎にローカルアカウントを作成して、マシン独自のSAMで認証を行なうことも可能である。ローカルアカウントを用いてマシンが所属するドメインのリソースにアクセスする場合は、後述するドメイン外のマシンからのアクセスと同様の認証が行なわれる。

以下、その仕組みについて解説して行こう。

ドメインへのマシンの参加

既にご存知の通り、Windows NTマシンからドメインにログオンしたり、Windows NTマシン上のリソースに対してドメインのアカウントにアクセス権を割り当てたりしたい場合は、そのマシンをドメインのメンバにするため、「サーバマネージャ」等を使ってマシンのドメインへの追加し、追加するマシン上でドメインへの参加という作業を行なうことが必要である(注xx16)。前述した写真xx5を取得する際に利用したマシンも、当然この作業を行なっている。

注xx16: もちろん追加したいクライアントPC 上で直接マシンを追加する権限のあるアカウント名とパスワードを用いて登録することも可能である。

実際のところ、これは実際はコンピュータアカウント(注xx15)の作成とパスワードの設定により該当マシンとドメインコントローラとの間にセキュアチャネル(注xx12)を確立できるようにする作業に他ならない。

注xx12: ネットワーキングガイド等によるとドメインに所属しているマシン同士はセキュアチャネルを用いることで安全に通信をできるという記述がある。しかしこれがなぜ安全か、どのようにして行っているのか等は、筆者もいろいろ調べているが良く分かっていない。

注xx15: マシンアカウントともいう。Microsoft の技術情報を見ていると英文では machine account と書かれているものが多いが、日本語では コンピュータアカウント となっているものが多い。

サーバマネージャでコンピュータを追加することにより、SAMにコンピュータアカウントが追加される。このアカウントは「コンピュータ名$」という名前であり、ユーザ属性として特殊なフラグを持つことで、一般のユーザとは識別されている(注xx17)が基本的にはユーザアカウントと同じアカウントであることに変わりはない(注xx17.5)。

注xx17: ADSIでは UF_WORKSTATION_TRUST_ACCOUNT(0x1000)という属性で参照できる。

注xx17.5: 従って、一度コンピュータアカウントを削除してしまった場合は再度同じ名前のアカウントを再作成しても同一とは見なされないため、マシンのドメイン参加の手続きを再度やり直す必要がある。

マシンがドメインにはじめて参加するときは、コンピュータアカウントのパスワード設定など、セキュアチャネルの構築に必要な各種設定が行われる。
参加する際の通信の詳細は省略するが、基本的にはドメイン名<1C>に対して、Query for Primary DC というパケットを送付することで、PDC マシンのコンピュータ名を知り、PDCに対して接続後、コンピュータアカウントのパスワードをランダムな文字列に変更する作業を行う。
コンピュータアカウント作成時点のパスワードはあるロジックによって一意に設定される(注xx18)ため、コンピュータアカウントを作成したままにしておくと、悪意を持つものがそのコンピュータ名のマシンから参加作業を行うことで簡単にドメインに参加できてしまう点に注意して欲しい。

注xx18: Sambaの実装をみるとどのようなパスワードかも明白であるが、本論とは無関係な為、ここでは伏せさせて頂きたい。

一度ドメインに参加すると、以後はマシン起動時に自動的にコンピュータアカウントを用いてドメインコントローラへのログオンとセキュアチャネルの構築が行われるようになる。ドメインメンバであるマシンMISAKOの起動時のパケットをキャプチャしたものを写真xx6に示す。なおネットワーク構成などは図xx5のようになっている。また特に注記しない限り、すべてのマシンはWINSクライアントである。

図xx5:
  ドメイン: TEST
  MISAKO(ドメインのメンバ) -+- [router] -- TOMOYO(PDC)
                            |
  MAYUKA(BDC) --------------+ 
写真xx6:

ネットワーク構成などは図xx5を参照のこと。

フレーム1ではドメイン名<1B>に対して、PDCのコンピュータ名を問い合わせ、4,5では応答が返却されるが、これらは利用されない。実質的な認証はフレーム2のTEST<1C>に対するブロードキャスト(注xx19)にフレーム3で応答したMAYUKAによって行われる。
このドメイン名<1C> はインターネットグループ名(コラム参照)という特殊なNetBIOSグループ名であり、応答としてドメインコントローラのIPアドレスのリストが返却されるが、ここではMAYUKAしか存在しないため、MAYUKAのアドレスのみが返却される。
なお、ログオンに必要な NetBIOS 名は、ここで登場したドメイン名<1C>および各ドメインコントローラのコンピュータ名<00>とコンピュータ名<20>の解決のみであり、ブラウジング機能が正しく動作しているかどうかは無関係である。

注xx19: 技術文書によると、ローカルセグメントのドメインコントローラによる認証を保証するため、WINS 等で ドメイン名<1C> が解決可能であっても、常にブロードキャストが先に行われる。

コラム: インターネットグループ名

本セミナの第1回で、NetBIOS 名についてはユニーク名及びグループ名が存在すると説明した。しかし、実際はもう一つ、インターネットグループ名という特殊なグループ名が存在する。このグループ名の特徴は、常にブロードキャストで名前解決が行なわれる通常のグループ名とは異なり、WINSデータベースに情報が格納され、問い合わせに対してはIPアドレスのリストが返却される点である。これによってグループのメンバとして様々なセグメントに所属するマシンを参加させることが可能になっている。
既にお気づきの通り、もともと単一セグメントでブロードキャスト通信が前提だった時代に作られたNetBIOSグループ名の概念をTCP/IPに対応させるにあたり、いわゆるNetBIOSグループ名は同一セグメント内へのブロードキャストを行なう仕様にしてしまったため、必要となった概念である。
なお仕様上はユーザで任意のインターネットグループを作成可能なはずだが(注xx14)、実際に利用しているところはまずないであろう。

注xx22: 筆者も動作を確認していないが、LMHOSTSで #SG キーワードを用いたり、WINSサーバの静的グループでインターネットグループを作成することで作成が可能なことは確認している。

フレーム6ではMISAKO$というコンピュータアカウントを利用してTEST<1C>に再度SAM LOGON request from clientを行っている。しかし、ここではMISAKO$ のコンピュータアカウントの情報がMAYUKAに複製されていなかったため、TOMOYOに転送され、TOMOYOからフレーム7,8で応答されている(注xx)。

注xx: この転送処理に付いては後述する。

この後、フレーム18から25でドメインが保持する信頼関係などの確認が行われ、フレーム30から35でMISAKO$のパスワード情報を用いてセキュアチャネルの確立が最終的に行われているようである。なお、フレーム35の後は、今まで説明したNetBIOS名の登録などの処理が行われていた。

コンピュータアカウントのパスワード

ここまで説明したように、コンピュータアカウントにもパスワードが存在する。これは前述したようにマシンのドメイン参加時にランダムな値に変更された後も、セキュリティの為にデフォルトで1週間に1回ずつ変更される(注xx20)。

注xx20: このパスワードの変更に関しては、各マシンが、PDCと直接通信を行なう必要はなく、変更を行なうマシンがBDCと通信を行なうことで、BDC がPDC に対して変更要求を送信するようである。パスワードが変更されるとSAM が更新されるため、最終的にはPDCからBDCに変更情報が複製される。このため、最終的にはPDCに対する通信が発生することには変わりないが、各マシンでPDCの名前解決を行う必要はない。

なお、この変更を停止することも可能である(注xx21)。Microsoftはセキュリティ上推奨していないが、コンピュータアカウントのパスワードだけを頻繁に変更しても、ユーザのパスワードを変更しないのであれば、セキュリティ上の効果はあまりない。トラヒック削減等のメリットもあるので、場合によっては実施を検討してもよいであろう。

注xx21: 方法に付いては、J043619: [NT] ドメインでのコンピュータアカウントの複製による影響 を参照して欲しい

この通信は、手動で発生させることができないため、キャプチャすることができなかった(注xx)。

注xx: 技術情報などを見る限り、NULLセッション上でNetrServerPasswordSet()というMSRPC通信を行うことで変更されるようである。

ドメインへのログオン

ドメインにマシンが参加する仕組みについて理解したところで、次にドメイン構成におけるユーザ認証について確認して行く。
まずはマシンのログオンダイアログからのユーザのログオン時にどのような通信が行なわれるのかを確認しよう。
写真xx5にドメインTESTのメンバであるMISAKOからドメインTESTにUser2というユーザでログオンした際のパケットをキャプチャしたものを示す。

写真xx5:

(*)なおこのキャプチャはNBTでフィルタリングを行なっている。

筆者が調査した限り、まず前述したSMB認証の前にセキュアチャネル(注xx12)を用いてアカウントの認証が行われるようである。セキュアチャネルの通信自体は前述したNULLセッションを用いて、認証を行ったドメインコントローラ(今回はMAYUKA)のコンピュータ名<20>に対して行われる。このNULLセッションはログオン時点で存在すればそれが利用され、存在していないときは新たに作成される。

注xx13: 単に「ドメインコントローラ」と記載した場合は、PDCおよびBDCのいずれか、もしくは両方が含まれる。

ここではフレーム23,24で既に確立されたNULLセッションを用いてアカウントの認証が行われている。フレーム25〜28でNULLセッションの切断が行われてから(注xx14)、フレーム29からSMB認証が開始される。なおNBTレベルの接続は、既にNULL セッションで確立されているものがそのまま用いられている。

注xx14: 筆者が確認した限りNULL セッションがこのタイミングで切断される場合とそうでない場合があった。理由は不明である。

認証の確立後に、フレーム31でシステムポリシーファイルntconfig.polへのアクセス、フレーム33から38でログオンスクリプト(ここではlogin.batと指定した)へのアクセスを試みているが、いずれもファイルは作成していないためエラーになっている。
フレーム39から42まではログオフ時の動作であり、SMBセッションのログオフと、セキュアチャネルのログオフを行っている。
なお、ユーザプロファイルを利用する際は、ポリシーファイルへアクセスする前に、ntuser.man、ntuser.datへのアクセスが順に行われ、更に認証完了後に、プロファイルを構成する各種データ(Application Data 等)へのアクセスが行われる。

リモートマシンからアクセスとパススルー認証

次に、ドメインのメンバとなっているマシンのリソースに対して別のマシンからアクセスがあった時の認証における通信に付いてみていこう。
以下<ドメイン名>\<ユーザ名>形式のアカウント表記を多用するが、これは広く使われているにも関わらず、正式な名称はないようであるため、説明の便宜上ここでは"完全ユーザ名" と表記することにする(注xx)。

注xx: 正式な名称があったら、御教授頂けると幸いである。

まず、ドメインにログオンしたユーザがリモートマシンにアクセスするときの通信に付いて確認しよう。写真xxは写真xxに引き続いて、MISAKOと同じセグメントにいるTEST ドメインに所属するYUKAKOというマシンにTEST\User2でログオンしてNET USE Z: \\MISAKO\TEMP を行った時の結果の一部である。なお、実際はTEST ドメインのマシンにログオンせずに、別のマシンから

NET USE Z: \\MISAKO\TEMP /USER:TEST\User2
のように完全ユーザ名を指定してアクセスを行っても同じである(注xx)。

注xx: /USER オプションで単に /USER:User2 のように指定した場合は、ドメインに所属しているマシンでは所属ドメイン名、スタンドアロンマシンではコンピュータ名が自動的に付加される。

よく誤解されていることがあるが、このように明示的に完全ユーザ名を指定すれば、アクセス先のサーバが所属しているドメインに所属していないマシンからでも、パスワードさえ知っていれば簡単にアクセスが可能である。従ってドメインに参加したからと言って、セキュリティが直接的に高まるものではないことは認識しておく必要がある。ユーザ情報の一括管理やドメインのユーザに対するアクセス権の付与などによる管理性の向上により、間接的にセキュリティが高まるとは言えなくもないが、ドメインのユーザ名とパスワードさえ知っていればドメイン外のマシンからでも接続自体は可能なのだ。

写真xx:

(*)NBTでフィルタを行っている。なおこのキャプチャ取得時にはBDCのMAYUKAが事情により存在していないため、TOMOYOが認証を行っている。

フレーム32のC session setupについて、MISAKOはドメインコントローラのTOMOYOにフレーム33でNetrLogonSamLogonという認証要求を行い、フレーム34の返却内容を確認してから、フレーム35でYUKAKOに結果を返却している。なおフレーム33,34の通信は、通信発生時点で既にセッションがあればそれが利用され、なければNULLセッションが新たに作成され、そこで行われる。このように、ドメインのメンバとなっているマシン上で認証が発生した場合は、通常必ずドメインコントローラに問い合わせが行われている(注xx)。これは一種のパススルー認証と言える。
もっともユーザ名をMISAKO\<username> のように表記してMISAKO 上のアカウントで認証することを明記すれば、ドメインコントローラへの問い合わせは行われない。この理由に付いては後で解説する。

ドメイン名の置き換え規則

では、認証時の完全ユーザ名の"ドメイン名"がMISAKOでもTESTでもなかった場合はどうなるのであろうか?
この場合は、まず <ドメイン名>\Username という完全ユーザ名でパススルー認証が行われる。しかしこれは必ず失敗するため(注xx)、次に<アクセス先のコンピュータ名>\Username という完全ユーザ名で認証を試みる。但しこの認証はパススルーされないため、ローカルアカウントとしてUsername に合致するアカウントが存在すればパスワードが合致していれば認証が成功し、そうでなければ通常パスワードを入力するダイアログが出てくることになるが、アカウントが存在しないと認証に失敗することとなる。

注xx: 信頼関係にあるドメインのアカウントだった場合は、後述するように、そのドメインに対してパススルー認証が行われる。

なお、ドメインのメンバではなくドメインコントローラの場合は、自分のSAMで処理を行うため、パススルー認証のパケットは通常発生しないが、BDCは自分のSAMに合致する完全ユーザ名が存在しないとPDCにパススルー認証を行う(注xx)。

注xx: これはPDC とBDCの整合性がとれていない場合の為の措置であり、詳しくは後述する。

また、ドメインコントローラに対して自身が所属しているか、信頼しているドメイン名(注xx)以外がドメイン名に指定された完全ユーザ名での認証要求があった時は、単に<自ドメイン名>\Username という完全ユーザ名で認証を試みる。 完全ユーザ名での認証に失敗した場合にドメイン名部分を適宜置き換えて認証を試みるというこの仕様は、認証要求時にドメイン名の情報を送信できない過去のクライアントとの互換性を保つためのもののようであるが、今となっては、この仕様が認証時の動作を混乱させてしまっていると言わざるを得ないであろう。

ドメイン名と認証

先程、MISAKO\<username>という完全ユーザ名で問い合わせるとドメインコントローラへの問い合わせが行われないと記述したがこの理由について少し説明しておきたい。まずは写真xxを見て欲しい。

写真xx:

これは写真xxの環境において、YUKAKO上から

NET USE Z: \\MISAKO\TEMP /USER:MISAKO\LMONYO
と指定した時のC session setupパケットの内容である。MISAKOはコンピュータ名であってドメイン名ではないにも関わらず、SMB Domain name に MISAKO と入っていることに注意して欲しい。
実はここはドメイン名ではなく認証コンテキスト名とでも称するのが実体に近い。
図xxをみて頂きたい。

図xx:

  TEST
    Administrator
    Guest
    User1           ----- TOMOYO
    User2                 MAYUKA
    ...

  MISAKO
    Administrator
    Guest           ----- MISAKO
    LMONYO
    User1
    ...

  YUKAKO
    Administrator   ----- YUKAKO
    Guest
    ...

前述したように、MISAKOやYUKAKOはTESTドメインのメンバであるが、図のようにローカルにもSAMを保持しているため、例えばMISAKOのローカルアカウントとTESTドメインとに同時にUser1というアカウントを作成することが可能である。完全ユーザ名中の「ドメイン名」は、このUser1がどこのSAMに格納されているかを示すと考えると分かりやすい。従って、MISAKO\User1と記述すれば、MISAKO(これだけではドメインか単体のマシンかは本来特定されない)に格納されているSAM中に存在するUser1という名前のアカウントを指していることになる。TEST\User1も同様である。 MISAKO は実際にはドメイン名でなくコンピュータ名の為、MISAKO\User1の情報はMISAKO上のSAM に格納される。それに対して、TESTは実際にはドメイン名のため、TEST\User1の情報はTESTドメインのドメインコントローラ(TOMOYO,MAYUKA)上のSAMに格納されるが、違いは格納先が1台のマシンか、ドメインコントローラという役割の複数マシンかの違いで、本質的にはMISAKOとTESTは同じ層の概念であると理解して頂けたことと思う。 実際、ドメインコントローラにはマシン固有のSAM がなく、TOMOYOとMAYUKAは本質的に同じSAMを保持している(注xx)のはご存知のことと思う。

注xx: 同期のタイミングによっては内容にずれが発生することもあるが、最終的には同期されることになる。

信頼関係とドメインへの参加

もちろん同じ層の概念であるということは、同一の概念であることではない。実際Windows NT/2000マシンは、ドメインに参加することでドメインのSAMに格納されたアカウントに対してマシンのリソースに対するアクセス権を割り当てたり、マシンのログオンダイアログで直接ドメインのアカウントを用いてログオンすることが可能になるが、逆を行うことはできない。
ところで、これを冷静に考えてみると、ドメインに参加するという言葉は、マシンがドメインを「信頼」するという片方向の信頼関係を結んだという言葉に置き換えてみると分かりやすい。
実際、マシンがドメインに参加している状態で、ドメイン上のコンピュータアカウントを削除すると、「プライマリドメインコントローラとの信頼関係に失敗しました」というエラーが発生する。
別のドメインを「信頼」することで別のドメインのアカウントに対してマシンのリソースに対するアクセス権を割り当てたり、マシンのログオンダイアログで直接別のドメインのアカウントを用いてログオンすることが可能になるが、これと本質的には変わらないということである。
理解の難しい仕様として、ドメインコントローラのローカルグループを用いて、ドメイン内のマシンのリソースに対するアクセス権を割り当てることが出来ない理由も、これで説明が付くのではないか。これは信頼しているドメインのローカルグループを用いて、自ドメイン内のリソースに対するアクセス権を割り当てることができないのと同じ理由なのである。
なお、信頼関係の維持とドメインへの参加の維持すなわちコンピュータアカウントの維持も全く同様の方法で行われているといってよい。信頼関係とマシンのドメインの参加は本質的に同じことなのである。

信頼関係

ここまでの説明を理解した方であれば、信頼関係とは、ドメインのメンバとドメインコントローラとの間で暗黙的に結ばれている関係をドメイン間で明示的に結んだものであるという説明で理解して頂けると思う。
信頼関係もマシンアカウントと同様に「ドメイン名$」という特殊なアカウントにより維持され(注xx)、このアカウントのパスワードもコンピュータアカウントのパスワードと同様に、デフォルト1週間毎に変更される(注xx)。

注xx: 詳細は J029889: [NT] ドメイン間の信頼アカウントパスワード や Q145697: HOWTO: Manage Trusted Domains Programmatically in Windows NT を参照して欲しい。

なお、コンピュータアカウントと異なり、アカウントの初期パスワードは手作業で設定する必要があるが、信頼関係締結時にランダムに変更され、以後はコンピュータアカウントのパスワードと同様に定期的に変更される。

ドメイン間のパススルー(pass-through)認証

明示的に信頼関係が結ばれている時に、認証要求が行なわれたマシンから別のマシンへパススルー認証が行われた際、どういう通信が行なわれるかも見ておこう。 写真xx は図xx のような環境で、GREEN にWATER\User1 でログオンし、以下のようなコマンドを発行したの通信をキャプチャしたものである。

NET USE Z: \\SOLDIER\TEMP

図xx:

GREEN - WATER メンバ                   SOLDIER - EARTH メンバ
  (User1 でログオン)
  192.168.1.2/24                       192.168.2.2/24

1ST-SERVANT -WATER PDC                 D-ANGEL - EARTH PDC
192.168.1.3     <-双方向信頼関係->     192.168.2.3
写真xx:

SOLDIER はEARTHドメインのメンバであるため、フレーム7で送信されて来たWATER\User1の認証をEARTH ドメインのPDCであるD-ANGELにフレーム8でパススルーしている。D-ANGELはWATERドメインが信頼関係にあるドメインであることを認識しているため、フレーム9で、更にWATERドメインのPDCである1ST-SERVANTにパススルー認証を行っている。
フレーム10から12まで認証の依頼とは逆の経路を辿って認証結果が返却されている。

ドメインコントローラの役割と複製

写真xx5の例ではBDCのMAYUKAから認証を受けていたが、このようにクライアントがログオン時に認証を受ける際にはドメインコントローラの役割による違いは基本的に存在しない。
しかし実際には既に良く知られているように、ドメインコントローラにはPDCとBDC があり、SAMのマスタを保持するPDCに対し、BDCはPDCからSAMの複製を受け取ることで機能している。以下この仕組みについて説明する。

複製が行われる契機

複製は、以下のような契機でPDCとBDCのSAMの内容(実際はWINSの複製と同様にバージョンIDで判断される)が一致しているかどうかの確認がPDC上で行なわれ、内容に差異があった場合に発生する。

  1. PDCが一定期間(デフォルト5分)毎に行なうチェックでSAMに変更点が存在し、同期要求が通知された場合
  2. PDCが一定期間(デフォルト)毎に行なうBDCへの同期要求が送信された場合
  3. BDCのNetlogonサービスが起動した場合
  4. ユーザが手作業で同期を行なった場合
  5. LSA データベースの内容が変更された場合
1はPDCによる定期的なチェックである。PDCデフォルト5分(注xx)毎にSAMが更新されたかどうかを確認する。更新が行われた場合は、SAMの更新が必要なBDCの中から一定数(注xx)を選択してSAMの同期を開始するように要求を行なう。なお、実際の更新はBDC側から通信が開始されるプル型の形態をとる。

注xx: この値はHKEY_LOCAL_MACHINE\CurrentControlSet\Services\Netlogon\Parameters にある DWORD: Pulseというレジストリの値で変更できる。

注xx: 1回のPulseで送信するBDCの数はHKEY_LOCAL_MACHINE\CurrentControlSet\Services\Netlogon\Parameters にある PulseConcurrencyというレジストリの値で制御する。

2もPDCによる定期的なチェックである(注xx)。このタイミングではSAMの更新の有無に関わらず、BDCに対して同期要求が送信される。

注xx: この間隔はHKEY_LOCAL_MACHINE\CurrentControlSet\Services\Netlogon\Parameters にある DWORD: PulseMaximumというレジストリの値で変更できる。

3は言うまでもないであろう。4 は例えばサーバマネージャの[コンピュータ]から[ドメインコントローラと同期]を選択した場合である。 写真xxに実際に同期が行われた際に実際に情報が送受信されている部分のキャプチャを示す。なお写真xx はユーザのパスワード変更を行ってから、サーバマネージャでMAYUKAを選択した状態から[ドメインコントローラと同期]を行ったものである。

写真xx:

(*) これはNBT以外をフィルタしている
実際は、この前後にセッションの確立等様々な一連のパケットがやりとりされている。

フレーム169のNetrDatabaseDeltas()に対し、フレーム172でPDC のTOMOYOから応答がある。なお、同期が完了すると、BDC 側のイベントログに写真xxのようなログが発生する。

写真xx:

なお、5のLSA データベースの変更が行われた場合、即座に同期要求が行われる(注xx)。これはLSA データベースはドメインのセキュリティを維持するのに重要な情報であると考えられているため、不整合な状態を早急に解決する為である。通信自体は写真xxと同様のものが行われるが、写真xx のようにAnnounce Change to UAS or SAMというパケットが事前に送付される点が異なっている。

写真xx:

注xx: ただしコンピュータアカウントの情報(パスワードなど)変更についてはWindows NT 4.0 SP4以降で即座に同期要求はされなくなった。詳細は Q175468: Effects of Machine Account Replication on a Domain を参照して欲しい。

差分更新と完全同期

SAMの複製は基本的に差分更新であるが、場合によっては完全同期が必要な場合もある。この仕組みに付いて解説しよう。
通常PDCは64KBの大きさのリングバッファ(注xx)に更新情報を書き込んでいく。リングバッファのため更新情報がバッファの容量を超過した場合古い更新情報が破棄されることになる。BDCは通常更新情報が破棄される前に、PDCとSAMの同期を行えるため、更新情報を確認して差分だけの転送を行うことができるわけである。しかし何らかの理由で確認すべき更新情報が破棄されてしまった場合は、完全同期が必要となるのである。また手作業で完全同期を行うことも可能である(注xx)。

注xx: このバッファのサイズはHKEY_LOCAL_MACHINE\CurrentControlSet\Services\Netlogon\Parameters にある DWORD: ChangeLogSizeというレジストリの値で変更できる。

注xx: NET ACCOUNTS /SYNC コマンドを利用する。

PDC 特有の役割

このように複製によりPDCとBDCのSAMの内容は整合性が保たれるため、通常クライアントがPDCに接続する必要はない。しかしPDCには特有の機能があり、基本的にドメインを維持して行くためにはすべてのクライアントはPDCに接続できる必要がある。以下それについて説明する。

複製のタイムラグとログオン

複製は一定間隔毎に行なわれるためSAMを更新した場合には、一時的にPDCとBDCとの間でSAMの不整合が発生する。これに対処するため、BDCで認証に失敗した場合には、BDCからPDCに対してパススルー認証が行なわれるようになっている。
写真xx5 の説明中でこれについては既に触れている。

SAMの更新

先程から述べているように、SAMのマスタはPDCが保持しているため、SAMを更新する作業を行なう際には、基本的にPDCに直接接続することが必要である。SAMを更新する代表的な処理としてはユーザのパスワードの更新がある。

PDC に接続しない運用

このように通常はSAMを更新するため接続が必須のPDCだが、逆にSAMを全く更新しない運用を行なえば、PDCに接続しない運用も可能である。具体的にはユーザ、グループの追加、削除もとよりパスワードの更新も行なわず、グループのメンバの追加なども行なわず、更に後述するマシンアカウントやそのパスワードの変更も一切行なわない運用を行なえば良い。一言でいうと「ユーザマネージャ」や「サーバマネージャ」を利用しない運用といえばよいであろう。
セキュリティを考えれば決して勧められる構成とは言えないが、Kiosk端末等を運用する場合などでは一考の価値はある。

Windows 9x の認証機構

ここまで Windows NT マシンの認証機構について説明を行ってきたが、これまでの場合と同様、Windows 9x マシンは Windows NT/2000 マシンとは様々な点で異なっている。以下 Windows NT/2000 との差異に付いて説明する。
なお以下確認は、図xx5のネットワークのMAYUKA側のセグメントにWindows 98のYUI というマシンを追加した構成で行っている。また全てのマシンは特に断らない限りWINSクライアントである。

ドメインの認証とセキュアチャネル

まず、注意する点として、Windows 9x マシンにコンピュータアカウントによる認証機構が存在しないため、決してドメインのメンバになることはなく、セキュアチャネルも構築されない点があげられる。
実例として、Microsoft ネットワーククライアントのプロパティでWindows ドメインにログオンするをチェックし、Windows NT ドメインに TEST を設定したWindows 98 マシンYUIを起動後、TESTドメインに存在するアカウントmonyoでログオンし、NET USE Z: \\MISAKO\TEMPを行った時のパケットキャプチャを写真xxに示す(当然 \\MISAKO\TEMP は存在している)。

写真xx:

(*) NBT でフィルタリングを行った上、ブラウジング関連の名前登録や、Host Announcement パケットをフィルタしている。

フレーム1,2 でTEST<00>の名前解決を行った上で、フレーム3でログオン要求をブロードキャスト、フレーム4で同一セグメント内のMAYUKAが応答している。なおここには記載していないが、MAYUKA が存在しない場合は、TEST<1C>に含まれるドメインコントローラ(ここではTOMOYO)に認証要求を送出する。
ここではMAYUKAが認証サーバのため、フレーム5,6でWINSサーバ(WINSSRV)にMAYUKA<20>の名前解決を行ってから、フレーム7から16までログオン認証を行っている。なお、フレーム10では # = 5 となっており、冒頭に紹介したWindows NT同士の場合と異なっているが、これはフレーム9でWindows 98側が提示したプロトコル数がWindows NTの場合より少ないためであり、結果として選択されるのはNTLM 0.12である点に違いはない。
注目すべきは、次のフレーム16,17でTEST<1B>(PDC)の名前解決を行ってから、以後フレーム18から39まで、\\TOMOYO\NETLOGON にある CONFIG.POL というシステムポリシーのファイルを読み出そうとしている点にある。このようにデフォルトではWindows 9xマシンは必ずPDC上のシステムポリシーファイルを読み出そうとする仕様になっている(注xx)ことは注意しておく必要がある。

注xx: この対応策は Q197986: How to Configure Windows 95 Policies with Load Balancing を参照のこと

フレーム40,41で認証を行ったMAYUKAとのセッションが切断され、次のフレーム42からは NET USEコマンドの入力により発生したフレームになる。みての通り、ドメインメンバのWindows NTマシン同士の通信の際に発生したセキュアチャネルのやりとりはなく、あくまで通常のSMBセッションの接続が行われる。
つまり、Windows 9xマシンはログオン時にドメインの認証を受けるように構成した場合とそうでない場合の違いは、ログオンダイアログで入力したユーザ名とパスワードをどこで認証するかだけである。ログオン後に各種リソースに接続する際はいずれにしてもログオン時に用いたユーザ名とパスワードが用いられるが、これはドメインで認証を行う設定にした場合でもそうでない場合でも全く同一のロジックで認証が行われるのである。

認証時に用いるユーザの制限

また Windows 9x ではリモートマシンのリソースに接続する際に、ログオンしたユーザ以外のユーザとして認証を行なうことが出来ないという制約が存在する。Windows NT では例えば NET USE コマンドの /USER オプションで認証に用いるユーザを指定することができるが、これに相当する機能が実装されていないのだ(注xx)。従ってリモートマシンが共有レベルのセキュリティのWindows マシンでない限り、現在ログオンしているのと同一名のアカウントによる認証ができないとアクセスすることが出来ないことになる。この制限のため、前述したドメインのメンバ上のリソースへの接続がどのようにしても行なえない場合が存在する(注xx)。

注xx: これはOSレベルの仕様であり、WNetAddConnection2() 等のAPIを直接用いてもこの制限は解除できない。

注xx: 日経Windows 2000 XX月号 P.xxx でこの問題についてのQ&A を行なっているので、参考にして頂きたい。

Windows 9x サーバの認証機構

Windows 9x をサーバにした場合はWindows NTとは異なり、デフォルトで「共有モード」のセキュリティという認証機構で構成され、共有毎にパスワードによる管理を行なうことしか出来ない。Windows 9x は独自のSAMを持たないため、単独ではユーザ単位での認証を行なうことが出来ないためである。
ただし、ドメイン、別のNTマシンやNetware サーバに認証を委託することで、「ユーザモードのセキュリティ」という認証機構も利用可能である。認証を委託されるサーバは、Windows NT Workstationでも可能である。この場合そのWindows 9xの共有に対して認証要求があったときは、パススルー認証が行われ、認証サーバに対して通信が行われる(注xx)。

注xx: ユーザレベルのセキュリティを構成する方法に付いてはWindows 98 リソースキットのP.xxx 等を参照して欲しい。

以下、Windows 98マシンのYUIをユーザレベルのセキュリティとして構成し、認証先としてTESTドメインを指定して起動し、直後に\\YUI\TEMPという共有にNADESIKOという別ワークグループのマシンから接続を行ったところである。なお本論とは直接関係ないがYUIはBノードとして構成されている。
YUIは起動直後にフレーム1,2でTEST<1C>の名前解決を行った後、フレーム3から6で認証先の存在(MAYUKA)を確認している。フレーム7でNADESIKOから NET USE \\192.168.10.208\TEMP(192.168.10.208 はYUIのIPアドレス)という通信が開始され、SMBセッションが開始される(注xx)。ここで注意すべき点は、フレーム13の後、フレーム14から21まで、認証先であるMAYUKAとNULLセッションを確立してから、フレーム22でフレーム13に応答している点である。
この後、フレーム25のユーザmonyoによる認証要求に対して、フレーム26から31まで、MAYUKAとの間で認証や所属グループ名などの情報のやりとり(フレーム28,29)を行った後で、フレーム32でNADESIKOに応答している。フレーム33以降は実際のファイルアクセスになるので省略するが、ユーザレベルのセキュリティの場合は、このようにして何かアクセスがある度に認証サーバと通信を行って認証の解決をしていくことになる。

写真xx:

(*)NBT でフィルタした上で、起動時の名前登録やブラウジング関連のパケットも排除してある。

注xx: フレーム7で一回*SMBSERVERという疑似的なNetBIOS 名を宛先に指定して通信を開始しているが、フレーム8で拒否されたため、フレーム9で改めて*<00...(15)>を宛先にしている。第1回の原稿執筆の時点で筆者の理解が不十分であったが、*SMBSERVER を宛先に指定するのがCIFSに則った通信方法であり、*<00...(15)>は更に古い形式のIP アドレス指定UNCによる通信の表現方式であった。陳謝するとともに訂正しておきたい。

今回のまとめ

Microsoftネットワークの認証機構については、セキュリティの保持という大義名分のためか詳しいことがほとんど明らかにされていないようであり、今回の記事執筆にあたってはまとまった資料がなく、今までの中でも最も苦労した。しかも語るべき事は非常に多く結果として詰め込みすぎの構成になってしまったことは否めない。
次回は、少し指向を変えて、トラヒックのチューニングの観点から、ISDN回線などにおけるWANトラヒックのチューニングに付いて考えてみたい。

注記・補足

  1. 本文書は、日経オープンシステム 2001 年 1 月号の「オープンセミナー」に掲載された「Microsoft ネットワークを解剖する 第5回「ドメインと認証機構」の草稿を有志の方に HTML 化していただき掲載しているものです。
  2. 本連載を元にして、「アンドキュメンテッド Microsoft ネットワーク」を出版しておりますので、併せてご参照ください。
  3. 元々の原稿では、紙面が限られていたため、「注」を多用していますが、HTML 化に伴い、本来「注」にする必要のないものについては、本文中に戻しました。

Copyright (C) 1998-2009 TAKAHASHI, Motonobu
Last update: 2006-07-12 00:00:19 JST
webmaster@monyo.com