
AWS Managed Microsoft AD と オンプレAD で信頼関係を構築する (2020年5月版)
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
しばたです。
AWS Managed Microsoft AD(以後Microsoft AD)では既存のドメインと連携したい場合は信頼関係を構築します。
信頼関係を構築する手順については以前にDevelopsers.IOでも弊社加藤による記事が公開されているのですが、私からも改めて手順を紹介したいと思います。
AWS Managed Microsoft AD の制約について
具体的に明記されているドキュメントを見つけることはできなかったのですが、Microsoft ADはマネージドサービスである都合シングルフォレスト・シングルドメイン構成を強制されます。
このためMicrosoft ADと既存のドメインを連携させたい場合は信頼関係を構築する必要がでるわけです。
Microsoft ADでは「片方向」「双方向」の両方向の信頼関係を構築する事ができます。
信頼関係はドメインリソースへのアクセスに直結するため原則片方向とし必要の無い方向の信頼関係は構築しない様にするのが推奨されています。
(例外はAWS SSOで、AWS SSOを使用する際にMicrosft ADとオンプレADの信頼関係を構築する場合は双方向の信頼関係を結ぶ必要があります)
また、信頼関係の種類には「フォレスト信頼」と「外部信頼」の二種類ありますが、Microsoft ADでは両者の信頼関係をサポートしています。
AWS Managed Microsoft AD と オンプレAD で信頼関係を構築する
ここから本題に入ります。
検証環境について
本記事では以前の加藤の記事の内容を踏まえてMicrosoft ADとオンプレAD間で信頼関係を構築する手順を解説しようと思いますが、オンプレ環境を用意するのが難しかったため、別VPCをオンプレ環境に見立てVPC Peeringでオンプレ環境↔AWS環境間の接続を再現します。

(やりたかった構成)

(今回検証する構成)
オンプレ想定VPCにcorp.shibata.techドメインを、Microsoft ADはaws-tokyo.shibata.techドメインをあらかじめ構築しておき、ここをスタート地点としてaws-tokyo.shibata.techからcorp.shibata.techへの片方向のフォレスト信頼関係を構築してきます。
基本的な手順
基本的な手順は以下のドキュメントに記載されていますので参考にしてください。
オンプレミス側のインバウンド許可
まずはAWS環境からオンプレ環境に対し以下の通信を許可する必要があります。
| プロトコル | ポート番号 | 送信元 | 備考 | 
|---|---|---|---|
| TCP/UDP | 53 | Microsoft ADのあるサブネット全て | DNS | 
| TCP/UDP | 88 | Microsoft ADのあるサブネット全て | Kerberos 認証 | 
| TCP/UDP | 389 | Microsoft ADのあるサブネット全て | LDAP | 
| TCP | 445 | Microsoft ADのあるサブネット全て | SMB | 
※これはあくまでもAWS側からオンプレ環境に対する最低限の設定であり、利用する機能によっては追加のポートを開ける必要があります。
ドメインで使用するポートについては以下のドキュメントを参考にしてください。
Microsoft ADのアウトバウンド通信
Microsoft ADを構築した際はそれ用のセキュリテグループが自動生成されます。
このセキュリテグループは、
- インバウンド通信はActive Directoryで使うポートを 0.0.0.0/0 で公開
- アウトバウンド通信は同一のセキュリテグループに対してのみ許可
となっているため、信頼関係を構築する際はオンプレ側ドメインコントローラーへの通信を許可してやる必要があります。
| プロトコル | ポート番号 | 送信元 | 備考 | 
|---|---|---|---|
| ALL | ALL | オンプレ側ドメインコントローラーのIP全て | 

(IPを絞る方がセキュリティ的には良いが今回はサブネット単位で通信を許可。192.168.0.0/16がオンプレ側サブネット)
Microsoft ADのインバウンド通信
Microsoft ADのインバウンド通信は自動生成されるセキュリテグループに従う形で問題ありません。
一応以下に記載しておきます。
| プロトコル | ポート番号 | 送信元 | 備考 | 
|---|---|---|---|
| ICMP | ALL | オンプレADおよびMicrosoft ADを使用するネットワーク | ICMP | 
| TCP/UDP | 53 | オンプレADおよびMicrosoft ADを使用するネットワーク | DNS | 
| TCP/UDP | 88 | オンプレADおよびMicrosoft ADを使用するネットワーク | Kerberos認証 | 
| UDP | 123 | オンプレADおよびMicrosoft ADを使用するネットワーク | |
| UDP | 138 | オンプレADおよびMicrosoft ADを使用するネットワーク | |
| TCP/UDP | 389 | オンプレADおよびMicrosoft ADを使用するネットワーク | |
| TCP | 445 | オンプレADおよびMicrosoft ADを使用するネットワーク | |
| TCP | 464 | オンプレADおよびMicrosoft ADを使用するネットワーク | |
| TCP | 636 | オンプレADおよびMicrosoft ADを使用するネットワーク | |
| TCP | 3268-3269 | オンプレADおよびMicrosoft ADを使用するネットワーク | |
| TCP | 1024-65535 | オンプレADおよびMicrosoft ADを使用するネットワーク | |
| ALL | ALL | ディレクトリのセキュリティグループ(自分自身) | 
Kerberos事前認証を有効にする
ユーザーアカウントの Kerberos 事前認証を有効にします。
デフォルトでは有効になっているので基本的には作業不要です。
オンプレミス側 DNS 条件付きフォワーダーの構成
ここから信頼関係を構築していきます。
まずはオンプレ環境のドメインコントローラー上でMicrosoft ADに対するフォーワーダー設定を実施します。
これは、Active Directoryでは自身のドメインに対するDNSはドメインコントローラーが担うため、互いのドメインに対しては条件付きフォーワーダーを設定してやる必要があるためです。
このためあらかじめ、
- Microsoft ADのドメイン名(FQDN)
- Microsoft AD DNSサーバーのIPアドレス
を把握しておく必要があります。
Microsoft AD DNSサーバーのIPアドレスはマネジメントコンソールから取得可能です。

上記の情報を踏まえて、オンプレ環境のドメインコントローラーで以下のPowerShellコマンドを実行します。
# Add-DnsServerConditionalForwarderZone コマンドで条件付きフォーワーダーを設定
$fqdn = 'Microsoft ADのFQDN' # 例 : aws-tokyo.shibata.tech
$dnsServers = @('Microsoft AD DNSサーバーのIPアドレス全て') # 例 : @('10.0.21.48','10.0.22.135') 
$params = @{
    Name = $fqdn
    MasterServers = $dnsServers
    ReplicationScope = 'Domain'
}
Add-DnsServerConditionalForwarderZone @params
成功すると下図の様に条件付きフォーワーダーが設定されます。


オンプレミス側の信頼関係(入力)の構築
続けてオンプレ側で入力方向の信頼関係を構築します。
こちらは以前の記事とは異なりPowerShellで作成していきます。
ここで軽く余談なのですが、信頼関係に関連するPowerShellコマンドレットは信頼関係を取得するGet-ADTrustはあるものの信頼関係を追加したり更新したりするものは何故かありません...
このため以下のサイトにある様にDirectoryServiceのForestオブジェクトを直接利用する必要があります。
オンプレ環境のドメインコントローラーで以下のPowerShellコマンドを実行します。
# Forestオブジェクトを直接利用して信頼関係を構築する
$targetForestName = 'Microsoft ADのFQDN' # 例 : aws-tokyo.shibata.tech
$trustPassword = '信頼パスワード'         # 信頼パスワードは自分で設定する(後で使う) 
$trustDirection = "Inbound"              # Inbound = 入力
# フォレストオブジェクトの生成
$forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
# 信頼関係を構築
$forest.CreateLocalSideOfTrustRelationship($targetForestName, $trustDirection, $trustPassword)
コマンドを実行し、エラーが出なければ成功です。
下図の様に入力方向の信頼関係が作成されます。

Microsoft AD側の信頼関係(出力)の構築
続けてMicrosoft AD側で出力の信頼関係を構築します。
Microsoft ADの設定画面では信頼関係の構築と同時に条件付きフォーワーダーの設定も行う形となります。
マネジメントコンソールから当該ディレクトリを選択し、「ネットワークとセキュリティ」欄に信頼関係の設定画面がありますので、「信頼関係の追加」ボタンをクリックします。

すると信頼関係の設定ダイアログが表示されますので、以下の様に必要な情報を入力します。
| 設定項目 | 設定内容 | 設定例 | 
|---|---|---|
| 信頼のタイプ | フォレストの信頼 | |
| リモートドメイン | オンプレ側ドメインのFQDN | corp.shibata.tech | 
| 信頼パスワード | 前項で指定したパスワード | |
| 信頼の方向 | 一方向:出力方向 | |
| 条件付きフォーワーダー | 全てのオンプレ側DNSサーバーIPアドレス | 192.168.101.114, 192.168.102.183 | 

最後に「追加」ボタンを押すと、信頼関係の構築が開始されます。

しばらく待つとステータスが「検証済み」になりますので、これで信頼関係の構築は完了となります。

ちなみにRSATを使ってMicrosoft ADの情報を確認すると、下図の様に出力方向の信頼関係がちゃんとできているのがわかります。

(なお、RSATではあくまでも参照のみ可能でここから設定を変更しようとしてもアクセス権エラーとなります)
補足 : AWS Tools for PowerShellを使う場合
補足として、AWS Tools for PowerShellを使ってMicrosoft ADの信頼関係を構築する場合はNew-DSTrustを使います。
今回の場合だとざっくり以下のコマンドで信頼関係を作成できます。
# AWS.Tools.DirectoryService モジュールを使用
Set-DefaultAWSRegion -Region ap-northeast-1
Set-AWSCredential -ProfileName YourProfile
# New-DSTrust で信頼関係を構築
$params = @{
    DirectoryId = 'd-xxxxxxxxxx' # ディレクトリID
    TrustType = 'Forest'
    TrustDirection = 'One-Way: Outgoing'
    RemoteDomainName = 'オンプレ側ドメインのFQDN' # 例 : corp.shibata.tech
    ConditionalForwarderIpAddr = @('オンプレDNSサーバーのIPアドレス全て') # 例 : @('192.168.101.114', '192.168.102.183')
    TrustPassword = '信頼パスワード'
}
New-DSTrust @params
# 作成した信頼関係は Get-DSTrust で確認
Get-DSTrust -DirectoryId 'd-xxxxxxxxxx'

最後に
ざっとこんな感じです。
本記事の内容を参考にすれば全ての作業をPowerShellで行うことも可能です。(さすがにそこまではやりませんでしたが...)
あと、今回は軽く流してますがActive Directoryは使用するプロトコルが多いためセキュリテグループやオンプレ側ファイアウォールによる通信制御の設定がかなり面倒です。
本記事の内容を実施してエラーになったり意図した挙動にならない場合は通信が正しく行われているかを確認すると問題が解決することが多いんじゃないかと予想します。
セキュリティとの兼ね合いもあり大っぴらにお勧めはできませんが、個人的な気持ちとしては、ドメインコントローラー同士はすべての通信を許可するくらいのほうが運用やトラブルシューティングは楽になるんじゃないかと思います。










