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

Last reviewed 2024-08-08 UTC

Questo documento illustra come configurare Active Directory Compute Engine in modo che le istanze di macchine virtuali (VM) Windows possano unire automaticamente Dominio della directory.

L'automazione del processo di unione delle VM Windows ad Active Directory 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 la rete 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 Managed Microsoft AD e non hai bisogno della pulizia automatica di computer inattivo account, valuta la possibilità di unire le VM Windows utilizzando la funzionalità di unione automatica dei domini. Per Per ulteriori informazioni, consulta l'articolo su come partecipare automaticamente a una VM Windows dominio.

Obiettivi

  • Esegui il deployment di un'app Cloud Run che abilita le istanze VM di progetti selezionati per aggiungere automaticamente il dominio Active Directory.
  • Crea un job Cloud Scheduler che analizzi periodicamente i tuoi Dominio Active Directory per gli account computer inattivi e li rimuove.
  • 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:

Le istruzioni in questo documento sono pensate per garantire l'utilizzo delle risorse entro i limiti del piano Always Free di Google Cloud livello. Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Al termine di questo documento, per evitare che la fatturazione continui eliminando il le risorse che hai creato. Per maggiori informazioni, vedi Pulizia.

Prima di iniziare

Questo documento presuppone che tu abbia già eseguito il deployment di Active Directory su Google Cloud Servizio gestito per Microsoft Active Directory (Microsoft AD gestito) o con il deployment di controller di dominio autogestiti su Google Cloud.

Per completare la procedura, 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 delle istanze Windows. La subnet deve essere configurato per utilizzare Accesso privato Google.

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

Implementazione di questo approccio

In un ambiente on-premise, puoi fare affidamento file di risposte (unattend.xml) e JoinDomain personalizzazione per aggiungere automaticamente nuovi computer a un dominio. Sebbene sia possibile utilizzare lo stesso in Google Cloud, questo approccio presenta diverse limitazioni:

  • L'utilizzo di un file unattend.xml personalizzato richiede la conservazione di un Immagine Compute Engine. Mantenere aggiornata un'immagine personalizzata utilizzando gli aggiornamenti di Windows richiede manutenzione o lavoro iniziale per configurare l'automazione. A meno che tu non debba gestire un'immagine personalizzata per altri motivi, questo impegno aggiuntivo potrebbe non essere giustificato.
  • L'utilizzo della personalizzazione JoinDomain associa un'immagine a un singolo account Dominio della directory perché il nome di dominio deve essere specificato unattend.xml. Se gestisci più foreste o domini Active Directory (ad esempio, per ambienti di test e produzione separati), potrebbe essere necessario mantenere 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 un'immagine in un potenziale obiettivo per gli aggressori. Sebbene sia possibile controllare l'accesso all'immagine impostando Autorizzazioni IAM (Identity and Access Management), la gestione dell'accesso a un'immagine personalizzata aggiunge una complessità superflua.

L'approccio descritto in questo documento non utilizza file di risposte 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.

Processo avviato da sysprep per lo scriptlet.

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 di specializzazione di sysprep. 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 account controller di dominio per cercare un'unità organizzativa (UO) il cui nome corrisponde all'ID progetto Google Cloud del token ID. Se viene trovata la UO corrispondente, le istanze VM del progetto sono autorizzate aggiungere il dominio Active Directory nella UO 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 offre un account computer in Active Directory. L'app salva il nome, la zona e ID come attributi nell'oggetto dell'account computer in modo che possa essere associate all'istanza VM.
  9. L'utilizzo del Protocollo password impostato Kerberos, 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 della procedura illustra i passaggi necessari per configurare l'aggiunta automatica ai 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. Perché sei automatizzare il processo di aggiunta dei computer al dominio Active Directory, la concessione di questo livello di accesso a livello universale è un rischio inutile per la sicurezza.

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

  1. Utilizzando un client RDP, accedi a una macchina che ha accesso amministrativo alla tua Active Directory dominio.
  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 pulsante destro del mouse su Default Domain Controller Policy (Criterio del controller di dominio predefinito) e fai clic 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 una macchina che ha accesso amministrativo alla tua Active Directory dominio.
  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

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 necessario per gestisci gli account e i gruppi di computer 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. Mostra il percorso della OU Projects e la password generata dell'account utente Active Directory register-computer. Prendi nota dei valori perché ne avrai bisogno in seguito.

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

Preparazione del progetto Google Cloud

Ora devi configurare il progetto del tuo dominio:

  • Se utilizzi Microsoft Active Directory gestito, il progetto del tuo dominio è il progetto in di cui hai eseguito il deployment di Microsoft Active Directory 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 di Accesso VPC serverless per consentire a Cloud Run di accedere ad Active Directory.
  • Esegui il deployment dell'app register-computer.
  • Configura Cloud Scheduler in modo che attivi la pulizia degli account computer inattivi.

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

Crea 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 Active Directory register-computer e lo archiviamo 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

Esegui il deployment dell'accesso VPC serverless

L'app register-computer deve comunicare con il tuo Controller di dominio Active Directory. Per consentire a Cloud Run di accedere alle risorse in un VPC, ora devi configurare Accesso VPC serverless:

  1. Inizializza le seguenti variabili:

    $VpcName = "vpc-name"
$ServerlessRegion = "serverless-region"
$ServerlessIpRange = "serverless-ip-range"

    Sostituisci quanto segue:

    • vpc-name: il nome della rete VPC che contiene i controller di dominio Active Directory.

    • serverless-region: la regione in cui eseguire il deployment in Cloud Run. Scegli una regione che supporti sia Cloud Run sia Accesso VPC serverless. La regione non deve essere necessariamente la stessa di quella che intendi creare di eseguire il deployment delle istanze VM.

    • serverless-ip-range: utilizzata da Accesso VPC serverless per consentire la comunicazione tra Cloud Run e le risorse nel tuo VPC. Impostato su un valore non prenotato Intervallo IP CIDR /28. Non deve sovrapporsi ad alcuna subnet esistente della tua rete VPC.

  2. Abilita le API di accesso VPC serverless:

    & gcloud services enable vpcaccess.googleapis.com

  3. Esegui il deployment dell'accesso VPC serverless:

    & gcloud compute networks vpc-access connectors create serverless-connector `
    --network $VpcName `
    --region $ServerlessRegion `
    --range $ServerlessIpRange

Concedi l'accesso a Kerberos e LDAP

Sebbene l'accesso VPC serverless consenta a Cloud Run di accedere alle risorse nella tua VPC, la connettività agli endpoint Kerberos e LDAP dei tuoi controller di dominio è comunque soggetta alle regole del firewall.

Devi creare una regola del firewall che consenta alle risorse serverless di accedere ai controller di dominio utilizzando i seguenti protocolli: LDAP (TCP/389), LDAPS (TCP/636), Kerberos (UDP/88, TCP/88) o modifica della password Kerberos (UDP/464, TCP/464). 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 applicare la regola firewall, esegui uno dei seguenti comandi in Cloud Shell:

    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 al tuo le VM del controller di dominio.
    • vpc-project-id: l'ID del progetto che Il VPC è definito in. Se utilizzi un VPC condiviso, utilizza il progetto host VPC; altrimenti usa l'ID del dominio progetto.

    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 servizio utilizzato dalle VM del controller di dominio.
    • vpc-project-id: l'ID del progetto a cui è connesso il VPC definita in. Se utilizzi un VPC condiviso, utilizza il progetto host VPC; altrimenti usa l'ID del progetto del 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:

    $AdDomain = "dns-domain-name"
$AdNetbiosDomain = "netbios-domain-name"
$ProjectsOrgUnitPath = "projects-ou-distinguished-name"

    Sostituisci quanto segue:

    • 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 eseguire i trigger di 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 un modello personalizzato La configurazione di compilazione di Cloud Run corrispondente 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 | Set-Content .\cloudbuild.hydrated.yaml

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

  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 il processo che lo unisce al dominio.

Attivare un progetto per l'unione automatica al dominio

L'app register-computer non consente alle istanze VM di partecipare a un dominio Active Directory a meno che il progetto della VM non sia abilitato per l'uso automatico aggiunta al dominio. Questa misura di sicurezza contribuisce a impedire alle VM collegate a progetti non autorizzati di accedere al tuo dominio.

Per attivare l'aggiunta automatica al dominio di un progetto, devi seguire questi passaggi:

  • Crea una UO 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. Nello snapshot MMC Utenti e computer di Active Directory, vai alla Projects UO.
  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 per eseguire il deployment delle tue 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 tuo progetto è ora pronto per supportare l'unione automatica al dominio.

Test dell'unione al dominio

Ora puoi verificare il corretto funzionamento della configurazione:

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

Creare e partecipare a una singola istanza VM

Crea un'istanza VM che verrà aggiunta automaticamente al dominio Active Directory:

  1. Torna alla sessione PowerShell in Cloud Shell e inizializzala 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 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 .

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

  5. Monitora il processo di avvio:

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

    Dopo circa un minuto, la macchina viene aggiunta alla tua Active Directory dominio. 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 aggiunta ad Active Directory

  1. Utilizzando un client RDP, accedi a una macchina che ha accesso amministrativo a il tuo dominio Active Directory.
  2. Apri lo snapshot 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 del computer è annotato con attributi LDAP aggiuntivi. Questi 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 della 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 fa sì che la VM entri nel 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.
  • 1 gruppo denominato group-01 contenente i tre account computer. Se prevedi per utilizzare gli account di servizio gestiti in gruppo (gMSA), puoi utilizzare questo gruppo per concedere l'accesso al gMSA.

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 register-computer app per eseguire periodicamente la scansione del tuo Dominio Active Directory per trovare e rimuovere automaticamente gli account inattivi.

L'app register-computer può usare: msDS-cloudExtensionAttribute di account computer per identificare quali gli account dei computer sono obsoleti. 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 dell'account del computer, richiama l'/cleanup dell'app Cloud Run. Per impedire a utenti non autorizzati di attiva una pulizia, questa richiesta deve essere autenticata utilizzando 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 su 24 e utilizza l'account di servizio register-computer-app per 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, la colonna Risultato mostra Operazione riuscita. che indica 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'appregister-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 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 di questo documento, puoi ripristinare la configurazione procedendo 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 un VPC condiviso, utilizza il progetto host VPC; altrimenti usa l'ID del progetto del dominio.

  5. Elimina l'accesso VPC serverless:

    gcloud compute networks vpc-access connectors delete serverless-connector --region $ServerlessRegion --quiet

Annullare le modifiche ad Active Directory

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

Passaggi successivi