2005-12-19

前回は認証、名前解決の視点からADを見てみましたが、今回はサービスロケータ、名前解決の視点からADを見ていこうと思います。

※注意事項

以下の事項に関しては、ここで述べるには複雑すぎるので詳しくは述べません。

スタンドアロンPCの場合には、特にサービスロケーターや名前解決の仕組みは必要ありません。

複数PCの場合には、どのPCに何が入っているかなどに関しては全て個人の記憶なりで管理します。特にPCの仕組みとしては組み込む必然性はありません。

ネットワークが利用できる環境では、通信をするために名前解決が必要ですし、共有リソースにアクセスする必要性も出てきます。

共有リソースの場所は記憶で管理し、名前解決はブロードキャスト(同一セグメントのみ)、ローカルファイル(hostsファイル、lmhostsファイル)を利用します。

どのPCがワークグループに参加しているか、という点に関しては、ブラウズリストを利用します。このブラウズリストに関しても、ブロードキャストやローカルファイルを利用して取得します。

NTドメインにおいては、アカウントデータベースも共有リソースとなります。つまり、ログオンする際にはドメインコントローラーを知り、通信を行う必要があります。

では、ドメインコントローラーの場所をどのようにしてクライアントは知ることが出来るのか?

これは複数の方法があり、(同一セグメントであれば)ブロードキャスト、各PCのlmhostsファイルに記述するといった方法もありますが、本命はWINSを利用する方法になります。

WINSの場所自体は、各PCに静的に設定します。

WINSの役割は複数ありますが、以下のものを提供します。 -ドメインコントローラーの場所 -NETBIOS名とIPアドレスの組(名前解決) -ブラウズリストの場所 WindowsNT時代にはWINSがサービスロケーター、名前解決の手段として一般的に利用されていました。

(余談)ちなみにNetBEUIプロトコルを利用しているかぎりにおいては、このあたりは全てブロードキャストで解決します。なぜならNetBEUIにはネットワークセグメントという概念はなく、全てのPCに対してブロードキャストが届くネットワークしか想定していないからです。

WINSサーバーには以下の問題がありました。

WINSのデータベースはフラットな構造であったので、必要なレコード、つまり全てのドメインの全てのレコードを保持する必要がありました。

(余談)WINSの場合、対象サーバーが保持しているレコードは名前解決できるし、保持していないレコードは名前解決できないという動きでした。自分が保持していないレコードだった場合には保持しているはずのWINSサーバーに問い合わせて、答えを返す・・・というようには動きません。

WINSサーバーが複数存在する環境では、WINSサーバー同士でレコードを明示的にPushしたり、Pullしたりする必要がありました。つまりWINSの複製のトポロジを管理者が管理しなくてはならず、しかも色々と複製にまつわるトラブルが多かったそうです。

NTドメインの時代にはログオンするDCはWINSサーバーから取得していたので、ログオンするDCが名前解決に依存してしまっていました。このため、最悪の場合には、近くにあるDCを利用せずに、ネットワーク的に非常に遠いDCを利用してしまうこともあったそうです。

サービスロケーターとしてWINSを捉えた際にWINSが扱えるものはDCの場所とブラウズリストの場所に関するものだけだったので、たとえば共有プリンタの場所などは扱えず、UNCパスを利用しなくてはなりませんでした。

ここまで見てきたWINSの問題点を改善するために、ADでは名前解決にDNS、サービスロケーターとしてもDNS,ADを利用するように変更されています。

DNSを採用することで、ドメインごとに管理を分散できるようになりました。

名前解決に関してはDNSを採用したため、WINSの構成を行う必要がなくなりました。それに加えて、ADのDNSでは「AD統合ゾーン」という仕組みを採用し、DCのレプリケーションにDNSのレコードも含められるようになっています。(通常の標準プライマリ、標準セカンダリとしても構成可能)

これによって、管理者は名前解決のための複製管理とDCの複製管理を分けて考える必要がなくなりました。

ADでは「サイト」という概念が導入されて、ログオンするDCはまずはサイト内を利用する・・・というように管理者が細かく管理できるようになりました。DCの場所はDNSのSRVレコードで示されています。

ADでは、ユーザー、グループ、共有フォルダ、共有プリンタなどのリソースに関しても「ADに公開」することが出来るようになりました。