Paso 1 Planear la infraestructura de DirectAccess

Artículo
08/30/2023

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

El primer paso a la hora de planear la implementación de acceso remoto en un único servidor consiste en prever la infraestructura necesaria para dicha implementación. En este tema se describen los pasos para la planificación de la infraestructura:

Tarea	Descripción
Planear la topología de red y la configuración	Decide dónde colocar el servidor de acceso remoto (en el perímetro, detrás de un firewall o detrás de un dispositivo de traducción de direcciones de red [NAT]), y planea el direccionamiento IP y el enrutamiento.
Planear requisitos de firewall	Planea la configuración de los firewalls perimetrales para permitir el paso de tráfico de Acceso remoto.
Planear requisitos de certificados	Acceso remoto puede usar Kerberos o certificados para la autenticación de clientes. En esta implementación básica de acceso remoto, Kerberos se configura automáticamente y la autenticación se realiza con un certificado autofirmado emitido automáticamente por el servidor de acceso remoto.
Planear los requisitos de DNS	Planea la configuración de DNS para el servidor de acceso remoto, los servidores de infraestructura, las opciones de resolución local de nombres y la conectividad de clientes.
Planear Active Directory	Planea los requisitos de los controladores de dominio y de Active Directory.
Planear objetos de directiva de grupo	Decide qué GPO se necesitan en tu organización y cómo crearlos o editarlos.

No es necesario completar las tareas de planificación en un orden específico.

Planear la topología de red y la configuración

Planear los adaptadores de red y el direccionamiento IP

Identifica la topología de adaptadores de red que quieres usar. El acceso remoto se puede configurar de las siguientes maneras:
- Con dos adaptadores de red: uno en el borde con un adaptador de red conectado a Internet y el otro a la red interna, o bien detrás de un NAT, un firewall o un dispositivo enrutador, con un adaptador de red conectado a una red perimetral y el otro a la red interna.
- Detrás de un dispositivo NAT con un adaptador de red: el servidor de Acceso remoto se instala detrás de un dispositivo NAT y el único adaptador de red se conecta a la red interna.
Identifica tus requisitos de direccionamiento IP:

DirectAccess usa IPv6 con IPsec para crear una conexión segura entre los equipos cliente de DirectAccess y la red corporativa interna. Sin embargo, DirectAccess no requiere necesariamente conectividad con Internet IPv6 ni compatibilidad nativa con IPv6 en las redes internas. En su lugar, configura y usa automáticamente tecnologías de transición IPv6 para tunelizar el tráfico IPv6 a través de Internet IPv4 (6to4, Teredo, IP-HTTPS) y a través de la intranet solo IPv4 (mediante NAT64 o ISATAP). Para obtener información general acerca de estas tecnologías de transición, consulta los siguientes recursos:
- Tecnologías de transición IPv6
- Especificación del protocolo de túnel IP-HTTPS

Configura los adaptadores y el direccionamiento obligatorios según la tabla siguiente. Para implementaciones detrás de un dispositivo NAT que usen un solo adaptador de red, configure las direcciones IP para que usen únicamente la columna "Adaptador de red interno".

Tipo de dirección IP	Adaptador de red externo	Adaptador de red interno	Requisitos de enrutamiento
Intranet IPv4 e Internet IPv4	Configurar lo siguiente: - Una dirección IPv4 pública estática con las máscaras de subred adecuadas. - Una dirección IPv4 de puerta de enlace predeterminada del firewall de Internet o del enrutador del proveedor de servicios de Internet (ISP) local.	Configurar lo siguiente: - Una dirección IPv4 de intranet con la máscara de subred adecuada. - Un sufijo DNS específico de la conexión del espacio de nombres de la intranet. También se debe configurar el servidor DNS en la interfaz interna. - No configure ninguna puerta de enlace predeterminada en ninguna interfaz de la intranet.	Para configurar el servidor de acceso remoto de manera que tenga acceso a todas las subredes de la red IPv4 interna, haz lo siguiente: 1. Enumere los espacios de direcciones IPv4 para todas las ubicaciones de la intranet. 2. Use los comandos route add -p o netsh interface ipv4 add route para agregar los espacios de direcciones IPv4 como rutas estáticas a la tabla de enrutamiento IPv4 del servidor de Acceso remoto.
Internet IPv6 e intranet IPv6	Configurar lo siguiente: - Use la configuración de direcciones automática proporcionada por su ISP. - Use el comando route print para comprobar que en la tabla de enrutamiento IPv6 existe una ruta IPv6 predeterminada que apunte al enrutador del ISP. - Determine si los enrutadores del ISP y de la intranet usan las preferencias predeterminadas del enrutador descritas en RFC 4191 y si usan unas preferencias predeterminadas superiores a las de los enrutadores de la intranet local. Si ambas condiciones se cumplen, no se necesita ninguna otra configuración para la ruta predeterminada. La preferencia mayor para el enrutador del ISP asegura que la ruta IPv6 predeterminada activa del servidor de acceso remoto apunta a Internet IPv6. Como el servidor de acceso remoto es un enrutador IPv6, si tienes una infraestructura IPv6 nativa, la interfaz de Internet también puede tener acceso a los controladores de dominio de la intranet. En este caso, agrega filtros de paquetes al controlador de dominio de la red perimetral que impidan que el servidor de acceso remoto conecte con la dirección IPv6 de la interfaz accesible desde Internet.	Configurar lo siguiente: - Si no usa los niveles de preferencia predeterminados, configure las interfaces de la intranet con el comando netsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabled. Este comando garantiza que las rutas predeterminadas adicionales que señalen a enrutadores de la intranet no se agregarán a la tabla de enrutamiento IPv6. Para conocer el índice de las interfaces de la intranet, usa el comando “netsh interface show interface”.	Si la intranet es IPv6, haz lo siguiente para configurar el servidor de acceso remoto para que tenga acceso a todas las ubicaciones IPv6: 1. Enumere los espacios de direcciones IPv6 para todas las ubicaciones de la intranet. 2. Usa el comando netsh interface ipv6 add route para agregar los espacios de direcciones IPv6 como rutas estáticas a la tabla de enrutamiento IPv6 del servidor de Acceso remoto.
Internet IPv6 e intranet IPv4	El servidor de acceso remoto reenvía el tráfico de la ruta IPv6 predeterminada a través del Adaptador 6to4 de Microsoft con una retransmisión 6to4 en Internet por IPv4. Puedes configurar un servidor de acceso remoto para la dirección IPv4 de la retransmisión 6to4 de Microsoft en Internet IPv4 (se usa cuando no hay implementado IPv6 nativo en la red corporativa) con el comando netsh interface ipv6 6to4 set relay name=192.88.99.1 state=enabled.

Nota

Si se ha asignado una dirección IPv4 pública al cliente de DirectAccess, este usará la tecnología de transición 6to4 para conectarse a la intranet. Si el cliente de DirectAccess no puede conectarse al servidor de DirectAccess mediante 6to4, usará IP-HTTPS.
Los equipos cliente IPv6 nativos pueden conectarse al servidor de acceso remoto a través de IPv6 nativo, y no se necesita ninguna tecnología de transición.

Planear requisitos de firewall

Si el servidor de acceso remoto está detrás de un firewall perimetral, se necesitan las siguientes excepciones para el tráfico de acceso remoto cuando el servidor de acceso remoto se encuentre en Internet IPv4:

Tráfico 6to4: protocolo IP 41 de entrada y de salida.
IP-HTTPS: puerto de destino 443 del protocolo de control de transmisión (TCP) y puerto de origen TCP 443 de salida.
Si implementas el acceso remoto con un único adaptador de red y lo instalas en el servidor de ubicación de red en el servidor de acceso remoto, también deberás agregar el puerto TCP 62000 a las excepciones.

Se necesitarán las siguientes excepciones para el tráfico de acceso remoto cuando el servidor de acceso remoto se encuentre en Internet IPv6:

Protocolo IP 50
Puerto de destino UDP 500 de entrada y puerto de origen UDP 500 de salida.

Si usa firewalls adicionales, aplique las siguientes excepciones de firewall de la red interna para el tráfico de acceso remoto:

ISATAP: protocolo 41 de entrada y de salida
TCP/UDP para todo el tráfico IPv4/IPv6

Planear requisitos de certificados

Entre los requisitos de certificados para IPsec se incluye un certificado de equipo que los equipos cliente de DirectAccess usan al establecer la conexión IPsec entre el cliente y el servidor de acceso remoto, y un certificado de equipo que los servidores de acceso remoto usan para establecer conexiones IPsec con los clientes de DirectAccess. Para DirectAccess en Windows Server 2012 no es obligatorio usar estos certificados IPsec. El Asistente para habilitar DirectAccess configura el servidor de acceso remoto para que actúe como proxy Kerberos a fin de realizar la autenticación de IPsec sin necesidad de certificados.

Servidor IP-HTTPS: cuando se configura Acceso remoto, el servidor de Acceso remoto se configura automáticamente para que actúe como agente de escucha web de IP-HTTPS. El sitio IP-HTTPS requiere un certificado de sitio web y los equipos cliente deben poder ponerse en contacto con el sitio de la lista de revocación de certificados (CRL) para consultar el certificado. El Asistente para habilitar DirectAccess intenta usar el certificado SSTP de VPN. Si SSTP no está configurado, comprueba si en el almacén personal del equipo hay un certificado para IP-HTTPS. Si no hay ninguno disponible, crea automáticamente un certificado autofirmado.
Servidor de ubicación de red: el servidor de ubicación de red es un sitio web usado para detectar si los equipos cliente están ubicados en la red corporativa. El servidor de ubicación de red requiere un certificado de sitio web. Los clientes de DirectAccess tienen que poder contactar con el sitio de la CRL para obtener el certificado. El Asistente para habilitar DirectAccess comprueba si hay un servidor de ubicación de red en el almacén personal de la máquina. Si no hay ninguno, creará automáticamente un certificado autofirmado.

En la tabla siguiente encontrarás un resumen de los requisitos de certificación para cada uno de estos:

Autenticación IPsec	Servidor IP-HTTPS	Servidor de ubicación de red
Se requiere una entidad de certificación (CA) interna que emita certificados de equipo tanto al servidor como a los clientes de Acceso remoto para la autenticación IPsec cuando no se use el proxy Kerberos para la autenticación.	Entidad de certificación pública: se recomienda usar una entidad de certificación pública para emitir el certificado IP-HTTPS, ya que esto garantiza que el punto de distribución de CRL esté disponible externamente.	Entidad de certificación interna: puede usar una entidad de certificación interna para emitir el certificado de sitio web del servidor de ubicación de red. Asegúrate de que el punto de distribución de CRL tenga alta disponibilidad desde la red interna.
	Entidad de certificación interna: puede usar una entidad de certificación interna para emitir el certificado IP-HTTPS, pero debe asegurarse de que el punto de distribución de CRL esté disponible externamente.	Certificado autofirmado: puede usar un certificado autofirmado para el sitio web del servidor de ubicación de red, pero no puede usarlo en implementaciones multisitio.
	Certificado autofirmado: puede usar un certificado autofirmado para el servidor de IP-HTTPS, pero debe asegurarse de que el punto de distribución de CRL está disponible externamente. Los certificados autofirmados no se pueden usar en implementaciones multisitio.

Planear certificados para IP-HTTPS

El servidor de acceso remoto actúa como agente de escucha de IP-HTTPS y tienes que instalar manualmente un certificado de sitio web HTTPS en el servidor. A la hora de planear, ten en cuenta lo siguiente:

Se recomienda usar una entidad de certificación pública para que haya CRL disponibles.
En el campo de sujeto, especifica la dirección IPv4 del adaptador de Internet del servidor de acceso remoto o el FQDN de la dirección URL de IP-HTTPS (la dirección ConnectTo). Si el servidor de acceso remoto está ubicado detrás de un dispositivo NAT, hay que especificar el nombre público o la dirección del dispositivo NAT.
El nombre común del certificado debe coincidir con el nombre del sitio IP-HTTPS.
En el campo Uso mejorado de clave, use el identificador de objeto (OID) de Autenticación de servidor.
En el campo Puntos de distribución CRL, especifique un punto de distribución CRL al que puedan obtener acceso los clientes de DirectAccess que estén conectados a Internet.
El certificado IP-HTTPS debe tener una clave privada.
El certificado IP-HTTPS se debe importar directamente al almacén personal.
Los nombres de certificado IP-HTTPS pueden contener comodines.

Planear certificados de sitio web para el servidor de ubicación de red

A la hora de planear el sitio web del servidor de ubicación de red, ten en cuenta lo siguiente:

En el campo Asunto, especifica una dirección IP de la interfaz de intranet del servidor de ubicación de red o el FQDN de la dirección URL de la ubicación de red.
Para el campo Uso mejorado de clave, usa el OID Autenticación de servidor.
Para el campo Puntos de distribución CRL, un punto de distribución de CRL que sea accesible por los clientes de DirectAccess que están conectados a la intranet. Este punto de distribución CRL no debe ser accesible desde fuera de la red interna.
Si más adelante tienes previsto configurar una implementación multisitio o en clúster, el nombre del certificado no debe coincidir con el nombre interno del servidor de acceso remoto.

Nota

Asegúrate de que los certificados de IP-HTTPS y el servidor de ubicación de red tengan un Nombre de sujeto. Si el certificado no tiene un Nombre e sujeto sino que tiene un Nombre alternativo, el Asistente para acceso remoto no lo aceptará.

Planear los requisitos de DNS

En una implementación de acceso remoto, se necesita DNS para lo siguiente:

Solicitudes de clientes de DirectAccess: DNS se usa para resolver las solicitudes de los equipos cliente de DirectAccess que no se encuentren en la red interna. Los clientes de DirectAccess intentan conectarse al servidor de ubicación de red de DirectAccess para determinar si se encuentran en Internet o en la red corporativa: si la conexión se establece correctamente, se determinará que los clientes están en la intranet, por lo que no se usará DirectAccess y las solicitudes de clientes se resolverán mediante el servidor DNS configurado en el adaptador de red del equipo cliente. Si se producen errores de conexión, se da por hecho que los clientes están en Internet. Los clientes de DirectAccess usarán la tabla de directivas de resolución de nombres (NRPT) para determinar el servidor DNS que usarán para resolver solicitudes de nombres. Puedes especificar que los clientes tengan que usar DNS64 de DirectAccess para resolver nombres, o bien un servidor DNS interno alternativo. Para llevar a cabo la resolución de nombres, los clientes de DirectAccess usan la tabla NRPT para identificar cómo gestionar una solicitud. Los clientes solicitan un nombre de dominio completo o un nombre de etiqueta única como https://internal. Si se solicita un nombre de etiqueta única, se anexa un sufijo DNS para crear un FQDN. Si la consulta DNS coincide con una entrada de la NRPT y se especifica DNS4 o un servidor DNS de intranet para la entrada, la consulta para la resolución de nombres se enviará mediante el servidor especificado. Si existe una coincidencia pero no se especifica ningún servidor DNS, esto indica una regla de exención y se aplicará la resolución de nombres normal.

Ten en cuenta que cuando se agrega un nuevo sufijo a la tabla NRPT en la consola Administración de acceso remoto, los servidores DNS predeterminados para el sufijo se pueden detectar automáticamente haciendo clic en el botón Detectar. La detección automática funciona de la siguiente manera:
1. Si la red corporativa se basa en IPv4 o usa IPv4 e IPv6, la dirección predeterminada es la dirección DNS64 del adaptador interno en el servidor de acceso remoto.
2. Si la red corporativa se basa en IPv6, la dirección predeterminada es la dirección IPv6 de los servidores DNS en la red corporativa.
Servidores de infraestructura
1. Servidor de ubicación de red: los clientes de DirectAccess intentan contactar con el servidor de ubicación de red para determinar si se encuentran en la red interna. Los clientes de la red interna deben ser capaces de resolver el nombre del servidor de ubicación de red, pero debe evitarse que resuelvan el nombre si se encuentran en Internet. Para que esto suceda, de manera predeterminada, el FQDN del servidor de ubicación de red se agregará como una regla de exención a la NRPT. Además, cuando se configura el acceso remoto, se crean automáticamente las siguientes reglas:
  1. Una regla de sufijo DNS para el dominio raíz o el nombre de dominio del servidor de acceso remoto y las direcciones IPv6 correspondientes a los servidores DNS de la intranet configurados en el servidor de acceso remoto. Por ejemplo, si el servidor de acceso remoto es miembro del dominio corp.contoso.com, se crea una regla para el sufijo DNS .corp.contoso.com.
  2. Una regla de exención para el FQDN del servidor de ubicación de red. Por ejemplo, si la dirección URL del servidor de ubicación de red es https://nls.corp.contoso.com, se crea una regla de exención para el nombre de dominio completo nls.corp.contoso.com.
  Servidor de IP-HTTPS: el servidor de Acceso remoto actúa como agente de escucha de IP-HTTPS y usa su certificado de servidor para autenticarse en los clientes de IP-HTTPS. Los clientes de DirectAccess que usan servidores DNS públicos deben poder resolver el nombre IP-HTTPS.
  
  Comprobadores de conectividad: Acceso remoto crea un sondeo web predeterminado que los equipos cliente de DirectAccess usan para comprobar la conectividad con la red interna. Para comprobar si el sondeo funciona correctamente es necesario registrar de forma manual los nombres siguientes en DNS:
  1. directaccess-webprobehost debe resolverse en la dirección IPv4 interna del servidor de Acceso remoto o la dirección IPv6 en un entorno de solo IPv6.
  2. directaccess-corpconnectivityhost: debe resolverse en la dirección de host local (bucle invertido). Es necesario crear un registro A y un registro AAAA: el registro A con el valor 127.0.0.1 y el registro AAAA con el valor compuesto a partir del prefijo NAT64 con los últimos 32 bits como 127.0.0.1. El prefijo NAT64 se puede recuperar si se ejecuta el cmdlet get-netnattransitionconfiguration.
    
    Nota
    
    Esto solo es válido en un entorno de solo IPv4. En un entorno de IPv4+IPv6 o en un entorno de solo IPv6, solo se debe crear un registro AAAA con la dirección IP de bucle invertido ::1.
  Se pueden crear comprobadores de conectividad adicionales con otras direcciones web a través de HTTP o PING. Debe existir una entrada DNS por cada comprobador de conectividad.

Requisitos del servidor DNS

En el caso de los clientes de DirectAccess, se debe usar un servidor DNS que use Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 o cualquier servidor DNS que admita IPv6.

Planear Active Directory

Acceso remoto usa Active Directory y los objetos de directiva de grupo de Active Directory como se indica a continuación:

Autenticación: Para la autenticación se usa Active Directory. El túnel de intranet usa la autenticación Kerberos para que el usuario acceda a los recursos internos.
Objetos de directiva de grupo: Acceso remoto recopila las opciones de configuración en los objetos de directiva de grupo que se aplican a los servidores, clientes y servidores de aplicaciones internos de Acceso remoto.
Grupos de seguridad: Acceso remoto usa grupos de seguridad para recopilar e identificar equipos cliente de DirectAccess y servidores de Acceso remoto. Las directivas de grupo se aplican en el grupo de seguridad correspondiente.
Directivas IPsec extendidas: Acceso remoto puede usar cifrado y autenticación IPsec entre los clientes y el servidor de Acceso remoto. Puedes extender el cifrado y la autenticación IPsec a los servidores de aplicaciones internos especificados.

Requisitos de Active Directory

A la hora de planear Active Directory para una implementación de acceso remoto, se necesita lo siguiente:

Al menos un controlador de dominio instalado en los sistemas operativos Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 o Windows Server 2003.

Si el controlador de dominio está en una red perimetral (y, por lo tanto, es accesible desde el adaptador de red con conexión a Internet del servidor de acceso remoto), impide que el servidor de acceso remoto acceda a él; para ello, agrega filtros de paquetes al controlador de dominio para impedir que el adaptador de Internet conecte con la dirección IP.
El servidor de acceso remoto debe ser un miembro del dominio.
Los clientes de DirectAccess deben ser miembros del dominio. Los clientes pueden pertenecer a:
- Cualquier dominio del mismo bosque que el servidor de acceso remoto.
- Cualquier dominio que tenga una confianza bidireccional con el dominio del servidor de acceso remoto.
- Cualquier dominio de un bosque que tenga una confianza bidireccional con el bosque al que pertenece el dominio de acceso remoto.

Nota

El servidor de acceso remoto no puede ser un controlador de dominio.
El controlador de dominio de Active Directory que se usa para acceso remoto no debe ser accesible desde el adaptador de Internet externo del servidor de acceso remoto (el adaptador no debe estar en el perfil de dominio del Firewall de Windows).

Planear objetos de directiva de grupo

La configuración de DirectAccess se lleva a cabo al configurar el acceso remoto y se recopila en objetos de directiva de grupo (GPO). Se rellenan tres tipos de GPO diferentes con las opciones de configuración de DirectAccess, y se distribuyen como sigue:

GPO de cliente de DirectAccess: este GPO contiene la configuración del cliente, incluidos los ajustes de la tecnología de transición IPv6, las entradas de NRPT y las reglas de seguridad de conexión del Firewall de Windows con seguridad avanzada. El GPO se aplica a los grupos de seguridad especificados para los equipos cliente.
GPO de servidor de DirectAccess: este GPO contiene la configuración de DirectAccess que se aplica a cualquier servidor configurado como servidor de Acceso remoto en la implementación. Asimismo, contiene las reglas de seguridad de conexión del Firewall de Windows con seguridad avanzada.
GPO de servidores de aplicaciones: este GPO contiene la configuración de los servidores de aplicación seleccionados, a los que opcionalmente se extienden la autenticación y el cifrado de los clientes de DirectAccess. Si la autenticación y el cifrado no están extendidos, no se usa este GPO.

El Asistente para habilitar DirectAccess crea automáticamente los GPO y se especifica un nombre predeterminado para cada GPO.

Precaución

Siga el procedimiento que se indica a continuación para realizar una copia de seguridad de todos los objetos de directiva de grupo de Acceso remoto antes de ejecutar los cmdlets de DirectAccess: Copia de seguridad y restauración de la configuración de Acceso remoto.

Los GPO se pueden configurar de dos maneras:

Automáticamente: se puede especificar que se creen automáticamente. Se especifica un nombre predeterminado para cada GPO.
Manualmente: se pueden usar los GPO predefinidos por el administrador de Active Directory.

Ten en cuenta que, después de configurar DirectAccess para que use unos GPO específicos, no se puede configurar para que use otros GPO.

GPO creados automáticamente

Ten en cuenta lo siguiente al usar GPO creados automáticamente:

Los GPO creados automáticamente se aplican según los parámetros de ubicación y destino del vínculo, de la siguiente manera:

Para el GPO de servidor de DirectAccess, los parámetros de ubicación y de vínculo apuntan al dominio que contiene el servidor de acceso remoto.
Cuando se crean los GPO de cliente, la ubicación se establece para un solo dominio donde se crea el GPO. El nombre del GPO se busca en cada dominio y se rellena con opciones de configuración de DirectAccess (si existen). El destino del vínculo se establece en la raíz del dominio donde se creó el GPO. Se crea un GPO para cada dominio que contiene equipos cliente o servidores de aplicación, y el GPO se vincula a la raíz de su dominio respectivo.

Cuando se usan GPO creados automáticamente para aplicar la configuración de DirectAccess, el administrador del servidor de acceso remoto requiere los siguientes permisos:

Permisos de creación de GPO para cada dominio.
Permisos de vinculación para todas las raíces de dominios de clientes seleccionadas.
Permisos de vinculación para todas las raíces de dominio de GPO de servidor.
Los GPO necesitan permisos de seguridad de creación, edición, eliminación y modificación.
Se recomienda que el administrador de acceso remoto tenga permisos de lectura en los GPO en todos los dominios necesarios. Esto permite que el acceso remoto compruebe que no haya GPO con nombres duplicados al crearlos.

Ten en cuenta que si no existen los permisos correctos para vincular GPO, se mostrará una advertencia. La operación de acceso remoto continuará pero no se producirá la vinculación. Si aparece esta advertencia, los vínculos no se crearán automáticamente, incluso después de que se agreguen los permisos. En su lugar, el administrador deberá crear los vínculos manualmente.

GPO creados manualmente

Ten en cuenta lo siguiente al usar GPO creados manualmente:

Los GPO deben existir antes de ejecutar el Asistente para instalación de acceso remoto.
Cuando se usan GPO creados manualmente, para aplicar la configuración de DirectAccess, el administrador de acceso remoto necesita permisos totales (seguridad de edición, eliminación y modificación) en los GPO creados manualmente.
Al usar GPO creados manualmente, se busca un vínculo al GPO en todo el dominio. Si el GPO no está vinculado en el dominio, se creará un vínculo automáticamente en la raíz del dominio. Si no están disponibles los permisos necesarios para crear el vínculo, se mostrará una advertencia.

Ten en cuenta que si no existen los permisos correctos para vincular GPO, se mostrará una advertencia. La operación de acceso remoto continuará pero no se producirá la vinculación. Si aparece esta advertencia, los vínculos no se crearán automáticamente, incluso aunque se agreguen los permisos posteriormente. En su lugar, el administrador deberá crear los vínculos manualmente.

Recuperación de un GPO eliminado

Si un GPO de servidor de acceso directo, de cliente o de servidor de aplicaciones se elimina accidentalmente y no hay una copia de seguridad disponible, tienes que quitar la configuración y volver a configurarlo. Si hay una copia de seguridad disponible, puedes usarla para restaurar el GPO.

Administración de Acceso remoto mostrará el siguiente mensaje de error: No se puede encontrar el GPO (nombre de GPO). Para quitar las opciones de configuración, sigue estos pasos:

Ejecuta el cmdlet de PowerShell Uninstall-remoteaccess.
Vuelva a abrir Administración de Acceso remoto.
Verás un mensaje de error que indica que no se encontró el GPO. Haz clic en Quitar opciones de configuración. Cuando se complete la operación, el servidor se restaurará a un estado sin configurar.

Share via