There is an environment where Linux EC2 instances are joined to AWS Managed Microsoft AD for integrated management of IDs, but until now, every time the number of instances increases, the AD join command is manually executed and the password is entered. It took a long time to deploy. In addition, I was considering EC2 Auto Scaling, and when I was investigating that I had to overcome this password input barrier, seamless AD participation was supported this year!

[Join Amazon EC2 for Linux Instances Seamlessly with AWS Directory Service](https://aws.amazon.com/jp/about-aws/whats-new/2020/08/seamlessly-join-amazon-ec2-for -linux-instance-to-aws-directory-service /)

So I tried to verify how to join AD when deploying a Linux instance. By the way, here is the AD participation method mentioned at the beginning ↓ ↓ Join Linux instances manually

Click here for the procedure verified this time ↓ ↓ Join Linux EC2 Instances Seamlessly AWS Managed Microsoft AD Directory

Prerequisites

First, the distributions and versions supported as of November 17, 2020 are as follows.

Amazon Linux AMI 2018.03.0 --Amazon Linux 2 (64-bit x86) --Red Hat Enterprise Linux 8 (HVM) (64-bit x86)
Ubuntu Server 18.04 LTS & Ubuntu Server 16.04 LTS
CentOS 7 x86-64
SUSE Linux Enterprise Server 15 SP1

In Note "Distributions prior to Ubuntu 14 and Red Hat Enterprise Linux 7 do not support the seamless domain join feature." So I decided that RHEL7 was OK and verified it with RHEL7.

In addition, the target instance requires AWS Systems Manager (SSM Agent) version 2.3.1644.0 or higher.

Verification environment

Region: Tokyo --DirectoryService: AWS Managed Microsoft AD Standard * Created --AD Participating Instances: RedHat Enterprise Linux 7.9 --Instance to connect to and operate AD: WindowsServer 2019 * Created

Let's verify

Join the RHEL7.9 instance to AWS Managed Microsoft AD at startup. First, create a domain user.

Creating a domain user for AD participation

To join the Linux instance in AD, set a domain user who has the authority to create a computer account as a service account. In this configuration, in Windows Server 2019 with AD participation, I opened "Active Directory Domain Services" (Run as another user and connect as the Microsoft AD Admin user) and created a new user.

ユーザー追加.png

Next, grant permissions to the created domain user. Since it will be used only for AD participation, the following PowerShell command was prepared because I wanted to give it the minimum authority possible. In the first line, `` `$ AccountName```, enter the domain user name you created earlier.

$AccountName = 'awsSeamlessDomain'
# DO NOT modify anything below this comment.
# Getting Active Directory information.
Import-Module 'ActiveDirectory'
$Domain = Get-ADDomain -ErrorAction Stop
$BaseDn = $Domain.DistinguishedName
$ComputersContainer = $Domain.ComputersContainer
$SchemaNamingContext = Get-ADRootDSE | Select-Object -ExpandProperty 'schemaNamingContext'
[System.GUID]$ServicePrincipalNameGuid = (Get-ADObject -SearchBase $SchemaNamingContext -Filter { lDAPDisplayName -eq 'Computer' } -Properties 'schemaIDGUID').schemaIDGUID
# Getting Service account Information.
$AccountProperties = Get-ADUser -Identity $AccountName
$AccountSid = New-Object -TypeName 'System.Security.Principal.SecurityIdentifier' $AccountProperties.SID.Value
# Getting ACL settings for the Computers container.
$ObjectAcl = Get-ACL -Path "AD:\$ComputersContainer" 
# Setting ACL allowing the service account the ability to create child computer objects in the Computers container.
$AddAccessRule = New-Object -TypeName 'System.DirectoryServices.ActiveDirectoryAccessRule' $AccountSid, 'CreateChild', 'Allow', $ServicePrincipalNameGUID, 'All'
$ObjectAcl.AddAccessRule($AddAccessRule)
Set-ACL -AclObject $ObjectAcl -Path "AD:\$ComputersContainer"

I ran the above command on Windows Server 2019 and set ** awsSeamlessDomain ** as a service account with the minimum required privileges.

Save service account information in Secrets Manager

Save the information in Secrets Manager so that the service account created earlier will be used when joining the domain when the instance is started. After transitioning to the Secrets Manager service console, click ** Store a new secret ** and set as shown in the figure below.

Select ** Other type of secrets ** and specify the service account name and password in key / value.
Specify the Secret name.
For Configure rotation, specify ** Disable automatic rotation **.
Review and save your settings and a new secret will be added. Make a note of the Secret ARN as it will be used when setting the IAM policy.

Creating an IAM role

Create an IAM role to grant to the instance that participates in AD. AWS managed policy x 2 and customer managed policy x 1 will be attached to the target IAM role, so create the customer managed policy first. Although the procedure is omitted, the policy name is ** SM-Secret-Linux-DJ- -Read **, and it was created with the following policy document.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue",
                "secretsmanager:DescribeSecret"
            ],
            "Resource": [
                "<Created Secret ARN>"
            ]
        }
    ]
}

Next, for the IAM role, select ** EC2 ** in ** Select type of trusted entity **, and check the following three management policies in the policy selection.

AmazonSSMManagedInstanceCore
AmazonSSMDirectoryServiceAccess --SM-Secret-Linux-DJ- -Read * Customer management policy created earlier

Name the role ** LinuxEC2DomainJoin ** and create an IAM role.

Join a Linux EC2 instance to AD

At this point, you're ready to have your Linux EC2 instance AD joined on a new boot! Start the instance and actually check that you can participate in AD.

--Click ** Launch Instances ** from the EC2 console. -** Step 1: Choose an Amazon Machine Image (AMI) ** is the Linux instance AMI to boot. This time, I chose RHEL 7.9 from Community AMIs. -** Step 2: Select any instance type in Choose an Instance Type . - Step 3: Configure Instance Details ** is the key step. VPC etc. are specified according to each environment, but in this step, AD, IAM role to participate, and UserData for installing SSM Agent are specified. --Domain join directory: Created AWS Managed Microsoft AD Standard domain - IAM role: LinuxEC2DomainJoin --User data: Specify the following script

#!/bin/bash -xe
exec > >(tee /var/log/user-data.log|logger -t user-data -s 2>/dev/console) 2>&1
yum install -y https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/latest/linux_amd64/amazon-ssm-agent.rpm
systemctl enable amazon-ssm-agent
systemctl start amazon-ssm-agent
systemctl status amazon-ssm-agent

-** Step 4 to 6 ** are set according to the environment. -** Step 7: Check the settings in Review Instance Launch ** and click ** Launch **.

A new Linux EC2 instance has started booting. Now log in to Windows Server again and try to check your AD computer account.

Before booting, only Windows that had already joined AD was displayed.

After the Linux EC2 instance has finished booting, refresh the screen and the computer account will be added.

When I check if the domain user can SSH log in to the Linux EC2 instance, You have successfully logged in!

Summary

We have verified how to seamlessly join AD when launching a Linux EC2 instance. In the past, there were times when domain participation was leaked due to manual command execution. If it automatically participates at startup, there will be no omission of work. With this, it seems that it can also be used during EC2 Auto Scaling.

(Added on 2020/11/19) Launch Templates specified in the Auto Scaling group does not seem to be able to specify the domain to join. .. So in the end, I wonder if there is no choice but to do it with UserData. ..

Seamlessly join a Linux EC2 instance to AWS Managed Microsoft AD