オンプレミスの Active Directory フェデレーション サービスを Azure に拡張する
この参照アーキテクチャでは、オンプレミス ネットワークを Azure に拡張し、 Active Directory フェデレーション サービス (AD FS) を使用して Azure で実行されるコンポーネントのフェデレーション認証と承認を実行する、セキュリティで保護されたハイブリッド ネットワークを実装します。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
Workflow
次のワークフローは、上記のダイアグラムに対応しています。
Active Directory Domain Services (AD DS) サブネット: AD DS サーバーは、ネットワーク セキュリティ グループ (NSG) 規則がファイアウォールとして機能する独自のサブネットに含まれています。
AD DS サーバー: Azure で仮想マシン (VM) として実行されるドメイン コントローラー。 これらのサーバーは、ドメイン内のローカル ID の認証を提供します。
AD FS サブネット: AD FS サーバーは、独自のサブネット内にあり、NSG 規則をファイアウォールとして使用します。
AD FS サーバー: AD FS サーバーは、フェデレーション承認と認証を提供します。 このアーキテクチャでは、以下のタスクを実行します。
パートナー ユーザーに代わってパートナー フェデレーション サーバーによって行われた要求を含むセキュリティ トークンを受け取ります。 AD FS は、要求を承認するために Azure で実行されている Web アプリケーションに要求を渡す前に、トークンが有効であることを確認します。
The application that runs in Azure is known as the relying party. パートナー フェデレーション サーバーは、Web アプリケーションが認識する要求を発行する必要があります。 The partner federation servers are known as account partners because they submit access requests on behalf of authenticated accounts in the partner organization. The AD FS servers are known as resource partners because they provide access to resources (the web application).
AD DS と Active Directory デバイス登録サービス (DRS) を使用して、Web アプリケーションへのアクセスを必要とする Web ブラウザーまたはデバイスを実行している外部ユーザーからの受信要求を認証および承認します。
AD FS サーバーは、Azure ロード バランサーを通じてアクセスされるファームとして構成されています。 この実装により、可用性とスケーラビリティが向上します。 AD FS サーバーはインターネットに直接公開されません。 All internet traffic is filtered through AD FS web application proxy (WAP) servers and a demilitarized zone (DMZ), also known as a perimeter network.
詳細については、 AD FS の概要を参照してください。
AD FS プロキシ サブネット: AD FS プロキシ サーバーは、独自のサブネット内に含め、保護に NSG 規則を使用できます。 このサブネット内のサーバーは、Azure 仮想ネットワークとインターネットの間にファイアウォールを提供する一連のネットワーク仮想アプライアンスを介してインターネットに公開されます。
AD FS WAP サーバー: これらの VM は、パートナー組織や外部デバイスからの受信要求の AD FS サーバーとして機能します。 WAP サーバーは、インターネットからの直接アクセスから AD FS サーバーをシールドするフィルターとして機能します。 AD FS サーバーと同様に、負荷分散を使用してファームに WAP サーバーを展開すると、スタンドアロン サーバーのコレクションを展開するよりも可用性とスケーラビリティが向上します。 詳細については、「 WAP サーバーのインストールと構成」を参照してください。
Partner organization: A partner organization runs a web application that requests access to a web application running in Azure. パートナー組織のフェデレーション サーバーは、要求をローカルで認証し、Azure で実行されている AD FS に要求を含むセキュリティ トークンを送信します。 Azure の AD FS は、セキュリティ トークンを検証します。 トークンが有効な場合、AD FS は要求を Azure で実行されている Web アプリケーションに渡して承認できます。
Note
また、Azure ゲートウェイを使用して VPN トンネルを構成し、信頼できるパートナーに対して AD FS への直接アクセスを提供することもできます。 これらのパートナーから受信した要求は、WAP サーバーを通過しません。
Components
このアーキテクチャは、「 Azure 仮想ネットワークへの AD DS のデプロイ」で説明されている実装を拡張します。 これには、次のコンポーネントが含まれています。
AD DS サブネットは、IP アドレス範囲をサイトにマップするオブジェクトです。 このマッピングにより、ドメイン コントローラーは、クライアントのネットワークの場所に基づいて認証とレプリケーションを効率的に行うことができます。
AD DS サーバー は、Active Directory Domain Services をホストするドメイン コントローラーです。 一元化された認証、ポリシーの適用、およびエンタープライズ ネットワーク間のディレクトリ データ レプリケーションが提供されます。
AD FS サブネットは、AD FS サーバーまたは WAP サーバーをホストするネットワークまたは仮想インフラストラクチャ内で定義された IP アドレス範囲です。 この IP アドレス範囲により、セキュリティで保護されたトラフィック フローとサイト対応の認証が可能になります。
AD FS サーバー は、セキュリティ トークンを発行し、クレーム ベースの ID プロトコルを使用して認証要求を処理する内部フェデレーション サーバーです。
AD FS プロキシ サブネット は、通常、WAP サーバーをホストする DMZ 内のネットワーク セグメントです。 これにより、内部 AD FS サーバーへの外部認証トラフィックのセキュリティで保護されたリレーが可能になります。
AD FS WAP サーバー は、外部ユーザー要求を事前認証し、フェデレーション アクセスのために AD FS に安全に転送する境界ネットワークに展開されるリバース プロキシ サーバーです。
Scenario details
AD FS はオンプレミスでホストできますが、アプリケーションがハイブリッドで、その一部が Azure に実装されている場合、クラウドに AD FS をレプリケートする方がより効率的な場合があります。
前述のダイアグラムは、次のシナリオを示します。
パートナー組織のアプリケーション コードは、Azure 仮想ネットワーク内でホストされている Web アプリケーションにアクセスします。
Active Directory Domain Services (AD DS) 内に格納されている資格情報を持つ外部の登録済みユーザーは、Azure 仮想ネットワーク内でホストされている Web アプリケーションにアクセスします。
承認されたデバイスを使用して仮想ネットワークに接続されたユーザーは、Azure 仮想ネットワーク内でホストされている Web アプリケーションを実行します。
This reference architecture focuses on passive federation, in which the federation servers decide how and when to authenticate a user. ユーザーは、アプリケーションの起動時にサインイン情報を提供します。 このメカニズムは、Web ブラウザーで最もよく使用され、ユーザーが認証するサイトにブラウザーをリダイレクトするプロトコルが含まれています。 AD FS also supports active federation, where an application takes on responsibility for supplying credentials without further user interaction, but that scenario is outside the scope of this architecture.
その他の考慮事項については、「 オンプレミスの Active Directory ドメインと Microsoft Entra ID の統合」を参照してください。
考えられるユース ケース
このアーキテクチャの一般的な用途は次のとおりです。
ワークロードの一部がオンプレミスで、一部が Azure で実行されるハイブリッド アプリケーション。
フェデレーション承認を使用して Web アプリケーションを取引先組織に公開するソリューション。
組織のファイアウォールの外部で実行されている Web ブラウザーからのアクセスをサポートするシステム。
リモート コンピューター、ノートブック、その他のモバイル デバイスなどの承認された外部デバイスから接続することで、ユーザーが Web アプリケーションにアクセスできるようにするシステム。
Recommendations
次の推奨事項は、ほとんどのシナリオに適用できます。 これらの推奨事項には、オーバーライドする特定の要件がない限り、従ってください。
Networking recommendations
静的プライベート IP アドレスを持つ AD FS および WAP サーバーをホストする各 VM のネットワーク インターフェイスを構成します。
AD FS VM にパブリック IP アドレスを指定しないでください。 For more information, see the Security considerations section.
AD DS VM を参照するように、各 AD FS および WAP VM のネットワーク インターフェイスの優先ドメイン ネーム サービス (DNS) サーバーの IP アドレスを設定します。 AD DS VM で DNS が実行されている必要があります。 この手順は、各 VM がドメインに参加できるようにするために必要です。
AD FS のインストール
フェデレーション サーバー ファームの展開 に関する記事では、AD FS をインストールして構成する方法の詳細な手順について説明します。 ファームで最初の AD FS サーバーを構成する前に、次のタスクを実行します。
サーバー認証を行うために一般的に信頼されている証明書を取得します。 The subject name must contain the name that clients use to access the federation service. この識別子には、ロード バランサーに登録されている DNS 名 (
adfs.contoso.comなど) を指定できます。 セキュリティ上の理由から、*.contoso.comなどのワイルドカード名は使用しないでください。 すべての AD FS サーバー VM では同じ証明書を使用します。 信頼できる証明機関から証明書を購入できますが、組織で Active Directory 証明書サービスを使用している場合は、独自の証明書を作成できます。DRS はサブジェクトの 別名 を使用して、外部デバイスからのアクセスを有効にします。 この DNS 名は、
enterpriseregistration.contoso.comの形式に従う必要があります。詳細については、「 AD FS の Secure Sockets Layer 証明書を取得して構成する」を参照してください。
ドメイン コントローラーで、キー配布サービス (KDS) の新しいルート キーを生成します。 有効時間を現在の時刻から 10 時間引いた値に設定します。 この構成により、ドメイン間でキーを分散および同期する場合に発生する可能性のある遅延が軽減されます。 この手順は、AD FS サービスの実行に使用されるグループ サービス アカウントの作成をサポートするために必要です。 次の PowerShell コマンドは、時間オフセットを持つ新しい KDS ルート キーを生成する方法を示しています。
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)各 AD FS サーバー VM をドメインに追加します。
Note
AD FS をインストールするには、ドメインのプライマリ ドメイン コントローラー エミュレーターフレキシブル シングル マスター操作ロールを実行するドメイン コントローラーが実行されていて、AD FS VM からアクセスできる必要があります。
AD FS の信頼
AD FS のインストールとパートナー組織のフェデレーション サーバーとの間にフェデレーション信頼を確立します。 必要な要求のフィルター処理とマッピングを構成します。
各取引先組織の DevOps スタッフは、AD FS サーバーを介してアクセス可能な Web アプリケーションの証明書利用者信頼を追加する必要があります。
所属する組織の DevOps スタッフは、取引先組織から提供される要求を AD FS サーバーが信頼できるように、要求とプロバイダー間の信頼を構成する必要があります。
所属する組織の DevOps スタッフは、組織の Web アプリケーションに要求を渡すように AD FS を構成する必要もあります。
詳細については、「 フェデレーション信頼の確立」を参照してください。
組織の Web アプリケーションを発行し、それを外部パートナーが使用できるようにするには、WAP サーバーを介した事前認証を使用します。 詳細については、「 AD FS 事前認証を使用したアプリケーションの発行」を参照してください。
AD FS は、トークンの変換と拡張をサポートしています。 Microsoft Entra ID にこの機能はありません。 AD FS を使用すると、信頼関係を設定するときに、次のタスクを実行できます。
承認規則の要求変換を構成する。 たとえば、Microsoft 以外のパートナー組織で使用される表現から、AD DS が組織内で承認できるものにグループ セキュリティをマップできます。
要求の形式を変換する。 たとえば、アプリケーションで SAML 1.1 要求のみがサポートされている場合は、SAML 2.0 から SAML 1.1 にマップすることができます。
AD FS の監視
AD FS 2012 R2 用 Microsoft System Center 管理パックは、フェデレーション サーバーの AD FS 展開のプロアクティブ監視と事後監視の両方を提供します。 この管理パックは、AD FS 展開の次の側面を監視します。
AD FS サービスがイベント ログに記録するイベント
AD FS パフォーマンス カウンターが収集するパフォーマンス データ
AD FS システムと Web アプリケーション (証明書利用者) の全体的な正常性と、重大な問題と警告
もう 1 つのオプションは、 Microsoft Entra Connect Health を使用して AD FS を監視することです。 Connect Health provides robust monitoring of your on-premises identity infrastructure. これにより、Microsoft 365 および Microsoft オンライン サービスへの信頼性の高い接続を維持できます。 キー ID コンポーネントの監視機能を提供することで、この信頼性を実現します。 また、これらのコンポーネントに関する重要なデータ ポイントにも簡単にアクセスできます。
Considerations
これらの考慮事項では、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 For more information, see Well-Architected Framework.
Reliability
信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性 設計レビューチェックリスト」を参照してください。
サービスの可用性を高めるために、少なくとも 2 台のサーバーを含む AD FS ファームを作成します。 ファーム内の AD FS VM ごとに異なるストレージ アカウントを使用します。 このアプローチにより、1 つのストレージ アカウントに障害が発生しても、ファーム全体にアクセスできなくなることを回避します。
AD FS VM と WAP VM に個別の Azure 可用性セットを作成します。 各セットに少なくとも 2 つの VM があることを確認します。 各可用性セットには、少なくとも 2 つの更新ドメインと 2 つの障害ドメインが必要です。
次の手順を実行して、AD FS VM と WAP VM のロード バランサーを構成します。
Azure ロード バランサーを使用して WAP VM への外部アクセスを提供し、内部ロード バランサーを使用して、ファーム内の AD FS サーバー全体に負荷を分散します。
ポート 443 (HTTPS) に表示されるトラフィックのみを AD FS または WAP サーバーに渡します。
ロード バランサーに静的 IP アドレスを指定します。
/adfs/probeに対して HTTP を使用して正常性プローブを作成します。 詳細については、「 Azure Load Balancer 用のカスタム HTTP/HTTPS 正常性プローブを作成する」を参照してください。Note
AD FS サーバーはサーバー名表示プロトコルを使用します。これにより、ロード バランサーからの HTTPS エンドポイント プローブが失敗します。
Add a DNS A record to the domain for the AD FS load balancer. ロード バランサーの IP アドレスを指定し、ドメインに名前を付けます (
adfs.contoso.comなど)。 この DNS レコードは、クライアントと WAP サーバーが AD FS サーバー ファームへのアクセスに使用する名前です。
AD FS の構成情報を保持するには、SQL Server または Windows Internal Database を使用できます。 Windows Internal Database は、基本的な冗長性を提供します。 変更は AD FS クラスター内の 1 つの AD FS データベースだけに直接書き込まれる一方で、他のサーバーはプル レプリケーションを使用してそれらのデータベースを最新の状態に保ちます。 SQL Server を使用すると、フェールオーバー クラスタリングまたはミラーリングを使用して、データベースの完全な冗長性と高可用性を実現できます。
セキュリティ
セキュリティでは、重要なデータやシステムへの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティ 設計レビューチェックリスト」を参照してください。
AD FS では HTTPS が使用されるため、Web 層 VM を含むサブネットの NSG 規則で HTTPS 要求が許可されていることを確認します。 これらの要求は、オンプレミス ネットワーク、Web 層、ビジネス層、データ層、プライベート DMZ、パブリック DMZ、AD FS サーバーを含むサブネットを含むサブネットから送信できます。
AD FS サーバーがインターネットに直接公開されないようにします。 AD FS サーバーは、セキュリティ トークンを付与するための完全な権限を持つ、ドメイン参加コンピューターです。 サーバーが侵害されると、悪意のあるユーザーは、すべての Web アプリケーションのほか、AD FS によって保護されているすべてのフェデレーション サーバーに対するフル アクセス トークンを発行できます。 信頼されたパートナー サイトから接続していないゲストからの要求をシステムで処理する必要がある場合は、WAP サーバーを使用してこれらの要求を処理します。 詳細については、「 フェデレーション サーバー プロキシを配置する場所」を参照してください。
AD FS サーバーと WAP サーバーを、独自のファイアウォールを持つ個別のサブネットに配置します。 NSG 規則を使用してファイアウォール規則を定義できます。 すべてのファイアウォールは、ポート 443 (HTTPS) のトラフィックを許可する必要があります。
AD FS および WAP サーバーへの直接サインイン アクセスを制限します。 DevOps スタッフだけが接続できるようにしてください。 WAP サーバーをドメインに参加させないでください。
監査目的で仮想ネットワークのエッジを通過するトラフィックに関する詳細情報をログに記録するネットワーク仮想アプライアンスのセットを使用することを検討してください。
Cost Optimization
コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コストの最適化 設計レビューチェックリスト」を参照してください。
Microsoft Entra Domain Services
コストを削減するために複数のワークロードが使用する共有サービスとして Microsoft Entra Domain Services を使用することを検討してください。 詳細については、「 Domain Services の価格」を参照してください。
AD FS
Microsoft Entra ID が提供するエディションの詳細については、 Microsoft Entra の価格を参照してください。 AD FS 機能は、すべてのエディションで使用できます。
Operational Excellence
オペレーショナル エクセレンスは、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスを対象としています。 詳細については、「オペレーショナル エクセレンス 設計レビュー チェックリスト」を参照してください。
DevOps スタッフは、以下のタスクの実行を準備する必要があります。
AD FS ファームの管理、フェデレーション サーバーでの信頼ポリシーの管理、フェデレーション サービスが使用する証明書の管理など、フェデレーション サーバーを管理する
WAP ファームと証明書の管理など、WAP サーバーを管理する
証明書利用者、認証方法、要求マッピングの構成など、Web アプリケーションを管理する
AD FS コンポーネントのバックアップ
DevOps に関するその他の考慮事項については、 Azure 仮想ネットワークへの AD DS のデプロイに関するページを参照してください。
Performance Efficiency
パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、「パフォーマンス効率 設計レビュー チェックリスト」を参照してください。
「AD FS の配置を計画する」の記事から要約された以下の考慮事項は、AD FS ファームのサイズ設定の出発点となります。
ユーザー数が 1,000 人未満の場合は、専用サーバーを作成しないでください。 代わりに、クラウド内の各 AD DS サーバーに AD FS をインストールします。 可用性を維持するために、少なくとも 2 つの AD DS サーバーがあることを確認します。 1 つの WAP サーバーを作成します。
1,000 から 15,000 人のユーザーがいる場合は、2 つの専用 AD FS サーバーと 2 つの専用 WAP サーバーを作成します。
ユーザーが 15,000 から 60,000 人の場合は、3 から 5 台の専用 AD FS サーバーと、少なくとも 2 台の専用 WAP サーバーを作成します。
これらの考慮事項では、Azure でデュアル クアッドコア VM (Standard D4_v2 以上) サイズを使用していることを想定しています。
Windows 内部データベースを使用して AD FS 構成データを格納する場合、ファーム内の AD FS サーバーは 8 台に制限されます。 今後さらに必要になる可能性があると思われる場合は、SQL Server を使用してください。 詳細については、「 AD FS 構成データベースの役割」を参照してください。
Contributors
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
Principal author:
- Sarah Parkes | Senior Cloud Solution Architect
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。