図9　WindowsマシンがほかのWindowsサーバーの共有フォルダへアクセスするまでの流れ 実際には，図のように（a），（b），（c）の3段階のステップを経て，共有フォルダへアクセスする。

同じサーバーならログインは1度だけ

　図8ではローカル・ディスクへアクセスするとき，WindowsXPがアクセス・トークンとセキュリティ・ディスクリプタと比較した。これがネットワーク経由になると，もう一つ別のしくみが加わる。その流れを図9[拡大表示]を見ながら追っていこう。

　まず，ユーザーはクライアントになるWindowsXPマシンへユーザー名とパスワードを入力してログインする（a）。このユーザー名とパスワードは，ユーザーがログアウトするまで，WindowsXPが覚えている。

　次にログインしたユーザーが，ネットワーク上のほかのWindowsXPマシン（図9ではサーバー）の共有フォルダへアクセスするとしよう（b）。このとき，クライアントはサーバーのユーザー認証を受けるために，記録していたユーザー名とパスワードを送る。

　これを受信したサーバーは，自身が持つユーザー管理情報（ユーザー名とパスワードの対応表）と比較して（bの(2)），一致すればそのユーザーのアクセス・トークンを作っておく（bの(3)）。さらに，サーバーはこのアクセス・トークンと1対1に対応する「UID」というユーザー識別子を作成し，UIDとアクセス・トークンの対応表に記録もしておく（bの(4)）。

　そして，サーバーはアクセス・トークンの代わりに，このUIDをクライアントへ返信する（bの(5)）。これでクライアントはサーバーに認証されたことになる。

　これ以降，クライアントはサーバーへアクセスするたびに，受信したUIDをIPパケットに入れる。サーバーはUIDからユーザーのアクセス・トークンがわかり，セキュリティ・ディスクリプタと比較できるしくみだ（c）。

　また，クライアントは同じサーバーの別の共有ディスク（図9（c）の例ではフォルダB）へアクセスする際にも，UIDを入れたパケットを送信するだけですみ，ユーザー認証を最初から受ける必要はない。

　ただし，UIDはサーバーが独自に管理する。このため，ほかのサーバーへアクセスするときは，ユーザー名とパスワードを送って認証を受けて別のUIDを取得しなければならない。

　なお図9(b)の(5)で，サーバーがアクセス・トークンそのものではなく，UIDを返信するのは，送受信データを小さくするためのようだ。アクセス・トークンにはユーザー自身のSIDのほか，ユーザーが所属するグループのSIDがすべて入るので，所属グループが増えればアクセス・トークン自体のデータ量が大きくなる。データ量の小さいUIDを使えば，クライアントがUIDとアクセス要求内容などを1パケット中に収めて送信できる。

クライアントはドメインでも同じ

図10　ドメインがあると，サーバーはユーザー認証をドメイン・コントローラに任せる 図9（b）の部分は，ドメインがあるとこのように流れが変わる。要は，ユーザー名とパスワードからユーザーを認証する部分だけをドメイン・コントローラが代行する。なお，図9の（a）や（c）の部分は，ドメインがあっても変わらない。

　ではドメインがあると，どうなるだろう。考え方は，ここまでの説明とほとんど同じである。違うのは図9（b）で説明したユーザーをサーバー側で認証する部分だけである（図10[拡大表示]）。

　クライアントからユーザー名やパスワードを受信したサーバーは，ドメインを一元管理しているドメイン・コントローラへユーザー名とパスワードを転送する（2）。

　するとドメイン・コントローラは受信したデータからユーザーを認証して（3），そのユーザー用のアクセス・トークンを作成する（4）。そして，サーバーへこのアクセス・トークンを返信する（5）。

　サーバーがアクセス・トークンを受信したあとは同じだ。サーバーがアクセス・トークンとUIDの対応表を更新して（6），UIDをクライアントに返信するだけである（7）。

　クライアントから見ると，ユーザー認証のためにユーザー名やパスワードを送り，認証に成功したらUIDが返ってくる。これはドメインに参加しているサーバーへアクセスした場合も，参加していないサーバーの場合も同じである。つまり，クライアントからみれば，ドメインのあり・なしで，使い勝手が変わることはない。