EC2インスタンスが自動的にMicrosoft Active Directoryドメインに参加するように構成する方法
AWS上でWindows EC2インスタンスをMicrosoft Active Directoryドメインにシームレスに参加させることは、とくにハイブリッドクラウドアーキテクチャを構築しているエンタープライズにとって一般的なシナリオです。AWS Directory Serviceによって、オンプレミスまたはAWS上でActive Directoryドメインの管理を可能にしています。AD ConnectorをつかったオンプレミスのActive DirectoryからAWSへの接続方法ではこのシナリオを実装するプロセスについて解説しています。
このブログ記事では、はじめに新規にWindowsインスタンスを起動するときにAmazon EC2 Launch Wizardで組織単位などカスタムのドメイン参加コンフィギュレーションを取り上げる標準的な方法をご紹介します。さらにEC2 Auto Scaling groupであたらしく起動したインスタンスでターゲットドメインへの自動的な参加を有効にする方法についても紹介します。どちらのシナリオにおいてもAmazon EC2 Simple Systems Manager （SSM）が中心的な役割を果たします。
前提条件と仮定
- Active DirectoryドメインをAWS上で管理している、またはオンプレミスのドメインにAD Connectorで接続しています。
- コンピュータ上にAWS CLIを適切にインストールして構成しています。
- このガイドはWindowsベースのインスタンスのみに適用されます。
パート 1: EC2 launch wizardでデフォルトのドメイン参加構成を変更する
はじめに、SSMについて知りましょう。SSMはWindows EC2インスタンスの構成をリモートで管理することができるサービスです。SSMによって、管理用のスクリプトやコマンドをWindowsインスタンス上でリモートで実行できます。
SSMはJSONドキュメントで構成されます。SSM JSONドキュメントは、たとえばWindows EC2インスタンスをドメインに参加させるようSSMに指示するaws:domainJoinのようにインスタンス上で実行したいコマンドを記述します。
以下はaws:domainJoinコマンドコンフィギュレーションによるサンプルのSSMドキュメントです。サンプルにもとづいて、サーバーを参加させたい組織単位など自身のドメイン参加のコンフィギュレーションをふくむSSMドキュメントを作成することができます。（このブログ記事では、プレースホルダー値は赤い文字で示してます。この値を自身のAWSの情報にあわせて置き換えてください。）
{
"schemaVersion": "1.0",
"description": "Sample configuration to join an instance to a domain",
"runtimeConfig": {
"aws:domainJoin": {
"properties": {
"directoryId": "d-1234567890",
"directoryName": "test.example.com",
"directoryOU": "OU=test,DC=example,DC=com",
"dnsIpAddresses": [
"198.51.100.1",
"198.51.100.2"
]
}
}
}
}
このコンフィギュレーションドキュメントでは：
- directoryId はAWS Directory Serviceで作成したディレクトリのID（またはAD Connector）です。
- directoryName はドメインの名前です（たとえば、example.com）。
- directoryOU はドメインの組織単位です。
- dnsIpAddresses にはDirectory Serviceでディレクトリ（またはAD Connector）を作成するときに指定したDNSサーバーのIPアドレスがふくまれます。
SSMとEC2 launch wizardとの間の接続についてはどうでしょうか？はじめてEC2 launch wizardでドメインを指定すると、ウィザードはドメインのデフォルトSSMドキュメントを生成します。デフォルトSSMドキュメントには必要なドメイン参加のコンフィギュレーションがふくまれますが、directoryOUプロパティは除外されます。Launch Wizardは以下の決まりを使用してSSMドキュメントに名前を付けます：awsconfig_Domain_<directoryId>_<directoryName>。ウィザードから起動したインスタンスが動作するようになるとすぐに、ウィザードは指定されたドメインのデフォルトSSMドキュメントに対して関連付けます。インスタンスのブートアッププロセスの一部として、EC2Configサービスはインスタンスに関連付けられたSSMドキュメントを適用します。
注：SSMドキュメントで指定されたコマンドまたはスクリプトはEC2ConfigサービスがWindowsのLocalSystemアカウントで動作するためインスタンス上の管理者権限で動作します。セキュリティ上の考慮点に関する詳細な情報は、Managing Windows Instance Configurationを参照してください。
デフォルトSSMドキュメントのドメイン参加コマンドはインスタンスの初回ブートアッププロセスのなかで一度だけ実行されます。インスタンスのストップ/スタートや、インスタンスの再起動時にはコマンドは実行されません。
デフォルトSSMドキュメントのリプレース
以下のステップは自分のドメインのためのデフォルトSSMドキュメントをdirectoryOUプロパティをふくむ自身のSSMドキュメントで置き換える方法を紹介します。はじめる前に、起動したEC2インスタンスがSSM APIと通信できるようにするためのAWS Identity and Access Management (IAM)ロールの設定をふくむSSMを使用するための前提条件を満たしていることを確認してください。さらに、以下のAWS CLIコマンドを実行するためにAWS CLIをインストールして構成済みであることを確認してください。AWS CLIのセットアップに効率的なAWSリージョンはターゲットのActive Directoryドメインが構成されているのと同じリージョンでWindows EC2インスタンスを起動するのと同じリージョンでセットアップするのが効率的です。
デフォルトSSMドキュメントをリプレースするには：
- 上記のJSONサンプルをベースにあたらしいSSMドキュメントを作成します。EC2 launch wizardでターゲットドメインのデフォルトにしたい組織単位をふくめるようにしてください。あとのステップでドキュメントを参照するためファイルとして保存します。
- 以下のコマンドを実行してデフォルトSSMドキュメントがドメインに存在するか検証します。
aws ssm get-document --name "awsconfig_Domain_<directoryId>_<directoryName>"
ターゲットドメインのデフォルトドキュメントが存在しなければ、コマンドの出力は"Invalid Document"エラーメッセージをしめします。これは単にウィザードからEC2インスタンスを起動してターゲットドメインに参加しようとしたことがないため、ディレクトリのデフォルトSSMドキュメントがまだ作成されていないことをしめしています。そのような場合は、ステップ5までスキップしてください。
デフォルトドキュメントが存在している場合、以前にウィザードからインスタンスを起動してターゲットドメインに参加しているためです。この場合、コマンドの出力はウィザードによって作成されたデフォルトSSMドキュメントのJSONの中身をあらわしています。ドメインのデフォルトSSMドキュメントはaws:domainJoinコマンドのdirectoryId、directoryName、dnsIpAddressesプロパティをふくみます。しかしながら、以下のサンプルJSONアウトプットにあるようにdirectoryOU—組織単位—がありません。
{
"schemaVersion": "1.0",
"description": "Automatic domain-join configuration created by the EC2 console.",
"runtimeConfig": {
"aws:domainJoin": {
"properties": {
"directoryId": "d-1234567890",
"directoryName": "test.example.com",
"dnsIpAddresses": [
"198.51.100.1",
"198.51.100.2"
]
}
}
}
}
コマンドの出力を後で参照するためにファイルに保存します（例えば、awsconfig_Domain_<directoryId>_<directoryName>.json）
- 以下のコマンドを実行してデフォルトSSMドキュメントがすでにいずれかのインスタンスに関連付けられているかを確認します。
aws ssm list-associations --association-filter-list key=Name,value="awsconfig_Domain_<directoryId>_<directoryName>"
ウィザードからインスタンスを起動してドメインに参加したことがなければ、コマンドの出力は関連付けが空のリストになります。そうでなければ、コマンドはウィザードから起動してドメインに参加したすべてのインタンスのリストを返します。参照のため出力をファイルに保存します。
- 現在のデフォルトSSMドキュメントを削除します。SSMドキュメントを削除すると、ドキュメントとすべてのインスタンスへの関連付けが削除されます。デフォルトSSMドキュメントの削除は関連付けられた稼働中のインスタンスに対して影響や変更はないことに注意してください。
以下のコマンドを実行してデフォルトのドキュメントを削除します。
aws ssm delete-document --name "awsconfig_Domain_<directoryId>_<directoryName>”
- 最後に、ステップ1で作成したSSMドキュメントをデフォルトドキュメントとしてアップロードします。以下のコマンドを実行することでそれを行うことができます。
aws ssm create-document --content file://path/to/new-ssm-doc-withOU.json --name “awsconfig_Domain_<directoryId>_<directoryName>”
注：上記のCLIコマンドをLinuxまたはMacコンピュータから発行しているのであれば、パスのはじめに"/"を追加する必要があります（例えば、file:///Users/username/temp）
create-documentコマンドの実行が成功した後に、デフォルトSSMドキュメントを作成したSSMドキュメントで置き換えます。EC2 launch wizardは新しいSSMコンフィギュレーションを指定したOUでドメインに参加するよう起動したすべてのWindowsインスタンスにデフォルトで適用されます。
さあ、このブログ記事のパート2に移りましょう！
パート 2: Auto ScalingグループのEC2インスタンスでActive Directoryドメインへの自動的な参加を有効にする
Auto Scalingはアプリケーションの負荷を対処するための適切な台数のEC2インスタンスを稼働させることを保証するために役に立つサービスです。EC2インスタンスの集合はAuto Scalingグループと呼ばれ、インスタンスの最小台数をAuto Scalingグループごとに指定することができます。Auto Scalingはグループがそのサイズ以下にならないことを保証します。同様に、Auto Scalingグループごとにインスタンスの最大台数を指定することができ、Auto Scalingはグループがそのサイズ以上にならないことを保証します。
Auto Scalingグループでインスタンスを起動したときにActive Directoryドメインに自動的に参加するようにしたい場合はどうでしょうか？組織単位を指定する必要がある場合はどうでしょうか？以下のステップはインスタンスをブートアップするときにWindows PowerShellスクリプトからSSMを呼び出してこれを完了する方法を紹介しています。
先に進む前に、この記事のパート1のステップ1と5で説明したように、SSMのcreate-documentコマンドを使用したドメイン参加コンフィギュレーションをふくむSSMドキュメントを作成してアップロードする必要があります。わかりやすいように、アップロードされたSSMドキュメントを参照する名前としてawsconfig_Domain_<directoryId>_<directoryName>を使用します。
ステップ 1: AmazonEC2RoleforSSMポリシーをコピーしてあたらしいIAMポリシーを作成する
このステップでは、 インスタンスをドメインに参加させるためのssm:CreateAssociationアクションを実行することをインスタンスに許可する権限を持つあたらしいIAMポリシーを作成します。 あたらしいポリシーはAWSマネージドのポリシー、AmazonEC2RoleforSSMをベースとします。
あたらしいIAMポリシーを作成するには：
- IAM consoleに移動して、 Policiesをクリックします。Create Policyをクリックします。
- Create Policyページで、Copy an AWS Managed Policyをクリックします。
- Search Policiesフィールドで、AmazonEC2RoleforSSMと入力して、Selectをクリックします。
- Policy Nameフィールドで、AmazonEC2RoleforSSM-ASGDomainJoinという名前を入力します。
- ポリシードキュメントエディタで、以下のスクリーンショットでハイライトされているようにssm:CreateAssociation権限を追加します。
最後に、Validate Policyをクリックします。ポリシーが正当であれば、Create Policyをクリックします。
ステップ 2: Auto ScalingグループにEC2インスタンスのあたらしいIAMロールを作成する
つぎに、あたらしいIAMロールを作成してAmazonEC2RoleforSSM-ASGDomainJoinポリシーをアタッチします。このロールとアタッチされたポリシーはEC2インスタンスがSSMサービスと通信して異なるSSMサービスAPIを実行する権限を付与します。あとからこのロールをAuto Scaling launch configuration wizardで指定します。
このあたらしいIAMロールを作成するには：
- IAM consoleに移動して、左のペインからRolesをクリックして、それからCreate Roleをクリックします。
- Role Nameフィールドで、EC2SSMRole-ASGと入力してNext Stepをクリックします。
- Select Role Typeページで、AWS Service Rolesを選択します。下にスクロールしてAmazon EC2 Role for Simple Systems Managerを選択します。
- ポリシーをアタッチしないでください。Next Stepをクリックして、それからCreate Roleをクリックします。Rolesページにもどります。
- Filterフィールドで、EC2SSMRole-ASGと入力し、それからロールをクリックします。
- Permissionsタブで、Attach Policyをクリックします。
- Filterフィールドで、AmazonEC2RoleforSSM-ASGDomainJoinと入力します。ポリシーの隣のチェックボックスを選択して、Attach Policyをクリックします。
ステップ 3: あたらしいAuto Scaling launch configurationを作成する
これはすべてをいっぺんに行うステップです。はじめに、作成したIAMロールを使用するAuto Scaling launch configurationを作成します：
- EC2 consoleに移動して、左のペインのAuto ScalingにあるLaunch Configurationsをクリックします。
- Create Auto Scaling groupをクリックしてLaunch Configuration creation wizardを開始します。Windows ServerのAmazon Machine Image (AMI)を選択してウィザードのステップ2にすすみます。必要に応じたインスタンスタイプを選択して、ウィザードのステップ3にすすみ、Configure Instance Detailsを行います。
- 適切なconfiguration detailsを入力します。IAM roleでは、EC2SSMRole-ASGを選択します。
- つぎに、あたらしいインスタンスがAuto Scalingグループのスケールアウトで起動したときに実行されるWindows PowerShellスクリプトを追加します。Advanced Detailsセクションを展開します。以下のスクリプトをカスタマイズして、コピーしたものをUser dataフィールドに貼り付けます。
<powershell> Set-DefaultAWSRegion -Region <region> Set-Variable -name instance_id -value (Invoke-Restmethod -uri http://169.254.169.254/latest/meta-data/instance-id) New-SSMAssociation -InstanceId $instance_id -Name “<ssmDocumentName>" </powershell>
このスクリプトをカスタマイズするには：
- regionはAuto Scaling launch configurationを作成したリージョンです（例えば、us-east-1）。
- ssmDocumentNameは以前作成したSSMドキュメントの名前です。
このスクリプトは裏でSSM APIアクションのssm:CreateAssociationを発行してそれぞれのインスタンスをドメインに参加させます。これはEC2Configサービスによって実行されるブートアッププロセスの一部として発生します。このアプローチによる重要な利点はドメイン認証情報をさらす必要がないことです。
- Launch Configuration wizardのステップ4にすすみ、Add Storageを行います。ストレージ要件を指定して、ステップ5にすすみ、Configure Security Groupを行います。ステップ5では、あたらしいSecurity Groupを作成することも既存のものを選択して修正することもできます。どちらを選択しても、選択したSecurity Groupでポート443（HTTPS）でインターネットにアウトバウンドのアクセスを許可していることを確認してください。これはAuto ScalingグループのEC2インスタンスがSSMサービスと通信するために必要です。Security Groupの構成に関するより詳細な情報は、Amazon EC2 Security Groups for Windows Instancesを参照してください。
ステップ 4: ディレクトリの不要なドメインオブジェクトの自動的なクリーンアップをスケジュールする
Auto Scalingグループがスケールアウトすると、インスタンスが作成されてドメインに参加します。Auto Scalingグループがスケールインすると、インスタンスが削除され、インスタンスに対応したコンピュータオブジェクトはディレクトリから削除されないことに注意することが重要です。すなわち、インスタンスの削除によって不要なエントリがのこります。
Active Directoryは大量のコンピュータオブジェクトを保持できますが、ディレクトリから不要なエントリを削除するスクリプトをスケジュールするのはよいやり方です。もしくは、ドメインからコンピュータの参加を解除するスクリプトをセットアップして、そのスクリプトをインスタンスをシャットダウンする前に実行することもできます。ふたつめのアプローチの暗黙の前提はAuto Scalingグループのインスタンスは必要がなくなったときにだけシャットダウン（と削除）されるということです。
どのようにクリーンアップを行うかはあなた次第で、やり方は管理者によって異なります。
結論
このブログ記事では、EC2 launch wizardでカスタムのドメイン参加コンフィグレーションを使用する方法について紹介しました。さらにAuto ScalingグループのEC2インスタンスが起動時に自動的にActive Directoryドメインに参加する方法と、ディレクトリの不要なコンピュータオブジェクトの定期的な削除のクリーンアップをスケジュールすることの必要性について説明しました。上記のすべてのシナリオの中心はSSMで、それは進化を続けてWindowsと同様にLinuxインスタンスに対する管理コントロールの機能を追加しています。
このブログ記事に関するコメントがあれば、以下の"Comments"セクションに書き込んでください。質問があれば、EC2 forumのあたらしいフォーラムスレッドを立ち上げてください。
- Moataz（日本語訳はSA渡邉（@gentaw0）が担当しました。原文はHow to Configure Your EC2 Instances to Automatically Join a Microsoft Active Directory Domain）
コメント