エクスポート (0) 印刷
すべて展開

Azure の仮想マシンでの Windows Server Active Directory のデプロイ ガイドライン

更新日: 2014年4月

このペーパーでは、Windows Server の Active Directory ドメイン サービス (AD DS) および Active Directory フェデレーション サービス (AD FS) の内部設置型での展開と Microsoft Azure の仮想マシン (VM) への展開との重要な違いについて説明します。

目次

このペーパーは、Active Directory を内部設置型で展開した経験のある方を対象としています。Active Directory の Microsoft Azure の仮想マシン/Azure の仮想ネットワークへの展開と従来の内部設置型での展開との違いを取り上げています。Azure の仮想マシンと Azure 仮想ネットワークは、クラウド内でコンピューティング リソースを活用するために組織で IaaS (Infrastructure-as-a-Service) の一部として使用されます。

AD の展開について詳しく理解していない方は、必要に応じて AD DS の展開ガイドまたは AD FS 2.0 の展開ガイドを参照してください。

このペーパーでは、対象読者が次の概念を理解していることを前提としています。

  • Windows Server AD DS の展開と管理

  • Windows Server AD DS インフラストラクチャをサポートするための DNS の展開と構成

  • Windows Server AD FS の展開と管理

  • Windows Server AD FS トークンを使用することがある証明書利用者アプリケーション (Web サイトや Web サービス) の展開、構成、管理

  • 一般的な仮想マシンの概念 (仮想マシン、仮想ディスク、仮想ネットワークの構成方法など)

このペーパーでは、ハイブリッド展開シナリオの要件を重点的に取り上げています。このシナリオでは、Windows Server の AD DS または AD FS を内部設置型システムと Azure の仮想マシンのそれぞれに展開します。このペーパーでは、まず、Windows Server の AD DS と AD FS を Azure の仮想マシンで実行する場合と内部設置型で実行する場合の重要な違いについて説明します。設計と展開に影響を与える重要な意思決定事項も取り上げます。次に、さまざまな展開シナリオでの意思決定に関する詳しいガイドライン、さまざまな展開シナリオへのテクノロジ分野の適用方法について説明します。

このペーパーでは、Azure Active Directory の展開と構成については説明しません。Azure AD はクラウド アプリケーションに ID 管理機能とアクセス制御機能を提供する最新の REST ベースのサービスです。ただし、Azure Active Directory (AD) と Windows Server AD DS は連携することで、最新のハイブリッド IT 環境とアプリケーションに ID 管理とアクセス管理のソリューションを提供するように設計されています。Windows Server AD DS と Azure AD の違いと関係の理解に役立つように、次の点を考慮します。

  1. Azure を使用して内部設置型データセンターをクラウドに拡張するときは、クラウド内の Windows Server AD DS を Azure の仮想マシンで実行する場合があります。

  2. Azure AD を使用して SaaS (Software-as-a-Service) アプリケーションへのシングル サインオンをユーザーに提供する場合があります。たとえば、このテクノロジは Microsoft Office 365 で使用されています。Azure などのクラウド プラットフォームで実行されるアプリケーションでも使用される場合があります。

  3. Azure AD (そのアクセス制御サービス) を使用して、クラウド内または内部設置型でホストされるアプリケーションに、ユーザーが Facebook、Google、Microsoft などの ID プロバイダーからの ID でログインできるようにする場合があります。

これらの違いの詳細については、「Azure ID」を参照してください。

Windows Server Active Directory を Azure の仮想マシンに展開するための基本的な要件は、内部設置型で仮想マシン (および部分的に物理マシン) に展開するための要件とほとんど違いはありません。たとえば、Windows Server AD DS のケースでは、Azure の仮想マシンに展開するドメイン コントローラー (DC) が既存の内部設置型の企業ドメイン/フォレストにある DC のレプリカである場合、Azure への展開は他の Windows Server Active Directory サイトを扱う場合とほとんど同じ方法になります。つまり、サブネットを Windows Server AD DS で定義し、サイトを作成し、サブネットをそのサイトにリンクし、適切なサイト リンクで他のサイトに接続する必要があります。ただし、一部の違いは Azure へのどの展開シナリオにも共通していますが、展開シナリオに固有のものもあります。それらの 2 つの基本的な違いについてここでは概要を示し、続く段落で詳細を示します。

  1. Azure の仮想マシンが内部設置型の企業ネットワークに接続できることが必要になる場合がある。

    Azure の仮想マシンを内部設置型の企業ネットワークに接続するには Azure 仮想ネットワークが必要です。この仮想ネットワーク内のサイト間またはサイト対ポイントの仮想プライベート ネットワーク (VPN) コンポーネントにより、Azure の仮想マシンと内部設置型コンピューターがシームレスに接続できるようになります。この VPN コンポーネントにより、内部設置型ドメイン メンバー コンピューターは、Azure の仮想マシンでのみホストされる Windows Server Active Directory ドメインにもアクセスできるようになります。しかし重要なのは、VPN に障害が発生した場合、認証だけでなく、Windows Server Active Directory に依存するその他の処理にもエラーが発生することです。ユーザーはキャッシュされた既存の資格情報を使用してログオンできる場合がありますが、チケットが未発行だったり期限切れだったりすると、ピア間またはクライアント サーバー間の認証の試みはすべて失敗します。

    デモ ビデオやステップバイステップ チュートリアルの一覧については、「ネットワーク」の「クロスプレミス接続用の仮想ネットワークの作成」などを参照してください。

    noteメモ
    内部設置型ネットワークに接続できない Azure 仮想ネットワークに Windows Server Active Directory を展開することもできます。ただし、このトピックのガイドラインでは、Azure の仮想ネットワークを使用することを前提とします。Azure の仮想ネットワークには Windows Server に必須の IP アドレス指定機能が用意されているためです。

  2. Azure の仮想マシンでは静的 IP アドレスがサポートされていますが、Azure PowerShell を使用して構成する必要があります。

    動的アドレスは既定で割り当てられます。動的アドレスを割り当てるには、Azure の仮想ネットワークを作成する必要があります。Azure の仮想ネットワークに接続された Azure の仮想マシンの動的 IP アドレスは、仮想マシンの有効期間にわたって保持されるため、IP の処理に関する Windows Server Active Directory と DNS の要件が満たされます。

    ただし、VM がシャットダウンされると、その動的 IP アドレスの割り当ては解除されます。IP アドレスの割り当てが解除されないようにするには、Set-AzureStaticVNetIP コマンドレットを使用して、静的 IP アドレスを割り当ててください

    詳細については、「IP アドレス指定と DNS」を参照してください。

次の一覧ではすべての用語を取り上げているわけではありませんが、関連するさまざまな Azure テクノロジを定義しているため、このペーパーの理解に役立ちます。すべての用語が網羅された用語集については、Windows Azure の用語集を参照してください。

  • Azure の仮想マシン: Azure の IaaS に含まれます。従来のほぼすべての内部設置型サーバーのワークロードを実行する VM を展開できます。

  • Azure の仮想ネットワーク: Azure のネットワーク サービスです。Azure で仮想ネットワークを作成および管理できるようになります。仮想プライベート ネットワーク (VPN) を使用して、Azure の仮想ネットワークを内部設置型ネットワーク インフラストラクチャに安全に接続することもできます。

  • 仮想 IP アドレス (VIP): インターネットに公開される IP アドレスですが、特定のコンピューターやネットワーク インターフェイス カードには割り当てられません。クラウド サービスに割り当てられて、Azure VM にリダイレクトされるネットワーク トラフィックを受信するために使用されます。VIP は、1 つ以上の Windows Azure の仮想マシンが含まれる場合があるクラウド サービスのプロパティです。Azure の仮想ネットワークには 1 つ以上のクラウド サービスが含まれる場合があることにも注意してください。VIP によりネイティブの負荷分散機能を使用できるようになります。

  • 動的 IP アドレス (DIP): DHCP によって Azure の仮想マシンの仮想ネットワーク アダプターに動的に割り当てられる IP アドレスです。ただし、IP アドレスは展開の有効期間にわたってその仮想マシン用に保持されます。これは、DHCP 予約により IP アドレスが個々の MAC アドレスに関連付けられる方法と同様です。

  • サービス復旧: Azure がサービスの実行失敗を検出した後、そのサービスを再び実行状態に自動的に戻すプロセスです。サービス復旧は、可用性と回復性をサポートする Azure を特徴付ける側面の 1 つです。まれにですが、VM で動作している DC のサービス復旧インシデントの後、予期しない再起動の場合と同様に、副作用となる次のいくつかの動作が伴います。

    • VM の仮想ネットワーク アダプターが変更される。

    • 仮想ネットワーク アダプターの MAC アドレスが変更される。

    • VM のプロセッサ/CPU ID が変更される。

    • VM が仮想ネットワークに接続されていて、VM の IP 構成が仮想ネットワークの一部または VM 自体 (ゲスト オペレーティング システム以外) として定義されている場合、仮想ネットワーク アダプターの IP 構成が変更されない。

    ただし、これらの動作はどれも Windows Server Active Directory に影響を与えません。MAC アドレスまたはプロセッサ/CPU ID への依存関係がないためです。また、Azure への Windows Server Active Directory のどの展開も、前に概説したように、Azure の仮想ネットワークで実行することをお勧めします。それにより IP アドレスがサービス復旧の実行中に保持されるためです。

Windows Server Active Directory DC を Azure の仮想マシンに展開する場合、内部設置型で仮想マシンに展開する場合と同じガイドラインに従うものとします。仮想化 DC の実行は DC のバックアップと復元に関するガイドラインに従う限り安全です。仮想化 DC の実行に関する制約とガイドラインの詳細については、「Hyper-V でのドメイン コントローラーの実行」を参照してください。

ハイパーバイザーにより、多くの分散システム (Windows Server Active Directory など) で問題の原因になる可能性があるテクノロジが提供されることもあれば、そのようなテクノロジが重要でなくなることもあります。たとえば、物理サーバーではディスクを複製したり、サポートされていない手段を使用してサーバー (SAN なども含む) の状態をロールバックしたりできますが、その作業はハイパーバイザーで仮想マシンのスナップショットを復元するよりもはるかに難しくなります。Azure ではスナップショットの復元機能は用意されていませんが、同様の望ましくない状態になる可能性のある機能が提供されています。たとえば、DC の VHD ファイルをコピーしないでください。代わりに定期的なバックアップを行ってください。コピーした VHD ファイルを使用して DC を復元することで、スナップショットの復元機能を使用した場合に似た状況になることがあるためです。

そのようなロールバックにより USN バブルが発生して DC 間で常に不整合が生じることがあります。特に、次のような状態になることがあります。

  • 残留オブジェクトが存在する。

  • パスワードが整合しない。

  • 属性値が整合しない。

  • スキーマ マスターがロールバックされた場合にスキーマが整合しない。

DC が受ける影響の詳細については、「USN と USN のロールバック」を参照してください。

Windows Server 2012 以降は、AD DS に追加の保護機能が組み込まれています。この機能は、基になるハイパーバイザー プラットフォームが VM-GenerationID をサポートしている場合に、ここに挙げた問題から仮想ドメイン コントローラーを保護するうえで役立ちます。Azure は VM-GenerationID をサポートしているため、Azure の仮想マシン上で Windows Server 2012 以降を実行しているドメイン コントローラーには、追加で保護機能が備わっていることになります。詳細については、「Active Directory ドメイン サービス (AD DS) の仮想化の概要」を参照してください。

Windows Server AD DS の多くの展開シナリオは Azure 上の VM としての展開によく適しています。たとえば、ある会社でヨーロッパのオフィスからアジアのリモート オフィスにいるユーザーを認証する必要があるとします。この会社はこれまでアジア オフィスに Windows Server Active Directory DC を展開したことはありません。展開に必要なコストに問題があり、サーバー展開後の管理に必要な専門知識が限られていたためです。その結果、アジア オフィスからの認証要求は、ヨーロッパ オフィスにある DC によって次善の結果を使用して処理されています。この場合は指定した VM に、アジア オフィスの Azure データセンター内で実行する必要のある DC を展開できます。リモート オフィスに直接接続されている Azure の仮想ネットワークにその DC を接続すると、認証パフォーマンスは向上します。

また、Azure はコストの高い障害復旧 (DR) サイトの代替手段としてもよく適しています。Azure での少数のドメイン コントローラーと 1 つの仮想ネットワークのホストが比較的低コストであることがその理由です。

さらに、Azure では SharePoint などのネットワーク アプリケーションを展開することもできます。ネットワーク アプリケーションは Windows Server Active Directory を必要としますが、内部設置型ネットワークと企業 Windows Server Active Directory には依存しません。この場合、Azure に分離したフォレストを展開して SharePoint サーバーの要件を満たすのが最適です。もちろん、内部設置型ネットワークと企業 Active Directory への接続が必要なネットワーク アプリケーションの展開もサポートされています。

noteメモ
Azure 仮想ネットワーク内の VPN コンポーネントにより、内部設置型ネットワークとの間でレイヤー 3 接続が可能であるため、内部設置型で動作するメンバー サーバーも、Azure 仮想ネットワークで Azure の仮想マシンとして動作する DC を活用できます。しかし VPN が利用できない場合は、内部設置型のコンピューターは Azure ベースのドメイン コントローラーと通信できず、その結果、認証エラーやその他のさまざまなエラーが発生します。 

  • 複数の VM を含むどの Windows Server Active Directory 展開シナリオでも、IP アドレスの整合性を確保するために Azure の仮想ネットワークを使用することをお勧めします。このペーパーでは、DC が Azure の仮想ネットワークで動作していることを前提とします。

    Azure 仮想ネットワークでは IP アドレスの整合性を得るために、概念上新しい 3 つ目の種類となる IP アドレスを使用します。これらのアドレスは DHCP 予約と同様の方法で割り当てられます。現在、静的 IP アドレスは、オペレーティング システム内で特定のネットワーク インターフェイス カードに割り当てられます。動的アドレスは、DHCP サーバーで定義されたスコープに応じて DHCP サーバーから自動的にリースされます。

    概念上 3 つ目の種類となる IP アドレスは、Azure 仮想ネットワークで導入されており、DHCP アドレス割り当てとはわずかに異なります。Azure の仮想マシンは、既定で DHCP から IP アドレスをリースするように構成されます。ただし、リース期限が切れると変更される可能性がある一般的な動的アドレスとは異なり、Azure の仮想ネットワークでの動的アドレスは、仮想マシンがシャットダウンされない限り、DHCP 予約と同様の方法で、VM の有効期間にわたって保持されます。

    VM がシャットダウンされると、その IP アドレスの割り当てが解除され、VM の再起動時に別の IP アドレスが割り当てられる可能性があります。シャットダウンしても IP アドレスの割り当てが解除されないようにするには、Set-AzureStaticVNetIP コマンドレットを使用して静的 IP アドレスを割り当ててください。Set-AzureStaticVNetIP の使用方法の詳細については、「Configure a Static Internal IP Address (DIP) for a VM (VM 用の静的内部 IP アドレス (DIP) の構成)」と「How to assign a private Static IP to a Windows Azure VM (Windows Azure VM にプライベート静的 IP を割り当てる方法)」を参照してください。

    Important重要
    VM で静的 IP アドレスを構成すると、結果的にその VM への接続が完全に失われます。

  • 仮想ネットワークに仮想マシンを展開する場合、内部設置型ネットワークへの接続が暗黙に必要になるわけではありません。仮想ネットワークでその接続が可能になるだけです。仮想ネットワークの作成が必要になるのは、Azure と内部設置型ネットワークとの間でプライベート通信が必要な場合です。内部設置型ネットワークに VPN エンドポイントを展開する必要があります。VPN は Azure から内部設置型ネットワークに開かれます。詳細については、「仮想ネットワークの概要」と「管理ポータルでのサイト間 VPN の構成」を参照してください。

    noteメモ
    個々の Windows ベースのコンピューターを Azure の仮想ネットワークに直接接続するときには、ポイント対サイト VPN を作成するという選択肢もあります。

  • 仮想ネットワークを作成するかどうかに関係なく、Azure では受信トラフィックではなく出力トラフィックに対して課金されます。Windows Server Active Directory のさまざまな設計上の意思決定事項は、展開によって送信トラフィックがどのように生成されるかに影響を与える場合があります。たとえば RODC の展開では、送信トラフィックはレプリケートされないため制限されます。トラフィックの料金の詳細については、「Azure 料金早見表」を参照してください。

  • 重要なのは、個別の Azure 仮想ネットワーク間が直接接続されないことです。つまり、2 つの仮想ネットワーク (地理的に分散されることが多い) を作成すると、それらの仮想ネットワークに接続された Azure VM 間で通信を行うには、サイト間 VPN 機能を使用して 2 つの仮想ネットワークを同じ企業ネットワークに接続することが必要になります。2 つの仮想ネットワーク間の通信は企業ネットワークを介してトラフィックをルーティングすることによりのみ可能です。したがって、個別の仮想ネットワークの地理的に分散された DC 間の通信は、仮想ネットワークと企業ネットワークの両方を通過する必要があります。たとえば、アジアにある仮想ネットワーク上の Azure VM が、南アメリカにある仮想ネットワーク上の別の Azure VM と通信するには、エンド ツー エンドの通信が内部ネットワークを通過する必要があります。

  • 内部設置型 VM にどのようなサーバー リソースを使用するか (Azure の RAM やディスクのサイズなど) は完全に制御できますが、あらかじめ構成されたサーバー サイズの一覧から選択する必要があります。DC の場合、オペレーティング システム ディスクに加えて、Windows Server Active Directory データベースを保存するためのデータ ディスクも必要です。

AD FS は、Azure の仮想マシンでの展開をサポートしています。ただし、ベスト プラクティスとしては、負荷分散、高可用性など、AD FS 自体に備わる機能よりも多くの機能を実現するテクノロジの併用を推奨しています。このようなテクノロジは、AD FS のネイティブ機能には含まれていないため、基になるインフラストラクチャにあらかじめ備わっていることが必要になります。たとえば、AD FS プロキシとセキュリティ トークン サービス (STS) のどちらのロールでも、負荷分散機能と高可用性機能の使用を強くお勧めしています。ところが、Azure では仮想マシンのプライベート インターフェイス (DIP) で負荷分散や高可用性の要件を満たすことができないため、一部の AD FS 展開構成に関していくらかの妥協が必要になります。

ベスト プラクティスをすべて満たし、妥協の必要がない AD FS を使用した展開構成の 1 つに、AD FS プロキシを社内 DMZ から Azure に移行するという方法があります。この構成では、VIP の Azure の負荷分散機能を利用します。これは、AD FS を実行するための負荷分散および高可用性のベスト プラクティスを完全に満たします。このシナリオの詳細については、「2. AD FS: 要求対応の内部設置型フロントエンド アプリケーションをインターネットに拡張する」を参照してください。

妥協が必要になる可能な AD FS 展開構成をよく理解するために、一般的な AD FS の内部設置型での展開方法に関する次の例を考えてみましょう。その後で、Azure の仮想マシンを使用する現在の状況と比較します。「AD FS の展開を計画する」から引用した次の図は、一般的な AD FS の展開を示しています。

AD FS WID とプロキシ

STS は企業のファイアウォールの内側に展開され、負荷分散のために NLB を使用します。企業ネットワークに接続しており、corp.fabrikam.com ドメインにログオンしているユーザーが、このシナリオで Office 365 にアクセスする必要がある場合、そのユーザーは STS の前にある負荷分散/高可用性エンドポイントにリダイレクトされます。

AD FS プロキシは境界ネットワークに展開され、外部ユーザーからの要求を負荷分散するために NLB を使用します。外部からの要求は最終的に、AD FS プロキシによって STS ロールの前にある負荷分散/高可用性エンドポイントに渡されます。

どのような場合にせよ、使用するインターフェイスに負荷分散と高可用性を実現することが推奨されます。これを実現するための手段は重要ではありません。NLB はあくまで例の 1 つとして使用しています。

noteメモ
このシナリオにおけるユーザーの認証方法の詳細については、「ADFS での Office 365 の操作方法」を参照してください。

ほとんどの場合、AD FS によって有効になるアプリケーションはミッション クリティカルであることが多いため、そこに障害の発生は許されません。AD FS はアプリケーションにアクセスする際のクリティカル パスに置かれているため、以下のベスト プラクティス (前の図にも示されています) に従うことを強く推奨しています。

  1. STS をインターネットに直接公開しない。

    セキュリティ面のベスト プラクティスは、STS インスタンスをファイアウォール内に配置したうえで企業ネットワークに接続し、インターネットに公開されないようにするというものです。STS ロールはセキュリティ トークンを発行するため、この操作は重要です。このようにすると、STS インスタンスにはドメイン コントローラーと同じレベルの保護が適用されます。STS がセキュリティで保護されていない状態にあると、悪意のあるユーザーが、信頼できる組織内にある証明書利用者アプリケーションと他の STS に対する要求が含まれる可能性のあるアクセス トークンを発行することができる状態になります。

  2. AD FS サービスは高い可用性を備えている必要がある。

    AD FS を必要とするアプリケーションがミッション クリティカルである場合、アプリケーションへのアクセスを維持するために、AD FS サービスは高い可用性を備えている必要があります。高可用性を実現するために、AD FS プロキシと STS の前には通常、ロード バランサーが展開されます。

次に、この構成を Azure の仮想マシンにどのように展開できるかを検討します。緑のチェック マークは、問題なくベスト プラクティスの要件を満たすことができることを示しています。赤の X は、Azure の仮想マシンを使用しても、この要件を満たすことができないことを示しています。

Windows Azure での AD FS とプロキシ

STS に負荷分散および高可用性が実現できていない点に注目してください。STS に対して負荷分散を実現する唯一の方法は、VIP を使用して STS を公開することです。DIP には負荷分散機能がないのに対し、VIP はネイティブの負荷分散機能を備えているためです。ところが、VIP を使用する方法では、(STS を直接インターネットに公開してはならないという) 1 つ目のベスト プラクティスに違反することになります。

つまり、このソリューションでは高可用性とセキュリティのいずれかの面で妥協が必要になります。アプリケーションがミッション クリティカルである場合には、AD FS がアプリケーションにアクセスする際のクリティカル パスに置かれているため、どのような点でも通常、妥協が許されません。

VIP を使用して STS を展開し、ファイアウォールを構成する方法はどうでしょうか?

VIP 自体にファイアウォールの制約を設定できる場合もありますが、指定した値に応じて長期にわたる安定性、構成、およびメンテナンスの要件を合理化する必要があります。どのようなルールを追加する必要があるか、プロキシと社内のユーザーが負荷分散された VIP エンドポイントにアクセスすることを許可する VIP のファイアウォール ルールをどのように表すかを検討してください。さらに、将来的に企業のネットワーク プロバイダーが変更になった場合に備えて、ACL のメンテナンスの流れや、プロバイダーの変更に伴ってアプリケーションに対するアクセスが失われる事態についての対応も検討が必要です。負荷分散については、Azure に置かれた STS の前に内部設置型の負荷分散テクノロジを展開することによって要件を満たすという方法があります。ただし、これはきわめて複雑な方法であると同時に、障害が発生した場合のトラブルシューティングが困難になるという問題があります。また、Azure に移行するそもそもの目的 (簡素化、コスト削減など) にも反するものと思われます。

目的が Office 365 のみの場合の代替策

目的が Office 365 のみである場合は、パスワード同期を使用しつつ、社内に DirSync を展開するという簡単な方法があります。これにより、展開の複雑な部分をほぼゼロにしながらも、同じ最終結果を得ることができます。注: この方法では AD FS や Azure は必要ありません。

次の表では、AD FS を展開した場合と展開しない場合のサインオン プロセスの動作を比較します。

 

AD FS と DirSync を使用した Office 365 のシングル サインオン DirSync とパスワード同期を使用した Office 365 の同じサインオン
  1. ユーザーは企業ネットワークにログオンして、Windows Server Active Directory に対して認証されます。

  2. ユーザーは Office 365 へのアクセスを試みます (@contoso.com を使用)。

  3. Office 365 はユーザーを Azure AD にリダイレクトします。

  4. Azure AD はユーザーを認証できず、内部設置型の AD FS との間に信頼関係があるものと認識するため、ユーザーは AD FS にリダイレクトされます。

  5. ユーザーは Kerberos チケットを AD FS STS に送信します。

  6. AD FS は Kerberos チケットを必要なトークン形式/クレームに変換し、ユーザーを Azure AD にリダイレクトします。

  7. ユーザーが Azure AD に認証されます (別の変換が行われます)。

  8. Azure AD はユーザーを Office 365 にリダイレクトします。

  9. ユーザーは暗黙のうちに Office 365 にサインインします。

  1. ユーザーは企業ネットワークにログオンして、Windows Server Active Directory に対して認証されます。

  2. ユーザーは Office 365 へのアクセスを試みます (@contoso.com を使用)。

  3. Office 365 はユーザーを Azure AD にリダイレクトします。

  4. Azure AD では Kerberos チケットを直接受理することができず、信頼関係が存在しないため、ユーザーに資格情報の入力を要請します。

  5. ユーザーは、同じ企業ネットワーク用パスワードを入力します。Azure AD は、DirSync で同期したユーザー名とパスワードに照らして入力内容を検証します。

  6. Azure AD はユーザーを Office 365 にリダイレクトします。

  7. ユーザーは、Azure AD トークンを使用して、Office 365 と OWA にサインオンできます。

DirSync とパスワード同期を使用するシナリオ (AD FS なし) では、シングル サインオンが "同一サインオン" に変わっています。ここで "同一" とは、Office 365 にアクセスするときにユーザー側で企業ネットワークと同じ資格情報を再入力する必要があることを指します。このデータは、入力回数を減らすために記憶しておくことができます。

結論

Azure VM に AD FS を展開するかどうかは、リスクとメリットの比較の問題です。Azure に AD FS 展開するメリットがリスクを上回る場合でも、採用の決定にあたっては、展開シナリオを考慮する必要があります。以下の表は、意思決定の要素をマトリックス形式で示したものです。

 

デプロイ メリット リスク

DIP のみを使用して STS を展開する

ベスト プラクティスのとおり、セキュリティ保護された展開を実現

高可用性と負荷分散が犠牲になっている

VIP を使用して STS を展開する

高可用性と負荷分散が実現

セキュリティ面で正規のベスト プラクティスに違反

VIP とファイアウォール ルールを使用して STS を展開する

セキュリティと高可用性を実現

複雑さが増し、構成が脆弱になる

Azure で DIP のみを使用する STS の前に内部設置型のロード バランサーを展開する

セキュリティと高可用性を実現

トラブルシューティングが複雑化

追加の思考材料

  • Windows Server AD FS プロキシを Azure の仮想マシンに展開する場合は、AD FS STS への接続が必要です。STS が内部設置型である場合は、仮想ネットワークで可能なサイト間 VPN 接続を活用して、プロキシが STS と通信できるようにすることをお勧めします。

  • Windows Server AD FS STS を Azure の仮想マシンに展開する場合は、Windows Server Active Directory ドメイン コントローラー、属性ストア、構成データベースへの接続が必要です。このほか、場合によってはサイト間 VPN が必要になります。

  • 課金はすべて Azure の仮想マシンの送信トラフィックに適用されます。コストが推進要因である場合は、AD FS プロキシを Azure に展開して、STS を内部設置型で残すことをお勧めします。STS を Azure の仮想マシン上にも展開するときは、社内ユーザーの認証にあたり追加のコストが発生します。Egress のトラフィックでは、VPN を走査しているかどうかにかかわらずコストが発生します。

  • AD FS STS に高可用性を実現することを目的として Azure のネイティブ サーバーの負荷分散機能を使用することにした場合には、その負荷分散機能にクラウド サービス内の仮想マシンの状態を確認できるプローブ機能が用意されていることに注意してください。Azure の仮想マシン (Web ロールまたは worker ロール以外) の場合は、カスタム プローブを使用する必要があります。既定のプローブに応答するエージェントが Azure の仮想マシン上にないためです。この調査が簡単になるように、カスタム TCP プローブを使用することもできます。この場合、TCP 接続 (syn ack) が正常に確立されるかどうかだけで、仮想マシンの正常性が判断されます。仮想マシン上のアクティブにリッスンしている TCP ポートを使用するように、カスタム プローブを構成できます。そのためには、Windows Azure のサイトで「LoadBalancerProbe スキーマ」を参照してください。

    noteメモ
    同じ一連のポート (ポート 80 や 443 など) をインターネットに直接公開する必要があるマシンは同じクラウド サービスを共有できません。したがって、Windows Server AD FS サーバー専用のクラウド サービスを作成して、アプリケーションと Windows Server AD FS に関するポートの要件が重複しないようにすることをお勧めします。

次のセクションでは、重要な考慮事項をわかりやすくするための一般的な展開シナリオについて概説します。各シナリオでは、意思決定事項と考慮すべき要因の詳細へのリンクを示します。

クラウドのみの AD DS デプロイ

図 1

SharePoint は Azure の仮想マシンに展開され、アプリケーションは企業のネットワーク リソースに依存していません。また、Windows Server AD DS が必要ですが、企業 Windows Server AD DS は不要です。Kerberos またはフェデレーションによる信頼関係は不要です。クラウド内の Azure の仮想マシンでもホストされている Windows Server AD DS ドメインに、ユーザーはアプリケーションから自己プロビジョニングされないためです。

  • ネットワーク トポロジ: クロスプレミス接続 (サイト間接続) を使用しない Azure の仮想ネットワークを作成します。

  • DC の展開構成: 新しいドメイン コントローラーを単一ドメインの新しい Windows Server Active Directory フォレストに展開します。Windows DNS サーバーと共に展開する必要があります。

  • Windows Server Active Directory のサイト トポロジ: 既定の Windows Server Active Directory サイトを使用します (すべてのコンピューターは Default-First-Site-Name サイトに配置されます)。

  • IP アドレス指定と DNS:

    • DHCP によってリースされたアドレスを使用します。VM をシャットダウンしても DHCP によってリースされたアドレスを保持するには、Set-AzureStaticVNetIP Azure PowerShell コマンドレットを使用します。

    • Azure 上のドメイン コントローラーに Windows Server DNS をインストールして構成します。

    • DC および DNS サーバー ロールをホストする VM の名前と IP アドレスを使用して、仮想ネットワークのプロパティを構成します。

  • グローバル カタログ: フォレスト内の最初の DC はグローバル カタログ サーバーとして構成する必要があります。追加の DC も GC として構成する必要があります。単一ドメイン フォレストでは、グローバル カタログに DC からの追加の処理が不要なためです。

  • Windows Server AD DS データベースと SYSVOL の配置: Windows Server Active Directory データベース、ログ、SYSVOL を格納するために、Azure VM として実行されている DC にデータ ディスクを追加します。

  • バックアップと復元: システムの状態のバックアップを保存する場所を決定します。必要に応じて、バックアップを保存するために DC VM に別のデータ ディスクを追加します。

クロスプレミス接続を使用したフェデレーション

図 2

内部設置型で展開されて企業ユーザーによって使用されている要求対応のアプリケーションがインターネットから直接アクセス可能になる必要があります。アプリケーションはデータを保存および取得する SQL データベースへの Web フロントエンドとして機能しています。アプリケーションによって使用される SQL サーバーは企業ネットワークにも配置されています。2 つの Windows Server AD FS STS と 1 つのロードバランサーが企業ユーザーによるアクセス用に内部設置型で展開されています。アプリケーションは、企業 ID を使用してビジネス パートナーによっても、既存の企業ユーザーによっても、インターネット経由で直接アクセスされることが必要になりました。

この新しい要件について展開と構成のニーズをより簡単に満たすために決定したのは、2 つの追加の Web フロントエンドと 2 つの Windows Server AD FS プロキシ サーバーを Azure の仮想マシンにインストールすることです。4 つの VM はすべてインターネットに直接接続され、Azure 仮想ネットワークのサイト間 VPN 機能を使用して内部設置型ネットワークに接続されます。

  • ネットワーク トポロジ: Azure の仮想ネットワークを作成し、クロスプレミス接続を構成します。

    noteメモ
    Windows Server AD FS の各証明書について、証明書テンプレート内で定義されている URL とそのリンク先の証明書に、Azure で実行されている Windows Server AD FS インスタンスからアクセスできることを確認します。そのために PKI インフラストラクチャ コンポーネントへのクロスプレミス接続が必要になる場合があります。たとえば、CRL のエンドポイントが LDAP ベースであり、内部設置型でのみホストされている場合は、クロスプレミス接続が必要になります。クロスプレミス接続を望まない場合は、CRL がインターネット経由でアクセス可能な CA 発行の証明書の使用が必要になることがあります。

  • クラウド サービスの構成: 2 つの負荷分散 VIP を提供するために 2 つのクラウド サービスがあることを確認します。最初のクラウド サービスの VIP は、ポート 80 と 443 を使用する 2 つの Windows Server AD FS プロキシ VM に割り振られます。Windows Server AD FS プロキシ VM は、Windows Server AD FS STS に接続された内部設置型ロード バランサーの IP アドレスを参照するように構成されます。2 番目のクラウド サービスの VIP は、同様にポート 80 と 443 を使用する Web フロントエンドを実行する 2 つの VM に割り振られます。機能中の Windows Server AD FS プロキシと Web フロントエンドの VM にのみロード バランサーがトラフィックを確実に割り振るように、カスタム プローブを構成します。

  • フェデレーション サーバーの構成: クラウド内に作成した Windows Server Active Directory フォレストのセキュリティ トークンを生成するように、Windows Server AD FS をフェデレーション サーバー (STS) として構成します。フェデレーション要求プロバイダーと ID 提供元のさまざまなパートナーとの信頼関係を設定します。また、証明書利用者とトークン生成先のさまざまなアプリケーションとの信頼関係を構成します。

    ほとんどのシナリオでは、Windows Server AD FS プロキシ サーバーはセキュリティ上の目的で展開されてインターネットに接続されますが、対応する Windows Server AD FS フェデレーション サーバーはインターネットに直接接続できないように分離されたままになります。展開シナリオに関係なくクラウド サービスの構成では、公開される IP アドレスを提供する VIP を設定する必要があります。また、2 つの Windows Server AD FS STS インスタンスまたはプロキシ インスタンス間の負荷分散に使用するポートも設定する必要があります。

  • Windows Server AD FS の高可用性構成: Windows Server AD FS ファームの展開では、フェールオーバーおよび負荷分散用のサーバーを 2 つ以上配置することをお勧めします。Windows Server AD FS 用に Windows Internal Database (WID) の使用や、ファーム内のサーバー間での受信要求の負荷分散用に Azure のネイティブのサーバー負荷分散機能の使用を検討することもできます。Azure のネイティブの負荷分散は、インターネットに接続された VIP を使用している場合にのみサポートされます。DIP は負荷分散できません。

    詳細については、AD FS 2.0 の展開ガイドラインを参照してください。

クロスプレミス AD DS デプロイ

図 3

Windows 統合認証をサポートし、構成およびユーザー プロファイル データのリポジトリとして Windows Server AD DS を使用する LDAP 対応アプリケーションが Azure の仮想マシンに展開されています。アプリケーションでは既存の企業 Windows Server AD DS を活用し、シングル サインオンが可能になる必要があります。アプリケーションは要求対応ではありません。また、ユーザーがインターネットから直接アプリケーションにアクセスする必要があります。パフォーマンスとコストを最適化するために決定したのは、企業ドメイン内の 2 つの追加のドメイン コントローラーをアプリケーションと共に Azure に展開することです。

  • ネットワーク トポロジ: Azure の仮想ネットワークを作成し、クロスプレミス接続を構成します。そのためには、互換性のある VPN エンドポイントを企業ネットワークの境界に展開することが必要になります。詳細については、「仮想ネットワークに使用する VPN デバイスについて」を参照してください。

  • インストール方法: 企業 Windows Server Active Directory ドメインからレプリカ DC を展開します。レプリカ DC 用に Windows Server AD DS を VM にインストールできます。また必要に応じて、メディアからのインストール機能 (IFM) を使用して、インストール時に新しい DC にレプリケートする必要があるデータの量を減らすことができます。チュートリアルについては、「Install a Replica Active Directory Domain Controller in Azure Virtual Networks (Azure の仮想ネットワークにレプリカ Active Directory ドメイン コントローラーをインストールする)」を参照してください。IFM 使用する場合でも、仮想 DC を内部設置型で構築して VHD 全体をクラウドに移動する方が、インストール時に Windows Server AD DS をレプリケートするよりも効率的なことがあります。セキュリティ上の理由から、VHD は Azure へのコピー後に内部設置型ネットワークから削除することをお勧めします。

  • Windows Server Active Directory のサイト トポロジ: Active Directory サイトとサービスで新しい Azure サイトを作成します。Azure 仮想ネットワークを表す Windows Server Active Directory サブネット オブジェクトを作成し、そのサブネットを新しい Azure サイトに追加します。新しいサイト リンクを作成し、そのリンクに新しい Azure サイト、および Azure 仮想ネットワークの VPN エンドポイントがあるサイトを追加します。その目的は、Azure に対する送受信の Windows Server Active Directory トラフィックを制御および最適化することにあります。

  • IP アドレス指定と DNS:

    • DHCP によってリースされたアドレスを使用します。VM をシャットダウンしても DHCP によってリースされたアドレスを保持するには、Set-AzureStaticVNetIP Azure PowerShell コマンドレットを使用します。

    • Azure 上のドメイン コントローラーに Windows Server DNS をインストールして構成します。

    • DC および DNS サーバー ロールをホストする VM の名前と IP アドレスを使用して、仮想ネットワークのプロパティを構成します。

  • 地理的に分散された DC: 必要に応じて追加の仮想ネットワークを構成します。仮想ネットワーク間で直接通信が必要な場合は、両方の仮想ネットワークでサイト間 VPN 機能を使用するように構成する必要があります。それにより、仮想ネットワーク間のすべてのトラフィックが社内ネットワークを通ってルーティングされるようになります。

  • 読み取り専用 DC: Azure サイトに RODC を展開する場合があります。この展開は、DC に対する書き込み操作を実行するための要件や、サイト内のアプリケーションやサービスと RODC との互換性に応じて行います。アプリケーションの互換性の詳細については、「アプリケーションと読み取り専用ドメイン コントローラーの互換性」を参照してください。

  • グローバル カタログ: GC はマルチドメイン フォレストでログオン要求を処理するために必要です。Azure サイトに GC を展開しない場合は、認証要求で他のサイトの GC を照会するため、送信トラフィックのコストが発生します。そのようなトラフィックを最小限に抑えるには、Active Directory サイトとサービスで、Azure サイトに対してユニバーサル グループ メンバーシップのキャッシュを有効にすることができます。

    GC を展開する場合は、Azure サイトの GC が、同じドメイン パーティションの一部をレプリケートする必要がある他の GC によってソース DC として優先されないように、サイト リンクとサイト リンク コストを構成します。

  • Windows Server AD DS データベースと SYSVOL の配置: Windows Server Active Directory データベース、ログ、SYSVOL を格納するために、Azure VM で実行されている DC にデータ ディスクを追加します。

  • バックアップと復元: システムの状態のバックアップを保存する場所を決定します。必要に応じて、バックアップを保存するために DC VM に別のデータ ディスクを追加します。

この表では、前に示したシナリオで適用した Windows Server Active Directory のテクノロジ分野、対応する意思決定事項、考慮すべき要因をまとめています。この後に示す詳細へのリンクも示しています。テクノロジ分野によっては、一部の展開シナリオに適用できない場合や、他のテクノロジ分野よりも展開シナリオに重要になる場合があります。

たとえば、仮想ネットワークにレプリカ DC を展開しており、フォレストに 1 つのドメインしかない場合、グローバル カタログ サーバーを展開することにしても、グローバル カタログはその展開シナリオに重要ではありません。グローバル カタログには追加のレプリケーションが不要なためです。一方、フォレストに複数のドメインがある場合、仮想ネットワークにグローバル カタログを展開することにすると、使用可能な帯域幅、パフォーマンス、認証、ディレクトリ検索などに影響を与えることができます。

 

項目番号

Windows Server Active Directory のテクノロジ分野

決定事項

要素

1

ネットワーク トポロジ

仮想ネットワークを作成するか。

会社のリソースにアクセスするための要件

認証

アカウント管理

2

DC の展開構成

  • 信頼関係を使用しない個別のフォレストを展開するか。

  • フェデレーションを使用する新しいフォレストを展開するか。

  • Kerberos による Windows Server Active Directory フォレストの信頼関係を使用する新しいフォレストを展開するか。

  • レプリカ DC を展開することで会社のフォレストを拡張するか。

  • 新しい子ドメインやドメイン ツリーを展開することで会社のフォレストを拡張するか。

セキュリティ

コンプライアンス

コスト

回復性とフォールト トレランス

アプリケーションの互換性

3

Windows Server Active Directory のサイト トポロジ

トラフィックを最適化してコストを最小限に抑えるために、サブネットとサイト、さらに Azure 仮想ネットワークとのサイト リンクをどのように構成するか。

サブネットとサイトの定義

サイト リンクのプロパティと変更通知

レプリケーション圧縮

4

IP アドレス指定と DNS

IP アドレスと名前解決をどのように構成するか。

Azure DHCP によってリースされたアドレスのみを使用する

Windows Server DNS サーバーをインストールする

5

地理的に分散された DC

個別の仮想ネットワーク上の DC にどのようにレプリケートするか。

地理的に分散された仮想ネットワーク間に直接通信はない

6

読み取り専用 DC

読み取り専用 DC または書き込み可能 DC を使用するか

HBI/PII 属性のフィルター処理

機密データのフィルター処理

送信トラフィックの制限

7

グローバル カタログ

グローバル カタログをインストールするか。

単一ドメイン フォレストの場合、すべての DC を GC として構成する

マルチドメイン フォレストの場合、GC は認証に必要になる

8

インストール方法

Azure に DC をどのようにインストールするか。

Important重要
Sysprep を使用して DC を複製しないでください。ただし、Windows Server 2012 を実行する Azure の仮想マシンでは仮想ドメイン コントローラーの複製を使用できます。

  • Windows PowerShell または Dcpromo を使用して AD DS をインストールする

または

  • 内部設置型の仮想 DC の VHD を移動する

9

Windows Server AD DS データベースと SYSVOL の配置

Windows Server AD DS データベース、ログ、SYSVOL をどこに保存するか。

Dcpromo.exe の既定値を変更する

Important重要
これらの重要な Active Directory ファイルは必ず、書き込みキャッシュを実装するオペレーティング システム ディスクではなく、Azure データ ディスクに配置してください。

10

バックアップと復元

データをどのように保護および復元するか。

システムの状態のバックアップを作成する

VHD ファイルをコピーまたは複製しない

11

フェデレーション サーバーの構成

クラウド内でフェデレーションを使用する新しいフォレストを展開するか。

AD FS を内部設置型で展開し、クラウド内でプロキシを公開するか。

セキュリティ

コンプライアンス

コスト

ビジネス パートナーによるアプリケーションへのアクセス

12

クラウド サービスの構成

仮想マシンを初めて作成すると、クラウド サービスは暗黙に展開される。追加のクラウド サービスを展開する必要があるか。

VM にインターネットへの直接接続が必要か。

サービスに負荷分散が必要か。

13

パブリックおよびプライベート IP のアドレス指定に関するのフェデレーション サーバーの要件 (DIP と VIP)

Windows Server AD FS インスタンスにインターネットから直接アクセスする必要があるか。

クラウドに展開するアプリケーションにインターネット接続専用の IP アドレスとポートが必要か。

展開に必要な VIP ごとに 1 つのクラウド サービスを作成する

14

Windows Server AD FS の高可用性構成

Windows Server AD FS サーバー ファーム内のノードの数は?

Windows Server AD FS プロキシ ファームに展開するノードの数は?

回復性とフォールト トレランス

Windows Server AD DS の IP アドレスの整合性と DNS の要件を満たすには、Azure の仮想ネットワークをまず作成し、仮想マシンをその仮想ネットワークに接続する必要があります。仮想ネットワークの作成時、必要に応じて内部設置型の企業ネットワークにも接続可能にするかどうかを決定する必要があります。接続可能にすると、Azure の仮想マシンが内部設置型コンピューターに透過的に接続するようになります。この接続性は、従来の VPN テクノロジを使用して実現され、VPN エンドポイントを企業ネットワークの境界に展開することが必要です。つまり、VPN は Azure から企業ネットワークに開始されます。その逆には開始されません。

仮想ネットワークを内部設置型ネットワークに拡張すると、各 VM に適用される標準の課金に加算して追加の課金が適用されることに注意してください。具体的には、Azure 仮想ネットワーク ゲートウェイの CPU 時間に対する課金、内部設置型コンピューターと通信する VPN 内の各 VM によって生成される送信トラフィックに対する課金などです。ネットワーク トラフィックの料金の詳細については、「Azure 料金早見表」を参照してください。

DC の構成方法は、Azure で実行されるサービスの要件によって異なります。たとえば、企業フォレストから分離した新しいフォレストを展開して、概念実証、新しいアプリケーション、その他の短期プロジェクトのテストに使用する場合があります。このようなテストでは、ディレクトリ サービスが必要で企業の内部リソースへのアクセスが不要なためです。

利点として、分離したフォレストの DC が内部設置型の DC からレプリケートされないため、システム自体によって生成される送信ネットワーク トラフィックが減り、コストの削減に直接つながります。ネットワーク トラフィックの料金の詳細については、「Azure 料金早見表」を参照してください。

別の例として、サービスに関するプライバシーの要件があることが前提ですが、サービスは内部 Windows Server Active Directory へのアクセスに依存する場合があります。クラウド内のサービスのデータをホスト可能であれば、内部フォレストの新しい子ドメインを Azure に展開してもかまいません。この場合、新しい子ドメインの DC を展開できます (プライバシーの問題への対処支援用にグローバル カタログは使用しません)。このシナリオでは、レプリカ DC の展開も必要になるため、内部設置型 DC との接続用に仮想ネットワークが必要です。

新しいフォレストを作成する場合は、Active Directory による信頼関係を使用するかフェデレーションによる信頼関係を使用するかを選択します。互換性、セキュリティ、コンプライアンス、コスト、回復性間のバランスを考慮して要件を調整します。たとえば、認証の選択を利用するために、Azure に新しいフォレストを展開し、内部設置型のフォレストとクラウドのフォレストとの間に Windows Server Active Directory による信頼関係を作成してもかまいません。ただし、アプリケーションが要求対応である場合は、Active Directory フォレストによる信頼関係ではなく、フェデレーションによる信頼関係を展開することもできます。考慮すべき別の要因はコストです。内部設置型 Windows Server Active Directory をクラウドに拡張することで、レプリケートするデータが増えたり、認証と照会の処理により生成される送信トラフィックも増えたりするので、そのために必要なコストが問題になります。

可用性とフォールト トレランスの要件も意思決定に影響を与えます。たとえば、リンクが中断された場合、Azure に十分なインフラストラクチャを展開していない限り、Kerberos による信頼関係またはフェデレーションによる信頼関係を利用するアプリケーションは、まったく使用できなくなる可能性が高くなります。レプリカ DC (書き込み可能 DC または RODC) など代替の展開構成を用意することで、リンクの停止を許容できる可能性が高くなります。

トラフィックを最適化してコストを最小限に抑えるには、サイトとサイト リンクを正しく定義する必要があります。サイト、サイト リンク、サブネットは DC 間のレプリケーション トポロジと認証トラフィックのフローに影響を与えます。次に示すトラフィックに対する課金を検討してから、展開シナリオの要件に応じて DC を展開して構成します。

  • ゲートウェイ自体に対して時間単位でわずかな課金が発生する。

    • 必要に応じてゲートウェイを起動/停止できます。

    • 停止した場合、Azure VM は企業ネットワークから分離されます。

  • 受信トラフィックは無料である。

  • 送信トラフィックに対して「Azure 料金早見表」に従って課金される。内部設置型のサイトとクラウドのサイトとの間のサイト リンクのプロパティは次のように最適化できます。

    • 複数の仮想ネットワークを使用している場合は、サイト リンクとそれらのコストを適切に構成することで、Windows Server AD DS によって Azure サイトが、同レベルのサービスを無料で提供できるサイトより優先されないようにします。[サイト リンクをすべてブリッジ] を無効にすることを検討してもかまいません (既定で有効になっています)。これにより確実に、直接接続されているサイトのみが相互にレプリケートされるようになります。推移的に接続されるサイト内の DC は以降互いに直接レプリケートできなくなります。代わりに、共通のサイトを介してレプリケートすることが必要になります。このような仲介サイトが何らかの理由で使用できなくなった場合、推移的に接続されるサイトにある DC 間のレプリケーションは、サイト間の接続が使用可能であっても実行されません。したがって、推移的に接続されるサイトでレプリケーション動作が必要な場合は、該当するサイト リンクやサイト (内部設置型サイトや企業ネットワーク サイトなど) を含むサイト リンク ブリッジを作成します。

    • 意図しないトラフィックを避けるように適切にサイト リンクのコストを構成します。たとえば、[次に最も近いサイトを試す] 設定が有効になっている場合、確実に仮想ネットワークのサイトが次に最も近いサイトにならないようにします。そのためには、企業ネットワークに Azure サイトを接続するサイト リンク オブジェクトのコストを増やします。

    • サイト リンク オブジェクトの整合性の要件と変更の頻度に応じて、サイト リンクの間隔スケジュールを構成します。許容される遅延時間に合わせてレプリケーションのスケジュールを調整します。DC は値の最後の状態のみをレプリケートするため、レプリケーション間隔を短くすると、オブジェクトの変更頻度が最小限に抑えられていれば、コストを節約できます。

  • コストを最小限に抑えることが優先事項である場合は、レプリケーションがスケジュールされていること、変更通知が有効になっていないことを確認します。これはサイト間のレプリケート時の既定の構成です。仮想ネットワークに RODC を展開する場合、この構成は重要ではありません。RODC は送信方向で変更をレプリケートしないためです。しかし、書き込み可能 DC を展開する場合は、不要に高い頻度で変更をレプリケートするようにサイト リンクが構成されていないことを確認します。グローバル カタログ サーバー (GC) を展開する場合は、GC を含む他のすべてのサイトが、Azure サイトの GC よりコストが低いサイト リンクに接続されたサイトのソース DC から、ドメイン パーティションをレプリケートすることを確認します。

  • さらに、レプリケーションの圧縮アルゴリズムを変更することで、サイト間のレプリケーションによって生成されるネットワーク トラフィックを減らすこともできます。圧縮アルゴリズムは、REG_DWORD レジストリ エントリである HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Replicator compression algorithm によって制御されます。既定値は 3 で、Xpress 圧縮アルゴリズムを指定しています。値を 2 に変更して、アルゴリズムを MSZIP に変更できます。ほとんどの場合、これにより圧縮率は高くなりますが、CPU 使用率も高くなってしまいます。詳細については、「Active Directory のレプリケーション トポロジのしくみ」を参照してください。

Azure の仮想マシンには、"DHCP によってリースされたアドレス" が既定で割り当てられます。Azure 仮想ネットワークの動的アドレスは仮想マシンの有効期間にわたって仮想マシンで保持されるため、Windows Server AD DS の要件が満たされます。

結果的に、Azure で動的アドレスを使用すると、実際には静的 IP アドレスを使用していることになります。アドレスはリース期間にわたって割り振り可能であり、リース期間はクラウド サービスの有効期間と等しくなるためです。

ただし、VM がシャットダウンされると、動的アドレスの割り当ては解除されます。IP アドレスの割り当てが解除されないようにするには、Set-AzureStaticVNetIP を使用して、静的 IP アドレスを割り当ててください

名前解決用には、独自の DNS サーバー インフラストラクチャを展開します (既存のものを活用してもかまいません)。Azure が提供する DNS は Windows Server AD DS の高度な名前解決のニーズを満たしません。たとえば、Azure の DNS は動的 SRV レコードなどをサポートしていません。名前解決は DC にも、ドメインに参加するクライアントにも重要な構成項目です。DC はリソース レコードを登録し、他の DC のリソース レコードを解決できる必要があります。

フォールト トレランスとパフォーマンス上の理由から、Azure で動作する DC に Windows Server DNS サービスをインストールするのが最適です。さらに、DNS サーバーの名前と IP アドレスを使用して、Azure の仮想ネットワークのプロパティを構成します。この場合は、仮想ネットワーク上の他の VM が起動したときに、動的 IP アドレスの割り当ての一環として、DNS クライアント リゾルバー設定が DNS サーバーと共に構成されます。

noteメモ
Azure で直接ホストされている Windows Server AD DS Active Directory ドメインにインターネット経由で内部設置型コンピューターを参加させることはできません。Active Directory とドメイン参加操作に関するポートの要件により、必要なポート (実際は DC 全体) をインターネットに直接公開することは実際にはできません。

VM は VM 自体の DNS 名を起動時または名前変更時に自動的に登録します。

この例の詳細と、最初の VM をプロビジョニングしてその VM に AD DS をインストールする別の例については、「Install a new Active Directory forest on an Azure virtual network (Windows Azure での新しい Active Directory フォレストのインストール)」を参照してください。Windows PowerShell の使用の詳細については、「Azure PowerShell の概要」および「Azure の管理コマンドレット」を参照してください。

複数の DC をそれぞれ異なる仮想ネットワークでホストする場合、Windows Azure には次の利点があります。

  • マルチサイトのフォールト トレランス

  • ブランチ オフィスへの物理的な近さ (遅延時間の短縮)

しかし、Windows Azure の仮想ネットワーク間に直接通信は存在しません。異なる Windows Azure の仮想ネットワーク間のすべての通信は内部設置型ネットワークを通ってルーティングされる必要があります。そのため、大量の送信トラフィック (さらにそのトラフィックに関連するコスト) が発生する場合があります。

仮想ネットワーク間の接続なし

図 4

読み取り専用 DC を展開するか書き込み可能 DC を展開するかを選択する必要があります。多くの場合 RODC を展開します。RODC は物理的に制御することはありませんが、物理的なセキュリティ リスクがある場所 (ブランチ オフィスなど) に展開するように設計されているためです。

Windows Azure でブランチ オフィスの物理的なセキュリティ リスクが生じるわけではありませんが、RODC のコスト効果がより高いことが実証される場合があります。RODC の機能は、理由はさまざまにせよ、これらの環境によく適しているためです。たとえば、RODC では送信方向のレプリケーションがなく、機密データ (パスワード) を選択して取り込むことができます。欠点として、ユーザーまたはコンピューターの認証時、これらの機密データが不足していると検証されるため、オンデマンドの送信トラフィックが発生する場合があります。しかし、機密データは選択してあらかじめ取り込んでキャッシュできます。

RODC にはさらに HBI および PII 関連の利点があります。機密データを保存する属性を、RODC で除外される属性セット (FAS) に追加できるためです。FAS は、RODC にレプリケートされない属性のカスタマイズ可能なセットです。Windows Azure での PII または HBI の保存を望まないか許可されていない場合は、FAS を保護対策として使用できます。詳細については、「RODC で除外される属性セット」を参照してください。

アプリケーションと使用予定の RODC とに互換性があることを確認します。Windows Server Active Directory 対応の多くのアプリケーションは RODC と互換性がありますが、書き込み可能 DC にアクセスできない場合、効率的または正常に実行できないアプリケーションもあります。詳細については、「アプリケーションと読み取り専用ドメイン コントローラーの互換性」を参照してください。

グローバル カタログをインストールするかどうかを選択する必要があります。単一ドメイン フォレストでは、すべての DC をグローバル カタログ (GC) サーバーとして構成する必要があります。それによりコストが増加することはありません。追加のレプリケーション トラフィックが発生することがないためです。

マルチドメイン フォレストでは、GC は認証プロセス中にユニバーサル グループのメンバーシップを取得するために必要です。GC を展開しない場合、Windows Azure 上の DC に対して認証を行う仮想ネットワークのワークロードにより、送信認証トラフィックが間接的に発生します。認証が試みられるたびに内部設置型の GC が照会されるためです。

GC に関連するコストはほとんど予測できません。各 GS がそれぞれのドメイン (その一部) をホストするためです。このワークロードでインターネットに公開されたサービスがホストされ、Windows Server AD DS に対してユーザーが認証される場合、コストはまったく予測できないことがあります。認証時にクラウド サイトの外での GC への照会を減らすには、ユニバーサル グループ メンバーシップ キャッシュを有効にするのが効果的です。

仮想ネットワークに DC をインストールする方法を選択する必要があります。

DC には、Azure の仮想マシン (Windows Azure の Web または worker ロールの VM 以外) のみを使用します。Azure の仮想マシンは持続的であり、DC には持続性が必要なためです。Azure の仮想マシンは DC などのワークロード用に設計されています。

SYSPREP を使用して DC を展開したり複製したりしないでください。DC の複製機能は Windows Server 2012 以降でのみ使用できます。DC の複製機能には、依存先のハイパーバイザーで VMGenerationID のサポートが必要です。Windows Server 2012 の Hyper-V と Windows Azure の仮想ネットワークは両方とも、サード パーティ製の仮想化ソフトウェア ベンダーと同様に、VMGenerationID をサポートしています。

Windows Server AD DS のデータベース、ログ、SYSVOL を検索する場所を選択します。それらのデータは Azure データ ディスクに展開する必要があります。“

noteメモ
Azure データ ディスクは 1 TB に制限されます。

データ ディスク ドライブは既定で書き込みデータをキャッシュしません。VM に接続されたデータ ディスク ドライブはライト スルー キャッシュを使用します。ライト スルー キャッシュでは、VM のオペレーティング システムの観点からトランザクションが完了するに、持続的な Azure ストレージに書き込みデータがコミットされます。これにより、書き込みが若干遅くなるものの、持続性が得られます。

この動作は Windows Server AD DS に重要です。後書きディスク キャッシュでは DC による推測データが無効になるためです。Windows Server AD DS は書き込みキャッシュを無効にしようとしますが、その無効化を許可するかどうかはディスク IO システムによります。書き込みキャッシュを無効にできない場合は、特定の状況下で USN ロールバックが行われて、結果的に残留オブジェクトやその他の問題につながります。

仮想 DC に関するベスト プラクティスとして、以下を行ってください。

  • Azure データ ディスクの [ホスト キャッシュ設定] を [なし] に設定します。そうすれば、AD DS 操作の際に書き込みキャッシュに関する問題が発生しません。

  • データベース、ログ、SYSVOL をすべて同じデータ ディスクに保存するか、別々のデータ ディスクに保存します。これは通常、オペレーティング システム自体に使用されるディスクとは別のディスクです。重要なのは、Windows Server AD DS のデータベースと SYSVOL を Azure オペレーティング システム ディスクに保存しないということです。既定では、AD DS のインストール プロセスによりこれらのコンポーネントは %systemroot% フォルダーにインストールされますが、Azure にはお勧めしません。

一般的には何が DC のバックアップと復元用にサポートされているかどうか、より正確に言うと、VM で実行されるかどうに注意してください。「仮想化ドメイン コントローラーのバックアップと復元に関する考慮事項」を参照してください。

Windows Server AD DS に関するバックアップの要件を厳密に満たしているバックアップ ソフトウェア (Windows Server バックアップなど) のみを使用して、システムの状態のバックアップを作成します。

DC の VHD ファイルをコピーまたは複製しないで、DC の定期的なバックアップを行ってください。復元が必要になった場合、複製またはコピーした VHD を使用して、Windows Server 2012 とサポートされているハイパーバイザーなしで復元を行うと、USN バブルが発生します。

Windows Server AD FS フェデレーション サーバー (STS) の構成の一部は、Azure に展開するアプリケーションが内部設置型ネットワーク上のリソースにアクセスする必要があるかどうかによって異なります。

アプリケーションが次の条件を満たしている場合は、内部設置型ネットワークから分離してアプリケーションを展開できます。

  • SAML セキュリティ トークンを受け取る。

  • インターネットに接続できる。

  • 内部設置型リソースにアクセスしない。

この場合、Windows Server AD FS STS を次のように構成します。

  1. Azure で分離した単一ドメイン フォレストを構成します。

  2. Windows Server AD FS フェデレーション サーバー ファームを構成することで、フォレストへのフェデレーション アクセスを可能にします。

  3. 内部設置型フォレストで Windows Server AD FS (フェデレーション サーバー ファームとフェデレーション サーバー プロキシ ファーム) を構成します。

  4. 内部設置型と Azure の Windows Server AD FS インスタンス間でフェデレーションによる信頼関係を確立します。

一方、アプリケーションで内部設置型リソースへのアクセスが必要な場合は、Azure 上の Windows Server AD FS とアプリケーションを次のように構成できます。

  1. 内部設置型ネットワークと Azure との間の接続を構成します。

  2. 内部設置型フォレストで Windows Server AD FS フェデレーション サーバー ファームを構成します。

  3. Azure で Windows Server AD FS フェデレーション サーバー プロキシ ファームを構成します。

この構成は内部設置型リソースの漏えいリスクを軽減できる利点があります。境界ネットワーク内で Windows Server AD FS とアプリケーションを構成することに似ています。

どちらのシナリオでも、企業間のグループ作業が必要な場合は、ID プロバイダーを増やしてそれらのプロバイダーとの信頼関係を確立できることに注意してください。

インターネットに VM を直接接続したり、インターネットに接続された負荷分散アプリケーションを公開したりする場合は、クラウド サービスが必要です。これが可能なのは、各クラウド サービスに 1 つの構成可能な VIP が割り当てられるためです。

各 Azure の仮想マシンは DIP を受け取ります。DIP は、Azure 内でのみアクセス可能なプライベート アドレスです。ただしほとんどの場合、Windows Server AD FS 展開用に VIP を構成する必要があります。VIP は、Windows Server AD FS のエンドポイントをインターネットに公開するために必要で、フェデレーション パートナーやクライアントによって認証と継続的な管理に使用されます。VIP は、1 つ以上の Azure の仮想マシンを含むクラウド サービスのプロパティです。Azure に展開された要求対応のアプリケーションと Windows Server AD FS の両方がインターネットに接続し、同じポートを共有する場合は、それぞれに専用の VIP が必要になります。したがって、アプリケーション用と Windows Server AD FS 用にそれぞれ 1 つのクラウド サービスを作成する必要があります。

VIP および DIP という用語の定義については、「用語と定義」を参照してください。

スタンドアロン Windows Server AD FS フェデレーション サービスを展開することはできますが、運用環境の AD FS STS とプロキシ用に、2 つ以上のノードを備えたファームを展開することをお勧めします。

特定のニーズに最適な展開構成オプションを決定するには、AD FS 2.0 の設計ガイドの「AD FS 2.0 の展開テクノロジに関する考慮事項」を参照してください。

noteメモ
Azure で Windows Server AD FS のエンドポイントの負荷分散を行うには、同じクラウド サービス内の Windows Server AD FS ファームのすべてのメンバーが HTTP ポート (既定では 80) と HTTPS ポート (既定では 443) に Azure の負荷分散機能を使用するように構成します。詳細については、Azure サイトで「LoadBalancerProbe スキーマ」を参照してください。

Windows Server のネットワーク負荷分散 (NLB) は Azure でサポートされていません。

表示:
© 2014 Microsoft