Cette page a été traduite par l'API Cloud Translation.

Configurez Active Directory pour permettre aux VM de s'associer automatiquement à un domaine

Last reviewed 2024-10-31 UTC

Dans ce document, vous découvrirez comment configurer Active Directory et Compute Engine de manière à ce que les instances de machines virtuelles (VM) Windows puissent se joindre automatiquement à un domaine Active Directory.

Automatiser le processus de jonction de VM Windows à Active Directory contribue à simplifier le processus de provisionnement des serveurs Windows. Cette approche vous permet également d'exploiter l'autoscaling sans pour autant sacrifier les avantages que procure Active Directory concernant la gestion des accès et la configuration.

Ce document est destiné aux administrateurs système et part du principe que vous connaissez bien la mise en réseau Active Directory et Google Cloud.

La configuration que vous créez en suivant la procédure décrite dans ce document peut servir de base pour des travaux supplémentaires avec Windows Server dans Google Cloud. Par exemple, une fois cette procédure terminée, vous pouvez déployer des applications ASP.NET avec l'authentification Windows dans des conteneurs Windows.

Si vous utilisez le service Microsoft AD géré et que vous n'avez pas besoin du nettoyage automatique des comptes d'ordinateur obsolètes, envisagez d'associer les VM Windows à l'aide de la fonctionnalité d'association automatisée de domaine. Pour en savoir plus, consultez la section Associer automatiquement une VM Windows à un domaine.

Objectifs

Déployez une application Cloud Run qui permet aux instances de VM des projets sélectionnés de se joindre automatiquement à votre domaine Active Directory.
Créez une tâche Cloud Scheduler qui analyse régulièrement votre domaine Active Directory afin d'identifier et de supprimer les comptes d'ordinateur obsolètes.
Testez la configuration en créant un groupe d'instances géré avec autoscaling par rapport aux instances de VM jointes au domaine.

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

Les instructions de ce document sont conçues pour que votre utilisation des ressources respecte les limites du niveau Toujours gratuit de Google Cloud. Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous aurez terminé de suivre ce document, vous pourrez éviter de continuer à payer des frais en supprimant les ressources créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

Dans ce document, nous partons du principe que vous avez déjà déployé Active Directory sur Google Cloud en utilisant le service géré pour Microsoft Active Directory (Service Microsoft AD géré) ou en déployant des contrôleurs de domaine autogérés sur Google Cloud.

Pour terminer les procédures, assurez-vous de disposer des éléments suivants :

Un accès administrateur au domaine Active Directory, y compris la capacité à créer des utilisateurs, des groupes et des unités organisationnelles (UO).
Une plage d'adresses IP CIDR /28 non utilisée dans le VPC au sein duquel vos contrôleurs de domaine Active Directory sont déployés. Vous utiliserez cette plage d'adresses IP pour configurer l'accès au VPC sans serveur.
Un sous-réseau dans lequel vous déployez les instances Windows. Ce sous-réseau doit être configuré pour utiliser l'accès privé à Google.

Si vous utilisez un contrôleur de domaine autogéré, vous aurez également besoin des éléments suivants :

Une zone de transfert DNS privée qui transfère les requêtes DNS à vos contrôleurs de domaine Active Directory.

Mettre en œuvre cette approche

Dans un environnement sur site, vous pouvez exploiter des fichiers de réponse (unattend.xml) ainsi que la personnalisation JoinDomain afin de joindre automatiquement de nouveaux ordinateurs à un domaine. Bien que vous puissiez utiliser cette approche dans Google Cloud, celle-ci présente un certain nombre de limitations :

L'utilisation d'un fichier unattend.xml personnalisé vous impose de maintenir une image Compute Engine personnalisée. Tenir une image personnalisée à jour à l'aide des mises à jour Windows nécessite soit une maintenance continue, soit un travail initial important pour configurer l'automatisation. À moins que vous n'ayez d'autres raisons de maintenir une image personnalisée, cet effort supplémentaire n'est probablement pas justifié.
Utiliser la personnalisation JoinDomain associe une image à un unique domaine Active Directory, car le nom du domaine doit être spécifié dans unattend.xml. Si vous gérez plusieurs domaines ou forêts Active Directory (par exemple, pour des environnements de test et de production distincts), vous serez peut-être amené à gérer plusieurs images personnalisées pour chaque domaine.
Joindre un ordinateur Windows à un domaine nécessite les identifiants d'un utilisateur possédant les autorisations requises pour créer un objet ordinateur dans l'annuaire. Si vous utilisez la personnalisation JoinDomain dans unattend.xml, vous devez insérer ces identifiants en texte brut dans unattend.xml. Ces identifiants intégrés peuvent faire de cette image une cible potentielle pour des pirates informatiques. Bien que vous puissiez contrôler l'accès à l'image en définissant des autorisations IAM (Identity and Access Management) appropriées, la gestion de l'accès à une image personnalisée complique inutilement les choses.

L'approche décrite dans ce document n'utilise pas de fichiers de réponse et ne nécessite donc pas d'images spécialement préparées. Utilisez plutôt le scriptlet "sysprep specialize" suivant lorsque vous créez une instance de VM :

iex((New-Object System.Net.WebClient).DownloadString('https://DOMAIN'))

Ce scriptlet "sysprep specialize" initie un processus qui est illustré dans le schéma suivant :

Processus lancé par le scriptlet "sysprep specialize".

La procédure est la suivante :

Une fois l'instance de VM créée, Windows démarre pour la première fois. Lors de la passe de configuration "specialize", Windows exécute le scriptlet "sysprep specialize". Le scriptlet "specialize" appelle l'application Cloud Run register-computer et télécharge un script PowerShell qui contrôle le processus de jonction à un domaine.
Windows appelle alors le script PowerShell téléchargé.
Le script PowerShell appelle le serveur de métadonnées afin d'obtenir un jeton d'ID qui identifie l'instance de VM de manière sécurisée.
Le script appelle à nouveau l'application register-computer, cette fois en lui transmettant le jeton d'identifiant afin de s'authentifier.
L'application valide le jeton d'identifiant et en extrait le nom, la zone et l'ID de projet Google Cloud de l'instance de VM.
L'application vérifie que le domaine Active Directory est bien configuré pour autoriser les instances de VM du projet donné à se joindre au domaine. Pour achever cette validation, l'application localise un contrôleur de domaine Active Directory et s'y connecte afin d'y rechercher une unité organisationnelle (UO) dont le nom correspond à l'ID de projet Google Cloud obtenu à partir du jeton d'identifiant. Si elle trouve une UO qui correspond, les instances de VM du projet sont autorisées à se joindre au domaine Active Directory dans l'UO identifiée.
L'application vérifie que le projet Google Cloud est configuré pour autoriser les instances de VM à se joindre à Active Directory. Pour achever cette validation, l'application vérifie si elle peut accéder à l'instance de VM au moyen de l'API Compute Engine.
Si toutes les étapes de validation sont concluantes, l'application prépare un compte d'ordinateur dans Active Directory. L'application enregistre le nom, la zone et l'identifiant de l'instance de VM en tant qu'attributs dans l'objet de compte d'ordinateur, de sorte que celui-ci peut être associé à l'instance de VM.
L'application utilise alors le protocole Kerberos "set password" pour attribuer un mot de passe aléatoire au compte d'ordinateur.
Le nom et le mot de passe de l'ordinateur sont renvoyés à l'instance Windows via un canal sécurisé par TLS.
Le script PowerShell utilise alors le compte d'ordinateur préalablement préparé pour joindre l'ordinateur au domaine.
Une fois que la passe de configuration "specialize" est terminée, l'ordinateur redémarre.

Le reste de cette procédure vous guide à travers les étapes requises pour configurer la jonction automatique à un domaine.

Préparer le domaine Active Directory

Commencez par préparer votre domaine Active Directory. Pour réaliser cette étape, vous devez disposer d'un ordinateur ayant un accès administrateur à votre domaine Active Directory.

Facultatif : restreindre les utilisateurs autorisés à joindre un ordinateur au domaine

Il peut être judicieux de limiter les utilisateurs autorisés à joindre des ordinateurs au domaine. Par défaut, la configuration de l'objet de stratégie de groupe (GPO) pour la stratégie par défaut des contrôleurs de domaine accorde le droit d'utilisateur Add workstations to domain à tous les utilisateurs authentifiés. Tout utilisateur possédant ce droit est autorisé à joindre des ordinateurs au domaine. Étant donné que vous automatisez le processus de jonction des ordinateurs à votre domaine Active Directory, attribuer ce niveau d'accès à tout utilisateur représente un risque de sécurité inutile.

Pour restreindre les utilisateurs autorisés à joindre des ordinateurs à votre domaine Active Directory, modifiez la configuration par défaut de l'objet GPO représentant la stratégie par défaut des contrôleurs de domaine :

À l'aide d'un client RDP, connectez-vous à une machine disposant d'un accès administrateur à votre domaine Active Directory.
Ouvrez la console de gestion des stratégies de groupe.
Accédez à Forêt > Domaines > domain-name > Objets de stratégie de groupe, où domain-name correspond au nom de votre domaine Active Directory.
Effectuez un clic droit sur Stratégie par défaut des contrôleurs de domaine et cliquez sur Modifier.
Dans la console Éditeur de gestion des stratégies de groupe, accédez à Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Attribution des droits utilisateur.
Double cliquez sur Ajouter des stations de travail au domaine.
Dans Propriétés, retirez de la liste les Utilisateurs authentifiés.
Pour autoriser les administrateurs à effectuer une jonction manuelle au domaine (facultatif), cliquez sur Ajouter un utilisateur ou un groupe, puis ajoutez à cette liste un groupe d'administrateurs.
Cliquez sur OK.

Vous pouvez maintenant fermer l'éditeur de gestion des stratégies de groupe et la console de gestion des stratégies de groupe.

Initialiser une structure d'annuaire

Vous allez maintenant créer une UO qui servira de conteneur pour toutes les UO spécifiques à un projet :

À l'aide d'un client RDP, connectez-vous à une machine disposant d'un accès administrateur à votre domaine Active Directory.
Ouvrez une session PowerShell avec élévation de privilèges.

Créez une unité organisationnelle :

$ParentOrgUnitPath = (Get-ADDomain).ComputersContainer
$ProjectsOrgUnitPath = New-ADOrganizationalUnit `
  -Name 'Projects' `
  -Path $ParentOrgUnitPath `
  -PassThru

Créer un compte utilisateur Active Directory

Pour accéder à Active Directory et préparer des comptes d'ordinateur, l'application register-computer a besoin d'un compte utilisateur Active Directory :

Créez un compte utilisateur Active Directory nommé register-computer, attribuez-lui un mot de passe aléatoire, puis placez-le dans l'UO Projects :

# Generate a random password
$Password = [Guid]::NewGuid().ToString()+"-"+[Guid]::NewGuid().ToString()

# Create user
$UpnSuffix = (Get-ADDomain).DNSRoot
$RegisterComputerUser = New-ADUser `
    -Name "register-computer Cloud Run app" `
    -GivenName "Register" `
    -Surname "Computer" `
    -Path $ProjectsOrgUnitPath `
    -SamAccountName "register-computer" `
    -UserPrincipalName "register-computer@$UpnSuffix" `
    -AccountPassword (ConvertTo-SecureString "$Password" -AsPlainText -Force) `
    -PasswordNeverExpires $True `
    -Enabled $True `
    -PassThru

Accordez au compte register-computer l'ensemble minimal d'autorisations requises pour gérer les comptes d'ordinateur et les groupes dans l'UO Projects et ses sous-unités :

$AcesForContainerAndDescendents = @(
    "CCDC;Computer",               # Create/delete computers
    "CCDC;Group"                   # Create/delete users
)

$AcesForDescendents = @(
    "LC;;Computer" ,               # List child objects
    "RC;;Computer" ,               # Read security information
    "WD;;Computer" ,               # Change security information
    "WP;;Computer" ,               # Write properties
    "RP;;Computer" ,               # Read properties
    "CA;Reset Password;Computer",  # ...
    "CA;Change Password;Computer", # ...
    "WS;Validated write to service principal name;Computer",
    "WS;Validated write to DNS host name;Computer",

    "LC;;Group",                   # List child objects
    "RC;;Group",                   # Read security information
    "WD;;Group",                   # Change security information
    "WP;;Group",                   # Write properties
    "RP;;Group"                    # Read properties
)

$AcesForContainerAndDescendents | % { dsacls.exe $ProjectsOrgUnitPath /G "${RegisterComputerUser}:${_}" /I:T | Out-Null }
$AcesForDescendents | % { dsacls.exe $ProjectsOrgUnitPath /G "${RegisterComputerUser}:${_}" /I:S | Out-Null }

L'exécution de cette commande peut prendre quelques minutes.

Accordez au compte register-computer l'autorisation de supprimer des enregistrements DNS:

Service Microsoft AD géré

Add-ADGroupMember -Identity "Cloud Service DNS Administrators" -Members ${RegisterComputerUser}

Domaine autogéré

$DnsPartition=(Get-ADDomain).SubordinateReferences | Where-Object {$_.StartsWith('DC=DomainDnsZones')}
$DnsContainer="DC=$((Get-ADDomain).DNSRoot),CN=MicrosoftDNS,$DnsPartition"

dsacls $DnsContainer /G "${RegisterComputerUser}:SD" /I:S

Afficher le chemin d'accès à l'UO Projects et le mot de passe généré pour le compte utilisateur Active Directory register-computer. Notez les valeurs, car vous en aurez besoin plus tard.
```
Write-Host "Password: $Password"
Write-Host "Projects OU: $ProjectsOrgUnitPath"
```

Préparer le projet Google Cloud

Configurez maintenant votre projet de domaine :

Si vous utilisez le service Microsoft AD géré, votre projet de domaine est le projet dans lequel vous avez déployé le service Microsoft AD géré.
Si vous utilisez un service Active Directory autogéré, votre projet de domaine est le projet qui exécute vos contrôleurs de domaine Active Directory. Dans le cas d'un VPC partagé, ce projet doit être le même que le projet hôte du VPC.

Vous utilisez ce projet de domaine pour effectuer les tâches suivantes :

Créer un secret Secret Manager contenant le mot de passe du compte utilisateur Active Directory register-computer.
Déployer l'application register-computer :
configurer Cloud Scheduler de manière à déclencher des nettoyages des comptes d'ordinateur obsolètes.

Nous vous recommandons d'accorder l'accès au projet de domaine en suivant le principe du moindre privilège.

Créer un secret Secret Manager

Dans la console Google Cloud, ouvrez Cloud Shell.

Ouvrir Cloud Shell
Lancez PowerShell :
```
pwsh
```
Initialisez la variable suivante, en remplaçant domain-project-id par l'ID de votre projet de domaine :
```
$DomainProjectId = "domain-project-id"
```
Définissez le projet de domaine en tant que projet par défaut :
```
& gcloud config set project $DomainProjectId
```

Activez l'API Secret Manager :

& gcloud services enable secretmanager.googleapis.com

Saisissez le mot de passe du compte utilisateur Active Directory register-computer et stockez-le dans un secret Secret Manager :

$RegisterComputerCredential = (Get-Credential -Credential 'register-computer')

$TempFile = New-TemporaryFile
Set-Content $TempFile $($RegisterComputerCredential.GetNetworkCredential().Password) -NoNewLine

& gcloud secrets create ad-password --data-file $TempFile

Remove-Item $TempFile

Accorder l'accès à Kerberos et LDAP

Pour gérer les adhésions au domaine, l'application register-computer accède à vos contrôleurs de domaine à l'aide des protocoles suivants:

LDAP (TCP/389) ou LDAPS (TCP/636)
Kerberos (UDP/88, TCP/88)
Changement de mot de passe Kerberos (UDP/464, TCP/464)

Service Microsoft AD géré

Vous n'avez pas besoin de configurer de règles de pare-feu.

Domaine autogéré

Créez une règle de pare-feu qui autorise l'accès à vos contrôleurs de domaine.

Vous pouvez appliquer la règle sur la base d'un tag réseau que vous avez attribué à vos contrôleurs de domaine, ou bien vous pouvez l'appliquer en utilisant un compte de service.

Par tag réseau

& gcloud compute firewall-rules create allow-adkrb-from-serverless-to-dc `
    --direction INGRESS `
    --action allow `
    --rules udp:88,tcp:88,tcp:389,tcp:636,udp:464,tcp:464 `
    --source-ranges $ServerlessIpRange `
    --target-tags dc-tag `
    --network $VpcName `
    --project vpc-project-id `
    --priority 10000

Remplacez les éléments suivants :

dc-tag : le tag réseau attribué aux VM de vos contrôleurs de domaine.
vpc-project-id : l'ID du projet dans lequel est défini le VPC. Si vous utilisez un VPC partagé, utilisez le projet hôte du VPC. Sinon, utilisez l'identifiant du projet de domaine.

Par compte de service

& gcloud compute firewall-rules create allow-adkrb-from-serverless-to-dc `
    --direction INGRESS `
    --action allow `
    --rules udp:88,tcp:88,tcp:389,tcp:636,udp:464,tcp:464 `
    --source-ranges $ServerlessIpRange `
    --target-service-accounts dc-sa `
    --network $VpcName `
    --project vpc-project-id `
    --priority 10000

Remplacez les éléments suivants :

dc-sa : l'adresse e-mail du compte de service utilisé par les VM de vos contrôleurs de domaine.
vpc-project-id : l'ID du projet dans lequel est défini le VPC. Si vous utilisez un VPC partagé, utilisez le projet hôte du VPC. Sinon, utilisez l'identifiant du projet de domaine.

Déployer l'application Cloud Run

Configurez maintenant Cloud Build pour déployer l'application register-computer sur Cloud Run :

Dans Cloud Shell, clonez le dépôt GitHub.

& git clone https://github.com/GoogleCloudPlatform/gce-automated-ad-join.git
cd gce-automated-ad-join/ad-joining

Initialisez les variables suivantes :
```
$ServerlessRegion = "serverless-region"
$VpcName = "vpc-name"
$VpcSubnet = "subnet-name"
$AdDomain = "dns-domain-name"
$AdNetbiosDomain = "netbios-domain-name"
$ProjectsOrgUnitPath = "projects-ou-distinguished-name"
```
Remplacez les éléments suivants :
- serverless-region: région dans laquelle déployer l'application register-computer. La région ne doit pas nécessairement être celle dans laquelle vous prévoyez de déployer des instances de VM.
- vpc-name : le nom du réseau VPC qui héberge les contrôleurs de votre domaine Active Directory.
- subnet-name: sous-réseau de vpc-name à utiliser pour l'accès direct au VPC. Le sous-réseau doit se trouver dans la même région que serverless-region.
- dns-domain-name : le nom de domaine DNS de votre domaine Active Directory.
- netbios-domain-name : le nom NetBIOS de votre domaine Active Directory.
- projects-ou-distinguished-name : le nom distinctif de votre UO Projects.

Activez les API Cloud Run et Cloud Build :

& gcloud services enable run.googleapis.com cloudbuild.googleapis.com

Créez un compte de service register-computer-app pour l'application Cloud Run :

& gcloud iam service-accounts create register-computer-app `
  --display-name="register computer Cloud Run app"

Créez un compte de service build-service pour exécuter des déclencheurs Cloud Build:

& gcloud iam service-accounts create build-service `
  --display-name="Cloud Build build agent"

Autorisez le compte de service Cloud Run à lire le secret contenant le mot de passe Active Directory :

& gcloud secrets add-iam-policy-binding ad-password `
  --member "serviceAccount:register-computer-app@$DomainProjectId.iam.gserviceaccount.com" `
  --role "roles/secretmanager.secretAccessor"

Accordez à Cloud Build les autorisations nécessaires pour déployer sur Cloud Run :

$DomainProjectNumber = (gcloud projects describe $DomainProjectId --format='value(projectNumber)')
& gcloud iam service-accounts add-iam-policy-binding register-computer-app@$DomainProjectId.iam.gserviceaccount.com `
  --member "serviceAccount:build-service@$DomainProjectId.iam.gserviceaccount.com" `
  --role "roles/iam.serviceAccountUser"

& gcloud projects add-iam-policy-binding $DomainProjectId `
  --member "serviceAccount:build-service@$DomainProjectId.iam.gserviceaccount.com" `
  --role roles/cloudbuild.builds.builder

& gcloud projects add-iam-policy-binding $DomainProjectId `
  --member "serviceAccount:build-service@$DomainProjectId.iam.gserviceaccount.com" `
  --role roles/run.admin

Utilisez le fichier cloudbuild.yaml comme modèle pour créer une configuration de compilation Cloud Run personnalisée correspondant à votre environnement :

$Build = (Get-Content cloudbuild.yaml)
$Build = $Build.Replace('__SERVERLESS_REGION__', "$ServerlessRegion")
$Build = $Build.Replace('__PROJECTS_DN__', "$ProjectsOrgUnitPath")
$Build = $Build.Replace('__AD_DOMAIN__', "$AdDomain")
$Build = $Build.Replace('__AD_NETBIOS_DOMAIN__', "$AdNetbiosDomain")
$Build = $Build.Replace('__SERVICE_ACCOUNT_EMAIL__', "register-computer-app@$DomainProjectId.iam.gserviceaccount.com")
$Build = $Build.Replace('__SERVERLESS_NETWORK__', "$VpcName")
$Build = $Build.Replace('__SERVERLESS_SUBNET__', "$VpcSubnet")
$Build | Set-Content .\cloudbuild.hydrated.yaml

Créez l'application et déployez-la sur Cloud Run :

& gcloud builds submit . `
  --config cloudbuild.hydrated.yaml `
  --substitutions _IMAGE_TAG=$(git rev-parse --short HEAD) `
  --service-account "projects/$DomainProjectId/serviceAccounts/build-service@$DomainProjectId.iam.gserviceaccount.com" `
  --default-buckets-behavior regional-user-owned-bucket

L'opération de déploiement prend quelques minutes.

Déterminez l'URL de l'application Cloud Run :

$RegisterUrl = (gcloud run services describe register-computer `
  --platform managed `
  --region $ServerlessRegion `
  --format=value`(status.url`))
Write-Host $RegisterUrl

Notez l'URL. Vous en aurez besoin chaque fois que vous créerez une instance de VM à associer à Active Directory.

Appelez l'application Cloud Run pour vérifier que le déploiement a bien fonctionné :
```
Invoke-RestMethod $RegisterUrl
```
Un script PowerShell s'affiche. La VM exécute ce script au cours de la phase "specialize" qui la joint au domaine.

Activer la jonction automatique à un domaine au niveau d'un projet

L'application register-computer n'autorise pas les instances de VM à se joindre à un domaine Active Directory, sauf si la jonction automatique à un domaine est activée au niveau du projet associé aux VM. Cette mesure de sécurité permet d'empêcher les VM connectées à des projets non autorisés d'accéder à votre domaine.

Pour activer la jonction automatique à un domaine au niveau d'un projet, procédez comme suit :

Créez dans Active Directory une UO dont le nom correspond à l'ID de votre projet Google Cloud.
Accordez à l'application register-computer l'accès au projet Google Cloud.

Commencez par créer l'unité organisationnelle :

À l'aide d'un client RDP, connectez-vous à une machine disposant d'un accès administrateur à votre domaine Active Directory.
Dans le composant logiciel enfichable MMC "Utilisateurs et ordinateurs Active Directory", accédez à l'UO Projects.
Effectuez un clic droit sur l'UO et sélectionnez Nouveau > Unité organisationnelle.
Dans la boîte de dialogue Nouvel objet, saisissez l'ID du projet Google Cloud dans lequel vous allez déployer vos VM.
Cliquez sur OK.

Ensuite, accordez à l'application register-computer l'accès au projet Google Cloud :

Dans Cloud Shell, lancez PowerShell :
```
pwsh
```
Initialisez les variables suivantes :
```
$ProjectId = "project-id"
$DomainProjectId = "domain-project-id"
```
Remplacer
- project-id par l'ID du projet Google Cloud dans lequel déployer vos VM.
- domain-project-id par l'ID du projet de votre domaine ;

Accordez au compte de service register-computer-app le rôle Compute Viewer sur le projet :

& gcloud projects add-iam-policy-binding $ProjectId `
    --member "serviceAccount:register-computer-app@$DomainProjectId.iam.gserviceaccount.com" `
    --role "roles/compute.viewer"

Votre projet autorise désormais la jonction automatique à un domaine.

Tester la jonction au domaine

Vous pouvez maintenant vérifier que la configuration fonctionne correctement en effectuant les étapes suivantes :

Créer une instance de VM unique qui rejoint automatiquement le domaine Active Directory
Créer un groupe d'instances géré d'instances de VM qui rejoignent automatiquement le domaine Active Directory

Créer et joindre une seule instance de VM

Créez une instance de VM qui rejoint automatiquement le domaine Active Directory :

Revenez à la session PowerShell dans Cloud Shell et initialisez les variables suivantes :
```
$Region = "vpc-region-to-deploy-vm"
$Zone = "zone-to-deploy-vm"
$Subnet = "vpc-subnet-to-deploy-vm"
$ServerlessRegion = "serverless-region"
```
Remplacez les éléments suivants :
- vpc-region-to-deploy-vm : la région dans laquelle déployer l'instance de VM
- vpc-subnet-to-deploy-vm : le sous-réseau dans lequel déployer l'instance de VM
- zone-to-deploy-vm : la zone dans laquelle déployer l'instance de VM
- serverless-region : la région dans laquelle vous avez déployé l'application Cloud Run.

Définissez le projet et la zone par défaut :

& gcloud config set project $ProjectId
& gcloud config set compute/zone $Zone

Recherchez à nouveau l'URL de l'application Cloud Run :

$RegisterUrl = (gcloud run services describe register-computer `
  --platform managed `
  --region $ServerlessRegion `
  --format value`(status.url`) `
  --project $DomainProjectId)

Créez une instance en transmettant le scriptlet "specialize" qui déclenche le processus de jonction de la VM au domaine :
VPC partagé
```
$VpchostProjectId = (gcloud compute shared-vpc get-host-project $ProjectId --format=value`(name`))
& gcloud compute instances create join-01 `
    --image-family windows-2019-core `
    --image-project windows-cloud `
    --machine-type n1-standard-2 `
    --no-address `
    --subnet projects/$VpchostProjectId/regions/$Region/subnetworks/$Subnet `
    --metadata "sysprep-specialize-script-ps1=iex((New-Object System.Net.WebClient).DownloadString('$RegisterUrl'))"
```
VPC autonome
```
& gcloud compute instances create join-01 `
    --image-family=windows-2019-core `
    --image-project=windows-cloud `
    --machine-type=n1-standard-2 `
    --no-address `
    --subnet $Subnet `
    --metadata "sysprep-specialize-script-ps1=iex((New-Object System.Net.WebClient).DownloadString('$RegisterUrl'))"
```
Si vous souhaitez utiliser un nom d'hôte personnalisé, ajoutez un paramètre --hostname à la commande.

Si vous utilisez une version de Windows Server antérieure à Windows Server 2019, TLS 1.2 peut être désactivé par défaut, ce qui peut entraîner l'échec du scriptlet "specialize". Pour activer TLS 1.2, utilisez le scriptlet suivant à la place :
```
[Net.ServicePointManager]::SecurityProtocol=[Net.SecurityProtocolType]::Tls12;iex((New-Object System.Net.WebClient).DownloadString('$RegisterUrl'))
```
Remarque : NetBIOS n'accepte que des noms d'ordinateur comportant 15 caractères ou moins. Si le nom d'hôte d'une instance de VM dépasse cette longueur maximale, le scriptlet "specialize" remplace automatiquement le nom de l'ordinateur par un nom unique comportant moins de 15 caractères.

Lorsque vous créez des instances de VM supplémentaires, veillez à ne pas dépasser le nombre maximal de caractères autorisé. Dans le cas contraire, la jonction d'une instance de VM à votre domaine risque d'échouer.

Surveillez le processus de démarrage :

& gcloud compute instances tail-serial-port-output join-01

Au bout d'une minute environ, la machine est jointe à votre domaine Active Directory. Le résultat ressemble à ce qui suit :

Domain           : corp.example.com
DomainController : dc-01.corp.example.com.
OrgUnitPath      : OU=test-project-123,OU=Projects,DC=corp,DC=example,DC=com

WARNING: The changes will take effect after you restart the computer

Computer successfully joined to domain

Pour arrêter la surveillance du processus de démarrage, appuyez sur CTRL+C.

Vérifier qu'une VM a correctement rejoint Active Directory

À l'aide d'un client RDP, connectez-vous à une machine disposant d'un accès administrateur à votre domaine Active Directory.
Ouvrez le composant logiciel enfichable MMC "Utilisateurs et ordinateurs Active Directory".
Dans le menu, assurez-vous que l'option Affichage > Fonctionnalités avancées est bien activée.
Accédez à l'UO nommée d'après l'ID du projet Google Cloud dans lequel vous avez créé une instance de VM.
Double-cliquez sur le compte join-01.

Dans la boîte de dialogue Propriétés, cliquez sur l'onglet Éditeur d'attributs.

Le compte d'ordinateur comporte des annotations d'attributs LDAP supplémentaires. Ces attributs vous permettent de suivre l'association entre l'objet ordinateur et l'instance Compute Engine.

Vérifiez que la liste contient les attributs et valeurs LDAP suivants.

Attribut LDAP	Valeur
`msDS-cloudExtensionAttribute1`	ID de projet Google Cloud
`msDS-cloudExtensionAttribute2`	Zone Compute Engine
`msDS-cloudExtensionAttribute3`	Nom d'instance Compute Engine

Les attributs msDS-cloudExtensionAttribute sont des attributs à usage général et ne sont pas utilisés par Active Directory proprement dit.

Diagnostiquer les erreurs

Si votre instance de VM n'a pas réussi à se joindre au domaine, consultez le journal de l'application register-computer :

Dans Google Cloud Console, accédez à Cloud Run.

Accédez à Cloud Run
Cliquez sur l'application register-computer.
Dans le menu, cliquez sur Journaux.

Supprimer l'instance

Après avoir vérifié que l'instance de VM s'est correctement jointe au domaine Active Directory, vous pouvez la supprimer.

Supprimez l'instance :

& gcloud compute instances delete join-01 --quiet

Créer et joindre un groupe d'instances géré

Vous pouvez également vérifier que les instances d'un MIG parviennent à se joindre automatiquement à votre domaine.

Créez un modèle d'instance en transmettant le script "specialize" qui déclenche le processus de jonction de la VM au domaine :

VPC partagé

$VpchostProjectId = (gcloud compute shared-vpc get-host-project $ProjectId --format=value`(name`))
& gcloud compute instance-templates create ad-2019core-n1-std-2 `
    --image-family windows-2019-core `
    --image-project windows-cloud `
    --no-address `
    --machine-type n1-standard-2 `
    --subnet projects/$VpchostProjectId/regions/$Region/subnetworks/$Subnet `
    --metadata "sysprep-specialize-script-ps1=iex((New-Object System.Net.WebClient).DownloadString('$RegisterUrl'))"

VPC autonome

& gcloud compute instance-templates create ad-2019core-n1-std-2 `
    --image-family windows-2019-core `
    --image-project windows-cloud `
    --no-address `
    --machine-type n1-standard-2 `
    --subnet projects/$ProjectId/regions/$Region/subnetworks/$Subnet `
    --metadata "sysprep-specialize-script-ps1=iex((New-Object System.Net.WebClient).DownloadString('$RegisterUrl'))"

Créez un groupe d'instances géré qui utilise ce modèle d'instance :

& gcloud compute instance-groups managed create group-01 `
    --template ad-2019core-n1-std-2 `
    --size=3

Attendez quelques minutes, puis utilisez le composant logiciel enfichable MMC "Utilisateurs et ordinateurs Active Directory" pour vérifier que quatre objets ont été créés dans Active Directory :

Trois comptes d'ordinateur correspondant aux trois instances de VM du groupe d'instances géré.
Un groupe intitulé group-01 contenant les trois comptes d'ordinateur. Si vous envisagez d'utiliser des comptes de service gérés de groupe (gMSA), vous pouvez utiliser ce groupe pour accorder l'accès aux gMSA.

Une fois que vous avez vérifié que les instances de VM de vos MIG se sont correctement jointes à votre domaine Active Directory, vous pouvez supprimer le groupe géré et le modèle d'instance en procédant comme suit :

Dans Cloud Shell, supprimez le groupe d'instances :

& gcloud compute instance-groups managed delete group-01 --quiet

Supprimez le modèle d'instance :

& gcloud compute instance-templates delete ad-2019core-n1-std-2 --quiet

Planifier le nettoyage des comptes d'ordinateur obsolètes

Automatiser le processus de jonction des ordinateurs au domaine réduit les efforts requis pour configurer de nouveaux serveurs et vous permet d'utiliser les serveurs joints au domaine dans des groupes d'instances gérés. Toutefois, au fil du temps, les comptes d'ordinateur obsolètes peuvent s'accumuler dans le domaine.

Pour éviter cette accumulation, nous vous recommandons de configurer l'application register-computer afin d'analyser régulièrement votre domaine Active Directory pour détecter et supprimer automatiquement les comptes caducs et leurs enregistrements DNS associés.

L'application register-computer peut utiliser les attributs msDS-cloudExtensionAttribute des comptes d'ordinateurs pour identifier les comptes obsolètes. Ces attributs contiennent le projet, la zone et le nom de l'instance de VM correspondante dans Compute Engine. L'application peut vérifier pour chaque compte d'ordinateur si l'instance de VM correspondante est toujours disponible. Si ce n'est pas le cas, le compte d'ordinateur est considéré comme obsolète et supprimé.

Pour déclencher le nettoyage des comptes d'ordinateur, vous devez appeler le point de terminaison /cleanup de l'application Cloud Run. Pour empêcher le déclenchement d'un nettoyage par des utilisateurs non autorisés, cette requête doit être authentifiée à l'aide du compte de service register-computer-app.

Configurer Cloud Scheduler

Les étapes suivantes vous montrent comment configurer Cloud Scheduler conjointement avec Cloud Pub/Sub afin de déclencher automatiquement un nettoyage toutes les 24 heures :

Dans Cloud Shell, activez l'API Cloud Scheduler dans votre projet de domaine :
```
& gcloud services enable cloudscheduler.googleapis.com
```
Définissez AppEngineLocation sur un emplacement App Engine valide dans lequel déployer Cloud Scheduler :
```
$AppEngineLocation = "location"
```
Remplacez location par la région App Engine que vous avez sélectionnée pour vos ressources VPC, par exemple us-central. Si cette région n'est pas disponible en tant qu'emplacement App Engine, choisissez un emplacement géographique proche de vous. Pour en savoir plus, consultez la page Régions et zones.

Initialisez App Engine :

& gcloud app create --region $AppEngineLocation --project $DomainProjectId

Créez une tâche Cloud Scheduler :

& gcloud scheduler jobs create http cleanup-computer-accounts `
    --schedule "every 24 hours" `
    --uri "$RegisterUrl/cleanup" `
    --oidc-service-account-email register-computer-app@$DomainProjectId.iam.gserviceaccount.com `
    --oidc-token-audience "$RegisterUrl/" `
    --project $DomainProjectId

Cette tâche appelle l'application register-computer une fois toutes les 24 heures et utilise le compte de service register-computer-app pour l'authentification.

Déclencher un nettoyage

Pour vérifier votre configuration de nettoyage des comptes d'ordinateur obsolètes, vous pouvez déclencher manuellement la tâche Cloud Scheduler.

Dans Google Cloud Console, accédez à Cloud Scheduler.

Accéder à Cloud Scheduler
Cliquez sur Exécuter pour la tâche cleanup-computer-accounts que vous avez créée

Au bout de quelques secondes, la colonne Résultat affiche la mention Opération réussie qui indique que le nettoyage s'est correctement exécuté. Si la colonne de résultat n'est pas automatiquement mise à jour au bout de quelques secondes, cliquez sur le bouton Actualiser.

Pour obtenir plus de détails sur les comptes ayant fait l'objet du nettoyage, consultez les journaux de l'application register-computer.

Dans Google Cloud Console, accédez à Cloud Run.

Accédez à Cloud Run
Cliquez sur l'application register-computer.
Dans le menu, cliquez sur Journaux.

Les entrées de journaux indiquent que les comptes d'ordinateur associés aux instances de VM que vous avez utilisées pour tester la jonction au domaine ont été identifiés comme obsolètes et, en conséquence, supprimés.

Effectuer un nettoyage

Si vous utilisez ce document comme référence pour d'autres architectures et déploiements de référence, consultez les autres documents pour savoir quand exécuter les étapes de nettoyage.

Si vous ne souhaitez pas conserver la configuration Google Cloud utilisée dans ce document, vous pouvez annuler cette configuration en procédant comme suit:

Dans Cloud Shell, supprimez la tâche Cloud Scheduler :

& gcloud scheduler jobs delete cleanup-computer-accounts `
  --project $DomainProjectId

Supprimez l'application Cloud Run :

& gcloud run services delete register-computer `
  --platform managed `
  --project $DomainProjectId `
  --region $ServerlessRegion

Supprimez le secret Secret Manager :

gcloud secrets delete ad-password --project $DomainProjectId

Supprimez la règle de pare-feu autorisant l'accès LDAP et Kerberos :
```
gcloud compute firewall-rules delete allow-adkrb-from-serverless-to-dc --project=vpc-project-id
```
Remplacez vpc-project-id par l'ID du projet dans lequel le VPC est défini. Si vous utilisez un VPC partagé, utilisez le projet hôte du VPC. Sinon, utilisez l'identifiant du projet de domaine.

Annuler les modifications apportées à Active Directory

À l'aide d'un client RDP, connectez-vous à une machine disposant d'un accès administrateur à votre domaine Active Directory.
Dans le composant logiciel enfichable MMC "Utilisateurs et ordinateurs Active Directory", accédez à l'UO Projects.
Supprimez le compte utilisateur Active Directory register-computer.
Supprimez l'UO que vous avez créée pour tester la jonction automatisée au domaine.

Étapes suivantes

Pour associer des VM Windows à un domaine Microsoft AD géré à l'aide de l'association de domaine automatisée, consultez la section Associer automatiquement une VM Windows à un domaine.
Consultez nos bonnes pratiques pour le déploiement d'une forêt de ressources Active Directory dans Google Cloud.
Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Cloud Architecture Center.