2025年9月30日でMicrosoftのSPLA（サービスプロバイダーライセンス契約）によるリモートデスクトップサービス（RDS）の提供が終了することに伴い、従来のオンプレミスライセンスを利用していた多くの企業はクラウドベースへの移行課題に直面しています。
この課題を解決する効果的な方法の一つが、自己管理型のActive Directory（AD）サーバーを構築し、Microsoft AD（MSAD）と接続するハイブリッドアプローチです。
ADとMSAD間で信頼関係（トラスト）を設定し、AWS License Managerのユーザー単位のサブスクリプション機能を活用することで、従来通りのユーザー管理を維持しつつ、ライセンス管理をクラウドへ移行できます。
この記事では、SPLA移行に備えた実践的な手順を紹介します：
• AWS上でADサーバーをデプロイ
• ADサーバーとMSAD間で双方向フォレストトラストを構築
• ADユーザーにAWS License Manager経由でRDSライセンスを付与
この仕組みは、トラストの設定からライセンスサーバーの構成、RDSHのインストール、ライセンスの割り当てまで、すべてAWS上で完結できます。オンプレのサーバーは不要で、普段通りのユーザー管理がそのまま使えるのもポイントです。
目次
- 1. Microsoft AD 管理者の資格情報を保存するシークレットの作成
- 2. Microsoft ADの作成
- 3. Microsoft AD を License Manager に登録
- 4. Remote Desktop Services (RDS) をサブスクライブ
- 5. 自己管理型ADサーバー用EC2インスタンスのデプロイ
- 6. ADドメインコントローラー構成とADユーザー作成
- 7. ドメイン参加済みEC2インスタンスの起動
- 8. 自己管理型ADサーバー側のトラスト設定
- 9. ドメイン参加済みインスタンス側のトラスト設定
- 10. RDS ライセンスサーバーとして登録
- 11. RDSH をインストール
- 12. グループポリシーで設定
- 13. RDSライセンス割り当て
- 14. Remote Desktop Users グループに追加
- 15. まとめ
- 16. 実現できたこと
構築図
1. Microsoft AD 管理者の資格情報を保存するシークレットの作成
AWS Secrets Managerを開きます。 AWS Secrets Manager＞シークレット＞新しいシークレットを作成する
Microsoft ADの管理者ユーザー名とパスワードをAWS Secrets Managerに保存します。
シークレット名は 「license-manager-user-」で始める必要があります。 これは AWS が定める管理者認証情報の形式であり、License Manager が正しく認識するために必要です。
シークレットの作成が完了したら、概要欄右側にある 「シークレットの値を取得する」ボタンをクリックして、 一覧画面で登録された内容が表示されていることを確認しておきます。
このシークレットは、後ほど License Manager から Microsoft AD(MSAD) を登録・設定する際に使用する認証情報として必要になります。
2. Microsoft ADの作成
Directory Serviceを開きます。 Directory Service＞ディレクトリ＞ディレクトリのセットアップ
このステップでは、ユーザー認証とリモートデスクトップライセンスの基盤となる Microsoft AD（MSAD） を AWS 上に作成します。
ドメイン名、NetBIOS 名を設定します。 後の構成でも使うため、わかりやすく一貫性のある名前をつけておくのがおすすめです。
次に、ネットワーク構成を選択します。Secrets Manager に保存した管理者パスワードを入力します。
作成が完了後、 作成したディレクトリ名（例：corpaws.local）の、ステータスが「アクティブ」になっていることを確認します。 このディレクトリは、今後のリモートデスクトップ環境の中心として機能します。
3. Microsoft AD を License Manager に登録
AWS License Manager を開きます。 AWS License Manager ＞ 設定＞ユーザーベースのサブスクリプション ＞ Active Directory を登録
次に、作成した Microsoft AD（MSAD） を AWS License Manager に登録します。 これにより、後のライセンスサーバー構成やユーザーごとのライセンス割り当てが可能になります。
登録が完了するまで数分かかることがあり、ステータスは最初「登録中」と表示されますが、10分ほど待つと「登録済み」に変わります。
4. Remote Desktop Services (RDS) をサブスクライブ
AWS License Manager を開きます。 AWS License Manager ＞ ユーザーベースのサブスクリプション ＞ 製品＞ Microsoft Remote Desktop Services (RDS)
その後、表示された「Microsoft Remote Desktop Services (RDS)」を選択し、AWS Marketplace 経由でサブスクリプションを行います（下図参照）。
数分後、製品一覧に「Microsoft Remote Desktop Services (RDS)」が表示され、「Marketplace サブスクリプションステータス」が「アクティブ」となっていれば準備完了です。
この操作によって、License Manager 経由で AD ユーザーに RDS ライセンスを割り当てられるようになります。
5. 自己管理型ADサーバー用EC2インスタンスのデプロイ
次に、オンプレミス相当の自己管理型ADサーバーをAWS上に構築し、ユーザーがLicense Manager製品にサブスクライブできるよう準備します。 まず、EC2ダッシュボードからWindowsインスタンスを起動し、自己管理型ADサーバーとして使用します。
AWS Marketplaceから適切なWindows AMIを選択
Microsoft ADと同じVPCのプライベートサブネットにデプロイ
起動後、キーペアを使用して取得した管理者パスワードでRDP接続します。
※ 次の手順でドメイン参加済みインスタンスを作成した後、両方のサーバーのセキュリティグループで相互に通信が許可されていることを確認してください。
6. ADドメインコントローラー構成とADユーザー作成
自己管理型AD サーバーに RDP 接続してログインした後、以下の作業を行います。
このサーバーをドメインコントローラー（DC）として昇格させ、新しい AD ドメインを構成します。
タスクバーの検索バーに「サーバー マネージャー」と入力し、表示されたアプリをクリックします。
管理＞役割と機能の追加を選択
次へを選択してサーバの役割までスキップします。 Active Directory Domain ServiceとDNS Serverにチェックを入れます。
機能を追加をクリック。 最後まで進めて「インストール」
インストール完了後、サーバーマネージャーに「このサーバーをドメインコントローラーに昇格する」という通知が出るのでクリック
新しいドメイン名を入力してください。 例："corp.local"
ディレクトリサービス復元モード（DSRM）パスワードに任意のパスワードを設定します。
ウィザードに従って進め、「インストール」をクリック
※ サーバーは自動で再起動します
再起動後、以下の手順でユーザーを作成します：
ユーザー名、ログオン名を入力（例：testuser1）
パスワードを設定し、「パスワードを無期限にする」にチェックを入れるのが推奨
次に「次へ」に進み、「完了」をクリックします。
その後、このユーザーを使用して、後ほど RDS サーバーに RDP 経由で接続します。
7. ドメイン参加済みEC2インスタンスの起動
Microsoft AD の登録が完了したら、ドメインに参加し、RDS ライセンスサーバーとして機能する EC2 インスタンスを起動します。
AWS Directory Service のディレクトリ詳細画面＞アクション＞「ディレクトリ管理 EC2 インスタンスの起動」を選択します。
「セキュリティグループ」「キーペア」を自身の環境に合わせたものを指定してください。 そのほかの設定項目については、特別な要件がなければデフォルトのままで問題ありません。
この操作で、指定されたドメインに自動的に参加済みの Windows Server インスタンスが起動されます。
インスタンスの起動が完了すると、ディレクトリの詳細画面の 「ディレクトリ管理 EC2 インスタンス」の項目に「i-」から始まるリンクが表示されます。 このリンクをクリックします。
インスタンスの状態が「実行中」になるまでしばらく待ちましょう。
8. 自己管理型ADサーバー側のトラスト設定
RDPで自己管理型ADサーバーに接続し、以下を実施します。
DNSマネージャーを開き、Microsoft AD側（corpaws.local）への名前解決ができるよう、条件付きフォワーダーを追加します。
条件付きフォワーダー追加手順。
条件付きフォワーダーの設定が完了したら、名前解決と通信が正しく行えるかを事前に確認しておくことが重要です。以下の手順を実行してください。
名前解決確認（nslookup）
nslookup corpaws.local
ネットワーク接続確認（ping）
ping 10.0.3.122
その後、自己管理型ADサーバーとMicrosoft AD間で双方向のフォレストトラストを構成し、自己管理型ADのユーザーがMicrosoft AD参加リソースに対して認証できるようにします。
プロパティ(R)を開く。
ドメイン結合インスタンスのドメイン名を入力。 例：corpaws.local
このドメインのみを選択
フォレストタイプを選択
双方向の信頼を選択
※ トラスト作成時のパスワードは自己管理型AD側とMicrosoft AD側で同一に設定してください。
必要ないので検証しないことを選択します。
完了をクリックする。
そうすれば、ドメイン参加済みインスタンスとの信頼関係が確立される。
9. ドメイン参加済みインスタンス側のトラスト設定
RDPでドメイン参加済みサーバーに接続し、以下を実施します。
「6. ADドメインコントローラー構成とADユーザー作成」と同じ手順で設定します。
※「サーバーの役割の選択」画面で「 DNS Serverのチェックボックス」 のみチェックを入れ、
以降の手順に従ってインストールを進めてください。
※DNS Server のインストールが完了したら、手順6 の残りの手順はスキップしてください。
次に「8. 自己管理型ADサーバー側のトラスト設定」と同じ手順で設定します。 ※新規条件付きフォワーダーの作成の際、 DNSドメインをADサーバー側（corp.local）に設定し、マスターサーバのIPアドレスには 自己管理型ADサーバーのプライベートIPアドレスを指定します。
条件付きフォワーダーの設定が完了したら、名前解決と通信が正しく行えるかを事前に確認しておくことが重要です。以下の手順を実行してください。
名前解決確認（nslookup）
nslookup corp.local
ネットワーク接続確認（ping）
ping 10.0.6.149
手順8までの信頼関係の設定が完了したら、 「Active Directory ドメインと信頼関係」 → プロパティ(R) → 「信頼」 タブの順に開き、
以下のように信頼関係が設定されていること、 また、自己管理型ADサーバーのドメイン名（corp.local） が正しく表示されていることを確認してください。
ドメイン参加済みインスタンスからの信頼関係の構成がうまくいかない場合、 AWS Directory Service のコンソールから信頼関係を追加する方法もあります。
＜コンソールから実施する手順＞
Directory Service＞該当のディレクトリ（例：corpaws.local）＞ 「ネットワークとセキュリティ」タブ ＞「信頼関係」セクション＞アクション＞「信頼関係を追加」
※ 通常はドメイン参加済みインスタンス内での設定で問題ありませんが、 信頼関係が正しく確立されない場合の回避策として、こちらの方法も検討してください。
信頼関係が正しく構成されると、Microsoft AD のコンソール上で「ステータス」が「検証済み」として表示されます。
10. 起動したドメイン参加済みの EC2 インスタンスを RDS ライセンスサーバーとして登録します。
AWS License Manager＞設定＞ユーザーベースのサブスクリプション
RDSライセンスサーバを設定をクリックします。
ここで対象の Active Directory を指定し、事前に作成しておいた Secrets Manager の認証情報を使って設定を完了させます。
シークレットの欄に作成したシークレットを選択し、設定をクリック
この登録が完了すれば、RDS のライセンスをユーザー単位で割り当てるための基盤が整います。
ライセンスサーバエンドポイントのステータス欄が「プロビジョニング済み」になれば完了です。
11. RDS ライセンスサーバーに RDSH をインストール
ライセンスサーバーとして構成した ドメイン参加済みサーバーにリモートデスクトップでログインし、RDSH（Remote Desktop Session Host） をインストールします。
ログイン後、PowerShell を管理者権限で開き、以下のコマンドを実行して RDSH をインストールします。
Install-WindowsFeature -Name RDS-Licensing, RDS-RD-Server –IncludeManagementTools
続けて、インストール状況を確認するには次のコマンドを実行します。
Get-WindowsFeature -Name RDS* | Where installed
すべての機能が正しくインストールされたことを確認したら、以下のコマンドでサーバーを再起動します。
Restart-Computer
これで、RDS ライセンスサーバーとしての基本設定は完了です。
※ RDS は、セットアップしてから最大120日間は何もしなくても接続ができます。 ですが、その期間をすぎると、「利用するための許可（ライセンス）」の設定が必要になります。
この設定が終わっていないと、ユーザーがリモート接続できなくなるため、できるだけ早めに設定を終わらせておくのがおすすめです。 ※ この設定（ライセンスの構成）については、以降の手順で詳しく説明していますので、続けて読み進めてください。
12. グループポリシーでライセンスサーバーとモードを指定
RDSH のインストールが完了したら、グループポリシーエディター（gpedit.msc） を使って、ライセンスサーバーとライセンスモードを構成します。
Windows の「ファイル名を指定して実行」から gpedit.msc を入力して起動します。
以下のパスをたどって設定を行います：
コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → リモート デスクトップ サービス → リモート デスクトップ セッション ホスト → ライセンス
まず、「指定のリモートデスクトップライセンスサーバーを使用する」を開いて有効化し、License Manager 上で表示された エンドポイント ID を入力します。
続けて「リモート デスクトップ ライセンス モードの設定」を開き、「ユーザー単位」を選択して有効化します。
設定を反映させるため、最後にサーバーを再起動します。
Restart-Computer
13. Active DirectoryユーザーへのRDSライセンス割り当て
最後に、作成したActive Directory ユーザーに対して Remote Desktop Services（RDS） のライセンスを割り当てます。
AWS License Manager＞ユーザーベースのサブスクリプション＞製品＞Microsoft Remote Desktop Services (RDS)＞ユーザーをサブスクライブ
対象のディレクトリを選択し、割り当てたいユーザー名を入力してサブスクライブを実行します。
数分後に RDS のライセンスが有効になります。 ただし、ユーザーが実際にリモートデスクトップ環境へアクセスできるようにするには、 対象のサーバーでそのユーザーを Remote Desktop Users グループに追加する必要があります。 そのためには、次のステップに従って設定を行ってください。
14. ADユーザーを Remote Desktop Users グループに追加
リモート接続を許可するため、ADユーザーを「Remote Desktop Users」グループに追加します。
ドメイン参加済みサーバーにログインし、管理者権限でPowerShellを開きます：
net localgroup "Remote Desktop Users" "NetBIOS名\ユーザ名" /add
続いて、グループに正しく追加されたかを確認するには、次のコマンドを実行します。
Get-LocalGroupMember -Group "Remote Desktop Users"
これでADユーザーによるRDP接続が可能になります。
15. まとめ
本記事では、自己管理型AD サーバーとAWS Microsoft AD（MSAD）を接続し、ハイブリッド型リモートデスクトップ環境をAWS上で構築する手順を紹介しました。
＜手順＞
• MSADのセットアップ
• AWS上に自己管理型ADサーバーをデプロイし、ドメインコントローラー化
• 条件付きフォワーダー設定と双方向トラスト構築
• ドメイン参加済みインスタンスのRDSライセンスサーバー登録
• RDSHインストールとグループポリシー設定
• AWS License ManagerによるRDSライセンス管理
これらの手順を通じて、SPLA終了後もスムーズにクラウドベース環境へ移行しつつ、既存のADユーザー管理を維持できます。
全てAWS上で完結するため、オンプレミス機器は不要です。
16. 実現できたこと
以下は、AWS 上でユーザーベースの RDS 環境を構築することによって得られる主なメリットと成果のまとめです。
• 自己管理型ADサーバーとMicrosoft AD間の双方向トラストによるシームレスな統合
• 既存ADユーザーを活用した認証とアクセス制御の一元化
• AWS上で実現するセキュアかつスケーラブルなリモートデスクトップ環境
• AWS License Managerによる簡単で自動化されたライセンス管理
• ユーザー追加時も柔軟に対応できるグループポリシーによる制御
SPLA廃止問題を解決するだけでなく、現代的で柔軟なRDS管理環境をAWSで実現できます。
これで、自己管理型ADとAWS Microsoft ADを統合したユーザーベースRDSライセンス管理ガイドは完了です。
最後まで読んでいただき、ありがとうございました！
