HIEDA NET Corpration
 > これは変だよ  > Active Directryを使え!


 

Microsoftが、マーケティングに長けているのは誰も認めるところだ。Windows 2000でActive Directryを発表したときに、
 「今までPCではなし得なかった大規模ネットワークにも対応可能です。」
的な広告が効を奏し、エンタープライズなネットワークにもWindows Serverが導入された。しかし、反面、
 「Active Directryは大規模ネットワーク向き。」
というウソが蔓延しているのも事実である。

Microsoftの販売戦略上ではクライアントOSと呼ばれているWindows NT Workstation・Windows 2000 Professional・Windows XPでも、何らかのサービスを提供すると言う意味では、サーバになれる。

  • IISを利用したwebサーバ
  • (同時アクセス数が10接続までと言う制限があるが)ファイルサーバやプリントサーバ
などが例にあげられる。 Microsoftの販売戦略上では、同時10接続を越える場合にはサーバOSを使用するほかない。

で、クライアントOSをサーバにしたり、同じ構成ではあるが同時接続数が10を越えるからサーバOSを採用している場合に、サーバとなるマシンにアクセスするであろうユーザアカウントを設定するのだが、この方法をワークグループという。詳しくはここを読むこと。

この方法で複数のサーバを用意する場合には、それぞれにユーザアカウントを設定しなければならない。任意のユーザが使用するアカウントが、

  • この複数サーバで異なるものが用意されていると、各々のサーバごとにアクセス認証画面が出る。
  • ローカルコンピュータへのログオンに使用したアカウントと異なるアカウントがサーバに用意されていると、アクセス認証画面が出る。
この方法はUnix使いがUnixでネットワークコンピュータを利用しているときと同じ方法である。Unixの場合には、たとへローカルコンピュータで利用しているアカウントとパスワードをリモートサーバでも利用できるように設定しても、ユーザー認証が必要だ。そこで、
  • 任意のサーバーにアクセスするときには○○というユーザIDでパスワードは△△にしようぜ!
と言う共用アカウントなんて運用方法もまかり通る。セキュリティ的にどうかな?なんて思うけれどね。アクセス履歴で誰がアクセスしたのか区別がつかないぞ!

さて、複数のサーバでユーザアカウントを 組織の人数分 × サーバ台数 なんてワークグループという利用方法はそのうちネットワーク管理者・サーバ管理者の負担になってくる。Microsoftはこのような場合の管理方法としてWindows ドメインを用意している。なんと、NETBEUIで運用していたLAN Managerの時からドメイン管理している。

※ この場合のドメインはDNSのドメインではない。いわゆるWindows NTドメインのことだ。

  • 複数のユーザアカウントを一箇所で管理する。同姓同名のユーザアカウントとパスワードを複数のサーバに設定するなどということはしない。
  • ユーザが使用するクライアント用コンピュータをドメインのメンバとして登録すると、ドメインのメンバーであるコンピュータを除くコンピュータからのログオンを許さなくなる。
  • ユーザが使用するクライアント用コンピュータをドメインのメンバとして登録すると、ローカルログオンもドメインのメンバとして登録してあるユーザアカウントを利用できる。この方法を利用すると、ローカルの管理者アカウントを除くユーザアカウントをクライアントコンピュータに用意する必要もなくなるので、ドメインのメンバーアカウント以外のログオンを許さなくなる。
なんて事が実現できる。セキュリティ的にもとても魅力ある。

UNIX互換OSで同様のアカウント集中管理の方法として、Sun MicrosystemsのNISやTivoliのAccess Manager・Identity Managerなどの製品があるが、TAMとTIMは有料で高価。NISではWindows NTドメインで出来ることがではない。しかも、僕の周りにいるUnix信者で、NISを利用している人を見たことがない。結局のところWindows NTドメインであろうとNISであろうと、アカウントの集中管理ということのメリットが判っていないんじゃないか?と思う。

このことは見たことも会ったこともないけれどこのページを見ているUnix使い・Unix信者の方々の悪口を言っているのでなく、今まで僕の人生でお会いしたことのあるUnix使い・Unix信者の方々が、どんなにCLIやviの使用がうまくても、SendmailやBINDの設定が出来ても、ユーザアカウントとコンピュータアカウントの集中管理のメリットがわからない阿呆ではなかったのかな?ということである。おっと、またまた嫌われることを書いてしまったね。

スタンドアロンサーバとして構成したファイルサーバを複数と、無い坊主とか言うwebイントラネットグループウェアと、POP+SMTPのメールサーバと複数箇所に複数のユーザアカウントが存在している環境では、ネットワーク管理・サーバー管理の負担は一箇所集中よりも稼動がかかるし、設定間違いも多くなる。

でActive Directryである。

どの程度の規模からドメイン管理をしたらメリットがあるのか?この答えはその環境によって異なるが、おおよその目安として、

  • クライアントOSの同時アクセス制限数10を超える場合
  • サーバOSを購入すると標準でついてくるCAL数5を満たす場合
があげられる。どちらも大規模とは言い難い数である。しかし、この数からドメインを構成してもメリットはある。
  • アカウントの集中管理でアカウントのないコンピュータやユーザのアクセスを回避
  • アカウントの再利用。SQLサーバやExchangeサーバで利用する。MailやイントラネットWebグループウェアで、再度、同数の同姓同名のアカウントを登録する必要がない。
などなど。パスワードの変更も一度で済ませられ、全てに反映するので、ネットワーク上の資源を利用するたびに異なるユーザIDとパスワードの組み合わせを思い出す、手間も省ける。

少なくとも、
 「各自でWindows UpadteとAnti Virusのパターンファイルアップデートをしておくれ!言うこと聞かない奴は罰金もんだ!」
なんていっていても(意図していなくても)ウイルスを撒く者がいるようなネットワークよりは、各自にWindows UpdateとAnti Virusのパターンファイルアップデートを任せないで、
 「ドメインのメンバーであるコンピュータに対しては集中管理でWindows UpadteとAnti Virusのパターンファイルアップデートを行う。ユーザーは意識しなくてもいい。」
 という管理のほうがよっぽどITだと思う。この程度のことが判らないのに、
 「各自でWindows UpadteとAnti Virusのパターンファイルアップデートをしておくれ!終わった者から、無い坊主(とか言う低機能)webイントラネットシステムの掲示板に報告!」
だの言っていては、どんなにテクニカルスキルがあって威張っていても、全く、ITではないよ!ということを自覚してもらいたいものだ。

 まぁ、こんなことばかり書いているから、仕事も干されてししまうのだが、誰かが書かないといけないことなのでね。

「まだ書ききれないが続きはまたいずれ・・・

初出 03 Oct 2004
最終更新日 09 Nov 2004


 

 (C)2003 HIEDA NET Corporation All rights reserved.