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.
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é dansunattend.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
dansunattend.xml
, vous devez insérer ces identifiants en texte brut dansunattend.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 :
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'UOProjects
:# 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'UOProjects
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.
Afficher le chemin d'accès à l'UO
Projects
et le mot de passe généré pour le compte utilisateur Active Directoryregister-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'accès au VPC sans serveur afin de permettre à Cloud Functions d'accéder à Active Directory.
- 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 Google Cloud Console, ouvrez 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
Déployer l'accès au VPC sans serveur
L'application register-computer
doit pouvoir communiquer avec les contrôleurs de votre domaine Active Directory. Pour permettre à Cloud Run d'accéder aux ressources d'un VPC, vous devez maintenant configurer l'accès au VPC sans serveur :
Initialisez les variables suivantes :
$VpcName = "
vpc-name
" $ServerlessRegion = "serverless-region
" $ServerlessIpRange = "serverless-ip-range
"Remplacez les éléments suivants :
vpc-name
: le nom du réseau VPC qui héberge les contrôleurs de votre domaine Active Directory.serverless-region
: la région dans laquelle déployer Cloud Run. Choisissez une région compatible avec Cloud Run et l'accès au VPC sans serveur. La région ne doit pas nécessairement être celle dans laquelle vous prévoyez de déployer des instances de VM.serverless-ip-range
: la plage d'adresses IP utilisée par l'accès au VPC sans serveur pour autoriser la communication entre Cloud Run et les ressources de votre VPC. Elle doit être définie sur une plage d'adresses IP CIDR /28 non réservée, et ne chevaucher aucun des sous-réseaux existants de votre réseau VPC.
Activez les API d'accès au VPC sans serveur :
& gcloud services enable vpcaccess.googleapis.com
Déployez l'accès au VPC sans serveur :
& gcloud compute networks vpc-access connectors create serverless-connector ` --network $VpcName ` --region $ServerlessRegion ` --range $ServerlessIpRange
Accorder l'accès à Kerberos et LDAP
Bien que l'accès au VPC sans serveur permette à Cloud Run d'accéder aux ressources de votre VPC, la connectivité aux points de terminaison Kerberos et LDAP de vos contrôleurs de domaine reste soumise aux règles de pare-feu.
Vous devez créer une règle de pare-feu autorisant les ressources sans serveur à accéder à vos contrôleurs de domaine à travers les protocoles suivants : LDAP (TCP/389), LDAPS (TCP/636), Kerberos (UDP/88, TCP/88), ou changement de mot de passe Kerberos (UDP/464, TCP/464). 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.
Pour appliquer la règle de pare-feu, exécutez l'une des commandes suivantes dans Cloud Shell :
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 :
$AdDomain = "
dns-domain-name
" $AdNetbiosDomain = "netbios-domain-name
" $ProjectsOrgUnitPath = "projects-ou-distinguished-name
"Remplacez les éléments suivants :
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 UOProjects
.
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"
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:$DomainProjectNumber@cloudbuild.gserviceaccount.com" ` --role "roles/iam.serviceAccountUser" & gcloud projects add-iam-policy-binding $DomainProjectId ` --member "serviceAccount:$DomainProjectNumber@cloudbuild.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 | 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)
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ôleCompute 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 VMvpc-subnet-to-deploy-vm
: le sous-réseau dans lequel déployer l'instance de VMzone-to-deploy-vm
: la zone dans laquelle déployer l'instance de VMserverless-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'))
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 Value 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.
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 ces comptes caducs.
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 exempleus-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 serviceregister-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.
Cliquez sur Exécuter pour la tâche
cleanup-computer-accounts
que vous avez crééeAu 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.
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.Supprimez l'accès au VPC sans serveur :
gcloud compute networks vpc-access connectors delete serverless-connector --region $ServerlessRegion --quiet
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 Centre d'architecture cloud.