【IDM】Active Directory の DMZ への展開シナリオ その1 ~ 4つの AD DS モデル


まず、ちょっとだけ告知させてください。

以下のセミナーでLT登壇者を募集中です!

--------------------------------------------------------------------------------------

さて、先日以下の投稿をしました。

【IDM】Active Directory の DMZ シナリオがようやく登場!ーActive Directory Domain Services in the Perimeter Network
http://blogs.technet.com/junichia/archive/2009/05/01/3233958.aspx

ざくっと読んでみたので、何回かに分けて投稿したいと思います。ちょいと今週来週とたてこんでいるので、間が空くかと思いますが…。

まずはじめに、このガイドの冒頭にこんなことが書かれています。

このガイドを読んだ後になって、「AD DSをDMZに展開することに何のベネフィットも無い」と感じるかもしれませんし、もしかすると他のソフトウェアを使って展開したほうがベネフィットが多いと感じる可能性もあります。そう思ったということは、あなたの環境におけるベストな選択肢は、「DMZにADを展開しない」ということになるかもしれません。

うーん。いきなりアレなかんじですが(笑)、要は、

技術的にできるからといって無理に適用すると帰って危険に鳴らす可能性がありますから気をつけましょう

ということです。決して弱気になっているわけではありません。

さて、さっそくはじめましょう。今回は「4つのAD DSモデル」についてお話します。

まず、大前提として以下の要件があることを確認しておいてください。

【要件】

  • インターネットからのユーザーに対してアプリケーションを公開したい
  • ユーザーにはIDとパスワードで認証および承認を行いたい

これを実現するために、大きく分けて、以下に示す4つのモデルが考えられます。

【モデル1:AD DS を DMZ に展開しない】

第一の選択肢は、AD DSをDMZに展開せず、DMZ上のアプリケーションサーバー上にユーザーIDを作成して個別に管理するという方法です。

image

この方法のデメリットは、DMZ上のサーバー(たとえばWEBサーバー)のアカウント管理をサーバー個別に行わなければならないという点です。もちろん、この場合の認証はローカルのSAMとなるため、Kerberos認証を使用することはできません。

また、サーバー間でSAMを共有することはできないため、例えば図にある3台のサーバーで個別にアカウントを管理する必要があります。

【モデル2:AD DSを独立したフォレストで展開する】

AD DSをDMZに展開するのですが、社内(プライベートネットワーク)とは独立したフォレストで展開するモデルです。

image

このモデルの場合には、DMZ上のサーバーの認証を統合することができます。が、フォレストが分割されているため、基本的に社内のフォレストとは通信は行わないため、よって、社内ドメインとのWindows統合認証機能は使用できません。

Exchange Server など、AD DSを必須とするアプリケーションサーバーの場合には、最低限、このモデルを採用する必要があります。

【モデル3:社内のフォレストをDMZまで拡張】

ちょっと図がわかりずらくて恐縮ですが、青い三角形(フォレストを意味します)がDMZと社内ネットワークをカバーしているところに注目してください。

image

このモデルを採用すると、もともと存在する社内ドメインを使用することができるので、通常のドメインコントローラをDMZに展開することもできますし、なにより RODC(Read Only Domain Contoroller)を展開できるというメリットがあります。また、IDを一元管理できるため、社内で使用するIDと同じIDをインターネット上からも使用できます。もちろんパスワードも同じですし、ユーザーの権限も社内ドメインで制御できます。

RODCを採用する場合、RODC上にはパスワードを持たないようにすることができるため、従来のドメインコントローラと比較すると安全性が格段に上がります。また、Read Only と言うくらいで、書き込みも制限されています。RODC について詳しい情報はこちら(TechCenter ブランチオフィスソリューション)をご覧ください。また、RODCに関する過去の投稿はこちらです。

ただし…DMZ上のアプリケーションがドメインコントローラに何らかの書き込みをする必要がある場合には、RODCは残念ながら採用が難しくなるでしょう…。

【モデル4:フォレスト間の信頼関係を構築する】

モデル2と似ていますが、このモデルでは社内ドメインとの信頼関係を結んでいます。

image

このモデルでは、ID管理者社内ドメインで行い、信頼関係によって認証を行うため、社内のID情報をDMZにさらす必要がありません。上の図では双方向に信頼関係が結ばれていますが、DMZから社内への1方向の信頼でもOKです。

ただし、このモデルの難点は管理コストが確実に増えてしまうという点です。DMZドメインのメンテナンスをしなければなりませんし、DMZと社内間のFirewallの設定も複雑になります。

このモデルに似た構成として、AD FS(Active Directory フェデレーションサービス)があります。

ひとまず今回はここまでで失礼します。

Comments (1)

  1. 匿名 より:

    いよいよTech・Edの夏が近づいてまいりました。 私の周囲も、ピリピリとした緊張感で満たされつつあります。 今年のTech・Edは 8月26日~28日の3日間と、従来よりも1日少なくなっています。が、そのぶん、内容は濃くなる予定です。

Skip to main content