Configurar o Active Directory para VMs para ingressar automaticamente em um domínio

Last reviewed 2024-08-08 UTC

Neste documento, mostramos como configurar o Active Directory e o Compute Engine para que as instâncias de máquina virtual (VM) do Windows possam participar automaticamente de um domínio do Active Directory.

A automatização do processo de associação de VMs do Windows para o Active Directory ajuda a simplificar o processo de provisionamento de servidores do Windows. A abordagem também permite que você aproveite o escalonamento automático sem sacrificar os benefícios do uso do Active Directory para gerenciar o acesso e a configuração.

Este documento é destinado a administradores do sistema e pressupõe que você esteja familiarizado com o Active Directory e a rede do Google Cloud.

A configuração que você cria seguindo o procedimento neste documento pode ser a base do trabalho extra que você faz com o Windows Server no Google Cloud. Por exemplo, depois de concluir este procedimento, você poderá implantar aplicativos ASP.NET com a autenticação do Windows em contêineres do Windows.

Se você estiver usando o Microsoft AD gerenciado e não precisar de limpeza automática de contas de computador desatualizadas, pense na possibilidade de juntar as VMs do Windows usando o recurso de união de domínios automatizada. Para mais informações, consulte Associar uma VM do Windows automaticamente a um domínio.

Objetivos

  • Implantar um aplicativo do Cloud Run que permita que instâncias de VM de projetos selecionados entrem automaticamente no domínio do Active Directory.
  • Criar um job do Cloud Scheduler que verifique periodicamente o domínio do Active Directory em busca de contas de computador desatualizadas e as remova.
  • Teste a configuração criando um grupo de instâncias gerenciadas (MIGs, na sigla em inglês) com escalonamento automático de instâncias de VM mescladas ao domínio.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

As instruções deste documento foram criadas para manter o uso de seus recursos dentro dos limites do nível Sempre gratuito do Google Cloud. Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir este documento, você evitará o faturamento contínuo excluindo os recursos criados. Para mais informações, consulte Limpeza.

Antes de começar

Neste documento, presumimos que você já implantou o Active Directory no Google Cloud usando o Serviço gerenciado para o Microsoft Active Directory (Managed Microsoft AD) ou implantando controladores de domínio autogerenciados no Google Cloud.

Para concluir os procedimentos, verifique se você tem o seguinte:

  • Acesso administrativo ao domínio do Active Directory, incluindo a capacidade de criar usuários, grupos e unidades organizacionais (UOs).
  • Um intervalo de IP CIDR /28 não usado na VPC em que os controladores de domínio do Active Directory estão implantados. Esse intervalo de IP é usado para configurar o acesso VPC sem servidor.
  • Uma sub-rede que você faz a implantação de instâncias do Windows. A sub-rede precisa ser configurada para usar o Acesso privado do Google.

Se você usa um controlador de domínio autogerenciado, também precisa de:

Como implementar essa abordagem

Em um ambiente local, é possível depender de arquivos de resposta (unattend.xml) e da JoinDomain personalização para associar automaticamente novos computadores a um domínio. Embora você possa usar o mesmo processo no Google Cloud, essa abordagem tem várias limitações:

  • Para usar um arquivo unattend.xml personalizado, você precisa manter uma imagem personalizada do Compute Engine. Manter uma imagem personalizada atual usando o Windows Updates requer manutenção contínua ou trabalho inicial para configurar a automação. A menos que você precise manter uma imagem personalizada por outros motivos, esse esforço extra pode não ser justificado.
  • O uso da personalização JoinDomain vincula uma imagem a um único domínio do Active Directory porque o nome de domínio precisa ser especificado em unattend.xml. Se você mantiver vários domínios ou florestas do Active Directory (por exemplo, para ambientes de teste e produção separados), talvez seja necessário manter várias imagens personalizadas para cada domínio.
  • A conexão de um computador Windows a um domínio requer credenciais de usuário com permissões para criar um objeto de computador no diretório. Se você usar a personalização JoinDomain em unattend.xml, precisará incorporar essas credenciais como texto simples em unattend.xml. Essas credenciais incorporadas podem transformar a imagem em um possível alvo para invasores. É possível controlar o acesso à imagem definindo as permissões de gerenciamento de identidade e acesso (IAM) apropriadas, mas gerenciar o acesso a uma imagem personalizada aumenta, sem necessidade, a complexidade.

A abordagem neste documento não usa arquivos de resposta. Portanto, não requer imagens especialmente preparadas. Em vez disso, use o seguinte scriptlet specialize do sysprep ao criar uma instância de VM:

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

O scriptlet specialize do sysprep inicia um processo ilustrado no diagrama a seguir.

Processo que o scriptlet specialize de sysprep inicia.

O processo funciona da seguinte maneira:

  1. Depois que uma instância de VM é criada, o Windows é inicializado pela primeira vez. Como parte do passe de configuração specialize, o Windows executa o scriptlet specialize do sysprep. O scriptlet specialize invoca o aplicativo Cloud Run register-computer e faz o download de um script do PowerShell que controla o processo de entrada no domínio.
  2. O Windows chama o script do PowerShell baixado.
  3. O script do PowerShell chama o servidor de metadados para receber um token de ID que identifica com segurança a instância de VM.
  4. O script chama o aplicativo register-computer novamente, passando o token de ID para se autenticar.
  5. O aplicativo valida o token de ID e extrai o nome, a zona e o ID do projeto do Google Cloud da instância de VM.
  6. O aplicativo verifica se o domínio do Active Directory está configurado para permitir que as instâncias de VM do projeto fornecido entrem no domínio. Para concluir essa verificação, o aplicativo localiza e se conecta a um controlador de domínio do Active Directory para verificar se há uma unidade organizacional (UO) com um nome correspondendo ao ID do projeto do Google Cloud pelo token de ID. Se uma unidade organizacional correspondente for encontrada, as instâncias de VM do projeto vão ter autorização para ingressar no domínio do Active Directory na unidade organizacional especificada.
  7. O aplicativo verifica se o projeto do Google Cloud está configurado para permitir que instâncias de VM entrem no Active Directory. Para concluir essa verificação, o aplicativo verifica se pode acessar a instância de VM usando a API Compute Engine.
  8. Se todas as verificações forem aprovadas com êxito, o aplicativo preparará uma conta de computador no Active Directory. O aplicativo salva 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. Usando o protocolo Kerberos set password, o aplicativo atribui uma senha aleatória à conta do computador.
  10. O nome e a senha do computador são retornados para a instância do Windows por meio de um canal protegido por TLS.
  11. Usando a conta de computador preparada, o script do PowerShell associa o computador ao domínio.
  12. Depois que o passo de configuração da especialização for concluído, a máquina será reinicializada.

No restante deste procedimento, explicamos as etapas necessárias para configurar a união automatizada de domínios.

Como preparar o domínio do Active Directory

Primeiro, prepare seu domínio do Active Directory. Para concluir essa etapa, você precisa de uma máquina que tenha acesso administrativo ao seu domínio do Active Directory.

Opcional: limite quem pode associar os computadores ao domínio

Convém restringir quem pode associar computadores ao domínio. Por padrão, a configuração do objeto de política de grupo (GPO, na sigla em inglês) da política do controlador de domínio padrão concede o direito de usuário Add workstations to domain a todos os usuários autenticados. Qualquer pessoa com esse direito de usuário pode associar computadores ao domínio. Como você está automatizando o processo de associação de computadores ao seu domínio do Active Directory, a concessão universal desse nível de acesso representa um risco de segurança desnecessário.

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

  1. Usando um cliente RDP, faça login em uma máquina que tenha acesso administrativo ao seu domínio do Active Directory.
  2. Abra o Console de Gerenciamento de Política de Grupo (GPMC, na sigla em inglês).
  3. Acesse Floresta > Domínios > domain-name > Objetos da política de grupo, em que domain-name é o nome do domínio do Active Directory.
  4. Clique com o botão direito em Política de controlador de domínio padrão e, em seguida, em Editar.
  5. No console do Editor de gerenciamento de políticas de grupo, vá para Configuração do computador > Políticas > Configurações do Windows > Configurações de segurança > Políticas locais > Atribuição de direitos do usuário.
  6. Clique duas vezes em Adicionar estações de trabalho ao domínio.
  7. Em Propriedades, remova Usuários autenticados da lista.
  8. Para permitir que os administradores participem do domínio manualmente (opcional), clique em Adicionar usuário ou grupo e adicione um grupo administrativo à lista.
  9. Clique em OK.

Agora é possível fechar o console do Editor de gerenciamento de política de grupo e o GPMC.

Inicializar uma estrutura de diretórios

Agora, crie uma unidade organizacional que sirva como contêiner para todas as unidades organizacionais específicas do projeto:

  1. Usando um cliente RDP, faça login em uma máquina que tenha acesso administrativo ao seu domínio do Active Directory.
  2. Abra uma sessão elevada do PowerShell.

  3. Crie uma nova unidade organizacional:

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

Criar uma conta de usuário do Active Directory

Para acessar o Active Directory e preparar as contas do computador, o aplicativo register-computer precisa de uma conta de usuário do Active Directory:

  1. Crie uma conta de usuário do Active Directory chamada register-computer, atribua uma senha aleatória e coloque-a na unidade organizacional 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 register-computer o conjunto mínimo de permissões necessárias para gerenciar contas de computador na unidade organizacional e subunidades organizacionais Projects:

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

    Isso pode demorar alguns minutos.

  3. Revele o caminho da unidade organizacional Projects e a senha gerada da conta de usuário do Active Directory register-computer. Anote os valores, porque você precisará deles depois.

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

Preparando o projeto do Google Cloud

Agora, configure o projeto do seu domínio:

  • Se você usa o Managed Microsoft AD, seu projeto de domínio é o projeto em que você implantou o Managed Microsoft AD.
  • Se você usa o Active Directory autogerenciado, seu projeto de domínio é o projeto que executa os controladores de domínio do Active Directory. No caso de uma VPC compartilhada, esse projeto precisa ser igual ao projeto host da VPC.

Você usa esse projeto de domínio para fazer o seguinte:

  • Crie um secret do Secret Manager que contenha a senha da conta de usuário do Active Directory register-computer.
  • Implantar Acesso VPC sem servidor para permitir que o Cloud Run acesse o Active Directory.
  • Implantar o aplicativo register-computer.
  • Configurar o Cloud Scheduler para acionar a limpeza de contas de computador desatualizadas.

Recomendamos que você conceda acesso ao projeto de domínio com base no privilégio mínimo.

Criar um secret do Secret Manager

  1. No Console do Google Cloud, abra o Cloud Shell.

    Abrir o Cloud Shell

  2. Inicie o PowerShell:

    pwsh

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

    $DomainProjectId = "domain-project-id"

  4. Defina o projeto do domínio como o projeto padrão:

    & gcloud config set project $DomainProjectId

  5. Ative a API Secret Manager:

    & gcloud services enable secretmanager.googleapis.com

  6. Digite a senha da conta de usuário do Active Directory register-computer e armazene-a em um secret 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

Implantar acesso VPC sem servidor

O aplicativo register-computer precisa se comunicar com os controladores de domínio do Active Directory. Para permitir que o Cloud Run acesse recursos em uma VPC, configure o acesso VPC sem servidor:

  1. Inicialize as seguintes variáveis:

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

    Substitua:

    • vpc-name: o nome da rede VPC que contém os controladores de domínio do Active Directory.

    • serverless-region: a região em que o Cloud Run será implantado. Escolha uma região compatível com o Cloud Run e o acesso VPC sem servidor. A região não precisa ser a mesma que você planeja implantar instâncias de VM.

    • serverless-ip-range: usado pelo acesso VPC sem servidor para ativar a comunicação entre o Cloud Run e os recursos da sua VPC. Defina como um intervalo de IP CIDR não compartilhado /28. Ele não pode se sobrepor a nenhuma sub-rede existente na sua rede VPC.

  2. Ative as APIs de acesso VPC sem servidor:

    & gcloud services enable vpcaccess.googleapis.com

  3. Implantar acesso VPC sem servidor:

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

Conceder acesso a Kerberos e LDAP

Embora o acesso VPC sem servidor permita que o Cloud Run acesse recursos em sua VPC, a conectividade com os endpoints Kerberos e LDAP de seus controladores de domínio ainda está sujeita às regras de firewall.

Você precisa criar uma regra de firewall que permita que recursos sem servidor acessem seus controladores de domínio usando os protocolos: LDAP (TCP/389), LDAPS (TCP/636), Kerberos (UDP/88, TCP/88) ou alteração de senha Kerberos (UDP/464, TCP/464). É possível aplicar a regra com base em uma tag de rede atribuída aos seus controladores de domínio ou aplicá-la usando uma conta de serviço.

  • Para aplicar a regra de firewall, execute um dos seguintes comandos no Cloud Shell:

    Por tag 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

    Faça estas substituições:

    • dc-tag: a tag de rede atribuída às VMs do controlador de domínio.
    • vpc-project-id: o ID do projeto em que a VPC está definida. Se você usar uma VPC compartilhada, use o projeto host da VPC. Caso contrário, use o ID do projeto de 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

    Faça estas substituições:

    • dc-sa: o endereço de e-mail da conta de serviço que as VMs de controlador de domínio usam.
    • vpc-project-id: o ID do projeto em que a VPC está definida. Se você usar uma VPC compartilhada, use o projeto host da VPC. Caso contrário, use o ID do projeto de domínio.

Implantar o aplicativo Cloud Run

Configure agora o Cloud Build para implantar o aplicativo 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:

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

    Faça estas substituições:

    • dns-domain-name: o nome de domínio DNS do seu domínio do Active Directory.
    • netbios-domain-name: o nome do NetBIOS do seu domínio do Active Directory.
    • projects-ou-distinguished-name: o nome distinto da sua unidade organizacional 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 o aplicativo Cloud Run:

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

  5. Permita que a conta de serviço do Cloud Run leia o secret que contém a senha do Active Directory:

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

  6. Conceda ao Cloud Build as permissões necessárias para implantar 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:$DomainProjectNumber@cloudbuild.gserviceaccount.com" `
  --role "roles/iam.serviceAccountUser"

& gcloud projects add-iam-policy-binding $DomainProjectId `
  --member "serviceAccount:$DomainProjectNumber@cloudbuild.gserviceaccount.com" `
  --role roles/run.admin

  7. Use o arquivo cloudbuild.yaml como um modelo para criar uma configuração de versão personalizada do Cloud Run 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 | Set-Content .\cloudbuild.hydrated.yaml

  8. Crie o aplicativo e implante-o no Cloud Run:

    & gcloud builds submit . `
  --config cloudbuild.hydrated.yaml `
  --substitutions _IMAGE_TAG=$(git rev-parse --short HEAD)

    A implantação pode levar alguns minutos para ser concluída.

  9. Determine o URL do aplicativo do Cloud Run:

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

    Anote o URL. Você precisará dele sempre que criar uma instância de VM que precise ser associada ao Active Directory.

  10. Chame o aplicativo Cloud Run para verificar se a implantação funcionou:

    Invoke-RestMethod $RegisterUrl

    Um script do PowerShell é exibido. A VM executa esse script durante a fase de especialização que o une ao domínio.

Ativando um projeto para associação automática ao domínio

O aplicativo register-computer não permite que instâncias de VM entrem em um domínio do Active Directory, a menos que o projeto da VM esteja ativado para a associação automática de domínio. Essa medida de segurança ajuda a impedir que as VMs conectadas a projetos não autorizados acessem seu domínio.

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

  • Crie uma unidade organizacional no Active Directory com o nome correspondendo ao ID do projeto do Google Cloud.
  • Conceda ao aplicativo register-computer acesso ao projeto do Google Cloud.

Primeiro, crie a unidade organizacional:

  1. Usando um cliente RDP, faça login em uma máquina que tenha acesso administrativo ao seu domínio do Active Directory.
  2. No snap-in de usuários do Active Directory e MMC de computadores acesse a unidade organizacional Projects.
  3. Clique com o botão direito do mouse na unidade organizacional e selecione Nova > Unidade organizacional.
  4. Na caixa de diálogo Novo objeto, insira o ID do projeto do Google Cloud para implantar suas VMs.
  5. Clique em OK.

Em seguida, conceda ao aplicativo register-computer acesso ao projeto do Google 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 pelo ID do projeto do Google Cloud para implantar suas VMs.
    • domain-project-id pelo ID do projeto do domínio.

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

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

Seu projeto está pronto para oferecer suporte à participação automática no domínio.

Como testar a junção de domínio

Para verificar se a configuração está funcionando corretamente:

  • Crie uma única instância de VM que entre automaticamente no domínio do Active Directory
  • Crie um grupo de instâncias gerenciadas de instâncias de VM que entre automaticamente no domínio do Active Directory

Criar e participar de apenas uma instância de VM

Crie uma instância de VM que entre automaticamente no domínio do Active Directory:

  1. Retorne à 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:

    • vpc-region-to-deploy-vm: a região em que a instância da VM será implantada.
    • vpc-subnet-to-deploy-vm: a sub-rede em que a instância de VM será implantada.
    • zone-to-deploy-vm: a zona em que a instância de VM será implantada.
    • serverless-region: a região em que você implantou o aplicativo do Cloud Run.

  2. Defina o projeto e a zona padrão:

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

  3. Procure o URL do aplicativo do Cloud Run novamente:

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

  4. Crie uma instância passando o scriptlet specialize que faz com que a VM seja associada ao domínio:

    VPC compartilhada 

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

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

    Se você usa uma versão do Windows Server anterior ao Windows Server 2019, o TLS 1.2 pode ser desativado por padrão (em inglês), o que pode causar falha no scriptlet specialize. Para ativar o TLS 1.2, use o seguinte scriptlet:

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

  5. Monitore o processo de inicialização:

    & 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. A saída será assim:

    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 inicialização, pressione CTRL+C.

Verificar se uma VM está associada ao Active Directory

  1. Usando um cliente RDP, faça login em uma máquina que tenha acesso administrativo ao seu domínio do Active Directory.
  2. Abra o snap-in dos usuários do Active Directory e do MMC de computadores.
  3. No menu, verifique se a Visualização > Recursos avançados está ativada.
  4. Acesse a unidade organizacional com o nome do ID do projeto do Cloud em que você criou uma instância de VM.
  5. Clique duas vezes na conta join-01.

  6. Na caixa de diálogo Propriedades, clique na guia Editor de atributos.

    A conta do computador é anotada com atributos LDAP adicionais. Esses atributos permitem rastrear a associação entre o objeto do 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 ID do projeto do Google Cloud
    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.

Diagnosticar erros

Se a instância de VM não conseguir entrar no domínio, verifique o registro do aplicativo register-computer:

  1. No console do Google Cloud, acesse o Cloud Run.

    Acesse o Cloud Run

  2. Clique no aplicativo register-computer.

  3. No menu, clique em Registros.

Excluir a instância

Depois de verificar se a instância da VM está associada ao domínio do Active Directory, você deve excluí-la.

  • Exclua a instância:

    & gcloud compute instances delete join-01 --quiet

Criar e participar de um grupo de instâncias gerenciadas

Você também pode verificar se as instâncias de um MIG podem participar automaticamente do seu domínio.

  1. Crie um modelo de instância passando o script specialize que faz com que a VM entre no domínio:

    VPC compartilhada 

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

    & 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 gerenciadas 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 use o snap-in dos usuários do Active Directory e o MMC de computadores para verificar se quatro novos objetos foram criados no Active Directory:

  • 3 contas de computador correspondentes às três instâncias de VM do grupo de instâncias gerenciadas.
  • 1 grupo chamado group-01 contendo as três contas de computador. Se você planeja usar contas de serviço gerenciadas de grupo (gMSA), pode usar esse grupo para conceder acesso ao gMSA.

Depois de verificar se as instâncias de VM de suas MIGs podem ingressar em seu domínio do Active Directory, é possível excluir o grupo gerenciado e o modelo de instância seguindo estas etapas:

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

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

  2. Exclua o modelo de instância:

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

Como programar a limpeza de contas de computador desatualizadas

Automatizar o processo de associação de computadores ao domínio reduz o esforço para configurar novos servidores e permite usar servidores associados a domínios em grupos de instâncias gerenciadas. No entanto, com o tempo, contas de computador desatualizadas podem se acumular no domínio.

Para evitar esse acúmulo, recomendamos que você configure o aplicativo register-computer para verificar periodicamente seu domínio do Active Directory para encontrar e remover contas desatualizadas automaticamente.

O aplicativo register-computer pode usar os atributos msDS-cloudExtensionAttribute das contas de computador para identificar quais contas estão desatualizadas. Esses atributos contêm o projeto, a zona e o nome da instância da VM correspondente no Compute Engine. Para cada conta de computador, o aplicativo pode verificar se a instância de VM correspondente ainda está disponível. Se não estiver, a conta do computador será considerada desatualizada e removida.

Para acionar uma limpeza de conta de computador, invoque o endpoint /cleanup do aplicativo Cloud Run. Para evitar que usuários não autorizados acionem uma limpeza, essa solicitação precisa ser autenticada usando a conta de serviço register-computer-app.

Configurar o Cloud Scheduler

As etapas a seguir mostram como configurar o Cloud Scheduler em conjunto com o Pub/Sub para acionar uma limpeza automaticamente a cada 24 horas:

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

    & gcloud services enable cloudscheduler.googleapis.com

  2. Definir AppEngineLocation para um local do App Engine para implantar o Cloud Scheduler:

    $AppEngineLocation = "location"

    Substitua location pela região do App Engine que você selecionou para seus recursos de VPC, por exemplo, us-central. Se essa região não estiver disponível como um local do App Engine, escolha um local geograficamente próximo a você. Para mais informações, consulte Regiões e zonas.

  3. Inicialize o Google App Engine:

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

  4. Crie um job 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

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

Acionar uma limpeza

Para verificar a configuração de limpeza de contas de computador desatualizadas, é possível acionar o job do Cloud Scheduler manualmente.

  1. No console do Google Cloud, acesse o Cloud Scheduler.

    Acessar o Cloud Scheduler

  2. Para o job cleanup-computer-accounts que você criou, clique em Executar agora.

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

Para mais detalhes sobre quais contas foram limpas, verifique os registros do aplicativo register-computer.

  1. No console do Google Cloud, acesse o Cloud Run.

    Acesse o Cloud Run

  2. Clique no aplicativo register-computer.

  3. No menu, clique em Registros.

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

Limpar

Se você estiver usando este documento como referência para outras arquiteturas de referência e implantações, leia os outros documentos sobre quando executar as etapas de limpeza.

Se não quiser manter a configuração do Google Cloud usada neste documento, reverta essa configuração fazendo o seguinte:

  1. No Cloud Shell, exclua o job do Cloud Scheduler:

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

  2. Exclua o aplicativo Cloud Run:

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

  3. Exclua o secret do Secret Manager:

    gcloud secrets delete ad-password --project $DomainProjectId

  4. Exclua 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 em que a VPC está definida. Se você usar uma VPC compartilhada, use o projeto host da VPC. Caso contrário, use o ID do projeto de domínio.

  5. Excluir o acesso VPC sem servidor:

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

Reverter alterações do Active Directory

  1. Usando um cliente RDP, faça login em uma máquina que tenha acesso administrativo ao seu domínio do Active Directory.
  2. No snap-in de usuários do Active Directory e MMC de computadores acesse a unidade organizacional Projects.
  3. Exclua a conta de usuário do Active Directory register-computer.
  4. Exclua a unidade organizacional que você criou para testar a associação automática de domínios.

A seguir