記事公開日
最終更新日
【AWS】プライベートサブネット内のEC2インスタンスをManaged Microsoft ADに参加させようとしたらハマったお話
こんにちは。DXソリューション営業本部の松浦です。
今回はAWSでManaged Microsoft ADを触っていてハマった点があったので、ポイントと対処法をご紹介いたします。
AWS Managed Microsoft ADについては以下AWSドキュメントをご参照下さい。
AWSドキュメント - AWS Managed Microsoft AD とは?
前提 / 構成図
本エントリは以下の構成を前提としてのご紹介となります。
構成のポイント / 前提条件は以下の通りです。
・ InternetGateway、NATGatewayを作成せずにインターネットアクセスを持たない閉じた環境とする。
・ AWSサービスとの通信が必要な場合はVPC エンドポイント経由とする。
・ 将来的にCloudFormation等でIaC対応を行えるよう、できるだけOS上の設定変更は自動化する。
何にハマったか？
今回、作成したEC2インスタンスをADへ参加させる方法として、
AWSマネージドで実現が可能なSystemsManagerのAWS-
※ マネジメントコンソールの操作の場合、EC2インスタンスの作成時にドメイン結合ディレクトリオプションで
AD参加設定を行うことが可能ですが、
CloudFormationの場合はドメイン結合ディレクトリオプションのプロパティが用意されていないため、
IaC化を見据えて不採用としました。
ところが、実際にAWS-JoinDirectoryServiceDomainを実行してみると、
いくつかのパブリックIPに対して疎通が行えないことによりエラーが発生し、上手くいきませんでした。
(AWSポリシーに抵触しないよう、具体的なIPアドレスの記載は控えます)
対象のパブリックIPをnslookupで確認してみると、「ds.ap-northeast-1.amazonaws.com」のIPのようです。
以下ドキュメントより、「ds.ap-northeast-1.amazonaws.com」はDirectory Serviceの東京リージョン用パブリックエンドポイントであることがわかりました。
AWSドキュメント - AWS Directory Service エンドポイントとクォータ
そして、以下ナレッジには「プライベートサブネットのEC2インスタンスを起動する場合は、インスタンスからパブリック AWS Directory Service エンドポイントへのトラフィックを許可する必要がある」旨の記載があります。
AWSナレッジ - SystemsManagerを使用したADへの参加方法
＞Note: If you launch an Amazon EC2 instance in a private subnet, then you must allow traffic from your instance to the public AWS Directory Service endpoints. For more information,
こういう時はVPCエンドポイントを使えばよいので、マネジメントコンソールからVPC画面でエンドポイントを作成しようとしたところ、
本エントリ執筆時点において「東京リージョンではDirecotry Service向けのVPCエンドポイントがサポートされていない」ということがわかりました。
※ 上記、AWSサポートへも確認が取れている情報となります。
結果として、「AWS-JoinDirectoryServiceDomainでのAD参加の為にはパブリック AWS Directory Service エンドポイントへの疎通が必要だが、VPCエンドポイントがサポートされていないため疎通ができず実現不可」というハマり方をしました。
代替策
これまでの内容で、今回のインターネットアクセスを持たない構成では「AWS-JoinDirectoryServiceDomain」を使用したAD参加が行えないことがわかりました。
そこで、「インターネットアクセスを持たない」と「CloudFormation化等のIaC化を考慮する」の両方を満たすことができる代替策を考えてみました。
・ EC2インスタンスの作成時にディレクトリ結合オプションで参加対象のADを選択する。
→ マネジメントコンソール作業の場合は問題ないが、IaC化すると採用不可。
(少なくともCloudFormationでは該当機能がサポートされていない)
・ EC2インスタンスへRDPして手動で設定を行う。
→ IaC化すると手動操作が増えるため運用工数が増える。
・ NAT Gatewayを経由してインターネットへのルート確保後、
Systems ManagerのAWS-JoinDirectoryServiceDomainを使用する。
→ 根本的な構成変更が必要となる。コストにも影響する。
・ EC2インスタンス作成時のユーザーデータまたはSystems ManagerのAWS-RunPowerShellScriptを
使用してAdd-Computerコマンドを実行する。
→ よさそう。
上記より、「インターネットアクセスを持たない」と「CloudFormation化等のIaC化を考慮する」を両立するには、
「EC2インスタンス作成時のユーザーデータまたはSystems ManagerのAWS-RunPowerShellScriptを使用してAdd-Computerコマンドを実行する」方式が適していそうです。
やってみた
実際にやってみました。
今回は失敗時の切り分けや将来的なログ出力設計を考慮し、Systems ManagerのAWS-RunPowerShellScriptを使用した方法を実演いたします。
前提として、以下が設定済みであることとします。
・ ManagedAD作成済み。(ディレクトリ名：example.com)
・ ManagedADと同サブネットにWindowsインスタンスを起動済み。
・ WindowsインスタンスにはAmazonSSMManagedInstanceCore、AmazonSSMDirectoryServiceAccessを含む
適切なIAMロール設定済み。
・ WindowsインスタンスはSystemsManagerAgentがインストール済みのAMIを使用。
・ SystemsManager用にssm,ssmmessages,ec2messagesのVPCエンドポイント作成済み。
・ Windowsインスタンスには同VPC内からのトラフィック許可のインバウンド / 全許可のアウトバウンドを持つ
セキュリティグループを適用済み。
・ SystemsManager用VPCエンドポイントのセキュリティグループは適切に設定済み。
・ ManagedADのセキュリティグループはデフォルトで作成されるものから変更無し。
また、これからご説明する手順は以下AWSドキュメントの内容を、SystemsManagerで実行する形に変更を加えたものとなります。
AWSドキュメント - EC2 Windowsインスタンスを手動でManaged Microsoft ADに結合する
(1) ManagedADのDNSアドレスを確認
サービス - Directory Service - (作成したManagedADのID) - ネットワークとセキュリティ - DNS アドレス の値を控える
(2) Run Command設定画面を表示
サービス - AWS Systems Manager - Run Command - Run command
(3) パラメータを入力
以下箇所を変更し、それ以外はデフォルトとする。
・ コマンドドキュメント：AWS-RunPowerShellScript
・ コマンドのパラメータ - Commands：以下(4)で記載します。
・ ターゲット： インスタンスを手動で選択する - 対象インスタンスを選択
・ 出力オプション - コマンド出力の Amazon S3 バケットへの書き込み：チェックを外す
※ 一番シンプルな設定内容としているため、ログ出力等は必要に応じて有効化してください。
(4) Commandsに以下を入力
# ネットワークアダプターへのDNS設定(Managed ADのIPアドレスを設定)
$adapter = Get-NetAdapter | Where-Object { $_.Status -eq 'Up' }
$primaryDNS = "【手順(1)で確認したDNSアドレス】"
$secondaryDNS = "【手順(1)で確認したDNSアドレス】"
foreach ($nic in $adapter) {
$nic | Set-DnsClientServerAddress -ServerAddresses ($primaryDNS, $secondaryDNS)
Get-DnsClientServerAddress -InterfaceAlias $nic.Name
}
# ドメインに参加する際の変数設定
$domainName = "example.com"
$ouPath = "OU=Computers,OU=example,DC=example,DC=com"
# 資格情報の設定
$username = "admin@example.com"
$password = ConvertTo-SecureString "【ManagedAD作成時のパスワード】" -AsPlainText -Force
# Credentialオブジェクトの作成
$credential = New-Object System.Management.Automation.PSCredential($username, $password)
# ドメインに参加
Add-Computer -DomainName $domainName -OUPath $ouPath -Credential $credential -Restart
※ primaryDNS,secondaryDNSは手順(1)で確認したManagedADのDNSアドレスを入力
※ domainName,ouPathは作成したManagedADに適した内容を入力
※ passwordはManagedAD作成時に設定したパスワードを入力
(5) 「実行」をクリック
(6) 結果を確認
コマンドの実行画面で以下を確認する。
・ 「全体的なステータス」が「成功」となっていること。
・ 「ターゲットと出力」から対象インタンスIDをクリック後、
「Error」ログに出力が無く"Error(0)"表示であること。
(7) 動作確認
対象インスタンスへ「ADの管理ユーザー(admin@example.com)」でRDP可能かを確認し、
RDP可能であれば操作完了です！
参考として、SystemsManagerでのRDP確認例は以下の通りです。
・ サービス - AWS Systems Manager - フリートマネージャー
・ 対象インスタンスにチェック - ノードアクション - 接続 - リモートデスクトップで接続
・ 認証タイプ：ユーザー認証情報、
ユーザー名：admin@example.com、
パスワード：ManagedAD作成時に設定したパスワード
まとめ
● 本エントリ執筆時点では、東京リージョンではDirectory Service用のVPCエンドポイントはサポートされておらず作成ができない。
⇒ プライベートサブネット環境かつインターネットアクセスを持たない環境では、
「AWS-JoinDirectoryServiceDomain」を使用したAD参加が行えない。
● 「インターネットアクセスを持たない」と「CloudFormation化等のIaC化を考慮する」の両方を満たすための
代替案としては以下が考えられる。
・ EC2インスタンス作成時のユーザーデータまたはSystems ManagerのAWS-RunPowerShellScriptを使用してAdd-Computerコマンドを実行する。
● 前提を変えることで、以下方法も選択肢に入る。
・ EC2インスタンスの作成時にディレクトリ結合オプションで参加対象のADを選択する。
・ EC2インスタンスへRDPして手動で設定を行う。
・ NAT Gatewayを経由してインターネットへのルート確保後、Systems ManagerのAWS-JoinDirectoryServiceDomainを使用する。
最後までお読みいただき、誠にありがとうございました！
インターネットアクセスを持たないプライベートサブネットでのDirectory Service使用時におけるハマりポイントをご紹介いたしました。
セキュリティ要件等により、インターネットアクセスを持たない構成を作成する場面もあるかと思いますので、
本エントリをご活用頂き設定の一助にして頂ければ幸いです。
もし「このサービスについて知りたい」「AWS環境の構築、移行」などのリクエストがございましたら、弊社お問合せフォームまでお気軽にご連絡ください！ のちほど当ブログにてご紹介させていただくか、複雑な内容に関するお問い合わせの内容の場合には直接営業からご連絡を差し上げます。
また、よろしければ以下のリンクもご覧ください！
＜QES関連ソリューション/ブログ＞
＜QESが参画しているAWSのセキュリティ推進コンソーシアムがホワイトペーパーを公開しました＞
※Amazon Web Services、”Powered by Amazon Web Services”ロゴ、およびブログで使用されるその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
