Configure o Active Directory para que as VMs se associem automaticamente a um domínio

Last reviewed 2024-10-31 UTC

Este documento mostra como configurar o Active Directory e o Compute Engine para que as instâncias de máquinas virtuais (VMs) do Windows possam juntar-se automaticamente a um domínio do Active Directory.

A automatização do processo de associação de VMs do Windows ao Active Directory ajuda a simplificar o processo de aprovisionamento de servidores Windows. Esta abordagem também lhe permite tirar partido da escalabilidade automática sem sacrificar as vantagens da utilização do Active Directory para gerir o acesso e a configuração.

Este documento destina-se a administradores de sistemas e pressupõe que tem conhecimentos sobre o Active Directory e as redes. Google Cloud

A configuração que cria seguindo o procedimento neste documento pode ser a base de trabalho adicional que faz com os servidores Windows em Google Cloud. Por exemplo, depois de concluir este procedimento, pode implementar aplicações ASP.NET com a autenticação do Windows em contentores do Windows.

Se estiver a usar o Microsoft AD gerido e não precisar da limpeza automática de contas de computadores desatualizadas, considere associar as VMs do Windows através da funcionalidade de associação ao domínio automatizada. Para mais informações, consulte o artigo Associe automaticamente uma VM do Windows a um domínio.

Objetivos

• Implemente uma app do Cloud Run que permita que as instâncias de VMs de projetos selecionados se juntem automaticamente ao seu domínio do Active Directory.
• Crie uma tarefa do Cloud Scheduler que analise periodicamente o seu domínio do Active Directory para verificar a existência de contas de computador obsoletas e as remova.
• Teste a configuração criando um grupo de instâncias geridas (GIGs) com escala automática de instâncias de VMs associadas a um domínio.

Custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

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

As instruções neste documento destinam-se a manter a sua utilização de recursos dentro dos limites do nível Google CloudSempre Gratuito. Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços.

Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação gratuita.

Quando terminar este documento, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte o artigo Limpe.

Antes de começar

Este documento pressupõe que já implementou o Active Directory em Google Cloud usando o Serviço gerido para o Microsoft Active Directory (Microsoft AD gerido) ou implementando controladores de domínio autogeridos em Google Cloud.

Para concluir os procedimentos, certifique-se de que tem o seguinte:

• Acesso administrativo ao seu domínio do Active Directory, incluindo a capacidade de criar utilizadores, grupos e unidades organizacionais (UOs).
• Um intervalo de IP CIDR /28 não usado na VPC na qual os controladores de domínio do Active Directory estão implementados. Use este intervalo de IPs para configurar o Acesso a VPC sem servidor.
• Uma sub-rede na qual implementa instâncias do Windows. A sub-rede tem de ser configurada para usar o acesso privado à Google.

Nota: o acesso privado à Google é necessário para que todas as instâncias de VM na sub-rede possam aceder ao Cloud Run. Se não ativar o acesso privado à Google, apenas as instâncias de VM com acesso à Internet podem aderir automaticamente ao seu domínio do Active Directory.

Se usar um controlador de domínio autogerido, também precisa do seguinte:

• Uma zona de encaminhamento de DNS privada que encaminha consultas DNS para os controladores de domínio do Active Directory.

Implementar esta abordagem

Num ambiente no local, pode confiar nos ficheiros de respostas (unattend.xml) e na JoinDomain personalização para associar automaticamente novos computadores a um domínio. Embora possa usar o mesmo processo no Google Cloud, esta abordagem tem várias limitações:

• A utilização de um ficheiro unattend.xml personalizado requer a manutenção de uma imagem do Compute Engine personalizada. Manter uma imagem personalizada atualizada através das atualizações do Windows requer manutenção contínua ou trabalho inicial para configurar a automatização. A menos que precise de manter uma imagem personalizada por outros motivos, este esforço adicional pode não ser justificado.
• A personalização com JoinDomain associa uma imagem a um único domínio do Active Directory porque o nome do domínio tem de ser especificado em unattend.xml. Se mantiver vários domínios ou florestas do Active Directory (por exemplo, para ambientes de teste e produção separados), pode ter de manter várias imagens personalizadas para cada domínio.
• A associação de um computador Windows a um domínio requer credenciais de utilizador com autorizações para criar um objeto de computador no diretório. Se usar a personalização JoinDomain no unattend.xml, tem de incorporar estas credenciais como texto simples no unattend.xml. Estas credenciais incorporadas podem transformar a imagem num potencial alvo para atacantes. Embora possa controlar o acesso à imagem definindo as autorizações da gestão de identidade e de acesso (IAM) adequadas, a gestão do acesso a uma imagem personalizada adiciona complexidade desnecessária.

A abordagem neste documento não usa ficheiros de respostas e, por isso, não requer imagens preparadas especialmente. Em alternativa, use o seguinte scriptlet de especialização do sysprep quando criar uma instância de VM:

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

Este scriptlet de especialização do Sysprep inicia um processo que o diagrama seguinte ilustra.

O processo funciona da seguinte forma:

1. Depois de criar uma instância de VM, o Windows é iniciado pela primeira vez. Como parte da passagem de configuração especializada, o Windows executa o scriptlet especializado do sysprep. O scriptlet especializado invoca a app do Cloud Run e transfere um script do PowerShell que controla o processo de associação ao domínio.register-computer
2. O Windows invoca o script do PowerShell transferido.
3. O script do PowerShell chama o servidor de metadados para obter um token de ID que identifica de forma segura a instância de VM.
4. O script chama novamente a app register-computer, transmitindo o token de ID para se autenticar.
5. A app valida o token de ID e extrai o nome, a zona e o Google Cloud ID do projeto da instância de VM.
6. A app verifica se o domínio do Active Directory está configurado para permitir que as instâncias de VM do projeto especificado se juntem ao domínio. Para concluir esta validação, a app localiza e liga-se a um controlador de domínio do Active Directory para verificar se existe uma unidade organizacional (UO) cujo nome corresponda ao ID do projeto Google Cloud do token de ID. Se for encontrada uma UO correspondente, as instâncias de VM do projeto são autorizadas a juntarem-se ao domínio do Active Directory na UO especificada.
7. A app verifica se o Google Cloud projeto está configurado para permitir que as instâncias de VM se juntem ao Active Directory. Para concluir esta validação, a app verifica se consegue aceder à instância de VM através da API Compute Engine.
8. Se todas as verificações forem bem-sucedidas, a app prepara previamente uma conta de computador no Active Directory. A app guarda o nome, a zona e o ID da instância de VM como atributos no objeto da conta do computador para que possa ser associado à instância de VM.
9. Através do protocolo de definição de palavra-passe do Kerberos, a app atribui uma palavra-passe aleatória à conta do computador.
10. O nome e a palavra-passe do computador são devolvidos à instância do Windows através de um canal protegido por TLS.
11. Através da conta de computador pré-preparada, o script do PowerShell associa o computador ao domínio.
12. Após a conclusão da passagem de configuração especializada, o computador reinicia-se automaticamente.

O resto deste procedimento explica os passos necessários para configurar a associação automática ao domínio.

Preparar o domínio do Active Directory

Primeiro, prepara o domínio do Active Directory. Para concluir este passo, precisa de um computador que tenha acesso administrativo ao seu domínio do Active Directory.

Opcional: limite quem pode associar computadores ao domínio

É aconselhável restringir quem pode associar computadores ao domínio. Por predefinição, a configuração do objeto de política de grupo (GPO) para a política do controlador de domínio predefinida concede o direito de utilizador Add workstations to domain a todos os utilizadores autenticados. Qualquer pessoa com esse direito de utilizador pode associar computadores ao domínio. Uma vez que está a automatizar o processo de associação de computadores ao seu domínio do Active Directory, conceder universalmente este nível de acesso é um risco de segurança desnecessário.

Nota: se usar o Microsoft AD gerido, por predefinição, apenas os membros do grupo Cloud Service Domain Join Accounts podem associar computadores ao seu domínio.

Para limitar quem pode associar computadores ao seu domínio do Active Directory, altere a configuração predefinida do GPO da política de controlador de domínio predefinida:

1. Usando um cliente RDP, inicie sessão numa máquina que tenha acesso administrativo ao seu domínio do Active Directory.
2. Abra a Consola de Gestão de Políticas de Grupo (GPMC).
3. Aceda a Forest > Domains > domain-name > Group Policy Objects, onde domain-name é o nome do seu domínio do Active Directory.
4. Clique com o botão direito do rato em Default Domain Controller Policy e clique em Editar.
5. Na consola do Group Policy Management Editor, aceda a Configuração do computador > Políticas > Definições do Windows > Definições de segurança > Políticas locais > Atribuição de direitos do utilizador.
6. Clique duas vezes em Adicionar estações de trabalho ao domínio.
7. Em Propriedades, remova Utilizadores autenticados da lista.
8. Para permitir que os administradores associem manualmente o domínio (opcional), clique em Adicionar utilizador ou grupo e, de seguida, adicione um grupo administrativo à lista.
9. Clique em OK.

Já pode fechar a consola do editor de gestão de políticas de grupo e a GPMC.

Inicialize uma estrutura de diretórios

Agora, cria uma UO que funciona como um contentor para todas as UOs específicas do projeto:

1. Usando um cliente RDP, inicie sessão numa máquina que tenha acesso administrativo ao seu domínio do Active Directory.
2. Abra uma sessão do PowerShell com privilégios elevados.

3. Criar uma nova unidade organizacional:

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

   Nota: ajuste o valor de $ParentOrgUnitPath para criar a UO numa localização que não seja o contentor predefinido.

Crie uma conta de utilizador do Active Directory

Para aceder ao Active Directory e pré-configurar contas de computador, a app precisa de uma conta de utilizador do Active Directory:register-computer

1. Crie uma conta de utilizador do Active Directory com o nome register-computer, atribua-lhe uma palavra-passe aleatória e, em seguida, coloque-a na UO Projects:

   # Generate a random password
   $Password = [Guid]::NewGuid().ToString()+"-"+[Guid]::NewGuid().ToString()
   
   # Create user
   $UpnSuffix = (Get-ADDomain).DNSRoot
   $RegisterComputerUser = New-ADUser `
       -Name "register-computer Cloud Run app" `
       -GivenName "Register" `
       -Surname "Computer" `
       -Path $ProjectsOrgUnitPath `
       -SamAccountName "register-computer" `
       -UserPrincipalName "register-computer@$UpnSuffix" `
       -AccountPassword (ConvertTo-SecureString "$Password" -AsPlainText -Force) `
       -PasswordNeverExpires $True `
       -Enabled $True `
       -PassThru
   

2. Conceda à conta do register-computer o conjunto mínimo de autorizações necessárias para gerir contas de computador e grupos na UO Projects e nas sub-UOs:

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

   O comando pode demorar alguns minutos a ser concluído.

3. Conceda autorização à conta register-computer para eliminar registos de DNS:

   Microsoft AD gerido

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

   Domínio autogerido

   $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. Revele o caminho da ProjectsUO e a palavra-passe gerada da conta de utilizador do register-computer Active Directory. Tome nota dos valores porque vai precisar deles mais tarde.

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

Preparar o projeto Google Cloud

Agora, configure o projeto do domínio:

• Se usar o Managed Microsoft AD, o projeto de domínio é o projeto no qual implementou o Managed Microsoft AD.
• Se usar o Active Directory autogerido, o projeto de domínio é o projeto que executa os controladores de domínio do Active Directory. No caso de uma VPC partilhada, este projeto tem de ser o mesmo que o projeto anfitrião da VPC.

Use este projeto de domínio para fazer o seguinte:

• Crie um segredo do Secret Manager que contenha a palavra-passe da conta de utilizador do register-computerActive Directory.
• Implemente a app register-computer.
• Configure o Cloud Scheduler para que acione limpezas de contas de computador desatualizadas.

Recomendamos que conceda acesso ao projeto de domínio com base no princípio do menor privilégio.

Crie um Secret do Secret Manager

1. Na Google Cloud consola, abra o Cloud Shell.

   Abra o Cloud Shell

2. Inicie o PowerShell:

   pwsh
   

3. Inicialize a seguinte variável, substituindo domain-project-id pelo ID do projeto do seu domínio:

   $DomainProjectId = "domain-project-id"
   

4. Defina o projeto de domínio como o projeto predefinido:

   & gcloud config set project $DomainProjectId
   

5. Ative a API Secret Manager:

   & gcloud services enable secretmanager.googleapis.com
   

6. Introduza a palavra-passe da register-computerconta de utilizador do Active Directory e armazene-a num segredo do 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
   

Conceda acesso ao Kerberos e ao LDAP

Para gerir as associações a domínios, a app register-computer acede aos seus controladores de domínio através dos seguintes protocolos:

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

• Alteração da palavra-passe do Kerberos (UDP/464, TCP/464)

Microsoft AD gerido

Não precisa de configurar regras de firewall.

Domínio autogerido

Crie uma regra de firewall que permita o acesso aos controladores de domínio.

Pode aplicar a regra com base numa etiqueta de rede que atribuiu aos controladores de domínio ou pode aplicá-la através de uma conta de serviço.

Por etiqueta de rede

& 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

Substitua o seguinte:

• dc-tag: a etiqueta de rede atribuída às VMs do controlador de domínio.
• vpc-project-id: o ID do projeto no qual a VPC está definida. Se usar uma VPC partilhada, use o projeto anfitrião da VPC. Caso contrário, use o ID do projeto do domínio.

Por conta de serviço

& 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

Substitua o seguinte:

• dc-sa: o endereço de email da conta de serviço que as VMs do controlador de domínio usam.
• vpc-project-id: o ID do projeto no qual a VPC está definida. Se usar uma VPC partilhada, use o projeto anfitrião da VPC. Caso contrário, use o ID do projeto de domínio.

Implemente a app do Cloud Run

Agora, configure o Cloud Build para implementar a app register-computer no Cloud Run:

1. No Cloud Shell, clone o repositório do GitHub:

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

2. Inicialize as seguintes variáveis:

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

   Substitua o seguinte:

   • serverless-region: a região na qual implementar a app register-computer. A região não tem de ser a mesma em que planeia implementar instâncias de VM.
   • vpc-name: o nome da rede VPC que contém os controladores de domínio do Active Directory.
   • subnet-name: a sub-rede de vpc-name a usar para o acesso direto à VPC. A sub-rede tem de estar na mesma região que serverless-region.
   • dns-domain-name: O nome de domínio DNS do seu domínio do Active Directory.
   • netbios-domain-name: o nome NetBIOS do seu domínio do Active Directory.
   • projects-ou-distinguished-name: O nome distinto da sua UO Projects.

3. Ative as APIs Cloud Run e Cloud Build:

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

4. Crie uma conta de serviço register-computer-app para a app Cloud Run:

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

5. Crie uma conta de serviço build-service para executar acionadores do Cloud Build:

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

6. Permita que a conta de serviço do Cloud Run leia o segredo que contém a palavra-passe do Active Directory:

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

7. Conceda ao Cloud Build as autorizações necessárias para a implementação no 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. Use o ficheiro cloudbuild.yaml como modelo para criar uma configuração de compilação do Cloud Run personalizada que corresponda ao seu 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: a app oferece definições configuráveis adicionais, como usar LDAPS em vez de LDAP. Para mais informações, consulte o ficheiro README.md da app. Para aplicar configurações adicionais, edite o ficheiro cloudbuild.yaml e adicione as variáveis de ambiente necessárias aos argumentos do passo cloud-sdk.

9. Crie a app e implemente-a no 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
   

   A implementação pode demorar alguns minutos a ser concluída.

   Nota: se mantiver o ficheiro cloudbuild.hydrated.yaml, pode implementar novamente a app mais tarde executando novamente o comando anterior.

10. Determine o URL da app do Cloud Run:

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

    Tome nota do URL. Precisa dele sempre que criar uma instância de VM que deve ser associada ao Active Directory.

11. Invoque a app do Cloud Run para verificar se a implementação funcionou:

    Invoke-RestMethod $RegisterUrl
    

    É apresentado um script do PowerShell. A VM executa este script durante a fase de especialização que a associa ao domínio.

Ativar um projeto para a associação automática de domínios

A app register-computer não permite que as instâncias de VM façam parte de um domínio do Active Directory, a menos que o projeto da VM esteja ativado para a participação automática no domínio. Esta medida de segurança ajuda a impedir que as VMs ligadas a projetos não autorizados acedam ao seu domínio.

Nota: se implementou o Active Directory numa VPC partilhada, recomendamos que crie um projeto para fins de teste e anexe o projeto à VPC partilhada.

A implementação do Acesso a VPC sem servidor cria uma sub-rede na sua VPC. Não precisa de partilhar esta sub-rede quando associa projetos de serviço ao projeto anfitrião de VPC.

Para ativar um projeto para a associação automática a um domínio, tem de fazer o seguinte:

• Crie uma UO no Active Directory cujo nome corresponda ao seu Google Cloud ID do projeto.
• Conceda à app register-computer acesso ao projetoGoogle Cloud .

Primeiro, crie a UO:

1. Usando um cliente RDP, inicie sessão numa máquina que tenha acesso administrativo ao seu domínio do Active Directory.
2. No snap-in MMC Utilizadores e computadores do Active Directory, aceda à Projects UO.
3. Clique com o botão direito do rato na UO e selecione Novo > Unidade organizacional.
4. Na caixa de diálogo Novo objeto, introduza o ID do Google Cloud projeto no qual implementar as suas VMs.
5. Clique em OK.

Em seguida, conceda à app register-computer acesso ao projetoGoogle Cloud :

1. No Cloud Shell, inicie o PowerShell:

   pwsh
   

2. Inicialize as seguintes variáveis:

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

   Substituir

   • project-id com o ID do Google Cloud projeto no qual implementar as suas VMs
   • domain-project-id com o ID do projeto do seu domínio

3. Conceda à conta de serviço register-computer-app a função Compute Viewer no projeto:

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

O seu projeto está agora pronto para suportar a associação automática a domínios.

Testar a associação ao domínio

Agora, pode verificar se a configuração está a funcionar corretamente:

• Criar uma única instância de VM que se associa automaticamente ao domínio do Active Directory
• Criar um grupo de instâncias geridas de instâncias de VM que se juntam automaticamente ao domínio do Active Directory

Crie e associe uma única instância de VM

Crie uma instância de VM que se associe automaticamente ao domínio do Active Directory:

1. Regresse à sessão do PowerShell no Cloud Shell e inicialize as seguintes variáveis:

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

   Substitua o seguinte:

   • vpc-region-to-deploy-vm: a região para implementar a instância de VM.
   • vpc-subnet-to-deploy-vm: a sub-rede na qual implementar a instância de VM.
   • zone-to-deploy-vm: a zona na qual implementar a instância de VM.
   • serverless-region: a região na qual implementou a app do Cloud Run.

2. Defina o projeto e a zona predefinidos:

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

3. Procure novamente o URL da app do Cloud Run:

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

4. Crie uma instância transmitindo o scriptlet especializado que faz com que a VM se junte ao domínio:

   VPC partilhada

   $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 autónoma

   & 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 quiser usar um nome de anfitrião personalizado, adicione um parâmetro --hostname ao comando.

   Se usar uma versão do Windows Server anterior ao Windows Server 2019, o TLS 1.2 pode estar desativado por predefinição, o que pode fazer com que o scriptlet de especialização falhe. Para ativar o TLS 1.2, use o seguinte scriptlet em alternativa:

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

   Nota: o NetBIOS só suporta nomes de computadores com até 15 carateres. Se o nome do anfitrião de uma instância de VM exceder este comprimento máximo, o scriptlet de especialização altera automaticamente o nome do computador para um nome exclusivo com menos de 15 carateres.
   
   Quando criar instâncias de VM adicionais, certifique-se de que o nome da instância não excede este limite de carateres. Caso contrário, é provável que a associação de uma instância de VM ao seu domínio falhe.

5. Monitorize o processo de arranque:

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

   Após cerca de um minuto, a máquina é associada ao seu domínio do Active Directory. O resultado é semelhante ao seguinte:

   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
   

   Para parar de observar o processo de arranque, prima CTRL+C.

Verifique se a VM está associada ao Active Directory

1. Usando um cliente RDP, inicie sessão numa máquina que tenha acesso administrativo ao seu domínio do Active Directory.
2. Abra o snap-in Utilizadores e computadores do Active Directory da MMC.
3. No menu, certifique-se de que Ver > Funcionalidades avançadas está ativado.
4. Aceda à UO com o nome do Google Cloud ID do projeto no qual criou uma instância de VM.
5. Clique duas vezes na conta join-01.

6. Na caixa de diálogo Propriedades, clique no separador Editor de atributos.

   A conta do computador está anotada com atributos LDAP adicionais. Estes atributos permitem-lhe acompanhar a associação entre o objeto de computador e a instância do Compute Engine.

   Verifique se a lista contém os seguintes atributos e valores LDAP.

   Atributo LDAP	Valor
   msDS-cloudExtensionAttribute1	Google Cloud ID do projeto
   msDS-cloudExtensionAttribute2	Zona do Compute Engine
   msDS-cloudExtensionAttribute3	Nome da instância do Compute Engine

   Os atributos msDS-cloudExtensionAttribute são atributos de uso geral e não são usados pelo próprio Active Directory.

Diagnostique erros

Se a instância de VM não tiver conseguido aderir ao domínio, verifique o registo da app register-computer:

1. Na Google Cloud consola, aceda ao Cloud Run.

   Aceda ao Cloud Run

2. Clique na app register-computer.

3. No menu, clique em Registos.

Elimine a instância

Depois de confirmar que a instância de VM está associada ao domínio do Active Directory, elimine a instância.

• Elimine a instância:

  & gcloud compute instances delete join-01 --quiet
  

Crie e participe num grupo de instâncias gerido

Também pode verificar se as instâncias de um MIG podem aderir automaticamente ao seu domínio.

1. Crie um modelo de instância transmitindo o script especializado que faz com que a VM se junte ao domínio:

   VPC partilhada

   $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 autónoma

   & 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. Crie um grupo de instâncias geridas que use o modelo de instância:

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

Aguarde alguns minutos e, em seguida, use o snap-in MMC Utilizadores e computadores do Active Directory para verificar se foram criados quatro novos objetos no Active Directory:

• 3 contas de computador correspondentes às 3 instâncias de VM do grupo de instâncias geridas.
• 1 grupo denominado group-01 que contém as 3 contas de computador. Se planear usar contas de serviço geridas por grupos (gMSA), pode usar este grupo para conceder acesso à gMSA.

Nota: o NetBIOS só suporta nomes de computadores com até 15 carateres. Se o nome do anfitrião de uma instância de VM exceder este comprimento máximo, o scriptlet de especialização altera automaticamente o nome do computador para um nome exclusivo com menos de 15 carateres. Certifique-se de que usa nomes curtos para grupos de instâncias geridos, para que os nomes das instâncias de VM não excedam 15 carateres.

Depois de verificar que as instâncias de VM dos MIGs podem aderir ao seu domínio do Active Directory, pode eliminar o grupo gerido e o modelo de instância seguindo estes passos:

1. No Cloud Shell, elimine o grupo de instâncias:

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

2. Elimine o modelo de instância:

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

Agendar a limpeza de contas de computador obsoletas

A automatização do processo de associação de computadores ao domínio reduz o esforço necessário para configurar novos servidores e permite-lhe usar servidores associados ao domínio em grupos de instâncias geridos. No entanto, ao longo do tempo, podem acumular-se contas de computador desatualizadas no domínio.

Para evitar esta acumulação, recomendamos que configure a app register-computer para analisar periodicamente o seu domínio do Active Directory para encontrar e remover automaticamente contas desatualizadas e os respetivos registos de DNS associados.

A app register-computer pode usar os atributos msDS-cloudExtensionAttribute das contas de computador para identificar que contas de computador estão desatualizadas. Estes atributos contêm o projeto, a zona e o nome da instância de VM correspondente no Compute Engine. Para cada conta de computador, a app pode verificar se a instância de VM correspondente ainda está disponível. Caso contrário, a conta do computador é considerada desatualizada e removida.

Para acionar uma limpeza de contas de computador, invoque o ponto final /cleanup da app Cloud Run. Para impedir que utilizadores não autorizados acionem uma limpeza, este pedido tem de ser autenticado através da conta de serviço register-computer-app.

Configure o Cloud Scheduler

Os passos seguintes mostram como configurar o Cloud Scheduler em conjunto com o Pub/Sub para acionar automaticamente uma limpeza a cada 24 horas:

1. No Cloud Shell, ative a API Cloud Scheduler no projeto do seu domínio:

   & gcloud services enable cloudscheduler.googleapis.com
   

2. Defina AppEngineLocation para uma localização do App Engine válida na qual implementar o Cloud Scheduler:

   $AppEngineLocation = "location"
   

   Substitua location pela região do App Engine que selecionou para os seus recursos de VPC, por exemplo, us-central. Se essa região não estiver disponível como uma localização do App Engine, escolha uma localização geograficamente próxima de si. Para mais informações, consulte o artigo Regiões e zonas.

3. Inicialize o App Engine:

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

4. Crie uma tarefa do 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
   

   Esta tarefa chama a app register-computer uma vez a cada 24 horas e usa a conta de serviço register-computer-app para autenticação.

Acione uma limpeza

Para validar a sua configuração para limpar contas de computador desatualizadas, pode acionar manualmente a tarefa do Cloud Scheduler.

1. Na Google Cloud consola, aceda ao Cloud Scheduler.

   Aceda ao Cloud Scheduler

2. Para a tarefa cleanup-computer-accounts que criou, clique em Executar agora.

   Após alguns segundos, a coluna Resultado apresenta Êxito, indicando que a limpeza foi concluída com êxito. Se a coluna de resultados não for atualizada automaticamente em alguns segundos, clique no botão Atualizar.

Para mais detalhes sobre as contas que foram limpas, consulte os registos da app register-computer.

1. Na Google Cloud consola, aceda ao Cloud Run.

   Aceda ao Cloud Run

2. Clique na app register-computer.

3. No menu, clique em Registos.

   As entradas de registo indicam que as contas de computador das instâncias de VM que usou para testar a associação ao domínio foram identificadas como desatualizadas e removidas.

Limpar

Se estiver a usar este documento como base para outras arquiteturas de referência e implementações, leia os outros documentos sobre quando executar os passos de limpeza.

Se não quiser manter a Google Cloud configuração usada neste documento, pode reverter esta configuração da seguinte forma:

1. No Cloud Shell, elimine a tarefa do Cloud Scheduler:

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

2. Elimine a app do Cloud Run:

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

3. Elimine o segredo do Secret Manager:

   gcloud secrets delete ad-password --project $DomainProjectId
   

4. Elimine a regra de firewall para acesso LDAP e Kerberos:

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

   Substitua vpc-project-id pelo ID do projeto no qual o VPC está definido. Se usar uma VPC partilhada, use o projeto anfitrião da VPC. Caso contrário, use o ID do projeto de domínio.

Reverta as alterações do Active Directory

1. Usando um cliente RDP, inicie sessão numa máquina que tenha acesso administrativo ao seu domínio do Active Directory.
2. No snap-in MMC Utilizadores e computadores do Active Directory, aceda à Projects UO.
3. Elimine a register-computerconta de utilizador do Active Directory.
4. Elimine a UO que criou para testar a associação automática ao domínio.

O que se segue?

• Para associar VMs do Windows a um domínio do Microsoft AD gerido através da associação automática a um domínio, consulte o artigo Associe automaticamente uma VM do Windows a um domínio.
• Reveja as nossas práticas recomendadas para implementar uma floresta de recursos do Active Directory no Google Cloud.
• Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.