Il existe un environnement dans lequel les instances Linux EC2 sont jointes à AWS Managed Microsoft AD pour une gestion intégrée des ID, mais jusqu'à présent, à chaque fois que le nombre d'instances augmente, la procédure d'exécution manuelle de la commande de jointure AD et de saisie du mot de passe est effectuée sur l'instance. Le déploiement a pris beaucoup de temps. De plus, lorsque j'envisageais EC2 Auto Scaling et que j'enquêtais sur le fait que je devais surmonter cette barrière de saisie de mot de passe, la participation AD transparente a été prise en charge cette année!

[Rejoignez en toute transparence l'instance Amazon EC2 pour Linux à AWS Directory Service](https://aws.amazon.com/jp/about-aws/whats-new/2020/08/s Seamlessly-join-amazon-ec2-for -instance-linux-vers-service-d'annuaire-aws /)

J'ai donc essayé de vérifier comment rejoindre AD lors du déploiement d'une instance Linux. En passant, voici la méthode de participation AD mentionnée au début ↓ ↓ Rejoignez les instances Linux manuellement

Cliquez ici pour la procédure vérifiée cette fois ↓ ↓ Rejoignez en toute transparence des instances Linux EC2 AWS Managed Microsoft AD Directory (https://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/s Seamlessly_join_linux_instance.html)

Conditions préalables

Tout d'abord, les distributions et versions prises en charge à compter du 17 novembre 2020 sont les suivantes.

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

En note "Distributions prior to Ubuntu 14 and Red Hat Enterprise Linux 7 do not support the seamless domain join feature." J'ai donc décidé que RHEL7 était OK et l'ai vérifié avec RHEL7.

En outre, l'instance cible nécessite AWS Systems Manager (SSM Agent) version 2.3.1644.0 ou supérieure.

Donc

Environnement de vérification

Region: Tokyo --DirectoryService: AWS Managed Microsoft AD Standard * créé --AD Instances participantes: RedHat Enterprise Linux 7.9 --Instance pour se connecter et fonctionner avec AD: WindowsServer 2019 * Créé

Vérifions

Joignez l'instance RHEL7.9 à AWS Managed Microsoft AD au moment du démarrage. Tout d'abord, créez un utilisateur de domaine.

Création d'un utilisateur de domaine pour la participation AD

Pour rejoindre une instance Linux dans AD, définissez un utilisateur de domaine autorisé à créer un compte d'ordinateur en tant que compte de service. Dans cette configuration, sur Windows Server 2019 avec participation AD, j'ai ouvert «Active Directory Domain Services» (Exécuter en tant qu'autre utilisateur et me connecter en tant qu'utilisateur administrateur Microsoft AD) et créer un nouvel utilisateur.

ユーザー追加.png

Ensuite, accordez des autorisations à l'utilisateur de domaine créé. Puisqu'elle ne sera utilisée que pour la participation AD, la commande PowerShell suivante a été préparée car nous voulions disposer de l'autorité minimale possible. Entrez le nom d'utilisateur de domaine que vous avez créé précédemment dans `` $ AccountName '' sur la première ligne.

$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"

J'ai exécuté la commande ci-dessus sur Windows Server 2019 et défini ** awsS SeamlessDomain ** en tant que compte de service avec les autorisations minimales requises.

Enregistrer les informations du compte de service dans Secrets Manager

Enregistrez les informations dans Secrets Manager afin d'utiliser le compte de service créé précédemment lors de l'adhésion au domaine lors du démarrage de l'instance. Après la transition vers la console de service Secrets Manager, cliquez sur ** Stocker un nouveau secret ** et définissez-le comme indiqué dans la figure ci-dessous.

Sélectionnez ** Autre type de secrets ** et spécifiez le nom et le mot de passe du compte de service dans clé / valeur.
Spécifiez le nom du secret.
Pour Configurer la rotation, spécifiez ** Désactiver la rotation automatique **.
Vérifiez et enregistrez vos paramètres et un nouveau secret sera ajouté. Notez l'ARN secret tel qu'il sera utilisé lors de la définition de la stratégie IAM.

Créer un rôle IAM

Créez un rôle IAM à accorder aux instances participantes AD. La stratégie gérée par AWS x 2 et la stratégie gérée par le client x 1 seront associées au rôle IAM cible, créez donc d'abord la stratégie gérée par le client. Bien que la procédure soit omise, le nom de la politique est ** SM-Secret-Linux-DJ- <identifiant de répertoire> -Lire **, et il a été créé avec le document de politique suivant.

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

Ensuite, pour le rôle IAM, sélectionnez ** EC2 ** dans ** Sélectionnez le type d'entité approuvée ** et vérifiez les trois stratégies de gestion suivantes dans la sélection de stratégie.

AmazonSSMManagedInstanceCore
AmazonSSMDirectoryServiceAccess --SM-Secret-Linux-DJ- <ID de répertoire> -Lire * Politique de gestion des clients créée précédemment

Créez un rôle IAM avec le nom de rôle ** LinuxEC2DomainJoin **.

Joindre une instance Linux EC2 à AD

À ce stade, vous êtes prêt à ajouter une instance Linux EC2 à AD lors d'un nouveau démarrage! Démarrez l'instance et vérifiez que vous pouvez participer à AD.

Cliquez sur ** Lancer des instances ** depuis la console EC2.
** Étape 1: Choisissez une Amazon Machine Image (AMI) ** est l'AMI d'instance Linux à démarrer. Cette fois, j'ai choisi RHEL 7.9 parmi les AMI communautaires.
** Étape 2: Choisissez un type d'instance ** pour sélectionner n'importe quel type d'instance.
** Étape 3: Configurer les détails de l'instance ** est l'étape clé. Les VPC, etc. sont spécifiés en fonction de chaque environnement, mais dans cette étape, AD, le rôle IAM pour participer et UserData pour l'installation de l'agent SSM sont spécifiés. --Annuaire de jointure de domaine: domaine créé par AWS Managed Microsoft AD Standard
- IAM role: LinuxEC2DomainJoin --Données utilisateur: spécifiez le script suivant

#!/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

** Les étapes 4 à 6 ** sont définies en fonction de l'environnement.
** Étape 7: Vérifiez les paramètres dans Review Instance Launch ** et cliquez sur ** Launch **.

Une nouvelle instance Linux EC2 a commencé à démarrer. Maintenant, connectez-vous à nouveau à Windows Server et essayez de vérifier votre compte d'ordinateur AD.

Avant le démarrage, seul Windows qui avait déjà rejoint AD était affiché.

Une fois le démarrage de l'instance Linux EC2 terminé, actualisez l'écran et le compte d'ordinateur sera ajouté.

Lorsque je vérifie si l'utilisateur du domaine peut se connecter en SSH à l'instance Linux EC2, J'ai pu me connecter avec succès!

Sommaire

Nous avons vérifié comment rejoindre de manière transparente AD lors du lancement d'une instance Linux EC2. Dans le passé, il y avait des moments où la participation au domaine était divulguée en raison de l'exécution manuelle de commandes. S'il participe automatiquement au démarrage, il n'y aura pas d'omission de travail. Avec cela, il semble qu'il puisse également être utilisé pendant EC2 Auto Scaling.

(Ajouté le 19/11/2020) Les modèles de lancement spécifiés dans le groupe Auto Scaling ne semblent pas pouvoir spécifier le domaine à rejoindre. .. Donc au final, je me demande s'il n'y a pas d'autre choix que de le faire avec UserData. ..

Joindre en toute transparence une instance Linux EC2 à AWS Managed Microsoft AD