ActiveDirectoryとは -認証、アカウント管理の視点-

ActiveDirectoryというと、色々な要素があり、なかなかとらえずらいですが、まずはひとつの見方として、認証、アカウント管理の視点からその進化の過程を見ていこうと思います。(※あくまでもひとつの見方です。)

スタンドアロンPC

まず、スタンドアロンPCではローカルでユーザー管理、アクセス制御を行います。ローカルにユーザーを作成することが出来、NT系のOSではローカルにユーザーを複数つくり、それぞれプロファイルを切り替えて使うことで1台のパソコンを共有する仕組みが備わっています。その上で他の人に見られたくないファイルには自分だけがファイルにアクセスできるようにアクセス権を設定することが出来ます。1台のWindowsマシン上で、マシンの共有とリソース権限の確保が実現されています。

複数のPCがあると困ること

複数のWindowsPCが存在すると、ユーザーアカウントデータベースはそれぞれのPCに個別に保持されます。アカウントとパスワードの組み合わせを複数覚える必要があるので少々不便になります。同じIDとパスワードにしてしまうことも考えられますが、ユーザーの登録作業は必須です。また複数PC間でリソースの共有ができないので、不便です。

ワークグループでのリソース共有

リソースの共有(例えば共有フォルダや共有プリンタなど)を実現するために、WindowsPC同士をネットワークでつなぎます。具体的にはNetBEUI、TCP/IPなどのネットワークプロトコルを構成し、相互に通信可能な状態にします。そのうえで、複数のマシンがネットワークに参加します。これをWindowsネットワークでは「ワークグループ」と呼びます。ワークグループに参加してしまえば、マイネットワークからネットワーク上のコンピューターの一覧が表示でき、共有したいリソースを「共有」し、他のPCに見せることが出来ます。しかし、ここでアクセス制御をする上で少々こまったことが起きます。

ワークグループでのリソース共有で困ること

リモートのPCで共有されているリソースにアクセスしようとすると、IDとパスワードを聞かれてしまいます。これは他のPCにアクセスするためにはそのPCで有効なIDパスワードを入力し、そのPCのユーザーとしてアクセスする必要があるからです。複数のパソコンにアカウントデータベースが存在し、連携されていないのですからこれは当たり前です。

複数のパソコンで複数のIDが管理されており、パスワードも一致していないとしたら・・・かなり混乱します。これを避けるために、同じIDを全てのWindowsPCに登録し、パスワードもそろえてしまうという運用方法があります。これなら他のPCのリソースにいちいちID/Passwordを入力しなくてもアクセスすることが出来ます。

しかし、ある程度大きな規模でこれを実現しようとすると、1人新しく人が加わっただけで全てのPCにユーザーを登録して回らなくてはいけません。さらにセキュリティ対策のために、定期的にパスワードを変更する必要がある・・・などとなったら面倒でやっていられません。

アカウントデータベースの一元管理(NTドメイン)

そこでアカウントのデータベースを個別のWindowsPCに持つのではなくて、一括してどこかにまとめて管理してしまおうという発想が出てきます。これがWindowsドメイン(NTドメイン)です。 NTドメインによって、認証やネットワーク資源の一元管理を行うことが出来るようになりました。

ユーザーはドメインに登録し、コンピューターはドメインに参加することで、ドメインに管理をゆだねます。PCにログオンするときや別のPCにあるリソースを使用する際には、アカウントデータベースとしてNTドメイン上のアカウントデータベースを利用するわけです。これで、どのPCにでも誰でもログオンでき、別のPCにあるリソースにアクセスする際に、一々ID,パスワードを入力する必要がなくなりました。

(余談)ローカル管理から一元管理への流れ

ホスト名の解決にしても、NETBIOS名の解決にしても、データベースにしても、たいていのものはローカルでの管理から始まって、ネットワーク上で共有する方向に向かっているように思われます。

NTドメインの問題点

こうしてNTドメインにアカウント情報が共有され、クライアントPCもドメインのリソースとして登録すれば、どのPCにでもログオンできるし、リソースの管理も一元化できます。しかし、以下の問題点が・・・。

扱えるオブジェクト数の限界

NTドメインでは単一のドメイン内で扱えるオブジェクト数がそれほど多くなく約4万が限界でした。そのため大規模な環境の場合、アカウントを登録するドメインとは別にリソースを登録するドメインを分ける・・・ということを余儀なくされることがありました。

管理者の権限

ドメイン内においてドメイン管理者は全てのオブジェクトに大しての権限を持つことになります。本来であればひとつの拠点や部署など小さな単位で管理権限を与えたい場合でも、一般ユーザーでない場合にはドメイン管理者にせざるを得ず、不必要に強い権限を与えなくてはいけませんでした。これを避けるためには、これまたドメインを分割する必要がありました。

信頼関係の管理

上記のような理由からにドメインを分割した場合には相互に連携するために、信頼関係を結ばなくてはいけません。この信頼関係はドメインが増えるたびに全て追加で個別に登録の必要があったため、維持、管理に問題がありました。

シングルマスタ

NTドメインではアカウントの管理は一元化されたものの、大規模に展開するためには、そのデータベースを複数用意し、参照できる必要があります。そうしないとトラブル発生時に全ての情報が失われてしまい、機能がストップしてしまうことになります。NTドメインではこれはPDCがマスター、BDCがバックアップといった具合に実現されています。

しかし、データベースの更新処理自体はPDCにしか行えず、PDCのデータのコピーをBDCが保持するという形態になっていたため、運用上少々不便でした。例えば、PDCが無い拠点とのネットワーク経路に障害が発生したような場合には、PDCにアクセスできず、ユーザー情報の更新すらできなくなってしまいます。

ActiveDirectoryでの改善

ActiveDirectoyでは上記の問題点が解消されています。

扱えるオブジェクト数の限界

ActiveDirectoryでは単一のドメインで扱えるオブジェクトの数が100万オブジェクト以上となり、事実上オブジェクト数のみを問題としてドメインを分割する必要はなくなりました。

信頼関係の管理

ActiveDirectoryでは「ActiveDirectoryフォレスト」というものを形成し、自動的に推移的な信頼関係を構築するので、信頼関係の維持管理にかかるコストが減少しました。

同一フォレストに子ドメインを作成すれば、自動的に信頼関係を結んでくれるようになったのです。

管理者の権限

ActiveDirectoryでは単一のドメインの中にOUという管理組織を作成することができ、その中にオブジェクトを格納できます。その上でそのOUに対して管理の委任を行うことができ、「このアカウントにはこのOUの管理を任せる」ということが出来るようになりました。

これによってわざわざドメインを分割することなく、1つのドメインの中で管理の制御が行えるようになりました。

シングルマスタからマルチマスタへ

ActiveDirectoryではドメインコントローラーが対等な立場として存在し、そのドメインコントローラーでも情報の更新が行えるマルチマスタモデルになりました。

ただし、全ての機能が対等に存在しているわけではなくて、5つの機能(フォレスト単位で2つ、ドメイン単位で3つ)に関しては単一のドメインコントローラーが保持しています、これはFSMO(フィズモ)の役割などと呼ばれます。FSMOに関しては別のところで述べます。

ActiveDirectoryのいけてないところ

色々改善されたActiveDirectoryですが、悪いところも多々あります。

データベース容量

扱えるオブジェクト数の限界は増えたものの、その分データベースにしわ寄せが来ている印象があります。データベースエンジンはMicrosoftおなじみのExtensible Storage Engine(ESE)です。それぞれのオブジェクトが消費するデータベースが結構大きく、削除済みのオブジェクトも規定で60日間、2003R2以降では180日間保持されます。なので、オブジェクトの絶対数はそれほどでもないけれども、毎日大量に削除~作成を行うようなシステムでは容量は要チェックです。

テストフェーズだからといって、大量にオブジェクトを生成、削除を繰り返していると、DBが肥大化してしまうことになりますので、気をつけましょう。

信頼関係の管理

フォレスト内での信頼関係はいいのですが、その他のNTドメインや別フォレストと信頼関係を結ぼうとすると、結局以前のNTドメインの際の問題に直面します。ある意味仕方ないのかもしれませんが・・・。

※ただし、フォレスト間の信頼関係に関してはWindowsServer2003で改善されています。

OUへの効率的なリソース配置

OUを分けることで管理を委任できる・・・というところが売りなのですが、OUに対していかに効率的にリソースを移動、配置するかという点はあまりサポートされていません。たとえば、コンピューターオブジェクトは普通にドメイン参加するとComputersコンテナに作成されるので、そこから手動でOUに移動する必要があります。ドメイン参加の際にコンピューターオブジェクトが作成される規定の場所を変更することは可能ですが、それも別の1箇所に変更するのみであって、条件によって振り分けるようなことは出来ません

たとえば、あるOU以下しか管理権限がない場合に、単純にドメイン参加すると、Computerオブジェクトが管理下にないOUに作成されてしまい、手も足も出なくなってしまいます。このような場合、先にコンピューターオブジェクトを管理下のOUにつくっておけば問題は回避できますが・・・。

OUへのオブジェクトの配置は今のところ独自にアプリケーションを開発するなどして管理してあげる必要があります。

シングルマスタ、マルチマスタ

複数のDCに書き込めることのメリットも確かに沢山あるのですが、複数に書き込めるようになった分だけその整合性を取るところでおかしなことが起きます。書き込んだつもりの情報があとから更新された情報によって上書きされたり、削除したはずのオブジェクトを再作成しようとすると、まだ削除の情報が全てのDCに伝わっていないためにエラーではじかれてしまったり。最悪なのはDC間の同期がおかしくなった場合です。この場合完全に全ての最新の情報を救うのは絶望的になります。DC間の同期の正常性の確保は非常に重要です!

子供3人。家族優先。都内SIer勤務。Windows系中心のインフラよりの何でも屋。脱原発。 Microsoft MVP for Cloud and Datacenter Management.

コメントを残す

メールアドレスが公開されることはありません。