Linuxの真実、Windowsの真実（2）
ワークロード1： ファイル／プリント・サーバ

　ファイル／プリント・サービスの第2回である今回は、運用管理面から見たWindows（Windows Server 2003）とLinux＋Sambaについて検討してみよう。

　企業への情報システム導入は、必要に応じて段階的に進むのが一般的である。しかしこれを続けていくと、各システムが独自にユーザーを管理する「ディレクトリ」を持つことになる。この場合、管理者から見れば、一人のユーザー情報を変更するにも、複数のシステムを別々に操作しなければならなくなる。またユーザーからすれば、異なるシステムや業務アプリケーションごとに、ユーザー名とパスワードを使い分けなければならない。ユーザー自身のID管理が煩雑になるだけでなく、覚えきれずにパスワードをメモしたりすると、その情報が漏れて侵入被害につながるなど、セキュリティ的にも好ましくない。

　またネットワークの規模が大きくなると、クライアントPCやアプリケーションなどの管理作業が膨大になる。小規模なうちは、手作業で管理することもできるが、一定の規模を超えたら、何らかの集中的な管理手段が必要になる。

　こうした問題を解消し、ネットワーク内のユーザーとコンピュータ、そのほかの情報を集中的かつ効率的に管理する技術がディレクトリ・サービスである。マイクロソフトは、Active Directory（以下AD）と呼ばれるディレクトリ・サービスをWindows 2000から追加した。ADは、特に複数ドメインで構成されるような大規模なネットワーク管理で高い効果を発揮するが、従来のNTドメインのような比較的小規模なWindowsネットワークにおいてもメリットは大きい。

　ADを導入することで、異なる複数のシステムで別々に管理していたユーザーID情報を一元化するシングル・サインオン環境を実現できる。ユーザーは、ADによる1回の認証で、アクセス許可を持つあらゆるサービスを利用可能になり、利便性が大幅に向上する。

　一方管理者は、ADによってユーザーIDとパスワードを集中管理できるため、定期的なパスワード変更も効率よく行えるようになり、ユーザー・アカントの管理負担を軽減するとともに、セキュリティ・レベルを向上させることができる。

ディレクトリ・サービスのないネットワーク

ユーザーID情報はシステムごとに管理されており、ユーザーはシステムごとに正しいユーザーIDを使って認証を受けなければならない。

Active Directory環境

AD環境では、ドメイン・コントローラによるシングル・サインオンが可能になる。ユーザーは、ドメイン・コントローラに認証されたアクセス権限で、ADに参加しているあらゆるシステムにアクセスできる。

　ADでは、グループ・ポリシー（Group Policy、以下GP）と呼ばれる管理メカニズムを利用して、多数のクライアント・コンピュータを集中管理できる。特定のデスクトップ構成やセキュリティ・ポリシーなどをグループ・ポリシーとして管理者が定義し、これを各クライアントに配布して適用することができる。GPは、ドメイン全体に適用することもできるが、ドメイン内に作成したOU（Organizational Unit＝組織単位）と呼ばれる単位で配布することもできる。部署をOUに割り当てれば、部署単位に適用するポリシーを切り替え可能だ。

　さらにADの導入により、成長するWindowsネットワークをシームレスに吸収可能な将来性や柔軟性も手に入れることができる。企業で活動する多くの情報システムやアプリケーションは、ユーザーIDに基づく適切な利用権限を管理するために、独自のデータベースやディレクトリ・サービスを備えている。例えば現実には、メール・サーバや人事システム、給与システムなどがそれぞれ独自のIDを持っていることも珍しくない。最初からADのようなディレクトリ・サービス環境があればよいが、こうした業務システムはAD以前から使われていたものが多い。また昨今活発化している企業の統合・合併などでは、深刻なディレクトリ統合の問題に直面するだろう。

　これに対しマイクロソフトは、異なる複数のディレクトリを統合して、ID情報の統合とデータの一貫性を保持するメタディレクトリ・サービス「Microsoft Identity Integration Server 2003（以下MIIS 2003）」を提供している。MIIS 2003を利用すれば、ADが提供するディレクトリ・サービスと、異種分散システムとの統合が実現され、事業部門のシステム統合や企業合併にも柔軟に対応できるようになる。

　Linux＋Sambaという組み合わせにより、NT 4.0と同程度のドメイン・コントローラとして機能させることができる。あるいはすでにNT Server 4.0やWindows Server 2003で構築済みのWindowsネットワークがあるなら、Linux＋Sambaをこれに参加させることも可能だ。

　ただし、Linux＋Sambaで構築できるのはNT 4.0相当のドメインである、たとえADドメインに参加する場合でも、AD階層の1ノードとして機能することはできない。またSambaでは、仕様が公開されていないWindowsネットワークの挙動を独自に分析して機能を実装しているため、マイクロソフトが提供する最新機能をタイムリーに提供するのは困難であるし、何よりそのような事情から、完全な互換性は保証されない。

　これに加え、Sambaでドメインを構築する場合には、次の3つの問題を考慮しておく必要がある。

１．ユーザー・アカウント情報の一元管理
　第1の問題は、ユーザー・アカウントの一元管理である。Linux＋Sambaを使うと、Sambaのユーザー・アカウント（＝Windowsのユーザー・アカウント）とLinuxのユーザー・アカウントが別々に存在することになる。ユーティリティを使えば、同一コンピュータ内のSambaとLinuxとの間で両者のアカウント情報を対応させることは可能だが、ネットワーク内にある複数のLinuxコンピュータ間で一致させることはできない。このため、Windows環境の1つのユーザー・アカウントに対して、複数のLinuxアカウントのID（uidやgid*1）が、Linuxマシンごとに異なってしまう危険性がある。これは、Linux上の別の機能を利用するときに問題となる。

２．ドメイン管理用データベースのバックアップ
　第2の問題は、ドメイン管理用データベースのバックアップである。NTドメインでは、プライマリ・ドメイン・コントローラ（PDC）と複数のバックアップ・ドメイン・コントローラ（BDC）を設置して冗長性を持たせ、可用性を高めることができる。しかしSambaから利用できる管理用データベースで、同様の機能を実現できるものは非常に限られている。

　UNIX系OS向けのディレクトリ・サービスであるOpenLDAPを導入すれば、前出の2つの問題を解決できる。OpenLDAPにより、各マシンのLinuxアカウント、Windowsアカウント、リソースなどを、LDAPデータベースで一元管理できるようになる。

OpenLDAP

ディレクトリ・サービスのOpenLDAPを導入すれば、Windows／Linux双方のユーザー・アカウントなどを一元管理できるようになる。

　つまりLinux＋SambaでNTドメイン相当のネットワークを構築し、一定レベルの可用性を確保するには、別途ディレクトリ・サービスの導入が不可欠である。しかしOpenLDAPは汎用のディレクトリ・サービスであり、Samba専用に設計されているわけではない。OpenLDAPを正しく機能させるには、LinuxアカウントとSambaのWindowsアカウントをOpenLDAPで管理するように設定する必要がある。これには、OpenLDAPのみならず、Linux、Sambaも含めた設定方法に精通していなければならない。と同時に、ユーザー・アカウントをLinux、Windows双方のデータベースで整合性を持った形で管理しなくてはならないために手間もかかる。

３．WINS複製
　第3の問題はWINS複製である。Sambaは、WINSサーバ（Windowsネットワークでの名前解決を提供するサービス）の機能を提供することもできる。しかし、複数のWINSサーバ間で名前解決データの複製ができないという制限があるため、WINSサーバに障害が発生した場合のバックアップ・サーバを提供できない（これについては、次のバージョンのSambaで対応する可能性がある）。

■

　Linux＋Sambaは、ごく小規模なネットワークに限定すればセットアップや管理の手間もさほどではないが、ある程度の規模を超えたネットワークを管理するには力不足である。特に中規模以上のネットワークでは、ユーザーやクライアントPCを統合的に管理し、管理コストを低減させるとともに、将来への拡張性をも備えるディレクトリ・サービスが重要である。ADは、シングル・サインオン環境やグループ・ポリシーによる複数クライアントの一括管理、メタディレクトリ・サービスによる、大規模なディレクトリ統合までをサポートする。Active Directoryは、現在から未来にわたるあらゆる種類の、あらゆる規模のネットワークに対して高い価値を提供してくれるメカニズムである。