Después de configurar las opciones de autenticación en dos fases en la configuración de puerta de enlace del pod de Horizon Cloud, también debe ajustar la configuración del sistema de la autenticación en dos fases correspondiente para permitir que reciba la comunicación de solicitudes de autenticación desde direcciones IP específicas relacionadas con la puerta de enlace.

Las instancias de Unified Access Gateway de la puerta de enlace intentarán comunicarse con el servidor de autenticación en dos fases desde direcciones IP específicas. El administrador de red determina la visibilidad de red sobre el servidor de autenticación en dos fases en la VNet de Azure y las subredes del pod. La combinación de la visibilidad de red y el tipo de puerta de enlace del pod, externa o interna, determina las direcciones IP específicas relacionadas con la puerta de enlace que se deben configurar en la configuración del servidor de autenticación en dos fases para permitir que acepte esa comunicación.

Importante:

Debe seguir la información de la documentación adecuada para su sistema de autenticación en dos fases.

Un sistema de autenticación en dos fases RADIUS utiliza el concepto de clientes RADIUS permitidos. Por ejemplo, como se describe en el wiki de FreeRADIUS para la configuración de cliente FreeRADIUS, el archivo /etc/raddb/clients.conf contiene definiciones de clientes RADIUS como:
client NAME {
  ipaddr = IPADDRESS
  secret = SECRET
}

Un sistema de autenticación en dos fases RSA SecurID utiliza el concepto de agentes de autenticación registrados para comunicarse con RSA Authentication Manager. Por ejemplo, como se describe en el tema sobre cómo Agregar un agente de autenticación de la Documentación de SecurID Authentication Manager, utilice la consola de seguridad de RSA Authentication Manager para agregar las direcciones IP necesarias a su base de datos interna.

En este tema, se describe la información del pod de Horizon Cloud que debe usar en el servidor de autenticación en dos fases para habilitar la comunicación entre la puerta de enlace del pod y para mantener la resistencia de esa comunicación después de cada actualización del pod.

Para aceptar la comunicación desde las instancias de Unified Access Gateway de la configuración de puerta de enlace, los servidores de autenticación en dos fases deben permitir las comunicaciones desde las direcciones IP adecuadas.

Por lo general, el administrador de red determina el acceso de red que tiene el servidor de autenticación en dos fases a la VNet y a las subredes conectadas al pod implementado. Las direcciones IP de origen específicas que utilizan las instancias de Unified Access Gateway al ponerse en contacto con el servidor de autenticación en dos fases dependen de lo siguiente:

  • Si se configuró un tipo RADIUS o RSA SecurID en la configuración de la puerta de enlace.
  • Si la configuración de la puerta de enlace es interna o externa.
  • Si el administrador de red determinó que se puede acceder al servidor de autenticación en dos fases dentro de la VNet del pod o fuera de la VNet.
  • La subred del pod en la VNet desde la cual el administrador de red configuró el acceso al servidor de autenticación en dos fases, si se puede acceder al servidor de autenticación en dos fases dentro de la VNet del pod.
RSA SecurID: configuraciones de puerta de enlace externa e interna
El servidor RSA Authentication Manager verá la comunicación de las NIC en las instancias de Unified Access Gateway individuales. En la configuración de RSA Authentication Manager, registre las siguientes direcciones IP de NIC como agentes de autenticación:
  • Para una puerta de enlace externa, las cuatro NIC de la subred dmz de la puerta de enlace
  • Para una puerta de enlace interna, las cuatro NIC de la subred tenant de la puerta de enlace.
RADIUS: configuración de puerta de enlace interna
Las instancias de Unified Access Gateway implementadas para una configuración de puerta de enlace interna utilizan las direcciones IP privadas de sus NIC para ponerse en contacto con ese servidor de autenticación en dos fases. El servidor de autenticación en dos fases ve las solicitudes procedentes de las direcciones IP de origen que son direcciones IP privadas de las NIC. El administrador de red determina si se puede acceder al servidor mediante el rango de direcciones IP de la subred del arrendatario o la administración del pod. El grupo de recursos de la puerta de enlace interna en Microsoft Azure tiene cuatro (4) NIC que se ajustan a esa subred: dos actualmente activas para las dos instancias de Unified Access Gateway y dos inactivas que se convertirán en activas después de que el pod pase por una actualización. Para admitir la conectividad de comunicación entre la puerta de enlace y el servidor de autenticación en dos fases en las operaciones del pod en curso y posteriores a cada actualización del pod, debe configurar el servidor a fin de permitir las conexiones de cliente desde las direcciones IP de las cuatro NIC en el grupo de recursos de la puerta de enlace interna de Microsoft Azure que corresponden a la subred con visibilidad sobre el servidor. Consulte la siguiente sección Permitir la comunicación desde las direcciones IP de las NIC de puerta de enlace del pod.
Nota: Para un tipo RSA SecurID configurado en la puerta de enlace interna, agregue las direcciones IP de NIC para las cuatro NIC en la subred de arrendatario.
RADIUS: la configuración de puerta de enlace es externa y se puede acceder al servidor de autenticación en dos fases dentro de la VNet del pod
Cuando el administrador de red configura el servidor de autenticación en dos fases para que se pueda acceder a él en la misma VNet que el pod, las instancias de Unified Access Gateway utilizan las direcciones IP privadas de sus NIC para ponerse en contacto con ese servidor. El servidor de autenticación en dos fases ve las solicitudes procedentes de las direcciones IP de origen que son direcciones IP privadas de las NIC. El administrador de red determina si se puede acceder al servidor mediante el rango de direcciones IP de la subred de administración, arrendatario o DMZ del pod. El grupo de recursos de la puerta de enlace externa en Microsoft Azure tiene cuatro (4) NIC que corresponden a esa subred: dos actualmente activas para las dos instancias de Unified Access Gateway y dos inactivas que se convertirán en activas después de que el pod pase por una actualización. Para admitir la conectividad de comunicación entre la puerta de enlace y el servidor de autenticación en dos fases en las operaciones del pod en curso y posteriores a cada actualización del pod, debe configurar el servidor a fin de permitir las conexiones de cliente desde las direcciones IP de las cuatro NIC en el grupo de recursos de la puerta de enlace externa de Microsoft Azure que corresponden a la subred con visibilidad sobre el servidor. Consulte la siguiente sección Permitir la comunicación desde las direcciones IP de las NIC de puerta de enlace del pod.
RADIUS: la configuración de puerta de enlace es externa y se puede acceder al servidor de autenticación en dos fases fuera de la VNet del pod
Cuando el administrador de red configura el servidor de autenticación en dos fases fuera de la VNet del pod, las instancias de Unified Access Gateway de la configuración de puerta de enlace externa usan la dirección IP del recurso de equilibrador de carga de Azure de la puerta de enlace externa para ponerse en contacto con ese servidor. Debe configurar ese servidor para permitir las conexiones de cliente desde la dirección IP del recurso de equilibrador de carga de la puerta de enlace externa. Consulte la siguiente sección Permitir la comunicación desde el equilibrador de carga de la puerta de enlace externa.

Permitir la comunicación desde las direcciones IP de las NIC de puerta de enlace del pod

Cuando se implementa el pod, el implementador de pods crea un conjunto de NIC en el grupo de recursos de la puerta de enlace en la suscripción de Microsoft Azure. Las siguientes capturas de pantalla son ejemplos de NIC para el tipo de puerta de enlace interna y el tipo de puerta de enlace externa. A pesar de que el identificador del pod se muestra pixelado en estas capturas de pantalla, se puede ver el patrón con el que el implementador nombra a las NIC, incluidos -management, -tenant y -dmz en esos nombres. Para conocer los nombres de los grupos de recursos del pod, consulte Arrendatarios de first-gen: grupos de recursos creados para un pod implementado en Microsoft Azure.


Captura de pantalla de las NIC y las máquinas virtuales que el implementador de pods crea para una configuración de puerta de enlace interna.


Captura de pantalla de las NIC y las máquinas virtuales que el implementador de pods crea para una configuración de puerta de enlace externa.

Debe obtener las direcciones IP de las NIC para la configuración de puerta de enlace en la que habilitó la autenticación en dos fases que corresponden a la subred con visibilidad de red sobre el servidor de autenticación en dos fases; además, debe especificar esas direcciones IP como clientes permitidos en la configuración del servidor de autenticación en dos fases.

Importante: Para evitar una interrupción de conectividad entre el servidor de autenticación en dos fases y el pod después de una actualización, en cada puerta de enlace que configuró con las opciones de autenticación en dos fases, asegúrese de que las direcciones IP de las cuatro (4) NIC descritas a continuación se especifiquen como clientes permitidos en la configuración del servidor de autenticación en dos fases. Si bien solo la mitad de las NIC se encuentran activas durante las operaciones del pod en curso, su estado cambia cuando se actualiza el pod. Después de una actualización del pod, la otra mitad de las NIC se activa y las NIC previas a la actualización quedan inactivas hasta la próxima actualización del pod, cuando su estado vuelve a cambiar. Si no agrega todas las direcciones IP de las NIC, tanto las activas como las inactivas, a la configuración del servidor de autenticación en dos fases, este servidor rechazará las solicitudes de conexión del conjunto de NIC posteriores a la actualización del pod y ahora activas; además, se interrumpirá el proceso de inicio de sesión para los usuarios finales que utilizan esa puerta de enlace.

Para obtener las direcciones IP de las NIC de la puerta de enlace que se deben agregar a la configuración del servidor de autenticación en dos fases:

  1. Solicite a su administrador de red la información sobre cuál de las subredes del pod tiene visibilidad de red sobre el servidor de autenticación en dos fases (administración, arrendatario o DMZ).
  2. Inicie sesión en el portal de Microsoft Azure para buscar su suscripción y localice el grupo de recursos de la puerta de enlace.
  3. Para las NIC correspondientes a la subred que, según el administrador de red, tiene visibilidad sobre el servidor de autenticación en dos fases, haga clic en cada NIC y copie su dirección IP.
  4. Siga la documentación del tipo de sistema de autenticación en dos fases para agregar esas direcciones IP de modo que el servidor de autenticación en dos fases acepte las comunicaciones desde estas NIC.
Ejemplo de adición de las direcciones IP de las NIC de la puerta de enlace cuando se utiliza un servidor de autenticación en dos fases RADIUS
El siguiente bloque de código ilustra una parte de las líneas de configuración de cliente de las NIC con direcciones IP en la subred de arrendatario del pod para una puerta de enlace interna en la que el administrador de red configuró el servidor RADIUS dentro de la misma VNet que el pod y habilitó la accesibilidad desde la subred de arrendatario del pod. La subred de tenant del pod se configuró como 192.168.25.0/22 cuando se implementó este pod. Cuando se implementa inicialmente el pod, NIC1 y NIC2 se encuentran activas, y NIC3 y NIC4 se encuentran inactivas. Sin embargo, se agregan las cuatro NIC a la configuración del servidor RADIUS para garantizar que, después de la actualización del pod, cuando NIC3 y NIC4 se activen, y NIC1 y NIC2 queden inactivas, el servidor RADIUS siga aceptando conexiones de esta puerta de enlace. Tenga en cuenta que debe utilizar la sintaxis adecuada específica de su servidor RADIUS.
client UAGTENANTNIC1 {
  ipaddr = 192.168.25.5
  secret = myradiussecret
}
client UAGTENANTNIC2 {
  ipaddr = 192.168.25.6
  secret = myradiussecret
}
client UAGTENANTNIC3 {
  ipaddr = 192.168.25.7
  secret = myradiussecret
}
client UAGTENANTNIC4 {
  ipaddr = 192.168.25.8
  secret = myradiussecret
}

Autenticación en dos fases RADIUS: Permitir la comunicación desde el equilibrador de carga de la puerta de enlace externa

Cuando el servidor de autenticación en dos fases se encuentra fuera de la VNet del pod, para la puerta de enlace externa en la que especificó ese servidor, debe agregar la dirección IP pública del recurso de equilibrador de carga de Azure de la puerta de enlace externa como cliente permitido en esa configuración del servidor de autenticación en dos fases. Para obtener la dirección IP del equilibrador de carga, en el portal de Microsoft Azure, busque el recurso de equilibrador de carga en el grupo de recursos de la puerta de enlace.

  1. Inicie sesión en el portal de Microsoft Azure para buscar su suscripción y localice el grupo de recursos de la puerta de enlace.
  2. En el grupo de recursos de la puerta de enlace, haga clic en el recurso de equilibrador de carga. Tiene un nombre con el patrón vmw-hcs-podID-uag-lb. Su dirección IP se muestra en la información general.
  3. Siga la documentación del tipo de sistema de autenticación en dos fases para agregar la dirección IP del equilibrador de carga de la puerta de enlace de modo que el servidor de autenticación en dos fases acepte las comunicaciones desde esta dirección IP.
Ejemplo de adición de la dirección IP del equilibrador de carga de la puerta de enlace externa cuando se utiliza un servidor de autenticación en dos fases RADIUS
El siguiente bloque de código es un ejemplo ilustrativo. Tenga en cuenta que debe utilizar la sintaxis adecuada específica de su servidor RADIUS.
client MYPODUAGEXTLBIP {
  ipaddr = 52.191.236.223
  secret = myradiussecret
}