Configurare Active Directory per consentire alle VM di partecipare automaticamente a un dominio

Last reviewed 2024-10-31 UTC

Questo documento mostra come configurare Active Directory e Compute Engine in modo che le istanze di macchine virtuali (VM) Windows possano unirsi automaticamente a un dominio Active Directory.

L'automazione del processo di unione delle VM Windows ad Active Directory consente di semplificare il processo di provisioning dei server Windows. Questo approccio ti consente anche di sfruttare lo scaling automatico senza rinunciare ai vantaggi dell'utilizzo di Active Directory per gestire l'accesso e la configurazione.

Questo documento è rivolto agli amministratori di sistema e presuppone che tu abbia familiarità con Active Directory e il networking Google Cloud .

La configurazione che crei seguendo la procedura descritta in questo documento può essere la base di un lavoro aggiuntivo che svolgi con Windows Server in Google Cloud. Ad esempio, dopo aver completato questa procedura, puoi eseguire il deployment di applicazioni ASP.NET con autenticazione Windows nei container Windows.

Se utilizzi Managed Microsoft AD e non richiedi la pulizia automatica degli account computer obsoleti, valuta la possibilità di unire le VM Windows utilizzando la funzionalità di unione automatica al dominio. Per maggiori informazioni, vedi Aggiungi automaticamente una VM Windows a un dominio.

Obiettivi

• Esegui il deployment di un'app Cloud Run che consente alle istanze VM dei progetti selezionati di unirsi automaticamente al tuo dominio Active Directory.
• Crea un job Cloud Scheduler che esegua periodicamente la scansione del tuo dominio Active Directory alla ricerca di account computer obsoleti e li rimuova.
• Verifica la configurazione creando un gruppo di istanze gestite (MIG) con scalabilità automatica di istanze VM aggiunte al dominio.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

• Compute Engine
• Serverless VPC Access
• Cloud Run
• Artifact Registry
• Secret Manager
• Cloud Scheduler

Le istruzioni riportate in questo documento sono pensate per mantenere l'utilizzo delle risorse entro i limiti del livello Always Free di Google Cloud. Per generare una stima dei costi in base all'utilizzo previsto, utilizza il calcolatore prezzi.

I nuovi utenti di Google Cloud potrebbero avere diritto a una prova gratuita.

Al termine di questo documento, puoi evitare l'addebito di ulteriori costi eliminando le risorse create. Per ulteriori informazioni, vedi Pulizia.

Prima di iniziare

Questo documento presuppone che tu abbia già eseguito il deployment di Active Directory su Google Cloud utilizzando Managed Service for Microsoft Active Directory (Managed Microsoft AD) o eseguendo il deployment di domain controller autogestiti su Google Cloud.

Per completare le procedure, assicurati di disporre di quanto segue:

• Accesso amministrativo al tuo dominio Active Directory, inclusa la possibilità di creare utenti, gruppi e unità organizzative (UO).
• Un intervallo IP CIDR /28 inutilizzato nel VPC in cui sono implementati i domain controller Active Directory. Utilizzi questo intervallo IP per configurare l'accesso VPC serverless.
• Una subnet in cui eseguire il deployment delle istanze Windows. La subnet deve essere configurata per utilizzare l'accesso privato Google.

Nota: l'accesso privato Google è necessario per consentire a tutte le istanze VM nella subnet di accedere a Cloud Run. Se non abiliti l'accesso privato Google, solo le istanze VM con accesso a internet potranno unirsi automaticamente al tuo dominio Active Directory.

Se utilizzi un controller di dominio autogestito, ti serve anche quanto segue:

• Una zona di forwarding DNS privato che inoltra le query DNS ai tuoi domain controller Active Directory.

L'implementazione di questo approccio

In un ambiente on-premise, potresti fare affidamento sui file di risposte (unattend.xml) e sulla personalizzazione JoinDomain per unire automaticamente nuovi computer a un dominio. Anche se puoi utilizzare lo stesso processo in Google Cloud, questo approccio presenta diverse limitazioni:

• L'utilizzo di un file unattend.xml personalizzato richiede la gestione di un'immagine Compute Engine personalizzata. Per mantenere aggiornata un'immagine personalizzata utilizzando Windows Update, è necessario eseguire una manutenzione continua o un lavoro iniziale per configurare l'automazione. A meno che tu non debba mantenere un'immagine personalizzata per altri motivi, questo sforzo aggiuntivo potrebbe non essere giustificato.
• L'utilizzo della personalizzazione JoinDomain associa un'immagine a un singolo dominio Active Directory perché il nome di dominio deve essere specificato in unattend.xml. Se gestisci più domini o foreste Active Directory (ad esempio, per ambienti di test e produzione separati), potresti dover gestire più immagini personalizzate per ogni dominio.
• Per unire un computer Windows a un dominio sono necessarie credenziali utente con autorizzazioni per creare un oggetto computer nella directory. Se utilizzi la personalizzazione JoinDomain in unattend.xml, devi incorporare queste credenziali come testo normale in unattend.xml. Queste credenziali incorporate possono trasformare l'immagine in un potenziale bersaglio per gli autori di attacchi. Sebbene tu possa controllare l'accesso all'immagine impostando le autorizzazioni IAM (Identity and Access Management) appropriate, la gestione dell'accesso a un'immagine personalizzata aggiunge una complessità non necessaria.

L'approccio descritto in questo documento non utilizza file di risposte e pertanto non richiede immagini preparate appositamente. Utilizza invece il seguente scriptlet di specializzazione sysprep quando crei un'istanza VM:

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

Questo scriptlet di specializzazione di sysprep avvia un processo illustrato nel seguente diagramma.

La procedura funziona nel seguente modo:

1. Dopo aver creato un'istanza VM, Windows viene avviato per la prima volta. Nell'ambito del passaggio di configurazione di specializzazione, Windows esegue lo scriptlet di specializzazione di sysprep. Lo scriptlet specializzato richiama l'app Cloud Run register-computer e scarica uno script PowerShell che controlla il processo di unione al dominio.
2. Windows richiama lo script PowerShell scaricato.
3. Lo script PowerShell chiama il server di metadati per ottenere un token ID che identifica in modo sicuro l'istanza VM.
4. Lo script chiama di nuovo l'app register-computer, passando il token ID per autenticarsi.
5. L'app convalida il token ID ed estrae il nome, la zona e l'ID progettoGoogle Cloud dell'istanza VM.
6. L'app verifica che il dominio Active Directory sia configurato per consentire alle istanze VM del progetto specificato di unirsi al dominio. Per completare questa verifica, l'app individua e si connette a un controller di dominio Active Directory per verificare la presenza di un'unità organizzativa (UO) il cui nome corrisponda all'ID progetto Google Cloud del token ID. Se viene trovata un'UO corrispondente, le istanze VM del progetto sono autorizzate a unirsi al dominio Active Directory nell'UO specificata.
7. L'app verifica che il progetto Google Cloud sia configurato per consentire alle istanze VM di unirsi ad Active Directory. Per completare questa verifica, l'app controlla se può accedere all'istanza VM utilizzando l'API Compute Engine.
8. Se tutti i controlli vengono superati, l'app preconfigura un account computer in Active Directory. L'app salva il nome, la zona e l'ID dell'istanza VM come attributi nell'oggetto account computer in modo che possa essere associato all'istanza VM.
9. Utilizzando il protocollo di impostazione della password Kerberos, l'app assegna quindi una password casuale all'account computer.
10. Il nome e la password del computer vengono restituiti all'istanza Windows tramite un canale protetto da TLS.
11. Utilizzando l'account del computer preconfigurato, lo script di PowerShell unisce il computer al dominio.
12. Al termine del passaggio di configurazione specializzata, la macchina si riavvia.

Il resto della procedura ti guida attraverso i passaggi necessari per configurare l'aggiunta automatica al dominio.

Preparazione del dominio Active Directory

Innanzitutto, prepara il dominio Active Directory. Per completare questo passaggio, devi disporre di una macchina con accesso amministrativo al tuo dominio Active Directory.

(Facoltativo) Limita chi può unire computer al dominio

Potresti voler limitare chi può unire computer al dominio. Per impostazione predefinita, la configurazione dell'oggetto Criteri di gruppo (GPO) per i criteri del controller di dominio predefinito concede il diritto utente Add workstations to domain a tutti gli utenti autenticati. Chiunque disponga di questo diritto utente può unire computer al dominio. Poiché stai automatizzando il processo di unione dei computer al tuo dominio Active Directory, concedere universalmente questo livello di accesso è un rischio per la sicurezza non necessario.

Nota :se utilizzi Microsoft AD gestito, per impostazione predefinita solo i membri del gruppo Cloud Service Domain Join Accounts possono unire i computer al tuo dominio.

Per limitare chi può unire computer al tuo dominio Active Directory, modifica la configurazione predefinita dell'oggetto Criteri di gruppo dei criteri del domain controller predefinito:

1. Utilizzando un client RDP, accedi a una macchina con accesso amministrativo al tuo dominio Active Directory.
2. Apri la Console Gestione Criteri di gruppo (GPMC).
3. Vai a Foresta > Domini > domain-name > Oggetti Criteri di gruppo, dove domain-name è il nome del tuo dominio Active Directory.
4. Fai clic con il tasto destro del mouse su Default Domain Controller Policy (Criteri predefiniti del controller di dominio) e poi su Modifica.
5. Nella console Editor Gestione Criteri di gruppo, vai a Configurazione computer > Criteri > Impostazioni di Windows > Impostazioni di sicurezza > Criteri locali > Assegnazione diritti utente.
6. Fai doppio clic su Aggiungi workstation al dominio.
7. In Proprietà, rimuovi Utenti autenticati dall'elenco.
8. Per consentire agli amministratori di partecipare manualmente al dominio (facoltativo), fai clic su Aggiungi utente o gruppo e poi aggiungi un gruppo amministrativo all'elenco.
9. Fai clic su OK.

Ora puoi chiudere la console Editor Gestione Criteri di gruppo e GPMC.

Inizializzare una struttura di directory

Ora crea un'UO che funge da contenitore per tutte le UO specifiche del progetto:

1. Utilizzando un client RDP, accedi a una macchina con accesso amministrativo al tuo dominio Active Directory.
2. Apri una sessione di PowerShell con privilegi elevati.

3. Crea una nuova unità organizzativa:

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

   Nota: modifica il valore di $ParentOrgUnitPath per creare l'UO in una posizione diversa dal container predefinito.

Crea un account utente Active Directory

Per accedere ad Active Directory e preconfigurare gli account computer, l'app register-computer ha bisogno di un account utente Active Directory:

1. Crea un account utente Active Directory denominato register-computer, assegnagli una password casuale e poi inseriscilo nell'unità organizzativa 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
   

2. Concedi all'account register-computer il set minimo di autorizzazioni necessarie per gestire account computer e gruppi nella UO Projects e nelle UO secondarie:

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

   Il completamento del comando potrebbe richiedere alcuni minuti.

3. Concedi l'autorizzazione all'account register-computer per eliminare i record DNS:

   Microsoft Active Directory gestito

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

   Dominio autogestito

   $DnsPartition=(Get-ADDomain).SubordinateReferences | Where-Object {$_.StartsWith('DC=DomainDnsZones')}
   $DnsContainer="DC=$((Get-ADDomain).DNSRoot),CN=MicrosoftDNS,$DnsPartition"
   
   dsacls $DnsContainer /G "${RegisterComputerUser}:SD" /I:S
   

4. Visualizza il percorso dell'unità organizzativa Projects e la password generata dell'account utente Active Directory register-computer. Prendi nota dei valori perché ti serviranno in seguito.

   Write-Host "Password: $Password"
   Write-Host "Projects OU: $ProjectsOrgUnitPath"
   

Preparazione del progetto Google Cloud

Ora configura il progetto del dominio:

• Se utilizzi Microsoft Active Directory gestito, il progetto di dominio è il progetto in cui hai eseguito il deployment di Microsoft Active Directory gestito.
• Se utilizzi Active Directory autogestito, il progetto di dominio è il progetto che esegue i domain controller Active Directory. Nel caso di un VPC condiviso, questo progetto deve essere lo stesso del progetto host VPC.

Utilizza questo progetto di dominio per:

• Crea un secret di Secret Manager che contenga la password dell'account utente Active Directory register-computer.
• Esegui il deployment dell'app register-computer.
• Configura Cloud Scheduler in modo che attivi le pulizie degli account computer obsoleti.

Ti consigliamo di concedere l'accesso al progetto di dominio in base al principio del privilegio minimo.

Crea un secret Secret Manager

1. Nella console Google Cloud , apri Cloud Shell.

   Apri Cloud Shell

2. Avvia PowerShell:

   pwsh
   

3. Inizializza la seguente variabile sostituendo domain-project-id con l'ID del progetto del tuo dominio:

   $DomainProjectId = "domain-project-id"
   

4. Imposta il progetto del dominio come progetto predefinito:

   & gcloud config set project $DomainProjectId
   

5. Abilita l'API Secret Manager:

   & gcloud services enable secretmanager.googleapis.com
   

6. Inserisci la password dell'account utente Active Directory register-computer e archiviala in un secret di 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
   

Concedere l'accesso a Kerberos e LDAP

Per gestire le unioni di domini, l'app register-computer accede ai controller di dominio utilizzando i seguenti protocolli:

• LDAP (TCP/389) o LDAPS (TCP/636)
• Kerberos (UDP/88, TCP/88)

• Modifica della password Kerberos (UDP/464, TCP/464)

Microsoft Active Directory gestito

Non è necessario configurare regole firewall.

Dominio autogestito

Crea una regola firewall che consenta l'accesso ai controller di dominio.

Puoi applicare la regola in base a un tag di rete che hai assegnato ai tuoi controller di dominio oppure puoi applicarla utilizzando un account di servizio.

Per tag di rete

& 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

Sostituisci quanto segue:

• dc-tag: il tag di rete assegnato alle VM del controller di dominio.
• vpc-project-id: l'ID del progetto in cui è definita la rete VPC. Se utilizzi un VPC condiviso, utilizza il progetto host VPC; altrimenti, utilizza l'ID del progetto di dominio.

Per account di servizio

& 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

Sostituisci quanto segue:

• dc-sa: l'indirizzo email del service account utilizzato dalle VM del controller di dominio.
• vpc-project-id: l'ID del progetto in cui è definita la rete VPC. Se utilizzi un VPC condiviso, utilizza il progetto host VPC; altrimenti, utilizza l'ID del progetto di dominio.

Esegui il deployment dell'app Cloud Run

Ora configuri Cloud Build per eseguire il deployment dell'app register-computer in Cloud Run:

1. In Cloud Shell, clona il repository GitHub:

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

2. Inizializza le seguenti variabili:

   $ServerlessRegion = "serverless-region"
   $VpcName = "vpc-name"
   $VpcSubnet = "subnet-name"
   $AdDomain = "dns-domain-name"
   $AdNetbiosDomain = "netbios-domain-name"
   $ProjectsOrgUnitPath = "projects-ou-distinguished-name"
   

   Sostituisci quanto segue:

   • serverless-region: la regione in cui eseguire il deployment dell'app register-computer. La regione non deve necessariamente corrispondere a quella in cui prevedi di deployare le istanze VM.
   • vpc-name: il nome della rete VPC che contiene i controller di dominio Active Directory.
   • subnet-name: la subnet di vpc-name da utilizzare per l'accesso VPC diretto. La subnet deve trovarsi nella stessa regione di serverless-region.
   • dns-domain-name: il nome di dominio DNS del tuo dominio Active Directory.
   • netbios-domain-name: il nome NetBIOS del tuo dominio Active Directory.
   • projects-ou-distinguished-name: il nome distinto della tua unità organizzativa Projects.

3. Abilita le API Cloud Run e Cloud Build:

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

4. Crea un account di servizio register-computer-app per l'app Cloud Run:

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

5. Crea un account di servizio build-service per l'esecuzione dei trigger Cloud Build:

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

6. Consenti al account di servizio Cloud Run di leggere il secret che contiene la password di Active Directory:

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

7. Concedi a Cloud Build le autorizzazioni necessarie per eseguire il deployment in 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
   

8. Utilizza il file cloudbuild.yaml come modello per creare una configurazione di build di Cloud Run personalizzata che corrisponda al tuo ambiente:

   $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
   

   Nota: l'app fornisce impostazioni configurabili aggiuntive, ad esempio l'utilizzo di LDAPS anziché LDAP. Per ulteriori informazioni, consulta il file README.md dell'app. Per applicare configurazioni aggiuntive, modifica il file cloudbuild.yaml e aggiungi le variabili di ambiente richieste agli argomenti del passaggio cloud-sdk.

9. Crea l'app ed eseguine il deployment in 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
   

   Il completamento del deployment può richiedere un paio di minuti.

   Nota: se conservi il file cloudbuild.hydrated.yaml, puoi eseguire di nuovo il deployment dell'app eseguendo nuovamente il comando precedente.

10. Determina l'URL dell'app Cloud Run:

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

    Prendi nota dell'URL. Ti servirà ogni volta che crei un'istanza VM che deve essere unita ad Active Directory.

11. Richiama l'app Cloud Run per verificare che il deployment sia andato a buon fine:

    Invoke-RestMethod $RegisterUrl
    

    Viene visualizzato uno script PowerShell. La VM esegue questo script durante la fase di specializzazione che la unisce al dominio.

Abilitazione di un progetto per l'aggiunta automatica di domini

L'app register-computer non consente alle istanze VM di unirsi a un dominio Active Directory, a meno che il progetto della VM non sia abilitato per l'unione automatica al dominio. Questa misura di sicurezza impedisce alle VM connesse a progetti non autorizzati di accedere al tuo dominio.

Nota :se hai eseguito il deployment di Active Directory in un VPC condiviso, ti consigliamo di creare un progetto a scopo di test e collegare il progetto al VPC condiviso.

Il deployment dell'accesso VPC serverless crea una subnet nel tuo VPC. Non è necessario condividere questa subnet quando colleghi i progetti di servizio al progetto host VPC.

Per attivare un progetto per l'aggiunta automatica al dominio, devi:

• Crea un'UO in Active Directory il cui nome corrisponda all'ID progettoGoogle Cloud .
• Concedi all'app register-computer l'accesso al progetto Google Cloud .

Innanzitutto, crea l'unità organizzativa:

1. Utilizzando un client RDP, accedi a una macchina con accesso amministrativo al tuo dominio Active Directory.
2. Nello snap-in MMC Utenti e computer di Active Directory, vai all'unità organizzativa Projects.
3. Fai clic con il tasto destro del mouse sull'unità organizzativa e seleziona Nuovo > Unità organizzativa.
4. Nella finestra di dialogo Nuovo oggetto, inserisci l'ID del progettoGoogle Cloud in cui eseguire il deployment delle VM.
5. Fai clic su OK.

Successivamente, concedi all'app register-computer l'accesso al progettoGoogle Cloud :

1. In Cloud Shell, avvia PowerShell:

   pwsh
   

2. Inizializza le seguenti variabili:

   $ProjectId = "project-id"
   $DomainProjectId = "domain-project-id"
   

   Sostituisci

   • project-id con l'ID del progetto Google Cloud in cui eseguire il deployment delle VM
   • domain-project-id con l'ID del tuo progetto di dominio

3. Concedi al account di servizio register-computer-app il ruolo Compute Viewer sul progetto:

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

Il progetto è ora pronto per supportare l'aggiunta automatica al dominio.

Test dell'aggiunta al dominio

Ora puoi verificare che la configurazione funzioni correttamente:

• Creazione di una singola istanza VM che si unisce automaticamente al dominio Active Directory
• Creazione di un gruppo di istanze gestite di istanze VM che si uniscono automaticamente al dominio Active Directory

Creare e unire una singola istanza VM

Crea un'istanza VM che si unisca automaticamente al dominio Active Directory:

1. Torna alla sessione PowerShell in Cloud Shell e inizializza le seguenti variabili:

   $Region = "vpc-region-to-deploy-vm"
   $Zone = "zone-to-deploy-vm"
   $Subnet = "vpc-subnet-to-deploy-vm"
   $ServerlessRegion = "serverless-region"
   

   Sostituisci quanto segue:

   • vpc-region-to-deploy-vm: la regione in cui eseguire il deployment dell'istanza VM.
   • vpc-subnet-to-deploy-vm: la subnet in cui eseguire il deployment dell'istanza VM.
   • zone-to-deploy-vm: la zona in cui eseguire il deployment dell'istanza VM.
   • serverless-region: la regione in cui hai eseguito il deployment dell'app Cloud Run.

2. Imposta il progetto e la zona predefiniti:

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

3. Cerca di nuovo l'URL dell'app Cloud Run:

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

4. Crea un'istanza passando lo scriptlet di specializzazione che fa in modo che la VM entri a far parte del dominio:

   VPC condiviso

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

   & 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'))"
   

   Se vuoi utilizzare un nome host personalizzato, aggiungi un parametro --hostname al comando.

   Se utilizzi una versione di Windows Server precedente a Windows Server 2019, TLS 1.2 potrebbe essere disabilitato per impostazione predefinita, il che può causare l'errore dello scriptlet specializzato. Per attivare TLS 1.2, utilizza il seguente scriptlet:

   [Net.ServicePointManager]::SecurityProtocol=[Net.SecurityProtocolType]::Tls12;iex((New-Object System.Net.WebClient).DownloadString('$RegisterUrl'))
   

   Nota: NetBIOS supporta solo nomi di computer di massimo 15 caratteri. Se il nome host di un'istanza VM supera questa lunghezza massima, lo scriptlet di specializzazione modifica automaticamente il nome del computer in un nome univoco e con meno di 15 caratteri.
   
   Quando crei altre istanze VM, assicurati di rispettare questo limite di caratteri per il nome dell'istanza, altrimenti l'unione di un'istanza VM al tuo dominio potrebbe non riuscire.

5. Monitora la procedura di avvio:

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

   Dopo circa un minuto, la macchina viene aggiunta al dominio Active Directory. L'output è simile al seguente:

   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
   

   Per interrompere l'osservazione della procedura di avvio, premi CTRL+C.

Verifica che la VM sia unita ad Active Directory

1. Utilizzando un client RDP, accedi a una macchina con accesso amministrativo al tuo dominio Active Directory.
2. Apri lo snap-in MMC Utenti e computer di Active Directory.
3. Nel menu, assicurati che Visualizza > Funzionalità avanzate sia attivato.
4. Vai all'unità organizzativa denominata in base all'ID progetto Google Cloud in cui hai creato un'istanza VM.
5. Fai doppio clic sull'account join-01.

6. Nella finestra di dialogo Proprietà, fai clic sulla scheda Editor attributi.

   L'account computer è annotato con attributi LDAP aggiuntivi. Questi attributi ti consentono di monitorare l'associazione tra l'oggetto computer e l'istanza Compute Engine.

   Verifica che l'elenco contenga i seguenti attributi e valori LDAP.

   Attributo LDAP	Valore
   msDS-cloudExtensionAttribute1	Google Cloud ID progetto
   msDS-cloudExtensionAttribute2	Zona Compute Engine
   msDS-cloudExtensionAttribute3	Nome dell'istanza Compute Engine

   Gli attributi msDS-cloudExtensionAttribute sono attributi generici e non vengono utilizzati da Active Directory.

Diagnostica degli errori

Se l'istanza VM non è riuscita a unirsi al dominio, controlla il log dell'app register-computer:

1. Nella console Google Cloud , vai a Cloud Run.

   Vai a Cloud Run

2. Fai clic sull'app register-computer.

3. Nel menu, fai clic su Log.

Elimina l'istanza

Dopo aver verificato che l'istanza VM sia unita al dominio Active Directory, elimina l'istanza.

• Elimina l'istanza:

  & gcloud compute instances delete join-01 --quiet
  

Crea e unisciti a un gruppo di istanze gestite

Puoi anche verificare che le istanze di un MIG possano unirsi automaticamente al tuo dominio.

1. Crea un modello di istanza passando lo script di specializzazione che fa in modo che la VM entri a far parte del dominio:

   VPC condiviso

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

   & 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'))"
   

2. Crea un gruppo di istanze gestite che utilizza il modello di istanza:

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

Attendi qualche minuto, quindi utilizza lo snap-in MMC Utenti e computer di Active Directory per verificare che siano stati creati quattro nuovi oggetti in Active Directory:

• 3 account computer corrispondenti alle 3 istanze VM del gruppo di istanze gestite.
• Un gruppo denominato group-01 che contiene i tre account computer. Se prevedi di utilizzare service account gestiti dal gruppo (gMSA), puoi utilizzare questo gruppo per concedere l'accesso al gMSA.

Nota: NetBIOS supporta solo nomi di computer di massimo 15 caratteri. Se il nome host di un'istanza VM supera questa lunghezza massima, lo scriptlet di specializzazione modifica automaticamente il nome del computer in un nome univoco e con meno di 15 caratteri. Assicurati di utilizzare nomi brevi per i gruppi di istanze gestite in modo che i nomi delle istanze VM non superino i 15 caratteri.

Dopo aver verificato che le istanze VM dei tuoi MIG possono accedere al tuo dominio Active Directory, puoi eliminare il gruppo gestito e il modello di istanza seguendo questi passaggi:

1. In Cloud Shell, elimina il gruppo di istanze:

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

2. Elimina il template di istanza:

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

Pianificazione della pulizia degli account computer obsoleti

L'automazione del processo di aggiunta di computer al dominio riduce lo sforzo necessario per configurare nuovi server e consente di utilizzare i server aggiunti al dominio nei gruppi di istanze gestite. Tuttavia, nel tempo, gli account computer obsoleti possono accumularsi nel dominio.

Per evitare questo accumulo, ti consigliamo di configurare l'app register-computer per eseguire periodicamente la scansione del tuo dominio Active Directory per trovare e rimuovere automaticamente gli account obsoleti e i relativi record DNS.

L'app register-computer può utilizzare gli attributi msDS-cloudExtensionAttribute degli account computer per identificare quali account computer sono obsoleti. Questi attributi contengono il progetto, la zona e il nome dell'istanza VM corrispondente in Compute Engine. Per ogni account computer, l'app può verificare se l'istanza VM corrispondente è ancora disponibile. In caso contrario, l'account computer viene considerato obsoleto e rimosso.

Per attivare la pulizia di un account computer, invoca l'endpoint /cleanup dell'app Cloud Run. Per impedire a utenti non autorizzati di attivare una pulizia, questa richiesta deve essere autenticata utilizzando il account di servizio register-computer-app.

Configura Cloud Scheduler

I seguenti passaggi mostrano come configurare Cloud Scheduler in combinazione con Pub/Sub per attivare automaticamente una pulizia ogni 24 ore:

1. In Cloud Shell, abilita l'API Cloud Scheduler nel progetto del tuo dominio:

   & gcloud services enable cloudscheduler.googleapis.com
   

2. Imposta AppEngineLocation su una posizione App Engine valida in cui eseguire il deployment di Cloud Scheduler:

   $AppEngineLocation = "location"
   

   Sostituisci location con la regione App Engine che hai selezionato per le tue risorse VPC, ad esempio us-central. Se questa regione non è disponibile come località di App Engine, scegli una località geograficamente vicina a te. Per saperne di più, consulta Regioni e zone.

3. Inizializza App Engine:

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

4. Crea un job 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
   

   Questo job chiama l'app register-computer una volta ogni 24 ore e utilizza l'account di servizio register-computer-app per l'autenticazione.

Attivare una pulizia

Per verificare la configurazione per la pulizia degli account computer obsoleti, puoi attivare manualmente il job Cloud Scheduler.

1. Nella console Google Cloud , vai a Cloud Scheduler.

   Vai a Cloud Scheduler

2. Per il job cleanup-computer-accounts che hai creato, fai clic su Esegui ora.

   Dopo alcuni secondi, la colonna Risultato mostra Successo, a indicare che la pulizia è stata completata correttamente. Se la colonna dei risultati non si aggiorna automaticamente entro pochi secondi, fai clic sul pulsante Aggiorna.

Per maggiori dettagli sugli account puliti, controlla i log dell'app register-computer.

1. Nella console Google Cloud , vai a Cloud Run.

   Vai a Cloud Run

2. Fai clic sull'app register-computer.

3. Nel menu, fai clic su Log.

   Le voci di log indicano che gli account computer delle istanze VM che hai utilizzato per testare l'unione al dominio sono stati identificati come obsoleti e rimossi.

Esegui la pulizia

Se utilizzi questo documento come base per altre architetture di riferimento e deployment, leggi gli altri documenti su quando eseguire i passaggi di pulizia.

Se non vuoi mantenere la Google Cloud configurazione utilizzata in questo documento, puoi ripristinarla nel seguente modo:

1. In Cloud Shell, elimina il job Cloud Scheduler:

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

2. Elimina l'app Cloud Run:

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

3. Elimina il secret di Secret Manager:

   gcloud secrets delete ad-password --project $DomainProjectId
   

4. Elimina la regola firewall per l'accesso LDAP e Kerberos:

   gcloud compute firewall-rules delete allow-adkrb-from-serverless-to-dc --project=vpc-project-id
   

   Sostituisci vpc-project-id con l'ID del progetto in cui è definita la rete VPC. Se utilizzi un VPC condiviso, utilizza il progetto host VPC; altrimenti, utilizza l'ID del progetto di dominio.

Ripristina modifiche di Active Directory

1. Utilizzando un client RDP, accedi a una macchina con accesso amministrativo al tuo dominio Active Directory.
2. Nello snap-in MMC Utenti e computer di Active Directory, vai all'unità organizzativa Projects.
3. Elimina l'account utente di Active Directory register-computer.
4. Elimina l'unità organizzativa che hai creato per testare l'aggiunta automatica al dominio.

Passaggi successivi

• Per aggiungere le VM Windows a un dominio Managed Microsoft AD utilizzando l'aggiunta automatica al dominio, consulta Aggiungere automaticamente una VM Windows a un dominio.
• Consulta le nostre best practice per il deployment di una foresta di risorse Active Directory su Google Cloud.
• Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.