営業部 佐竹です。
今回は、AWS Managed Microsoft AD（MSAD） へ EC2 インスタンス構築時に自動で参加させる設定について記載します。
はじめに
以下のドキュメントの通り MSAD のドメインに対して、EC2 インスタンス構築時に自動的に参加することが可能です。
今回はこの手順を実行し、EC2 インスタンス構築時にドメイン参加させる方法をご紹介します。
前提条件
今回は、Directory Service の AWS Managed Microsoft AD が既に構築済という前提で記載させていただきます。
AWS 環境構成図
簡易的な AWS 環境構成図は以下の通りです。
作業内容
実施する作業内容は、非常に簡単です。
- EC2 インスタンス構築時に参加するディレクトリを指定
- 同時に、適切な権限を持つ IAM Role を指定
この2つさえクリアすれば問題ありません。なお、指定するディレクトリ(MSAD)は、EC2 インスタンスからネットワークとして通信可能である必要があります。
詳細を以下に記載します。
IAM Role の作成
AWS Managed Policy である AmazonSSMManagedInstanceCore と AmazonSSMDirectoryServiceAccess をアタッチした IAM Role を予め作成しておきます。
今回は少しややこしい名前ではありますが「AmazonSSMDirectoryServiceAccess」という名前で IAM Role を作成しました。
これら2つのポリシーから推測される通り、AD への参加には Systems Manager (SSM) が利用されます。
EC2 インスタンスの構築
マネジメントコンソールから通常通り EC2 インスタンスを構築します。
この時、「Step 3: Configure Instance Details」において、「Domain join directory」と「IAM role」をそれぞれ指定してください。
今回、Domain join directory には「d-956703043a (satake1.local)」を指定します。IAM Role には事前に作成済の「AmazonSSMDirectoryServiceAccess」を指定しました。
後は通常通りの構築作業の通りで問題ありません。
Security Group やネットワーク設定の注意点としては、MSAD への通信が可能となるよう設定ください。今回は MSAD と EC2 インスタンスを同 VPC かつ同 Subnet 上に展開しています。
補足ですが、VPC の DHCP Options Sets は AmazonProvidedDNS を指定したままとなっており、特に MSAD を指定するように変更はしておりません。
注意点
AWS Managed Microsoft AD のステータスが「Impaired」の状態の場合は、ドメインへの参加に失敗しますため念のため注意してください。
ドメインに参加できているか確認
リモートデスクトップ接続を行い、実際に Windows Server が指定のドメインに参加できているか確認します。
ハードウェアと接続のプロパティを確認すると、上の通り DNS サーバが以下の通り satake1.local が持つ IP アドレスに変更されています。
- 192.168.64.94
- 192.168.64.125
加えて、ネットワーク名も「satake1.local」となっていました。
さらに、システムのプロパティも確認してみましたが問題ありませんでした。
コンピュータ名を変更したい場合
今回、コンピュータ名が自動生成される値になっているため、これを構築時に指定したい場合は Launch 作業の中で Userdata を流し込むと良いでしょう。
実際に、インスタンス構築時に以下のような Userdata を流し入れてみましたが、コンピュータ名が変更された状態でドメイン参加できていました。
<powershell> Rename-Computer "DomainJoin1022" </powershell>
コンピュータ名は15文字が最大となっている点にご注意ください。
既に構築されている Windows Server ではどのように行うか？
既に構築済のインスタンスでは手動での参加以外に Systems Manager のドキュメント AWS-JoinDirectoryServiceDomain の Run command を実行して参加させることが可能です。詳細は以下をご覧ください。
裏で何が行われているのか
本題です。EC2 インスタンスの構築時にディレクトリを指定して IAM Role をアタッチするだけで AD に参加可能となるために、EC2 インスタンスの中で何が行われているのか軽く調べてみました。調査方法ですが C:\ProgramData\Amazon\SSM\Logs に存在する、Systems Manager のログを調査したものとなります。
結論から申し上げますと、Systems Manager のドキュメントが内部で生成され、それが実行されているようです。実行されていたドキュメントは「ssm-document-worker.log」を調べる限りは以下のようなものでした。
{
"DocumentInformation": {
"DocumentID": "f54ccc02-7d2a-42b2-9423-d420b4e9a4be.2021-10-22T04-14-48.357Z",
"CommandID": "",
"AssociationID": "f54ccc02-7d2a-42b2-9423-d420b4e9a4be",
"InstanceID": "i-0ad4ce4c70583db03",
"MessageID": "aws.ssm.f54ccc02-7d2a-42b2-9423-d420b4e9a4be.i-0ad4ce4c70583db03",
"RunID": "2021-10-22T04-14-48.357Z",
"CreatedDate": "2021-10-22T04:14:48.029Z",
"DocumentName": "awsconfig_Domain_d-956703043a_satake1.local",
"DocumentVersion": "1",
"DocumentStatus": "InProgress",
"RunCount": 0,
"ProcInfo": {
"Pid": 3384,
"StartTime": "2021-10-22T04:14:48.452963Z"
},
"ClientId": "",
"RunAsUser": "",
"SessionOwner": ""
},
"DocumentType": "Association",
"SchemaVersion": "1.0",
"InstancePluginsInformation": [
{
"Configuration": {
"Settings": null,
"Properties": {
"directoryId": "d-956703043a",
"directoryName": "satake1.local",
"dnsIpAddresses": [
"192.168.64.94",
"192.168.64.125"
]
},
"OutputS3KeyPrefix": "i-0ad4ce4c70583db03/f54ccc02-7d2a-42b2-9423-d420b4e9a4be/2021-10-22T04-14-48.357Z/awsdomainJoin",
"OutputS3BucketName": "",
"S3EncryptionEnabled": false,
"CloudWatchLogGroup": "",
"CloudWatchEncryptionEnabled": false,
"CloudWatchStreamingEnabled": false,
"OrchestrationDirectory": "C:\\ProgramData\\Amazon\\SSM\\InstanceData\\i-0ad4ce4c70583db03\\document\\orchestration\\f54ccc02-7d2a-42b2-9423-d420b4e9a4be\\2021-10-22T04-14-48.357Z\\awsdomainJoin",
"MessageId": "aws.ssm.f54ccc02-7d2a-42b2-9423-d420b4e9a4be.i-0ad4ce4c70583db03",
"BookKeepingFileName": "f54ccc02-7d2a-42b2-9423-d420b4e9a4be.2021-10-22T04-14-48.357Z",
"PluginName": "aws:domainJoin",
"PluginID": "aws:domainJoin",
"DefaultWorkingDirectory": "",
"Preconditions": null,
"IsPreconditionEnabled": false,
"CurrentAssociations": [
"f54ccc02-7d2a-42b2-9423-d420b4e9a4be"
],
"SessionId": "",
"ClientId": "",
"KmsKeyId": "",
"RunAsEnabled": false,
"RunAsUser": "",
"ShellProfile": {
"windows": "",
"linux": ""
},
"SessionOwner": ""
},
"Name": "aws:domainJoin",
"Result": {
"pluginID": "",
"pluginName": "",
"status": "",
"code": 0,
"output": null,
"startDateTime": "0001-01-01T00:00:00Z",
"endDateTime": "0001-01-01T00:00:00Z",
"outputS3BucketName": "",
"outputS3KeyPrefix": "",
"stepName": "",
"error": "",
"standardOutput": "",
"standardError": ""
},
"Id": "aws:domainJoin"
}
],
"CancelInformation": {
"CancelMessageID": "",
"CancelCommandID": "",
"Payload": "",
"DebugInfo": ""
},
"IOConfig": {
"OrchestrationDirectory": "C:\\ProgramData\\Amazon\\SSM\\InstanceData\\i-0ad4ce4c70583db03\\document\\orchestration\\f54ccc02-7d2a-42b2-9423-d420b4e9a4be\\2021-10-22T04-14-48.357Z",
"OutputS3BucketName": "",
"OutputS3KeyPrefix": "i-0ad4ce4c70583db03/f54ccc02-7d2a-42b2-9423-d420b4e9a4be/2021-10-22T04-14-48.357Z",
"CloudWatchConfig": {
"LogGroupName": "",
"LogStreamPrefix": "",
"LogGroupEncryptionEnabled": false
}
}
}
このドキュメントは EC2 インスタンス内部で生成されるようで、探したところ Systems Manager のコンソールからは確認ができませんでした。OutputS3BucketName は空になっており、S3 Bucket にログなどは出力されません。
このログからも Systems Manager で実行されることの裏付けが取れました。
まとめ
今回は、AWS Managed Microsoft AD（MSAD） へ EC2 インスタンス構築時にシームレスに参加させる方法を実際に検証してみました。
最初に記載させて頂いたように、「MSAD の指定」と「IAM Role の指定」の2つのみを行えば、あとは EC2 インスタンス内部の Systems Manager Agent がドキュメントの実行を行いディレクトリへの参加が完了します。
簡単ですが以上になります。
では、またお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
