Compartir a través de

Configuración personalizada de Active Directory para Azure Local, versión 23H2

  • Artículo

Se aplica a: Azure Local, versión 23H2

En este artículo se describen los permisos y los registros DNS necesarios para la implementación de Azure Local, versión 23H2. En el artículo también se usan ejemplos con pasos detallados sobre cómo asignar manualmente permisos y crear registros DNS para el entorno de Active Directory.

La solución Azure Local se implementa en directorios activos grandes con procesos y herramientas establecidos para asignar permisos. Microsoft proporciona un script de preparación de Active Directory que se puede usar opcionalmente para la implementación local de Azure. Los permisos necesarios para Active Directory, la creación de la unidad organizativa y la herencia de bloqueo de GPO, también se pueden configurar manualmente.

También tiene la opción del servidor DNS que se va a usar, por ejemplo, puede usar servidores DNS de Microsoft que admitan la integración con Active Directory para aprovechar las ventajas de las actualizaciones dinámicas seguras. Si no se usan servidores DNS de Microsoft, debe crear un conjunto de registros DNS para la implementación y actualización de la solución Local de Azure.

Acerca de los requisitos de Active Directory

Estos son algunos de los requisitos de Active Directory para la implementación local de Azure.

  • Se requiere una unidad organizativa dedicada para optimizar los tiempos de consulta para la detección de objetos. Esta optimización es fundamental para los directorios activos de gran tamaño que abarcan varios sitios. Esta unidad organizativa dedicada solo es necesaria para los objetos de equipo y el CNO del clúster de conmutación por error de Windows.

  • El usuario (también conocido como usuario de implementación) requiere los permisos necesarios sobre la unidad organizativa dedicada. El usuario puede residir en cualquier parte del directorio.

  • Es necesario bloquear la herencia de directivas de grupo para evitar conflictos de configuración procedentes de objetos de directiva de grupo. El nuevo motor introducido con Azure Local, versión 23H2, administra los valores predeterminados de seguridad, incluida la protección contra desfase. Para más información, consulte Características de seguridad para Azure Local, versión 23H2.

  • Los objetos de cuenta de equipo y el CNO del clúster se pueden crear previamente mediante el usuario de implementación como alternativa a la propia implementación que los crea.

Permisos necesarios

Los permisos requeridos por el objeto de usuario al que se hace referencia como usuario de implementación se limitan a ser aplicables solo a la unidad organizativa dedicada. Los permisos se pueden resumir como de lectura, creación y eliminación de objetos de equipo con la capacidad de recuperar información de recuperación de BitLocker.

Esta es una tabla que contiene los permisos necesarios para el usuario de implementación y el CNO del clúster sobre la unidad organizativa y todos los objetos descendientes.

Role Descripción de los permisos asignados
Usuario de implementación sobre la unidad organizativa y todos los objetos descendientes Contenido de la lista.
Lee todas las propiedades.
Permisos de lectura.
Crear objetos de equipo.
Eliminar objetos de equipo.
Usuario de implementación a través de unidad organizativa, pero aplicado solo a objetos msFVE-Recoveryinformation descendientes Control total.
Contenido de la lista.
Lee todas las propiedades.
Escriba todas las propiedades.
Eliminar.
Permisos de lectura.
Modificar permisos.
Modificar propietario.
Todas las escrituras validadas.
CNO del clúster a través de la unidad organizativa aplicada a este objeto y a todos los objetos descendientes Lee todas las propiedades.
Crear objetos Computer.

Asignación de permisos mediante PowerShell

Puede usar cmdlets de PowerShell para asignar los permisos adecuados para la implementación del usuario a través de la unidad organizativa. En el ejemplo siguiente se muestra cómo se pueden asignar los permisos necesarios a un usuario de implementación a través de la unidad organizativa HCI001 que reside en el dominio de Active Directory contoso.com.

Nota:

El script requiere que cree previamente el objeto de usuario New-ADUser y la unidad organizativa en Active Directory. Para obtener más información sobre cómo bloquear la herencia de directivas de grupo, consulte Set-GPInheritance.

Ejecute los siguientes cmdlets de PowerShell para importar el módulo de Active Directory y asignar los permisos necesarios:

#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 necesarios

Si el servidor DNS no admite actualizaciones dinámicas seguras, debe crear registros DNS necesarios antes de implementar el sistema local de Azure.

La tabla siguiente contiene los tipos y registros DNS necesarios:

Object Tipo
Nombre de equipo Host A
CNO del clúster Host A
VCO de clúster Host A

Nota:

Cada máquina que se convierte en parte del sistema local de Azure requiere un registro DNS.

Ejemplo: comprobación de que existe un registro DNS

Para comprobar que el registro DNS existe, ejecute el siguiente comando:

nslookup "machine name"

Espacio de nombres separado

Un espacio de nombres separado se produce cuando el sufijo DNS principal de uno o varios equipos miembros del dominio no coincide con el nombre DNS de su dominio de Active Directory. Por ejemplo, si un equipo tiene un nombre DNS de corp.contoso.com, pero forma parte de un dominio de Active Directory denominado na.corp.contoso.com, usa un espacio de nombres separado.

Antes de implementar Azure Local, versión 23H2, debe:

  • Anexe el sufijo DNS al adaptador de administración de cada nodo.
  • Compruebe que puede resolver el nombre de host en el FQDN de Active Directory.

Ejemplo: anexar el sufijo DNS

Para anexar el sufijo DNS, ejecute el siguiente comando:

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

Ejemplo: resolución del nombre de host en el FQDN

Para resolver el nombre de host en el FQDN, ejecute el siguiente comando:

nslookup node1.na.corp.contoso.com

Nota:

No puede usar directivas de grupo para configurar la lista de sufijos DNS con Azure Local, versión 23H2.

Actualización con reconocimiento del clúster (CAU)

La actualización compatible con clústeres aplica un punto de acceso de cliente (objeto de equipo virtual) que requiere un registro DNS.

En entornos en los que no es posible realizar actualizaciones seguras dinámicas, es necesario crear manualmente el objeto de equipo virtual (VCO). Para obtener más información sobre cómo crear el VCO, consulte Preconfigurar objetos de equipo de clúster en Servicios de dominio de Active Directory.

Nota:

Asegúrese de deshabilitar la actualización dinámica de DNS en el cliente DNS de Windows. Esta configuración está protegida por el control de desfase y está integrada en network ATC. Cree el VCO inmediatamente después de deshabilitar las actualizaciones dinámicas para evitar la reversión del desfase. Para obtener más información sobre cómo cambiar esta configuración protegida, consulte Modificación de los valores predeterminados de seguridad.

Ejemplo: deshabilitar la actualización dinámica

Para deshabilitar la actualización dinámica, ejecute el siguiente comando:

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

Pasos siguientes

Continúe con: