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

Last reviewed 2024-10-31 UTC

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

L'automazione del processo di adesione delle VM Windows ad Active Directory consente di semplificare il processo di provisioning dei server Windows. Questo approccio ti consente inoltre di usufruire dell'autoscaling senza sacrificare i 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 di Google Cloud.

La configurazione creata seguendo la procedura descritta in questo documento può essere la base di ulteriori attività che esegui con i server Windows in Google Cloud. Ad esempio, dopo aver completato questa procedura, puoi eseguire il deployment di applicazioni ASP.NET con autenticazione di Windows nei container Windows.

Se utilizzi Microsoft AD gestito e non hai bisogno del pulizia automatica degli account computer inattivi, valuta la possibilità di unire le VM Windows utilizzando la funzionalità di unione al dominio automatica. Per maggiori informazioni, consulta Associare automaticamente una VM Windows a un dominio.

Obiettivi

• Esegui il deployment di un'app Cloud Run che consenta alle istanze VM di progetti selezionati di partecipare automaticamente al tuo dominio Active Directory.
• Crea un job Cloud Scheduler che esamini periodicamente il tuo dominio Active Directory alla ricerca di account computer inutilizzati e li rimuovi.
• Testa la configurazione creando un gruppo di istanze gestite (MIG) con scalabilità automatica di istanze VM aggiunte al dominio.

Costi

In questo documento utilizzi 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 progettate per mantenere l'utilizzo delle risorse entro i limiti del livello Sempre gratis 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 essere idonei per una prova gratuita.

Al termine di questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, vedi Pulizia.

Prima di iniziare

Questo documento presuppone che tu abbia già implementato Active Directory su Google Cloud utilizzando Managed Service for Microsoft Active Directory (Managed Microsoft AD) o implementando controller di dominio 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 (OU).
• Un intervallo IP CIDR /28 inutilizzato nella VPC in cui sono dipiazzati i domain controller Active Directory. Utilizza questo intervallo IP per configurare Accesso VPC serverless.
• Una subnet in cui esegui il deployment di istanze Windows. La subnet deve essere configurata per l'utilizzo di Accesso privato Google.

Nota: l'accesso privato Google è necessario affinché tutte le istanze VM nella subnet possano accedere a Cloud Run. Se non attivi l'accesso privato Google, soltanto le istanze VM con accesso a internet potranno partecipare automaticamente al tuo dominio Active Directory.

Se utilizzi un controller di dominio autogestito, devi disporre anche di quanto segue:

• Una zona di inoltro DNS privata che inoltra le query DNS ai tuoi controller di dominio Active Directory.

Implementazione di questo approccio

In un ambiente on-premise, puoi utilizzare i file di risposta (unattend.xml) e la personalizzazione JoinDomain per aggiungere automaticamente nuovi computer a un dominio. Sebbene sia possibile utilizzare la stessa procedura in Google Cloud, questo approccio presenta diversi limiti:

• L'utilizzo di un file unattend.xml personalizzato richiede la gestione di un'immagine Compute Engine personalizzata. Mantenere aggiornata un'immagine personalizzata utilizzando Windows Update richiede manutenzione continua o un lavoro iniziale per configurare l'automazione. A meno che non debba mantenere un'immagine personalizzata per altri motivi, questo impegno aggiuntivo potrebbe non essere giustificato.
• L'utilizzo della personalizzazione JoinDomain lega un'immagine a un singolo dominio Active Directory perché il nome di dominio deve essere specificato in unattend.xml. Se gestisci più foreste o domini Active Directory (ad esempio per ambienti di test e di produzione separati), potresti dover gestire più immagini personalizzate per ogni dominio.
• L'unione di un computer Windows a un dominio richiede 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 non cifrato in unattend.xml. Queste credenziali incorporate possono trasformare l'immagine in un potenziale bersaglio per gli attaccanti. Sebbene tu possa controllare l'accesso all'immagine impostando le autorizzazioni Identity and Access Management (IAM) appropriate, la gestione dell'accesso a un'immagine personalizzata aggiunge complessità non necessaria.

L'approccio descritto in questo documento non utilizza file di risposta e quindi non richiede immagini preparate appositamente. Quando crei un'istanza VM, utilizza invece il seguente scriptlet sysprep specialize:

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

Questo scriptlet di specializzazione di Sysprep avvia una procedura illustrata nel seguente diagramma.

La procedura funziona nel seguente modo:

1. Dopo aver creato un'istanza VM, Windows si avvia per la prima volta. Nell'ambito del passaggio di configurazione di specializzazione, Windows esegue lo scriptlet sysprep specialize. Lo scriptlet di specializzazione invoca l'app register-computer Cloud Run e scarica uno script PowerShell che controlla la procedura di adesione al dominio.
2. Windows richiama lo script PowerShell scaricato.
3. Lo script PowerShell chiama il server metadati per ottenere un token di identità che identifica in modo sicuro l'istanza VM.
4. Lo script richiama 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 progetto Google Cloud dell'istanza VM.
6. L'app verifica che il dominio Active Directory sia configurato per consentire alle istanze VM del progetto specificato di partecipare 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 (OU) il cui nome corrisponde all'ID progetto Google Cloud del token ID. Se viene trovata un'OU corrispondente, le istanze VM del progetto sono autorizzate ad accedere al dominio Active Directory nell'OU specificata.
7. L'app verifica che il progetto Google Cloud sia configurato per consentire alle istanze VM di partecipare 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 esegue la pre-esecuzione di 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 associata all'istanza VM.
9. Utilizzando il protocollo Kerberos per l'impostazione della password, l'app assegna una password casuale all'account del computer.
10. Il nome e la password del computer vengono restituiti all'istanza Windows tramite un canale protetto da TLS.
11. Utilizzando l'account computer preconfigurato, lo script di PowerShell connette il computer al dominio.
12. Al termine del passaggio di configurazione della specializzazione, la macchina si riavvia.

Il resto di questa procedura illustra i passaggi necessari per configurare l'unione automatica dei domini.

Preparazione del dominio Active Directory

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

(Facoltativo) Limita gli utenti che possono collegare computer al dominio

Potresti voler limitare gli utenti che possono aggiungere computer al dominio. Per impostazione predefinita, la configurazione dell'oggetto Criteri di gruppo (GPO) per il criterio 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ò aggiungere computer al dominio. Poiché stai automatizzando la procedura di associazione dei computer al tuo dominio Active Directory, la concessione universale di questo livello di accesso rappresenta un rischio per la sicurezza non necessario.

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

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

1. Utilizzando un client RDP, accedi a un computer 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 Criteri del controller di dominio predefiniti e poi su Modifica.
5. Nella console dell'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 stazioni di lavoro al dominio.
7. In Proprietà, rimuovi Utenti autenticati dall'elenco.
8. (Facoltativo) Per consentire agli amministratori di partecipare al dominio manualmente, 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 di 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 un computer con accesso amministrativo al tuo dominio Active Directory.
2. Apri una sessione 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 contenitore predefinito.

Creare un account utente Active Directory

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

1. Crea un account utente Active Directory denominato register-computer, assegnagli una password random e inseriscilo nell'OU 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 l'insieme minimo di autorizzazioni necessarie per gestire gli account e i gruppi di computer nell'OU Projects e nelle OU 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 all'account register-computer l'autorizzazione 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. Mostra il percorso della OU Projects e la password generata dell'account utente Active Directory register-computer. Prendi nota dei valori, perché ti serviranno più avanti.

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

Preparazione del progetto Google Cloud

Ora configura il progetto del tuo dominio:

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

Utilizza questo progetto di dominio per:

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

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

Creare un secret di 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 tuo progetto di dominio:

   $DomainProjectId = "domain-project-id"
   

4. Imposta il progetto di 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 register-computer Active Directory e memorizzala 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
   

Concedi l'accesso a Kerberos e LDAP

Per gestire gli accoppiamenti 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 controller di dominio oppure 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 è definito il VPC. Se utilizzi una rete VPC condivisa, utilizza il progetto host VPC; in caso contrario, 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 dell'account servizio utilizzato dalle VM del controller di dominio.
• vpc-project-id: l'ID del progetto in cui è definito il VPC. Se utilizzi una rete VPC condivisa, utilizza il progetto host VPC; in caso contrario, utilizza l'ID del progetto di dominio.

Esegui il deployment dell'app Cloud Run

Ora configura 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 eseguire il deployment delle 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 diretto alla VPC. 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 dell'OU 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 degli trigger Cloud Build:

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

6. Consenti all'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 compilazione Cloud Run personalizzata adatta 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 mantieni il file cloudbuild.hydrated.yaml, puoi eseguire di nuovo il deployment dell'app in un secondo momento 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 abbia funzionato:

    Invoke-RestMethod $RegisterUrl
    

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

Attivare un progetto per l'unione automatica al dominio

L'app register-computer non consente alle istanze VM di far parte di un dominio Active Directory, a meno che per il progetto della VM non sia abilitato il join automatico al dominio. Questa misura di sicurezza contribuisce a impedire alle VM collegate 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 di collegarlo al VPC condiviso.

Il deployment di Accesso VPC serverless crea una subnet nella VPC. Non è necessario condividere questa subnet quando colleghi i progetti di servizio al progetto host VPC.

Per attivare un progetto per l'unione automatica dei domini, devi eseguire i seguenti passaggi:

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

Innanzitutto, crea l'OU:

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

Poi, concedi all'app register-computer l'accesso al progetto Google 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 progetto del tuo dominio

3. Concedi all'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'unione automatica dei domini.

Test dell'unione 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 partecipare a una singola istanza VM

Crea un'istanza VM che si unisce 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 consente alla VM di partecipare al 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 autonoma

   & 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 di specializzazione. Per attivare TLS 1.2, utilizza invece il seguente scriptlet:

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

   Nota: NetBIOS supporta solo nomi di computer con fino a 15 caratteri. Se il nome host di un'istanza VM supera questa lunghezza massima, lo scriptlet di specializzazione cambia automaticamente il nome del computer in un nome univoco di meno di 15 caratteri.
   
   Quando crei istanze VM aggiuntive, assicurati di mantenere il nome dell'istanza al di sotto di questo limite di caratteri; in caso contrario, 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, il computer viene aggiunto al tuo 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 del processo di avvio, premi CTRL+C.

Verifica che la VM sia unita ad Active Directory

1. Utilizzando un client RDP, accedi a un computer 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 l'opzione Visualizza > Funzionalità avanzate sia attivata.
4. Vai all'OU 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	ID progetto Google Cloud
   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 stessa.

Diagnostica gli errori

Se l'istanza VM non è riuscita ad accedere 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 è unita al dominio Active Directory, eliminala.

• Elimina l'istanza:

  & gcloud compute instances delete join-01 --quiet
  

Creare e partecipare a un gruppo di istanze gestite

Puoi anche verificare che le istanze di un gruppo di istanze gestite possano partecipare automaticamente al tuo dominio.

1. Crea un modello di istanza passando lo script di specializzazione che consente alla VM di partecipare al 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 autonoma

   & 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 in Active Directory siano stati creati quattro nuovi oggetti:

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

Nota: NetBIOS supporta solo nomi di computer con fino a 15 caratteri. Se il nome host di un'istanza VM supera questa lunghezza massima, lo scriptlet di specializzazione cambia automaticamente il nome del computer in un nome univoco di 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 partecipare al tuo dominio Active Directory, puoi eliminare il gruppo gestito e il modello di istanze seguendo questi passaggi:

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

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

2. Elimina il modello di istanza:

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

Pianificazione della pulizia degli account computer inutilizzati

L'automazione del processo di adesione dei computer al dominio riduce il lavoro necessario per configurare i nuovi server e ti consente di utilizzare i server aggiunti al dominio nei gruppi di istanze gestite. Tuttavia, nel tempo, nel dominio possono accumularsi account computer inattivi.

Per evitare questo accumulo, ti consigliamo di configurare l'app register-computer in modo che esamini periodicamente il tuo dominio Active Directory per trovare e rimuovere automaticamente gli account inattivi e i relativi record DNS associati.

L'app register-computer può utilizzare gli attributi msDS-cloudExtensionAttribute degli account computer per identificare quelli non aggiornati. Questi attributi contengono il progetto, la zona e il nome dell'istanza 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, richiedi l'endpoint /cleanup dell'app Cloud Run. Per impedire agli utenti non autorizzati di attivare una pulizia, questa richiesta deve essere autenticata utilizzando l'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 selezionata per le risorse VPC, ad esempio us-central. Se questa regione non è disponibile come località di App Engine, scegli una località geograficamente vicina a te. Per ulteriori informazioni, 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 inattivi, 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, nella colonna Risultato viene visualizzato Successo, indicando 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 sottoposti a pulizia, 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'aggiunta al dominio sono stati identificati come non aggiornati e rimossi.

Esegui la pulizia

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

Se non vuoi mantenere la configurazione di Google Cloud 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 è definito il VPC. Se utilizzi una rete VPC condivisa, utilizza il progetto host VPC; in caso contrario, utilizza l'ID del progetto di dominio.

Ripristinare le modifiche di Active Directory

1. Utilizzando un client RDP, accedi a un computer con accesso amministrativo al tuo dominio Active Directory.
2. Nell'snap-in MMC Utenti e computer di Active Directory, vai alla OU Projects.
3. Elimina l'account utente register-computer di Active Directory.
4. Elimina l'OU creata per testare l'unione automatica al dominio.

Passaggi successivi

• Per aggiungere le VM Windows a un dominio Microsoft AD gestito utilizzando l'unione al dominio automatica, 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 altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.