いまさら聞けないサイトの役割：今だからこそ学び直すActive Directory基礎のキソ（4）
先人たちが作り上げてきたActive Directoryドメインには、必ずと言っていいほど複数のドメインコントローラーが存在します。ドメインコントローラーが“複数あるのは当たり前”とも言えますが、ドメインコントローラーが複数のネットワークに存在する場合、その接続はどのように制御すればよいのでしょうか？ ネットワーク的な観点からどうすべきなのでしょうか？ 今回は、ネットワークの視点からActive Directoryドメインの「サイト」について学び直します。
今だからこそ学び直すActive Directory基礎のキソ
Active Directoryの「サイト」って何ですか？
本連載第2回「いまさら聞けないドメイン／ドメインコントローラーの役割」でも触れた通り、1つのドメインに複数の「ドメインコントローラー」が存在した場合は、ドメインコントローラー間でアカウント情報などが複製され、どのドメインコントローラーでも等しく同じ認証情報でドメイン認証が実施されます。
ここでのポイントは以下の2つです。
（1）ドメインコントローラー間の複製
（2）ドメインユーザーの認証
「（1）ドメインコントローラー間の複製」は、複数のドメインコントローラーで1つのドメインを構成するActive Directoryの根幹を成すもの、といっても過言ではありません。この複製が正しく行われていないと、ドメインコントローラーAに存在するアカウントがドメインコントローラーBには存在しない、という事態が発生してしまいます。最終的には、どちらかのドメインコントローラーでは認証されない、という状態になってしまいます。
「（2）ドメインユーザーの認証」は、本連載第2回の「ドメインコントローラーとDNSサーバの密な関係」に記述されている通り、ドメイン参加クライアントは自身が所属するネットワークに最寄りのドメインコントローラーに認証を要求します。この動きにより、ネットワーク的な遅延を最小限に抑えながら確実な認証が実施されることになります。
上記の2つをコントロールしているのが、Active Directoryの「サイト」になります。
Active Directoryのサイトは、Active Directory管理ツールの一つである「Active Directoryサイトとサービス」から確認できます。画面1は、設定変更を一切行うことなくドメインを作成し、2台目のドメインコントローラーを追加しただけのサイトの状態です。
2台のドメインコントローラーは「Default-First-Site-Name」というラベルのグループの下に配置されています。この「Default-First-Site-Name」のラベルを持ったグループこそが“サイト”になります。
このグループを定義するために、重要な要素が一つあります。それはネットワーク構成です。例えば、図1のようなネットワークとドメインコントローラー、そしてサイト設定があるとしましょう。
東京サイトと大阪サイトは10Mbpsの専用線で結ばれている、物理距離的にもネットワーク的にも離れた拠点同士です。それぞれの拠点に1台ずつドメインコントローラーが設置されていますが、サイトとしては同一サイトに属する設定になっています。
この設定がどういう結果を生むかというと、「ネットワークの視点から見るとかなり遠距離にあるにもかかわらず、ドメインコントローラーの視点から見ると同じ場所にいる」という矛盾した状態になります。
この状態で、大阪オフィスに接続しているドメイン参加クライアントが認証を要求するとどうなるでしょう。前述の通り「ドメイン参加クライアントは自身が所属するネットワークに最寄りのドメインコントローラーに認証要求を実施する」のであれば、大阪オフィス内のcontoso-ad02に認証要求を投げるはずです。しかし、実際に確認してみると、画面2のように東京オフィスの「ネットワーク的に遠いし遅い」contoso-ad01に認証されている、という状態が発生する場合があります。
東京オフィスと大阪オフィスが1Gbpsや10GbpsといったLAN接続といっても差し支えない高速な回線で接続されていれば（距離遅延を意識しなければ）全く問題ないのですが、狭帯域の回線だったり、従量課金の回線だったりすると、非常に問題になります。
そのため、ネットワーク的な視点を持っていないActive Directoryに“ネットワークのかたまり（サブネット）を把握させること”が必要になります。その設定こそが「サイト」設定であり、サイトを適切に設定することで、Active Directoryの世界にネットワーク的な視点を持たせることが可能になります。
具体的な「サイト」の設定例
先述の例の具体的なサイト設定は、図2のようになります。
こうすることで、サイトに設定されたサブネットのアドレス範囲にあるドメイン参加クライアントは、Active Directoryの仕組みによって「自身が所属するネットワークに最寄りのドメインコントローラー」を識別し、適切なドメインコントローラーに認証を要求できます。
実際に設定した環境では、画面3のようにネットワーク的にも近いドメインコントローラーに認証されていることが分かります。
ドメインコントローラー間の複製制御
ドメインコントローラー間の複製設定は、ドメインコントローラーとして動き始めると同時に作成されます。自動作成の他、手動でも作成可能ですが、複製設定そのものを全て明示的に設定したい場合を除き、自動設定に任せて問題ありません。自動で設定された複製設定は、画面4のように「＜自動生成＞」という名前が付与されます。
サイト「Tokyo-Site」のドメインコントローラーであるcontoso-ad01は、サイト内のドメインコントローラーであるcontoso-ad03と、サイト「Osaka-Site」のドメインコントローラーであるcontoso-ad02との複製設定がされています。
contoso-ad03の複製設定を見ると、画面5のようにcontoso-ad02との複製設定がありません。
これはサイト間の複製は、サイトを代表する「ブリッジヘッドサーバ」同士が行うことになっているためです。なぜこのような実装になっているかは後述します。
今まで見てきた中では、ドメインコントローラー間の複製設定は、同一サイトであれ、異なるサイトであれ、同じ設定が実施されているように見えますが、実のところは異なります。
異なるのは複製が実施されるスケジュールですが、これにはActive Directoryが登場した2000年ごろのネットワーク事情があると考えられます。
今でこそ広帯域の専用線が低廉化していたり、インターネットVPN（仮想プライベートネットワーク）をはじめとする低価格なネットワークが存在していたりしますが、Active Directoryの登場当時は64kbpsや128kbpsといった狭帯域の専用線や1.5Mbps程度の専用線が一般的でした。場所によってはダイヤルアップ回線による従量課金、というネットワークもあったほどです。
サイト間接続で狭帯域回線やダイヤルアップ回線を用いている場合は、いかにトラフィックを減らし、短時間かつ少ない頻度で複製するかということが重要でした。LANと同じように通信すると電話代が高額になってしまうので、どうにかしなければならないという状態だったのです。
そのため、サイト内でのドメインコントローラーとサイト間のドメインコントローラーでは表1のようにデフォルトの複製間隔が異なるのです。
| 複製タイミング | データ圧縮 | |
|---|---|---|
| サイト内複製 | 15秒後に複製を開始 | データ圧縮なし |
| サイト間複製 | 3時間ごとに複製（既定） | データ圧縮あり |
| 表1 ドメインコントローラー間の複製設定 | ||
サイト間複製の複製タイミングに「（既定）」と書かれている理由は、設定により変更可能なためです。「Active Directoryサイトとサービス」管理ツールで「サイトリンク」を設定することで、画面6のようにサイト間の複製間隔（画面6では「180分に1回」となっている）や、複製が利用可能な時間帯を指定できます。
サイトリンクは複数設定することも可能で、サイトごとに複製間隔や複製スケジュールを変更することもできます。
こうした細かい設定やサイト間の複製をブリッジヘッドサーバに集約して行うといった思想も、当時のWAN回線の事情を反映したものと筆者は考えています。
「サイト」設定は、本当に必要なのか？
広帯域なWAN回線や低廉で広帯域なブロードバンド回線をバックボーンとするIPsec（Security Architecture for Internet Protocol） VPNなどの仮想専用線が当たり前に使える現在、通信料の節約を目的とするサイト設定は不要と思われがちです。
事実、デフォルトで作成されるサイト「Default-First-Site-Name」だけで運用されているActive Directoryもあるでしょうし、実際の現場でもそうしたActive Directoryを数多く見てきました。
では、本当にサイト設定は不要なのでしょうか？ 実は、現在もなお従量課金のネットワークは残っています。それは、クラウドネットワークです。
クラウドとオンプレミスをネットワークで接続する場合や、冗長性化のために異なるリージョン間でネットワークをピアリングする際、その接続ネットワーク上でトラフィックが発生すると、課金が生じる可能性があります。
- AzureでのVirtual Networkの価格（Microsoft Azure）
上記サイトは「Microsoft Azure」での仮想ネットワークピアリングの課金ですが、1GB当たりで送受信ともに課金されます。
こうした従量課金の回線でドメインコントローラーの複製トラフィックが頻繁に発生すると、全体量からすれば微々たるものですが予想外の課金として計上される場合があるので注意が必要です。
現在はクラウド上にドメインコントローラーをホストすることも一般的になってきていますので、ドメインコントローラー間の複製トラフィックによる課金、ドメイン参加クライアントの認証要求が従量課金ネットワークへの流入を最低限に抑えるためにも、サイト設定は現在だからこそ必要なのかもしれません。
サイトが1つしかない現場で発生したトラブルの実例
サイト設定に起因したトラブルではありませんでしたが、サイトが1つしか存在しないActive Directoryで発生し、問題解消に時間がかかった実例を紹介しておきましょう。
そのトラブルは、東京3拠点と大阪1拠点の4拠点で構成され、各地にドメインコントローラーが合計10台設置されたネットワークで発生しました。トラブルの内容としては「間欠的にクライアントがドメイン認証に失敗する」というものでした。
ドメイン認証が失敗するクライアント端末は全ての拠点に存在するものの、特定のクライアント端末で発生するわけではなく、またドメイン認証に失敗しても再起動すると認証が成功する（問題が解消される）という状態で、再現確率は低く、原因の特定につながる手掛かりがかなり少ない状況でした。
最終的には、問題が発生した端末を見つけたらすぐさまパケットキャプチャーを実施し、ドメインコントローラーとどのようなやりとりをしているかを確認。そこまでやって、ようやく原因が判明しました。原因は1台のドメインコントローラーが複製異常を起こしており、アカウント情報が更新されていなかった、というものでした。
「なんだ、ドメインコントローラーの問題じゃん」というオチではありますが、ドメインコントローラーが全て同じサイトに属しており、4拠点のどのクライアント端末から見ても全てのドメインコントローラーが「最寄りのドメインコントローラー」になってしまうため、クライアント端末は10台のドメインコントローラーの全てで認証される可能性がある、という状態だったのです。
つまり、ドメイン認証を行う際、複製問題を抱えたドメインコントローラーに当たる確率が10分の1であり、たまたま問題のドメインコントローラーに認証を依頼した端末がドメイン認証に失敗するという、いわばガチャを回して当たり（？）を引くと認証されない、という障害だったというわけです。
当然のことながら、当該ドメインコントローラーを停止（最終的にはドメインコントローラーの強制降格）することで問題は解消されたのですが、1つのサイトにあまりにも多くのドメインコントローラーが存在すると「ドメインコントローラーガチャ」が発生して問題発生時に切り分けが難しくなる、という教訓を得た障害でした。
こういった問題からも分かるように、ネットワークトポロジーを勘案してサイトを正しく設定することで、クライアント端末の認証先のコントロールや、ドメインコントローラーの複製トポロジーをコントロールすることが可能となり、健全なActive Directory環境の運用が可能になります。
いま一度、ご自身が管理するActive Directoryのサイト設定を確認してみてください。
筆者紹介
後藤 諭史（ごとう さとし）
Microsoft MVP for Cloud and Datacenter Management（2012-2025）。現業の傍ら、コミュニティーイベントでの登壇や著作にてMicrosoftテクノロジーに関する技術情報の発信、共有を続けている。ネットワークやハードウェアといった物理層に近いところが大好きな、昔ながらのインフラ屋さん。得意技はケーブル整線。近著は『詳解! Windows Server仮想ネットワーク』（日経BP社）。
Copyright © ITmedia, Inc. All Rights Reserved.