Partilhar via

Configuração personalizada do Ative 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 Ative Directory.

A solução Azure Local é implantada em grandes Diretórios Ativos com processos e ferramentas estabelecidos para atribuir permissões. A Microsoft fornece um script de preparação do Ative Directory que pode ser usado opcionalmente para a implantação Local do Azure. As permissões necessárias para o Ative 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 Ative 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 Ative Directory

Aqui estão alguns dos requisitos do Ative Directory para a implantação Local do Azure.

  • Uma unidade organizacional dedicada (UO) é necessária para otimizar os tempos de consulta para a descoberta de objetos. Essa otimização é crítica para grandes diretórios ativos que abrangem vários locais. 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 sobre a UO dedicada. O usuário pode residir em qualquer lugar no 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 desvio. 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 CNO de cluster podem ser pré-criados usando o usuário de implantação como uma alternativa à própria implantação que os cria.

Permissões obrigatórias

As permissões exigidas pelo objeto de usuário referenciado como usuário de implantação têm como escopo ser 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 cluster CNO sobre a UO e todos os objetos descendentes.

Role Descrição das permissões atribuídas
Usuário de implantação sobre UO e todos os objetos descendentes Listar conteúdos.
Leia todas as propriedades.
Permissões de leitura.
Crie objetos de computador.
Excluir objetos de computador.
Usuário de implantação sobre UO, mas aplicado somente a objetos msFVE-Recoveryinformation descendentes Controlo Completo.
Listar conteúdos.
Leia todas as propriedades.
Escreva todas as propriedades.
Eliminar.
Permissões de leitura.
Modificar permissões.
Modificar proprietário.
Todas as gravações validadas.
CNO de cluster sobre a UO aplicada a este objeto e a todos os objetos descendentes Leia todas as propriedades.
Criar 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 pela UO. O exemplo a seguir mostra como você pode atribuir as permissões necessárias a um usuário de implantação sobre a UO HCI001 que reside na contoso.com de domínio do Ative Directory.

Nota

O script requer que você pré-crie o objeto de usuário New-ADUser e OU no Ative Directory. Para obter mais informações sobre como bloquear a herança de diretiva de grupo, consulte Set-GPInheritance.

Execute os seguintes cmdlets do PowerShell para importar o módulo Ative 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

Registos DNS necessários

Se o seu servidor DNS não suportar atualizações dinâmicas seguras, tem de criar os registos DNS necessários antes de implementar o seu sistema Local do Azure.

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

Object Type
Nome da máquina Anfitrião A
Cluster CNO Anfitrião A
Cluster VCO Anfitrião A

Nota

Cada máquina 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 separado

Um namespace separado 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 Ative Directory. Por exemplo, se um computador tiver um nome DNS de corp.contoso.com mas fizer parte de um domínio do Ative Directory chamado na.corp.contoso.com, ele está usando um namespace separado.

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 Ative 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 - resolva 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

Nota

Não é possível usar políticas de grupo para configurar a lista de sufixos DNS com o Azure Local, versão 23H2.

Atualização com reconhecimento de cluster (CAU)

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

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

Nota

Certifique-se de desativar a atualização de DNS dinâmico no cliente DNS do Windows. Esta definição está protegida pelo controlo de desvio e está incorporada no ATC de rede. Crie o VCO imediatamente após desativar as atualizações dinâmicas para evitar a reversão de desvio. Para obter mais informações sobre como alterar essa configuração protegida, consulte Modificar padrões de segurança.

Exemplo – desativar a atualização dinâmica

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

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

Próximos passos

Prossiga para: