Compartilhar via

Configuração personalizada do Active Directory para o Azure Local, versão 23H2

  • Artigo

Aplica-se a: Azure Local, versão 23H2

Este artigo descreve as permissões e os registros DNS necessários para a implantação do Azure Local, versão 23H2. O artigo também usa exemplos com etapas detalhadas sobre como atribuir permissões manualmente e criar registros DNS para seu ambiente do Active Directory.

A solução local do Azure é implantada em grandes Active Directories com processos e ferramentas estabelecidos para atribuir permissões. A Microsoft fornece um script de preparação do Active Directory que pode ser usado opcionalmente para a implantação local do Azure. As permissões necessárias para o Active Directory, a criação da unidade organizacional e o bloqueio da herança de GPOs também podem ser configuradas manualmente.

Você também tem a opção do servidor DNS a ser usado, por exemplo, você pode usar servidores DNS da Microsoft que suportam a integração com o Active Directory para aproveitar as atualizações dinâmicas seguras. Se os servidores DNS da Microsoft não forem usados, você deverá criar um conjunto de registros DNS para a implantação e atualização da solução Local do Azure.

Sobre os requisitos do Active Directory

Aqui estão alguns dos requisitos do Active Directory para a implantação local do Azure.

  • Uma unidade organizacional (UO) dedicada é necessária para otimizar os tempos de consulta para a descoberta de objetos. Essa otimização é crítica para grandes Active Directories que abrangem vários sites. Essa UO dedicada só é necessária para os objetos de computador e o CNO do cluster de failover do Windows.

  • O usuário (também conhecido como usuário de implantação) requer as permissões necessárias na UO dedicada. O usuário pode residir em qualquer lugar do diretório.

  • O bloqueio da herança de diretiva de grupo é necessário para evitar conflitos de configurações provenientes de objetos de diretiva de grupo. O novo mecanismo introduzido com o Azure Local, versão 23H2, gerencia padrões de segurança, incluindo a proteção contra desvios. Para obter mais informações, consulte Recursos de segurança para o Azure Local, versão 23H2.

  • Os objetos de conta de computador e o cluster CNO podem ser pré-criados usando o usuário de implantação como uma alternativa à própria implantação que os cria.

Permissões necessárias

As permissões exigidas pelo objeto de usuário referenciado como usuário de implantação têm escopo para serem aplicáveis somente à UO dedicada. As permissões podem ser resumidas como ler, criar e excluir objetos de computador com a capacidade de recuperar informações de recuperação do BitLocker.

Aqui está uma tabela que contém as permissões necessárias para o usuário de implantação e o CNO do cluster sobre a UO e todos os objetos descendentes.

Função Descrição das permissões atribuídas
Usuário de implantação sobre UO e todos os objetos descendentes Listar conteúdo.
Leia todas as propriedades.
Permissões de leitura.
Crie objetos de computador.
Exclua objetos de computador.
Usuário de implantação sobre UO, mas aplicado apenas a objetos msFVE-Recoveryinformation descendentes Controle total.
Listar conteúdo.
Leia todas as propriedades.
Escreva todas as propriedades.
Delete.
Permissões de leitura.
Modifique as permissões.
Modifique o proprietário.
Todas as gravações validadas.
Agrupe o CNO sobre a UO aplicada a este objeto e a todos os objetos descendentes Leia todas as propriedades.
Crie objetos de computador.

Atribuir permissões usando o PowerShell

Você pode usar cmdlets do PowerShell para atribuir permissões apropriadas ao usuário de implantação na UO. O exemplo a seguir mostra como você pode atribuir as permissões necessárias a um deploymentuser na UO HCI001 que reside no domínio do Active Directory contoso.com.

Observação

O script exige que você pré-crie o objeto de usuário New-ADUser e a UO no Active Directory. Para obter mais informações sobre como bloquear a herança de política de grupo, consulte Set-GPInheritance.

Execute os seguintes cmdlets do PowerShell para importar o módulo do Active Directory e atribuir as permissões necessárias:

#Import required module
import-module ActiveDirectory

#Input parameters
$ouPath ="OU=HCI001,DC=contoso,DC=com"
$DeploymentUser="deploymentuser"

#Assign required permissions
$userSecurityIdentifier = Get-ADuser -Identity $Deploymentuser
$userSID = [System.Security.Principal.SecurityIdentifier] $userSecurityIdentifier.SID
$acl = Get-Acl -Path $ouPath
$userIdentityReference = [System.Security.Principal.IdentityReference] $userSID
$adRight = [System.DirectoryServices.ActiveDirectoryRights]::CreateChild -bor [System.DirectoryServices.ActiveDirectoryRights]::DeleteChild
$genericAllRight = [System.DirectoryServices.ActiveDirectoryRights]::GenericAll
$readPropertyRight = [System.DirectoryServices.ActiveDirectoryRights]::ReadProperty
$type = [System.Security.AccessControl.AccessControlType]::Allow 
$inheritanceType = [System.DirectoryServices.ActiveDirectorySecurityInheritance]::All 
$allObjectType = [System.Guid]::Empty

#Set computers object GUID, this is a well-known ID
$computersObjectType = [System.Guid]::New('bf967a86-0de6-11d0-a285-00aa003049e2')

#Set msFVE-RecoveryInformation GUID,this is a well-known ID
$msfveRecoveryGuid = [System.Guid]::New('ea715d30-8f53-40d0-bd1e-6109186d782c')
$rule1 = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($userIdentityReference, $adRight, $type, $computersObjectType, $inheritanceType)
$rule2 = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($userIdentityReference, $readPropertyRight, $type, $allObjectType , $inheritanceType)
$rule3 = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($userIdentityReference, $genericAllRight, $type, $inheritanceType, $msfveRecoveryGuid)
$acl.AddAccessRule($rule1)
$acl.AddAccessRule($rule2)
$acl.AddAccessRule($rule3)
Set-Acl -Path $ouPath -AclObject $acl

Registros DNS necessários

Se o servidor DNS não der suporte a atualizações dinâmicas seguras, você deverá criar os registros DNS necessários antes de implantar o sistema local do Azure.

A tabela a seguir contém os registros e tipos de DNS necessários:

Objeto Tipo
Nome do computador Anfitrião A
Cluster CNO Anfitrião A
Cluster VCO Anfitrião A

Observação

Cada computador que se torna parte do sistema local do Azure requer um registro DNS.

Exemplo - verifique se o registro DNS existe

Para verificar se o registro DNS existe, execute o seguinte comando:

nslookup "machine name"

Namespace não contíguo

Um namespace não contíguo ocorre quando o sufixo DNS primário de um ou mais computadores membros do domínio não corresponde ao nome DNS do domínio do Active Directory. Por exemplo, se um computador tiver um nome DNS de corp.contoso.com mas fizer parte de um domínio do Active Directory chamado na.corp.contoso.com, ele estará usando um namespace não contíguo.

Antes de implantar o Azure Local, versão 23H2, você deve:

  • Anexe o sufixo DNS ao adaptador de gerenciamento de cada nó.
  • Verifique se você pode resolver o nome do host para o FQDN do Active Directory.

Exemplo - anexar o sufixo DNS

Para acrescentar o sufixo DNS, execute o seguinte comando:

Set-DnsClient -InterfaceIndex 12 -ConnectionSpecificSuffix "na.corp.contoso.com"

Exemplo - resolver o nome do host para o FQDN

Para resolver o nome do host para o FQDN, execute o seguinte comando:

nslookup node1.na.corp.contoso.com

Observação

Você não pode usar políticas de grupo para configurar a lista de sufixos DNS com o Azure Local, versão 23H2.

CAU (Atualização com reconhecimento de cluster)

A atualização com reconhecimento de cluster aplica um ponto de acesso do cliente (Objeto de Computador Virtual) que requer um registro DNS.

Em ambientes em que as atualizações dinâmicas seguras não são possíveis, é necessário criar manualmente o VCO (Objeto de Computador Virtual). Para obter mais informações sobre como criar o VCO, consulte Pré-configurar objetos de computador de cluster nos Serviços de Domínio Active Directory.

Observação

Certifique-se de desabilitar a atualização de DNS dinâmico no cliente DNS do Windows. Essa configuração é protegida pelo controle de descompasso e é incorporada à ATC de Rede. Crie o VCO imediatamente após desabilitar as atualizações dinâmicas para evitar a reversão de desvios. Para obter mais informações sobre como alterar essa configuração protegida, consulte Modificar padrões de segurança.

Exemplo – desabilitar atualização dinâmica

Para desativar a atualização dinâmica, execute o seguinte comando:

Get-NetAdapter "vManagement*"|Set-DnsClient -RegisterThisConnectionsAddress $false

Próximas etapas

Prossiga para: