サーバでユーザーIDを集中管理
まずは、ユーザーIDが複数のPCにばらばらに保存されている例を考えよう。
ある会社では、社員数人に1台の割合でPCを配布している。社員、派遣社員、アルバイトの各自は、必要に応じて手近にある、空いているPCを使える。このような会社では、派遣・アルバイトのIDとパスワードは共通のことが多いが、セキュリティを考慮するのであれば、ユーザーIDは人物それぞれに個別に設定することが望ましい。
入れ替わりの激しい派遣社員やアルバイトに対して、個別のユーザーIDを設定するのは確かに面倒だが、誰もが同じユーザーIDとパスワードを使っていると、不正が見つかったとしても、誰が原因なのか特定が難しくなる。もし、出入りの人数が多すぎて各自にユーザーIDを与えることが難しいのであれば、IDとパスワードは共通であっても、退職者が出る度にパスワードを変更するといったルールを徹底したほうがいい。
管理作業自体は、社内にユーザーIDを集中管理するサーバがなくてもできる。5台程度のPCなら、更新作業は兼任の管理者が1人しかいなくても、さほど手間にはならない。ところが、社内のPCが10台を超えるあたりから、作業は急に面倒になる。極端な例だが、管理者1人の作業でPC1台あたりの更新に3分かかるとする。10台の作業であれば、かかる時間は30分。作業にあたる従業員は、それだけ余分に働くことになる。言い換えれば、経営者には、30分間の残業代を支払う義務が発生する。
複数のPCを数人でシェアしているような会社でユーザーID管理をしっかり行おうとすると、PCの台数やユーザー数が増えるたびに管理者の手間も増える。
社内にサーバがあれば、現在のユーザーIDを1カ所にまとめて管理できる。
Windows Server（2000以降）は、ユーザーID管理用に「アクティブディレクトリ（Active Directory：ユーザーIDの電子名簿帳）」という仕組みを持っている。ユーザーがクライアント（サーバにつながったPC）からログオンすると、アクティブディレクトリで管理されているユーザーIDを参照して、認証と承認を実施する。
アクティブディレクトリを保管する特別なサーバを「ドメインコントローラ（Domain Controller：DC）」と呼ぶ。ドメイン（Domain）とは直訳すると領域のことで、ユーザーID名簿を管理する責任領域だと思えばよい。DCが社内にある状態をドメイン環境と呼ぶ。DCがない場合は、「ワークグループ環境」または「スタンドアロン環境」と呼ぶ。
中小零細企業では、せっかくWindows Serverを使っているというのに、アクティブディレクトリを使わずに、ワークグループ環境で使っているというケースが多い。ユーザーIDをアクティブディレクトリで集中管理すれば、必要な更新作業は1回で済む。クライアントの数がいくら増えても、手間数は同じ。PCの台数が増えれば増えるほど、大幅な省力化になる。
アクティブディレクトリを導入すると、複数のPCから参照されるユーザーID名簿を利用できるようになる。更新や管理の作業はPCの台数にかかわらず1回だけ行えばよい。
さて、ここでひとつ注意すべき点がある。サーバの名簿を使っても、クライアントの名簿は自然には消えない。そのため、これまで個別のPCでユーザーIDを管理していた環境にアクティブディレクトリを導入すると、サーバとクライアントの2か所にユーザーID名簿を持った状態になってしまう。この問題については、最終章の「すでにあるPCをActive Directoryに登録する」で触れる。
