セールス: 1-800-867-1380

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

更新日: 2014年11月

このペーパーでは、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 のデプロイメントを計画する」を参照してください。

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

  • 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 に依存するその他の処理にもエラーが発生することです。ユーザーはキャッシュされた既存の資格情報を使用してログオンできる場合がありますが、チケットが未発行だったり期限切れだったりすると、ピア間またはクライアント サーバー間の認証の試みはすべて失敗します。

    デモ ビデオやステップバイステップ チュートリアルの一覧については、「仮想ネットワーク」の「管理ポータルでのサイト間 VPN の構成」などを参照してください。

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

  2. 静的 IP アドレスは、Azure PowerShell を使用して構成する必要があります。

    既定では動的アドレスが割り当てられますが、Set-AzureStaticVNetIP コマンドレットを使用して、代わりに静的 IP アドレスを割り当てます。これにより、サービス復旧および VM シャットダウン/再起動の実行中に維持される静的 IP アドレスが設定されます。詳細については、「VM 用の静的内部 IP アドレス (DIP) の構成」を参照してください。

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

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

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

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

  • 動的 IP アドレス (DIP):これは、内部専用の IP アドレスです。(Set-AzureStaticVNetIP コマンドレットを使用して) DC/DNS サーバー ロールをホストする VM 用の静的 IP アドレスとして構成する必要があります。

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

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

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

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

    • VM が仮想ネットワークに接続されていて、VM の IP アドレスが静的である場合、仮想ネットワーク アダプターの IP 構成が変更されない。

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

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 以降を実行しているドメイン コントローラーには、追加で保護機能が備わっていることになります。

noteメモ
ゲスト オペレーティング システム内でドメイン コントローラー ロールを実行する VM を、Azure の管理ポータルでの [シャットダウン] オプションを使用せずに、シャットダウンし、再起動する必要があります。現在のところ、管理ポータルを使用して VM をシャットダウンすると、VM の割り当ては解除されます。割り当てが解除された VM では料金が発生しないという利点がありますが、VM-GenerationID がリセットされます。これは DC に対しては望ましくありません。VM-GenerationID がリセットされると、AD DS データベースの invocationID もリセットされ、RID プールは破棄され、SYSVOL は権限がないとマークされます。詳細については、「Active Directory ドメイン サービス (AD DS) の仮想化の概要 (レベル 100)」と「DFSR の安全な仮想化」を参照してください。

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 の仮想ネットワークで動作していることを前提とします。

  • 内部設置型の DC と同様に、静的 IP アドレスをお勧めします。Azure PowerShell を使用しなければ、静的 IP アドレスを構成できません。「VM 用の静的内部 IP アドレス (DIP) の構成」を参照してください。ゲスト オペレーティング システム内で静的 IP アドレスの構成を確認する監視システムなどのソリューションがある場合、同じ静的 IP アドレスを VM のネットワーク アダプター プロパティに割り当てることができます。ただし、VM がサービス復旧を受けているか、または管理ポータルでシャットダウンされ、そのアドレスの割り当てが解除されている場合は、ネットワーク アダプターは無視されることに注意してください。その場合、ゲスト内の静的 IP アドレスをリセットする必要があります。

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

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

  • 仮想ネットワークを作成するかどうかに関係なく、Azure では受信トラフィックではなく出力トラフィックに対して課金されます。Windows Server Active Directory のさまざまな設計上の意思決定事項は、展開によって送信トラフィックがどのように生成されるかに影響を与える場合があります。たとえば RODC の展開では、送信トラフィックはレプリケートされないため制限されます。ただし、RODC をデプロイするための判断は、DC に対して書き込み操作を行う必要性や、サイト内のアプリケーションやサービスと RODC との互換性を考慮して慎重に検討する必要があります。トラフィックの料金の詳細については、「Azure 料金早見表」を参照してください。

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

はい、Azure Virtual Machines に Windows Server AD FS をデプロイでき、内部設置型の AD FS デプロイメントのベスト プラクティスが、同じように Azure での AD FS デプロイメントにも適用されます。ただし、ベスト プラクティスには、AD FS 自体では提供できない、負荷分散および高可用性などのテクノロジが必要になるものがあります。これらは、基になるインフラストラクチャにより提供される必要があります。これらのベスト プラクティスをいくつか紹介し、それらを Azure VM と Azure VNet を使用して実現する方法を確認します。

  1. セキュリティ トークン サービス (STS) サーバーをインターネットに直接公開しない。

    STS ロールはセキュリティ トークンを発行するため、この操作は重要です。そのため、AD FS サーバーなどの STS サーバーは、ドメイン コントローラーと同じレベルの保護を使用して扱う必要があります。STS がセキュリティで保護されていない状態にあると、悪意のあるユーザーが、信頼できる組織内にある証明書利用者アプリケーションと他の STS サーバーに対する要求が含まれる可能性のあるアクセス トークンを発行することができる状態になります。

  2. AD FS サーバーと同じネットワーク内のすべてのユーザー ドメインの Active Directory ドメイン コントローラーをデプロイします。

    AD FS サーバーは、Active Directory ドメイン サービスを使用してユーザーを認証します。AD FS サーバーと同じネットワーク上にドメイン コントローラーをデプロイすることをお勧めします。これにより、Azure ネットワークと内部設置型ネットワークの間のリンクが壊れている場合にビジネスの継続性が提供され、待機時間が短くなり、ログインのパフォーマンスが向上します。

  3. 高可用性を実現し、負荷を分散するために複数の AD FS ノードをデプロイする。

    ほとんどの場合、セキュリティ トークンを必要とするアプリケーションはミッション クリティカルであることが多いため、AD FS によって有効になるアプリケーションに障害の発生は許されません。さらに、AD FS はミッション クリティカル アプリケーションにアクセスする際のクリティカル パスに置かれているため、AD FS サービスは、複数の AD FS プロキシと AD FS サーバーを通じて高い可用性を備えている必要があります。要求の分散を実現するために、AD FS プロキシと AD FS サーバーの前には通常、ロード バランサーがデプロイされます。

  4. インターネット アクセス用の 1 つまたは複数の Web アプリケーション プロキシ ノードをデプロイします。

    ユーザーが、AD FS サービスで保護されているアプリケーションにアクセスする必要がある場合、AD FS サービスがインターネットから使用可能である必要があります。これは、Web アプリケーション プロキシ サービスをデプロイすることで実現されます。高可用性と負荷分散のために、複数のノードをデプロイすることを強くお勧めします。

  5. Web アプリケーション プロキシ ノードから内部ネットワーク リソースへのアクセスを制限する。

    外部ユーザーに、インターネットから AD FS へのアクセスを許可するには、Web アプリケーション プロキシ ノード (または以前のバージョンの Windows Server の AD FS プロキシ) をデプロイする必要があります。Web アプリケーション プロキシ ノードは、直接インターネットに公開されます。これらはドメインに参加している必要はなく、TCP ポート 443 と 80 経由で AD FS サーバーにアクセスすることのみが必要です。その他のすべてのコンピューター (特にドメイン コントローラー) への通信をブロックすることを強くお勧めします。

    通常、これは DMZ によって内部設置型で実現できます。ファイアウォールは、操作のホワイトリスト モードを使用して、DMZ から内部設置型ネットワークへのトラフィックを制限します (つまり、指定された IP アドレスからのトラフィックと、指定されたポートを経由したトラフィックのみが許可され、他のすべてのトラフィックはブロックされます)。

次の図に、従来の内部設置型 AD FS デプロイメントでのこのしくみを示します。

DMZ を使用するオンプレミス環境での ADFS

ただし、Azure はネイティブですべての機能を備えたファイアウォール機能を提供しないため、他のオプションを使用してトラフィックを制限する必要があります。次の表に、各オプションおよびその長所と短所を示します。

 

オプション 長所 短所

Azure でのネットワーク ACL

低コストで単純な初期構成

新しい VM がデプロイメントに追加される場合は、追加のネットワーク ACL 構成が必要です。

Barracuda NG Firewall

操作のホワイトリスト モード (ネットワーク ACL 構成は必要ありません)

コストと、初期セットアップの複雑さが増加します。

この場合に AD FS をデプロイする手順の概要は次のとおりです。

  1. VPN または ExpressRoute を使用して、クロスプレミス接続を備えた仮想ネットワークを作成します。

  2. 仮想ネットワーク上にドメイン コントローラーをデプロイします。この手順は省略可能ですが、推奨されます。

  3. 仮想ネットワーク上でドメインに参加している AD FS サーバーをデプロイします。

  4. AD FS サーバーを含み、仮想ネットワーク (DIP) 内で新しいプライベート IP アドレスを使用する内部負荷分散セットを作成します。

    1. DNS を更新して、内部負荷分散されたプライベート IP アドレス (DIP) を指す FQDN を作成します。

  5. Web アプリケーション プロキシ ノードのクラウド サービス (または個別の仮想ネットワーク) を作成します。

  6. クラウド サービスまたは仮想ネットワークで Web アプリケーション プロキシ ノードをデプロイします。

    1. Web アプリケーション プロキシ ノードを含む、外部負荷分散セットを作成します。

    2. クラウド サービスのパブリック IP アドレス (VIP) を指すように外部 DNS 名 (FQDN) を更新します。

    3. AD FS サーバーの内部負荷分散セットに対応する FQDN を使用するように AD FS プロキシを構成します。

    4. 要求プロバイダーの外部 FQDN を使用するように、要求ベースの Web サイトを更新します。

  7. Web アプリケーション プロキシの間のアクセスを AD FS 仮想ネットワークの任意のコンピューターに制限します。

トラフィックを制限するため、Azure 内部ロード バランサーの負荷分散セットは、TCP ポート 80 と 443 へのトラフィックのみに対して構成し、負荷分散セットの内部 DIP への他のすべてのトラフィックは削除します。

ADFS ネットワーク ACL

次のソースによってのみ、AD FS サーバーへのトラフィックが許可されます。

  • Azure 内部ロード バランサー。

  • 内部設置型ネットワークの管理者の IP アドレス。

Warning警告
設計では、Azure 仮想ネットワークのその他の VM または内部設置型ネットワーク上の任意の場所に、Web アプリケーション プロキシ ノードが到達するのを防ぐ必要があります。これを行うには、ExpressRoute 接続用の内部設置型のアプライアンスまたはサイト間 VPN 接続用の VPN デバイスでファイアウォール ルールを構成します。

このオプションの欠点の 1 つは、内部ロード バランサー、AD FS サーバー、仮想ネットワークに追加されるその他のサーバーを含む複数のデバイスに対して、ネットワーク ACL を構成する必要があることです。任意のデバイスが、デバイスへのトラフィックを制限するようにネットワーク ACL を構成することなくデプロイメントに追加された場合、デプロイメント全体が危険にさらされる可能性があります。Web アプリケーション プロキシ ノードの IP アドレスを変更した場合、ネットワーク ACL をリセットする必要があります (つまり、静的 DIP を使用するようにプロキシを構成する必要があります)。

ネットワーク ACL を使用する Azure での ADFS

別のオプションとして、Barracuda NG Firewall アプライアンスを使用して、AD FS プロキシ サーバーと AD FS サーバーの間のトラフィックを制御します。このオプションは、セキュリティおよび高可用性のためのベスト プラクティスに準拠していて、初期セットアップ後の管理が少なくて済みます。Barracuda NG Firewall アプライアンスはファイアウォール管理のホワイトリスト モードを提供し、Azure 仮想ネットワーク上で直接インストールできるためです。これにより、新しいサーバーをデプロイメントに追加するたびに、ネットワーク ACL を構成する必要がなくなります。ただし、このオプションでは、初期デプロイメントの複雑さとコストが増します。

この場合、1 つではなく 2 つの仮想ネットワークをデプロイします。VNet 1 にはプロキシが含まれ、VNet2 には STS と企業ネットワークへのネットワーク接続が含まれます。したがって、VNet1 は (仮想的であるにもかかわらず) 物理的に VNet2 から分離され、それにより企業ネットワークからも分離されます。次に、TINA (Transport Independent Network Architecture) という特殊なトンネリング テクノロジを使用して、VNet 1 が VNet2 に接続されます。TINA トンネルが Barracuda NG Firewall を使用して各 Vnet に接続されます (VNet ごとに 1 つの Barracuda)。高可用性を実現するため、各 VNet に 2 つの Barracuda (1 つはアクティブ、もう 1 つはパッシブ) をデプロイすることをお勧めします。これらの Barracuda は、Azure で従来の内部設置型の DMZ の操作を再現できる豊富なファイアウォール機能を提供します。

ファイアウォールを使用する Azure での ADFS

詳細については、「2. AD FS:要求対応の内部設置型フロントエンド アプリケーションをインターネットに拡張する」を参照してください。

目的が Office 365 の SSO のみである場合の、AD FS デプロイの別の方法

Office 365 のサインオンを有効にすることのみが目的の場合は、AD FS のデプロイに別の方法があります。その場合は、単に内部設置型でパスワード同期により 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 にサインオンできます。

Office 365 で、パスワード同期を行う DirSync のシナリオ (AD FS なし) では、シングル サインオンは「同一サインオン」で置き換えられます。ここで、「同一」とは、ユーザーが Office 365 にアクセスする場合に、内部設置型の同じ資格情報を再入力する必要があることを意味します。このデータはユーザーのブラウザーで記憶して、それ以降の入力回数を減らすことができます。DirSync とパスワード同期を行うシナリオ (AD FS なし) では、シングル サインオンは「同一サインオン」で置き換えられます。ここで、「同一」とは、ユーザーが Office 365 にアクセスする場合に、内部設置型の同じ資格情報を再入力する必要があることを意味します。このデータを記憶して、それ以降の入力回数を減らすことができます。

追加の思考材料

  • Azure 仮想マシンに AD FS プロキシをデプロイする場合は、AD FS サーバーへの接続が必要です。それらのフェデレーション サーバーが内部設置型である場合は、仮想ネットワークで可能なサイト間 VPN 接続を活用して、Web アプリケーション プロキシ ノードが AD FS サーバーと通信できるようにすることをお勧めします。

  • Azure の仮想マシン上で AD FS サーバーをデプロイする場合は、Windows Server Active Directory ドメイン コントローラー、属性ストア、および構成データベースへの接続が必要であり、Azure 仮想ネットワークと内部設置型ネットワークの間に ExpressRoute 接続またはサイト間 VPN 接続が必要にある場合もあります。

  • Azure の仮想マシンからのすべてのトラフィック (送信トラフィック) に対して、課金が発生します。コストが推進要因である場合は、Web アプリケーション プロキシ ノードを Azure にデプロイして、AD FS サーバーを内部設置型で残すことをお勧めします。AD FS サーバーを Azure の仮想マシン上にもデプロイするときは、社内ユーザーの認証にあたり追加のコストが発生します。送信トラフィックは、ExpressRoute または VPN サイト間接続を経由するかどうかにかかわらず、コストを発生させます。

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

    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:

    • Azure PowerShell コマンドレットである Set-AzureStaticVNetIP を使用して DC に静的 IP アドレスを設定します。

    • 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 の内部負荷分散機能を使用することを検討することもできます。

    詳細については、「AD DS のデプロイメント ガイド」を参照してください。

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

図 3

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

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

  • インストール方法: 企業 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:

    • Azure PowerShell コマンドレットである Set-AzureStaticVNetIP を使用して DC に静的 IP アドレスを設定します。

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

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

  • 地理的に分散された DC: 必要に応じて追加の仮想ネットワークを構成します。Active Directory サイト トポロジが、さまざまな Azure リージョンに対応する地理的場所で DC を必要とする場合は、適宜、Active Directory サイトを作成します。

  • 読み取り専用 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 アドレスと名前解決をどのように構成するか。

Set-AzureStaticVNetIP コマンドレットを使用して静的 IP アドレスを割り当てます

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

5

地理的に分散された DC

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

Active Directory サイト トポロジが、さまざまな Azure リージョンに対応する地理的場所で DC を必要とする場合は、適宜、Active Directory サイトを作成します。VNet 間の接続を構成することで、個別の VNets 上のドメイン コントローラー間でレプリケートします。

6

読み取り専用 DC

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

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

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

送信トラフィックの制限

7

グローバル カタログ

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

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

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

8

インストール方法

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

  • 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

バックアップと復元

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

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

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 には次の利点があります。

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

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

仮想ネットワーク間での直接通信の構成の詳細については、「VNet 間の接続の構成」を参照してください。

読み取り専用 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 Storage に書き込みデータがコミットされます。これにより、書き込みが若干遅くなるものの、持続性が得られます。

この動作は 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 でサポートされていません。

この情報は役に立ちましたか。
(残り 1500 文字)
フィードバックをいただき、ありがとうございました
表示:
© 2015 Microsoft