リファレンスアーキテクチャ:Citrix DaaS -CSP 用Microsoft Active Directoryのマネージドサービスを使った GCP アーキテクチャ

はじめに

このドキュメントの目的は、Microsoft Active Directory toryのマネージドサービスでGoogle Cloud Platform（GCP）をCitrix DaaSリソースの場所として使用することを検討しているCitrix Service Provider（CSP）に設計とアーキテクチャのガイダンスを提供することです。

このドキュメントは、CSP用のCitrix DaaSを展開する方法に関する段階的なガイダンスを提供することを意図していません。これは、CSP用のCitrix DaaS環境の設計と展開に関する詳細な考慮事項を提供する、CSP仮想アプリケーションおよびデスクトップのリファレンスアーキテクチャを理解していることを前提としています。

GCP 上の Citrix DaaS に関する詳細なガイダンスについては、Google Cloud 上の Citrix DaaS のソリューションハブを参照してください。

この文書は、このマニュアルを快適に活用するために理解する必要がある最も一般的なGCP要素を見直すことから始めます。Google は、GCP でコンポーネントの名前付けや整理を行う独自の方法を作成しています。そのため、設計および展開を成功させるには、コンポーネントを理解することが重要です。

次に、管理 AD サービスの詳細、従来の Microsoft Active Directory との類似点と相違点、および GCP 管理リソースの場所をプロビジョニングするための CSP として使用できる展開モデルについて説明します。

最後に、GCP にマネージド AD サービスドメインを展開するために必要な手順について説明します。

用語

複数のサービスは、異なるパブリッククラウドプロバイダー間で同様の機能を提供しますが、用語は異なる場合があります。以下は、GCP のドキュメントで説明されているように、このリファレンスアーキテクチャに従って理解しておく必要のある最も一般的なGCP要素です。

• VPC ネットワーク:GCP の仮想ネットワークオブジェクト。GCP の仮想プライベートクラウドネットワーク (VPC) はグローバルです。つまり、各 GCP リージョンから VPC にサブネットをデプロイできます。VPC は、すべてのサブネットと CIDR 範囲を自動的に作成する自動モード、またはカスタムモードでデプロイできます。カスタムモードでは、サブネットと CIDR 範囲を手動で作成できます。異なるプロジェクトからの重複しない VPC は、VPC ピアリングを介して接続できます。
• VPC ピアリング:VPC ピアリングを使用すると、VPC を接続できます。そうしないと、接続が切断されます。この場合、GCP マネージド AD サービスによって VPC ピアが自動的に作成され、VPC がマネージド AD サービス VPC に接続されます。
• 共有 VPC:共有 VPC を複数のプロジェクトにまたがることができ、プロジェクトごとに個別の VPC を作成する必要がなく、VPC ピアリングの使用も不要です。
• GCP組織:組織は、GCPリソース階層内のルートノードを表します。組織を作成するには、GCP クラウドアイデンティティまたは Google ワークスペース（旧 G-Suite）が必要です。組織は必須ではありませんが、リソースを効率的に整理および管理するために、実稼働環境に組織を展開することを強くお勧めします。
• フォルダ:フォルダは GCP 内のリソースを整理するために使用され、フォルダやプロジェクトをさらに格納できます。たとえば、フォルダを作成して、部門、環境タイプ、またはその他の条件別にプロジェクトを区切ることができます。フォルダは必ずしも必須ではありませんが、組織の場合と同様に、より適切なリソース編成のために推奨されます。
• プロジェクト:プロジェクトは、GCP 内のリソースの抽象的なグループを提供し、GCP 内のすべてのリソースはプロジェクトに属している必要があります。通常の状況では、VPC ピアまたは共有 VPC が使用されない限り、あるプロジェクトの VM インスタンスは別のプロジェクトの VM インスタンスと通信できません。
• 請求アカウント:請求アカウントは、GCP消費の支払に使用される支払プロファイルを表します。請求アカウントは複数のプロジェクトにリンクできますが、1 つのプロジェクトは 1 つの請求アカウントにのみリンクできます。
• IAM:GCP の ID およびアクセス管理プラットフォームは、GCP リソースに対してアクションを実行する権限をユーザーに付与するために使用されます。このプラットフォームは、サービスアカウントの展開と管理にも使用されます。
• サービスアカウント:サービスアカウントは、実際のユーザーに接続されていない GCP アカウントで、代わりに VM インスタンスまたはアプリケーションを表します。サービスアカウントには、さまざまな GCP API に対してさまざまなアクションを実行するアクセス許可を付与できます。Citrix DaaS を GCP に接続し、マシン作成サービスを有効にするには、サービスアカウントが必要です。
• GCE:Google コンピュートエンジンは、仮想マシンインスタンス、ディスク、インスタンステンプレート、インスタンスグループなどのコンピューティングリソースをデプロイする GCP プラットフォームです。
• GCEインスタンス：GCEインスタンスは、GCEプラットフォームにデプロイされた任意の仮想マシンです。クラウドコネクタ、ゴールデンイメージ、AD 管理VM、および環境内のその他の仮想マシンは GCE インスタンスと見なされます。
• インスタンステンプレート:GCP で VM とインスタンスグループをデプロイするために利用できる「ベースライン」リソース。Citrix MCSプロセスにより、ゴールデンイメージがインスタンステンプレートにコピーされ、カタログマシンの展開に使用されます。
• クラウド DNS: DNSゾーンとレコードを管理するために使用される GCP サービス。マネージド AD サービスの作成により、クラウド DNS はマネージドドメインコントローラに DNS クエリを転送するように自動的に構成されます。

GCP でのマネージド AD サービス

Microsoft Active Directory 向けGCPのマネージドサービスは、Google Cloud Platform 上のフルマネージド型Active Directory サービスです。このサービスは、Windows Server VM インスタンスを構築および保守するオーバーヘッドなしで、完全に機能する Active Directory フォレスト/ドメインを提供します。

マネージド AD サービスは、可用性の高い Google 管理インフラストラクチャ上に構築され、マネージドサービスとして提供されます。各ディレクトリは複数の GCP ゾーンにデプロイされ、監視によって障害が発生したドメインコントローラーが自動的に検出され、置き換えられます。ソフトウェアをインストールする必要はないので、Googleはすべてのパッチ適用とソフトウェアの更新を処理します。

マネージド广告サービスは,分離されたGCPプロジェクトとVPCネットワーク上で,高可用性Active Directory ドメインコントローラを自動的にデプロイおよび管理します。VPC ピアリングは、Active Directory に到達するために、広告に依存するワークロード用のサービスとともに自動的にデプロイされます。さらに、すべての DNS クエリを管理された AD サービスに転送するように Google クラウド DNS が自動的に構成されます。

マネージド AD サービスの考慮事項

従来の Microsoft Active Directory 環境と GCP のマネージド AD サービスには多くの類似点がありますが、GCP のマネージド AD サービスをデプロイする際には、いくつかの考慮事項に留意する必要があります。

1. ドメインコントローラーのアクセスは制限されており、管理インスタンスをデプロイし、リモートサーバー管理ツールをインストールすることによってのみ、ドメインを管理できます。
2. GCP共有リソースロケーションに新しい顧客/プロジェクトを追加する前に,共有VPCをデプロイする必要があります。管理対象の AD ドメインに到達するには、プロジェクトが共有 VPC に属している必要があります。共有 VPC にピア接続されている VPC があるプロジェクトにデプロイされたリソースは、マネージド AD サービスドメインに到達できません。詳細については、「GCPVPC ピアリング要件」ページおよび「Google Cloud Platform（GCP）の共有VPCサポートとCitrix DaaStech-zone PoCガイド」を参照してください。
3. ドメイン管理者/エンタープライズ管理者アカウントのアクセス許可は使用できません。これらのアカウントは、GCP がドメインを管理するためにのみ使用されます。
4. AD オブジェクトは、既定のコンテナ (/Computers など) には作成できません。読み取り専用です。この制限により、CitrixのMCSプロビジョニングテクノロジを使用するときによくある間違いが発生しますが、書き込み可能なコンテナ/OUにMCS管理VDAのマシンアカウントを作成する必要があります。このような場所を選択しない場合、MCSはマシンアカウントを作成できません。
5. 証明書サービスなど、一部の AD 統合機能をインストールできません。そのため、この制限は、Citrixのフェデレーション認証サービス（FAS）テクノロジー（AD統合証明書サービスを必要）を利用する必要があるCSPに影響します。このようなお客様は、Windows Server VM インスタンスを使用して Google クラウド上に独自の Active Directory を構築および管理する必要があります。
6. サービスによって、2 つの主要な組織単位 (OU) が作成されます。すべての AD リソースをホストする「クラウド」OU。この OU とその子で、完全に制御できます。また、ドメインを管理するために GCP によって使用される「クラウドサービスオブジェクト」OU。リソースと OU 自体は読み取り専用ですが、一部の属性は書き込み可能です。
7. このサービスは、さまざまなAD 管理機能を使用できるように、複数の AD ユーザーグループを自動的に作成します。これらのユーザーグループのメンバーシップを管理できます。
8. アカウントは、サービスの作成時にデフォルト名「setupadmin」で作成されます。このアカウントは、ドメインの管理に使用されます。「setupadmin」アカウントの権限の完全なリストについては、このページを確認してください。
9. 信頼は、オンプレミスの Active Directory 環境への一方向の送信信頼として構成できます。この構成では、管理対象の AD サービスドメインは、コンピューターアカウントをホストする「信頼する」ドメインになり、オンプレミスドメインはユーザーアカウントをホストする「信頼された」ドメインになります。このモデルは、リソースフォレストの展開でよく使用されます。これについては、次のセクションで説明します。

マネージド AD サービスフォレストの設計に関する考慮事項

Citrix Service Providerのコンテキストでは、管理型ADサービスは、2つの異なるActive Directory フォレスト設計モデルの下に展開できます。

マネージド AD サービスを展開する最初の簡単な方法は、組織フォレスト設計モデルを使用することです。このモデルでは、GCP 管理 AD サービスは、ユーザーアカウントとリソース (コンピューターアカウント)、およびすべての管理アカウントの両方をホストします。

通常の状況では、組織フォレストでは、別の組織フォレストとの関係を確立するように信頼を構成できます。ただし、GCP マネージド AD サービスは一方向の送信信頼のみをサポートしていることに注意してください。

森林設計モデルの第2のタイプは、リソースフォレストです。このモデルでは、オンプレミスの Active Directory 環境との関係を確立するために、一方向の送信信頼が構成されます。

前に説明したように、この展開モデルでは、管理 AD サービスは、リソースをホストする「信頼する」フォレストであり、オンプレミス AD はユーザー ID が存在する「信頼された」フォレストです。つまり、管理対象の AD サービスドメインでは、オンプレミスドメイン内のユーザーがそのリソースにアクセスできるようになります。

注：
Active Directory toryフォレストモデルを設計するときは、Citrix Cloud Connectorの技術的な詳細に留意してください。クラウドコネクタはフォレストの信頼を通過できません。オンプレミスのActive Directory からのユーザーアカウントは、そのフォレストにクラウドコネクタのセットを展開しない限り、Citrix Cloudでは表示されません。

アーキテクチャ

クラウド導入過程において、すべての CSP が同じ段階にあるわけではないことを理解しています。GCP上のCitrix のさまざまなデザインパターンの詳細な説明については、Google Cloud上のCitrix仮想化リファレンスアーキテクチャのこのセクションを確認してください。

また、CSPが利用できるCitrix Cloud のマルチテナンシー機能と顧客管理機能を十分に理解していることを前提としています。これらの機能は、CSP の仮想アプリケーションとデスクトップのリファレンスアーキテクチャで詳しく説明されています。

CSP デザインパターンの Microsoft Active Directory 用マネージドサービス

CSP用Microsoft Active Directory用マネージドサービスの設計パターンでは、マネージド AD サービスを使用して GCP の管理リソースの場所を使用して CSP が使用できるさまざまなアーキテクチャモデルの組み合わせに焦点を当てています。

Citrix CloudでマネージドDaaSサービスを展開するパートナーは、CSPで利用可能な独自の顧客管理機能とマルチテナント機能を使用できます。これらのマルチテナント機能を使用すると、CSPは共有Citrix Cloudコントロールプレーン/テナントに複数の顧客を展開したり、専用のコントロールプレーン/テナントを提供したりできます。

Citrix Cloudは、GCP上の共有または専用のリソースの場所で展開できます。CSP は、さまざまなメトリックによって、各顧客の特定の要件に適合するモデルを判断できます。また、エンドカスタマーの規模、セキュリティとコンプライアンス要件、コスト削減などに基づいて、CSP が判断できます。

GCP Organizations (1) は、オプションのコンポーネントですが、CSP GCP サブスクリプション上のさまざまなプロジェクトとフォルダの階層を管理するために使用できます。また、特定のエンドカスタマーで使用されている GCP サブスクリプションとリソースは、CSP ではなくエンドカスタマーに属している可能性があることに注意してください。

共有VPCネットワーク（2）は、複数の顧客が管理対象ADサービスドメイン、ゴールデンイメージ、Citrix Cloud Connectorなどのコンポーネントを共有するリソースロケーションに展開されます。他のカスタマーは、同じ GCP 組織内の専用 VPC およびリソースロケーション（3）でホストできます。これらのお客様は、独自のマネージドADサービスドメイン、ゴールデンイメージ、およびCitrix Cloud Connectorを持っています。

管理 AD サービスは、共有リソースの場所 (4) または専用のリソース場所 (5) にデプロイできます。このプロセスにより、プロジェクト（アクセスできない）と、VPC からマネージド AD サービスをホストする VPC へのネットワークピアリングが作成されます。

前に説明したように、新しい顧客/プロジェクトを共有リソースロケーションにデプロイするたびに、マネージド AD サービスドメインに到達するには、共有 VPC に属している必要があります。共有 VPC にピア接続されている VPC があるプロジェクトにデプロイされたリソースは、マネージド AD サービスドメインに到達できません。この制限は、VPC が推移的でない場合です。共有リソースの場所の管理対象 AD サービスドメインは、専用のリソースの場所にあるドメインとは異なります。

共有リソースの場所 (6) で各顧客のリソース (VDA) をホストするには、個別のGCPプロジェクトをお勧めします。この考慮事項により、さまざまな環境のサポートを担当する管理者にとって、リソース管理と IAM アクセス許可の適用が簡単になります。

また、主要なプラクティスに従って、共有 VPC ホストプロジェクトはリソースをホストしません (7)。このプロジェクトは、共有 VPC と管理対象 AD サービスドメインのデプロイにのみ使用されます。

注：
マネージド AD サービスドメインはホストプロジェクトからデプロイされますが、実際のリソース (ドメインコントローラーと VPC ネットワーク) は Google が管理するプロジェクトに属します。このプロジェクトへのアクセス権がありません。

共有Citrix Cloudテナント（8）は、複数の顧客のリソースを展開および管理するためにプロビジョニングされます。これらのお客様は、Citrix Virtual Apps and Desktopサービスのコンポーネント（Delivery Controller、データベース、Director、Studio、ライセンス、APIなど）を共有しています。

お客様ごとに専用のCitrix Workspace エクスペリエンス（9）が展開されます。専用のワークスペースエクスペリエンスにより、CSP はログインページをブランド化し、各顧客のアクセス URL をカスタマイズできます。各顧客は、リソースへの認証とHDX接続にCitrix Gateway Serviceを使用します。

大規模で複雑な顧客向けに、専用のCitrix Cloudテナント（10）をプロビジョニングできます。この専用環境は、Citrix Virtual Apps と Desktop サービスとそのすべてのコンポーネント、および専用のCitrix Workspaceエクスペリエンスを提供します。専用のCitrix Cloudテナントを展開する場合、追加のCitrixライセンスコストは発生しません

Microsoft Active Directory 用のマネージドサービスの展開

このセクションでは、マネージド AD サービスドメインを展開するために必要な手順について説明します。このセクションでは、GCP サブスクリプションが使用可能であり、プロジェクト、VPC ネットワーク、ファイアウォール設定、その他の GCP コンポーネントなどのリソースが既にデプロイされていることを前提としています。

1-ナビゲーションメニューで、[ID とセキュリティ] > [ID] > [管理された Microsoft AD]の順に移動します。

2-[Microsoft Active Directory 用マネージドサービス] 画面で、[新しいドメインの作成] をクリックします。

メモ:
* 管理対象ドメインコントローラは、ADDSおよび DNS ロールを使用して展開されます。
* 管理仮想マシンは別途作成する必要があります。

3-[新しいドメインの作成] 画面で、次の情報を入力します。

• 完全修飾ドメイン名: ドメイン FQDN (例:customer.com)
• NetBIOS: これは自動的に入力されます
• ネットワークの選択: サービスにアクセスできるネットワーク、
• CIDR 範囲: ドメインコントローラがデプロイされる VPC の /24 CIDR 範囲

メモ:
* サービスの一部としてデプロイされた VPC は、GCP コンソールからは管理できません。
* CIDR 範囲は、現在のサブネットと重複してはいけません。

4-下にスクロールし、次の情報を入力します。

• リージョン: 管理対象の AD サービスドメインを展開する GCP リージョン
• 委任された管理者: 委任された管理者アカウントの名前
• [ドメインの作成] をクリックします。

メモ:
* 委任された管理者アカウントは、Users コンテナにあります。ADUC コンソールでパスワードを直接リセットできますが、オブジェクトを別の OU に移動することはできません。
* コンピュータをドメインに参加させると、デフォルトの Computers コンテナではなく、[クラウド] > [コンピュータ]OU の下にその AD アカウントが作成されます。
* サービスの作成には最大60分かかります。

5-作成が完了したら、ドメインを選択し、[パスワードの設定] をクリックします。

6-[パスワードの設定] ウィンドウで、[確認] をクリックします。

7-[新しいパスワード] ウィンドウで、パスワードをコピーし、[完了] をクリックします。

サービスを作成して使用できる状態になったら、他のインスタンスのデプロイを開始してドメインに参加できます。また、Citrix DaaS サイトの構成を完了することもできます。