Directory ServiceのMicrosoft ADとオンプレミスのADで信頼関係を組んでみた
おはようございます､加藤です｡東京暑すぎませんか?最高気温34度って理解が追いつかないです､体が溶けてしまいそう...
今回はWorkSpacesを使う際に役立つかなと考えDirectory ServiceのADとオンプレミスのADで信頼関係を構築してみました｡
やってみた
検証の為にオンプレミスのサーバーを用意するのは手間なので､EC2で代用します｡
本ブログでは､EC2のADをオンプレミスAD・オンプレミス側､Directory ServiceのADをマネージドAD､AWS側と呼称します｡
検証用環境の作成
まずは､図のような構成を作成します｡NAT Gatewayは冗長化していますが検証用なのでSingle-AZにしてもOKです｡
今回ADは同一のVPC内に作成しました｡また､EC2 on ADする場合はプライベートサブネットに置く事が多いと思いますが､ここでは踏み台を省略し､パブリックサブネットに配置しました｡
- VPC
- Internet Gateway
- Public Subnet × 2
- Private Subnet × 2
- NAT Gateway × 2
- EC2
- EC2
- Active Directory
- EC2
- Directory Service
- Microsoft AD
オンプレミス側のインバウンド許可
AWS→オンプレミス方向の通信を許可します｡
今回の検証環境の場合は､オンプレミスADのセキュリティグループとWindows Firewallを設定します｡
| プロトコル | ポート番号 | 送信元 | 備考 |
| TCP/UDP | 53 | マネージドADが存在するサブネットのCIDR | DNS |
| TCP/UDP | 88 | マネージドADが存在するサブネットのCIDR | Kerberos認証 |
| TCP/UDP | 389 | マネージドADが存在するサブネットのCIDR | LDAP |
| TCP | 445 | マネージドADが存在するサブネットのCIDR | SMB |
Directory ServiceはMulti-AZになっています｡複数のサブネットのCIDRから許可することを忘れないようにしてください｡
マネージド側のアウトバウンド許可
Directory ServiceのMicrosoft ADはデフォルトではアウトバウンド通信が自分のセキュリティグループにしか許可されていません｡オンプレミス側に通信するためにアウトバウンドを許可します｡
Directory Serviceの管理画面からID(d-xxxxxxxxxx)を確認して､一致するセキュリティグループを見つけます｡
| プロトコル | ポート番号 | 送信元 | 備考 |
| ALL | ALL | オンプレミス側ADのIPアドレス |
マネージド側のインバウンド許可
オンプレミス→AWS方向の通信を許可します｡
ものすごい数がありますが､一番上のICMP以外はデフォルトで0.0.0.0/0に対して開放されています｡
| プロトコル | ポート番号 | 送信元 | 備考 |
| ICMP | ALL | オンプレミス側ADのIPアドレス | ICMP |
| TCP/UDP | 53 | オンプレミス側ADのIPアドレス | DNS |
| TCP/UDP | 88 | オンプレミス側ADのIPアドレス | Kerberos認証 |
| UDP | 123 | オンプレミス側ADのIPアドレス | |
| UDP | 138 | オンプレミス側ADのIPアドレス | |
| TCP/UDP | 389 | オンプレミス側ADのIPアドレス | LDAP |
| TCP | 445 | オンプレミス側ADのIPアドレス | SMB |
| TCP | 464 | オンプレミス側ADのIPアドレス | |
| TCP | 636 | オンプレミス側ADのIPアドレス | |
| TCP | 3268-3269 | オンプレミス側ADのIPアドレス | |
| TCP | 1024-65535 | オンプレミス側ADのIPアドレス | |
| ALL | ALL | ディレクトリのセキュリティグループ(自分自身) |
Kerberos 事前認証を有効にする
ユーザーアカウントの Kerberos 事前認証を有効にします。デフォルトでは有効になっているので今回は作業しませんでした｡
この設定を確認する場合は「事前認証」を確認してください。
オンプレミス側 DNS 条件付きフォワーダーの構成
オンプレミス→AWS方向にDNSフォワーダーを設定します｡
最初にマネジメントコンソールで必要な情報を収集します｡FQDNとDNS ServerのIPアドレスが必要です｡
次は､オンプレミスADで作業をします｡PowerShellで以下のコマンドを実行します｡変数部分は収集した情報に合わせて変更してください｡
$dnsservers = @("xx.xx.xx.xx","xx.xx.xx.xx")
$fqdn = "example.internal"
Add-DnsServerConditionalForwarderZone `
-MasterServers $dnsservers `
-Name $fqdn `
-ReplicationScope "Domain"
オンプレミス側の信頼関係の作成
双方向の信頼関係作成をします｡
オンプレミスADで作業をします｡｢Active Directory ドメインと信頼関係｣を開き画像の通り操作してください｡
この部分もPowerShellで作成したかったのですが､うまくいきませんでした...
AWS側のドメイン名を入力します｡
任意の信頼パスワードを設定してください｡
信頼関係の作成
双方向の信頼関係作成と､AWS→オンプレミス側のDNSフォワーダーを設定します｡
マネジメントコンソールのディレクトリの画面から信頼関係を追加します｡
オンプレミス側のドメイン､信頼パスワードを入力する｡
信頼方向は双方向に設定し､条件付きフォワーダーにオンプレミスADのIPアドレスを入力する｡
ステータスが検証済みになれば成功です｡
あとがき
無事に構築できました!オンプレミスADの信頼関係を構築するところをPowerShell化できなかったのが残念ですね､ググると情報は出てくるのですが､今回の環境では上手く動きませんでした｡いつかリベンジしたいです｡
信頼関係を組むメリットは片方が死んでも継続動作できることです｡WorkSpacesでDirectory ServiceをAD ConnectorでオンプレミスADを利用している場合､間の回線(VPN,DX)やオンプレミスADがダウンするとWorkSpacesがマネージドサービスだとしても止まってしまいます｡
信頼関係を組むことによって普段は連携し､障害時もサービスが継続期待できます｡
以上です､ありがとうございました｡
