Active Directoryの設計や構築だけでなく、運用保守でもたびたび登場するDNSサーバー。今回は、Active Directoryとともに使われるDNSサーバーを見ていこう。
“Active Directoryのトラブルの多くはDNS絡み”――。これは、Active Directory管理者の間で古くからいわれてきたことである。
なぜ、Active Directoryでは名前解決サービスを提供する「DNS」(Domain Name System)サーバーが必要なのだろうか。その理由は、DNSサーバーが保持する「SRVレコード」の存在にある。
SRVレコードは、組織内で利用するさまざまなサービスがどの場所で提供されているのか(提供されているサービスの位置情報)を表すためのレコードである。Active Directoryでは、ドメインコントローラーの場所を特定するためにSRVレコードが利用される([参考記事]DNS Tips:SRVリソースレコードって何ですか?)。
言い方を変えると、クライアントコンピューターがドメインコントローラーにアクセスする際、DNSサーバーのSRVレコードを参照できなければ、ドメインコントローラーを見つけることができないため、アクセスできないということになる。これが「Active Directoryで起こるトラブルの多くはDNS絡み」といわれる理由である。
今回は、Active Directoryの運用管理やサポートに携わる方が、DNS絡みのトラブルに適切に対処できるように、DNSとActive Directoryの関係をあらためて確認しておきたい。
Active DirectoryでDNSサーバーを利用する最大の理由は、クライアントがドメインコントローラーにアクセスするとき、どこにドメインコントローラーがあるかを確認するためである(図1)。
Active Directoryでは、クライアントがドメインへ参加したり、サインインしたり、ドメイン内の各サーバーを利用したりする際などに、ドメインコントローラーにアクセスする。これらの通信が正しく行われるようにするために、クライアントはドメインコントローラーにアクセスする前に、最初にDNSサーバーに接続するようになっている。そして、DNSサーバーに接続すると、SRVレコードを利用してドメインコントローラーの場所を特定している。
これは、ドメインコントローラーがデータベースをレプリケーション(複製)するために、他のドメインコントローラーにアクセスする場合にも同じである([参考記事]ドメインコントローラーの複製とは)。
Active Directoryのクライアントは、必ず近くのドメインコントローラーにアクセスしようとする。そして、近くのドメインコントローラーを見つける方法として、「サイト」を利用する。クライアントが自分と同じサイト内にあるドメインコントローラーを見つけるときには、やはりDNSサーバーのSRVレコードを利用する。実際に、DNSサーバーの中を見てみると、SRVレコードがサイトに分かれて保存されていることが分かる(画面1)。
そもそも、DNSサーバーはインターネット上にあるさまざまなサーバーの名前解決のために用意されるものであり、通常は自社内にインターネット向けのDNSサーバーを構築したり、サービスプロバイダーが提供するDNSサーバーを利用したりしているはずだ。
一方、Active DirectoryのDNSサーバーは、ドメインコントローラーの居場所を特定するために特化したサーバーになる。
DNSサーバーに格納されるインターネット向けの情報と、社内向けの情報は、セキュリティレベルがそれぞれ異なるので、同一サーバーに格納するべきではない。そのため、Active Directory環境ではインターネット向けと社内向け(Active Directory)で、別々のDNSサーバーを用意して運用することになるのだが、これでは二つのDNSサーバーの面倒を見ることになるため、運用が煩雑になる。そこで、一般にはDNSサーバーが搭載する「フォワーダー」機能を使って、運用の煩雑さを解決することになる。
フォワーダーとは、クライアントからの問い合わせ(名前解決要求)を受け取ったDNSサーバーが答えが分からなかった場合、他のDNSサーバーに名前解決要求を丸投げする機能である(図2)。DNSサーバーはフォワーダーを使うことで、自分が頑張って何が何でも名前解決しようとするのではなく、分からないことは他人に聞くという潔さで、あらゆる名前解決要求に対応するのである。
こうして、インターネット向けのDNSサーバーと、Active DirectoryのDNSサーバーの両方にアクセスしなければならない場合でも、フォワーダー機能を使うことで、クライアントはどちらかのDNSサーバーにアクセスするだけで、二つのDNSサーバーから名前解決が受けられるようになる。
TCP/IP設定の画面を開くと、DNSサーバーアドレスを入力する欄が二つあることに気が付くだろう(「優先DNSサーバー」と「代替DNSサーバー」)。ここで、それぞれインターネット向けのDNSサーバー、Active Directory用DNSサーバーのアドレスを設定すれば、フォワーダーは必要ないのではと思うかもしれない。
しかし、TCP/IP設定に二つのDNSサーバーを登録しても、同時にアクセスすることはなく、あくまでも「優先DNSサーバー」に登録したサーバーにアクセスできなかった場合に、「代替DNSサーバー」にアクセスするというだけなので注意してほしい(画面A)。
Active Directoryドメインには、さまざまな名前の付け方がある。一つは組織のドメイン名と同じ名前を、Active Directoryのドメイン名にする方法だ。名前を一つに集約できて、見た目の管理は簡単そうである。しかし、DNSの観点から言えば、一つだけ注意しなければならないことがある。それは、フォワーダーを使っても二つのDNSサーバーには同時にアクセスできないことだ。
例えば、ドメイン名「example.com」を持つ組織が、Active Directoryのドメイン名も同じ「example.com」に設定したとしよう。組織のWebサイトやメールサーバーにアクセスするための情報を格納するDNSサーバー(外向けDNSサーバー)と、Active DirectoryのDNSサーバーを別々に用意して、Active DirectoryのDNSサーバーからは外向けDNSサーバーにフォワーダーを設定する。
しかし、このフォワーダー設定では、組織内のクライアントコンピューターから外向けDNSサーバーの名前解決をすることはない。なぜなら、クライアントは「example.com」ドメインの名前解決をすでにActive DirectoryのDNSサーバーで行っており、Active DirectoryのDNSサーバーに保存されていない情報を探しに他の「example.com」ゾーンの情報を持つDNSサーバーにアクセスしても、そこで名前解決することはないからだ。
そのため、組織のドメイン名とActive Directoryのドメイン名が同じ場合には、外向けのDNSサーバーに保存している情報と同じ情報を、Active DirectoryのDNSサーバーにも保存しておくことが最も現実的な運用となる。
Active DirectoryのDNSサーバーは、クライアントからActive Directoryにアクセスする際に、その場所を確認するために使うと説明してきたが、実際どのような通信が発生するのかをここでまとめておこう(図3)。
まず、クライアントはドメインコントローラーの場所を確認するために、DNSサーバーにアクセスする。クライアントからDNSサーバーにアクセスするには、クライアントのTCP/IP設定で、DNSサーバーのIPアドレスが指定されていなければならない(図3のチェックポイント1)。
また、IPv6が有効になっていたり、(二つのNICを搭載しているために)二つのネットワークにアクセスできるように構成されていることで参照するDNSサーバーが毎回異なっていたりなど、さまざまな理由で思い通りのDNSサーバーにアクセスできない場合にも注意しよう。
クライアントの問題が解決し、無事DNSサーバーにアクセスできる状態になっていても、DNSサーバーに正しくレコードが登録されていなければドメインコントローラーの場所を特定することはできない。ということで、クライアントの次にチェックすべきは、DNSサーバーのレコードの設定になる(図3のチェックポイント2)。
登録されているDNSサーバーのSRVレコードが正しいものであるかどうかは、目視で確認するのも一つの方法だ。だが、より簡単にトラブルシューティングを行うなら、SRVレコードを作り直すのもよいだろう。SRVレコードの作り直しは簡単で、ドメインコントローラー上でWindows PowerShellの「Restart-Service netlogon」コマンドレットを実行するだけである。
なお、自動的に作成されたSRVレコードが正しいかどうかを確認したい場合には、あらかじめ正しい状態のSRVレコードの構成を保存しておき、それと比較してみるとよい。そのためにも、事前に以下の画面2のように、正常時のDNSサーバーのスクリーンショットを撮っておくことをお勧めする。
ここまで、Active DirectoryにおけるDNSサーバーの必要性を見てきた。Active DirectoryのトラブルのほとんどはDNSが関係していると冒頭で説明したが、ここまで見てきたような仕組みでActive DirectoryのDNSサーバーが使われていることが分かれば、トラブルに遭遇しても、自分で問題の原因を推測し、問題を解決できるようになるだろう。
クラウドの登場により、Active Directoryに求められる役割も変化しつつあります。
クラウドに対応させるためのActive Directoryの設計ポイントとはどにあるのか? iOSやAndroidは、Active Directoryにどう絡むのか? Azure Active Directoryとは何者か? 生産性を高めるためのセキュリティを実現するには、どのようなインフラが必要か?
今こそ、Active Directoryの役割を再学習し、古い知識をリセットしましょう!
国井 傑(くにい すぐる)
株式会社ソフィアネットワーク取締役。1997年よりマイクロソフト認定トレーナーとして、Active DirectoryやActive Directoryフェデレーションサービス(ADFS)など、ID管理を中心としたトレーニングを提供している。2007年よりMicrosoft MVP for Directory Servicesを連続して受賞。なお、テストで作成するユーザーアカウントには必ずサッカー選手の名前が登場するほどのサッカー好き。
Copyright © ITmedia, Inc. All Rights Reserved.