Configurar y probar un servidor RADIUS en Sophos Firewall

RADIUS conecta Sophos Firewall con Microsoft NPS, una puerta de enlace MFA u otro servicio de autenticación centralizado. Primero se preparan el sistema remoto y la ruta de red. A continuación, se crea el servidor en Authentication > Servers y se asigna únicamente a los servicios de inicio de sesión necesarios en Authentication > Services. La validación se realiza con un inicio de sesión real y comprobaciones del usuario, el grupo y las reglas.

Para las consultas clásicas de usuarios y grupos de un dominio de Windows, suele resultar adecuada la integración de Active Directory con Sophos Firewall. En escenarios modernos de acceso remoto, Microsoft Entra ID SSO para Sophos Connect y VPN Portal puede ser la arquitectura más apropiada. Si el objetivo es que el firewall reconozca a usuarios Wi-Fi ya autenticados a partir de paquetes de accounting entrantes, debe seguirse otro procedimiento: configurar RADIUS SSO con accounting en Sophos Firewall.

Cuándo conviene utilizar RADIUS

El firewall envía el nombre de usuario y las credenciales al servidor RADIUS. Allí, el origen de usuarios, la Network Policy y, si procede, MFA determinan si se devuelve Access-Accept o Access-Reject. Solo entonces el grupo de usuarios local, la política de VPN y las reglas de firewall determinan a qué recursos se puede acceder.

En el modelo RADIUS, los datos de autenticación y autorización se almacenan en perfiles de usuario. Para autorizar un servicio, la solicitud debe coincidir con los atributos previstos, por ejemplo, con la dirección IP del cliente RADIUS que realiza la solicitud. El Shared Secret protege las contraseñas de los usuarios; esto no implica que se cifre todo el transporte RADIUS.

Algunos casos de uso habituales son:

• Remote Access VPN con Microsoft NPS o un servicio MFA;
• inicio de sesión centralizado en User Portal, VPN Portal o Captive Portal;
• una solución de transición cuando no se desea conectar AD o LDAP directamente al firewall;
• varios dispositivos de red que utilizan el mismo servicio RADIUS.

Una red WLAN empresarial administrada desde el firewall utiliza además la selección de servidores de Wireless > Wireless settings. Por ello, el procedimiento completo de 802.1X se describe en configurar una red WLAN directamente en Sophos Firewall.

En una red WLAN empresarial administrada por SFOS, Accounting Request y Accounting Response contienen información de sesión y de accounting. Son independientes de las solicitudes, respuestas y desafíos de acceso utilizados para iniciar sesión. Para esta vía inalámbrica, Sophos documenta la compatibilidad con accounting en todos los dispositivos con capacidad Wi-Fi; Wireless Network debe utilizar 802.1X y el accounting debe estar habilitado en el servidor RADIUS. La guía WLAN enlazada explica los puertos separados y la ausencia de Interim Accounting Updates. La compatibilidad con accounting no implica que se admita un servidor RADIUS secundario.

Documentar el estado inicial y la vía de retorno

Antes de migrar un servicio de producción, se debe anotar lo siguiente para cada sección afectada de Authentication > Services:

• los servidores seleccionados y su orden;
• el estado de Set authentication methods same as firewall, Same as VPN o Same as firewall;
• el valor actual de Default group en la autenticación del firewall;
• un usuario con el que se haya comprobado que el método anterior funciona.

Durante el cambio de los inicios de sesión de administrador, se debe mantener abierta una sesión de WebAdmin existente. También hay que comprobar un superadministrador local a través de una ruta de administración que ya esté permitida. La selección de servidores para administradores no se aplica a este superadministrador, pero nunca debe cambiarse el método de inicio de sesión de un administrador externo sin haber confirmado antes una vía de retorno local.

Planificar la conexión RADIUS

Funciones, ruta de red y protocolos

En un entorno NPS, Sophos Firewall es el cliente RADIUS y NPS es el servidor RADIUS. NPS contrasta la solicitud con su Connection Request Policy y su Network Policy y, por lo general, también con Active Directory. Una política de VPN o una regla de firewall posterior sigue siendo la que determina el acceso efectivo.

La ayuda general de SFOS 22 describe la comunicación entre el firewall y el servidor RADIUS mediante PAP. Sin embargo, en Authentication > Services, Sophos enumera PAP, CHAP y MSCHAPv2 para conexiones L2TP y PPTP. Esta matriz de protocolos no demuestra que se admitan los mismos métodos para IPsec u otras vías de inicio de sesión. Por tanto, deben comprobarse conjuntamente el servicio, el cliente y el método permitido en el servidor RADIUS.

RADIUS clásico utiliza UDP y la interfaz documentada de SFOS no ofrece campos de TLS ni de certificados. Por ello, el tráfico debe circular por una ruta interna controlada o protegida de otra forma. Un Shared Secret robusto no sustituye ni a la segmentación ni a una autorización restrictiva entre el firewall y el servidor RADIUS.

Los sistemas antiguos pueden requerir otros puertos, como 1645/UDP y 1646/UDP. Lo determinante son los puertos realmente configurados en ambos extremos, no estos valores históricos.

Elegir los valores de ejemplo de forma consciente

Esta guía utiliza los siguientes valores:

• nombre del servidor: NPS-HQ-RADIUS;
• IP del servidor: 10.20.30.15;
• puerto de autenticación: 1812;
• puerto de accounting: 1813;
• tiempo de espera: 5 segundos;
• nombre de dominio: corp.example.

10.20.30.15 y corp.example deben sustituirse por la dirección interna y la convención de nombres propias. Cinco segundos es un valor inicial para una comprobación directa de contraseña, no el valor predeterminado de Sophos. En el caso de una notificación push, una llamada telefónica o un desafío externo, el valor debe ajustarse al proveedor y al cliente real dentro del intervalo de 1 a 60 segundos permitido por SFOS.

El Shared secret es el secreto técnico compartido por el cliente y el servidor RADIUS, no la contraseña de un usuario. Sophos lo limita a 48 caracteres. El valor debe intercambiarse por una vía independiente y protegida, almacenarse de forma segura e introducirse exactamente igual en ambos extremos; RADIUS no transmite el propio secreto por la red.

Crear el servidor RADIUS en Authentication

La ruta del menú es Authentication > Servers.

1. Abra Add y, en Server type, seleccione RADIUS server.
2. En Server name, introduzca, por ejemplo, NPS-HQ-RADIUS.
3. En Server IP, introduzca la dirección IP interna del servidor RADIUS; en este ejemplo, 10.20.30.15.
4. Ajuste Authentication port al servidor, normalmente 1812.
5. Defina Time-out. Para la primera prueba directa, el ejemplo utiliza 5 segundos.
6. Active Enable accounting solo si el sistema remoto debe procesar datos de accounting. En ese caso, ajuste también Accounting port, normalmente 1813.
7. Introduzca el Shared secret exactamente como está configurado en el sistema remoto.
8. De forma opcional, configure Domain name. Si se utilizan AD y RADIUS en paralelo, un dominio uniforme evita que una misma persona aparezca como distintos objetos de usuario locales. Con Domain name, en el primer inicio de sesión se crea automáticamente una entrada local con el formato user@domainname. Sin este valor, RADIUS crea un usuario sin dominio, mientras que AD crea una entrada con el dominio incluido; por ello, pueden generarse dos entradas locales para la misma persona.
9. Introduzca Group name attribute únicamente si se ha comprobado que el sistema remoto proporciona el atributo esperado. La ayuda de Sophos lo define como un alias del nombre de grupo configurado, pero no documenta aquí una asignación general de atributos NPS arbitrarios a grupos locales.
10. Abra Enable additional settings solo si existe una política adecuada. NAS-identifier identifica el Network Access Server solicitante, por ejemplo mediante un FQDN. NAS-port-type describe el tipo de puerto del inicio de sesión.
11. Ejecute Test connection con un usuario piloto propio y, a continuación, seleccione Save.

El firewall admite un máximo total de 20 servidores de autenticación configurados. También pueden seleccionarse como máximo 20 servidores por método de autenticación en Authentication > Services.

Límites de la API de SFOS 22 y 23

Para automatizar, lea las referencias de la API por separado del procedimiento de WebAdmin. Las siguientes notas no constituyen una solicitud Add/Edit ejecutable; antes de escribir, confirmar la representación admitida en la API help del build instalado.

• Ejemplo XML y tabla de parámetros: El ejemplo anida RADIUSServer dentro de AuthenticationServer. Utiliza ServerAddress, Port y DomainName; la tabla, en cambio, utiliza ServerIP, AuthenticationPort y domainName. No considere estas grafías intercambiables mediante una normalización de etiquetas supuesta.
• Accounting: El comentario del ejemplo indica que se debe incluir AccountingPort para activar el accounting; sin este parámetro, queda desactivado. Esto no demuestra un comportamiento probado al omitir un campo en Edit o en una actualización parcial. 2222 es solo el valor del ejemplo XML, no el valor predeterminado de WebAdmin 1813; no elimine silenciosamente del XML generado el puerto de accounting previsto.
• Valores sin resolver: Para IntegrationType, el ejemplo muestra LooseIntegration/TightIntegration, pero la tabla indica Only '1' are allowed.; para ServerType, indica Only '4' are allowed.. No deduzca de ello una correspondencia de enumeraciones ni valores válidos para una solicitud. Para realizar cambios, el procedimiento de WebAdmin anterior sigue siendo la vía segura mientras no se aclare la sintaxis de la API para la versión utilizada.
• Límites de entrada de la API: ServerName es una cadena de hasta 50 caracteres; se admite UTF-8, pero no comas. GroupNameAttribute y domainName son cadenas de hasta 50 caracteres cada una. AuthenticationPort es un entero de 1 a 65535, con un máximo de 5 dígitos y el valor predeterminado documentado 1812. La tabla marca ServerIP, AuthenticationPort, SharedSecret y GroupNameAttribute con Yes en Mandatory; la recomendación anterior de WebAdmin sobre Group name attribute no convierte el campo de la API en opcional. Son límites de la referencia de la API, no restricciones de la GUI confirmadas de nuevo.
• Delete e identidad: Delete también documenta ServerName como identificador del servidor con los mismos límites de nombre. Para la eliminación prevista, utilice el nombre existente exacto, no un nombre normalizado de nuevo. Aunque Add/Edit y Delete muestran para ServerName la indicación Mandatory: No con la celda Default vacía, esto no demuestra que se admita la eliminación sin nombre, con comodines o masiva. Siguen siendo necesarias las comprobaciones de las asignaciones de servicios y la reversión segura descritas más abajo.

Nota sobre la API de SFOS 23: La referencia de la API para añadir y editar servidores RADIUS incorpora el parámetro opcional EmailAddressAttribute (cadena de texto, máximo 50 caracteres) y lo incluye en el ejemplo XML de RADIUSServer. No se indica ningún valor predeterminado. Esta nota se refiere a la documentación de la API, no a un campo adicional de WebAdmin.

Respuestas de la API al migrar de SFOS 22 a 23: Para las automatizaciones existentes, las clases de respuesta documentadas cambian al añadir y editar servidores RADIUS. Las referencias de la API indican los siguientes valores en la columna Status:

Por tanto, debe comprobarse el tratamiento de las respuestas por separado para cada versión de SFOS y cada operación; una lógica basada exclusivamente en los valores de error anteriores no es suficiente para SFOS 23. Estos valores son valores de estado de la API documentados, no una prueba de códigos de estado HTTP. Las claves JavaScript de la columna Message no demuestran ningún texto de respuesta concreto en tiempo de ejecución. Las tablas no proporcionan ni una correspondencia inequívoca entre cada error antiguo y uno nuevo ni una regla de reintento.

Interpretar correctamente el accounting

Con Enable accounting, el firewall envía un mensaje Accounting-Start al iniciar sesión y un mensaje Accounting-Stop al cerrar sesión normalmente para los tipos de cliente compatibles. Sophos enumera Windows client, HTTP client, Linux client, Android, iOS, iOS HTTP client, Android HTTP client y API client. Las solicitudes de inicio y fin también contienen, respectivamente, el momento del inicio y del cierre de sesión.

Cuando el firewall se apaga o reinicia, no se envía ningún Accounting-Stop. Si una sesión permanece abierta en el servidor RADIUS, debe contrastarse el momento del reinicio con los registros de RADIUS. Esta función de accounting saliente no es el RADIUS SSO Accounting entrante con el que el firewall aprende sesiones de otros sistemas.

Preparar Microsoft NPS como sistema remoto

Sophos Firewall debe estar configurado en NPS como cliente RADIUS. La comprobación mínima en la consola Network Policy Server es la siguiente:

1. Abra RADIUS Clients and Servers > RADIUS Clients.
2. Cree un New RADIUS Client con un Friendly name inequívoco, como Sophos-Firewall-HQ.
3. En Address (IP or DNS), introduzca la dirección desde la que NPS recibe realmente la solicitud.
4. En Vendor, seleccione normalmente RADIUS standard.
5. Introduzca el mismo Shared secret que en el firewall.
6. En la Connection Request Policy y la Network Policy correspondientes, compruebe las condiciones, la decisión de acceso y el método de autenticación permitido para el usuario piloto.
7. Tenga disponibles Event Viewer y los registros de accounting de NPS para la validación.

En clústeres de HA, conexiones enrutadas o entornos con NAT, la dirección del cliente NPS no debe deducirse únicamente de la topología. Una primera prueba muestra en NPS qué IP de origen llega realmente. Si la solicitud no llega en absoluto o NPS no puede validarla, compruebe primero el enrutamiento, la regla que permite el tráfico UDP, la dirección del cliente RADIUS y el Shared Secret. En cambio, un Access-Reject normal apunta al usuario, a la política o al método de autenticación.

Asignar RADIUS a los servicios correctos

Después de guardar, el objeto de servidor todavía no está activo para ningún inicio de sesión. En SFOS 22, Authentication > Services contiene las siguientes secciones:

• Firewall authentication methods;
• User portal authentication methods;
• VPN portal authentication methods;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods;
• Administrator authentication methods;
• SSL VPN authentication methods.

En User Portal, VPN Portal, VPN y administradores, la selección de servidores puede estar vinculada a la autenticación del firewall. SSL VPN ofrece Same as VPN y Same as firewall. Antes de realizar cualquier cambio, compruebe si la sección afectada utiliza una lista propia o una lista vinculada.

Para una prueba piloto limitada, añada NPS-HQ-RADIUS únicamente en la sección necesaria, colóquelo en la posición prevista y seleccione Apply. El firewall consulta varios servidores en el orden mostrado. Si el mismo usuario ya puede autenticarse correctamente mediante un servidor anterior, no se alcanzará una política RADIUS MFA situada después.

Captive Portal y Default Group

Captive Portal no dispone de una sección propia en Authentication > Services. Utiliza Firewall authentication methods. Además, la zona prevista debe tener habilitado Captive portal en Administration > Device access y debe existir una regla de firewall basada en usuarios correctamente configurada. Una prueba funcional oficial consiste en iniciar sesión en https://<firewall-ip>:8090.

La opción Default group de Firewall authentication methods es relevante para la seguridad. Cuando un usuario externo inicia sesión correctamente por primera vez en un servicio del firewall, se crea en Authentication > Users. Si no existe una asignación adecuada a un grupo local, se aplica el valor configurado en Default group. Antes de la prueba piloto, compruebe las políticas del grupo y todas las reglas en las que se utiliza; un Default group con permisos excesivos no debe convertirse inadvertidamente en el grupo de reserva.

Delimitar la MFA con desafío según el servicio

Según la ayuda de SFOS 22, VPN Portal no admite autenticación RADIUS con MFA basada en desafíos. Por tanto, una ejecución correcta de Test connection no demuestra que esta vía del portal funcione. Push, llamada, OTP y desafío tampoco son intercambiables: cada cliente y servicio previsto debe probarse por separado. Para la MFA local de Sophos Firewall, consulte el procedimiento específico para activar MFA en Sophos Firewall WebAdmin, VPN Portal y Remote Access.

Validar la configuración

1. Conexión y sistema remoto

En Authentication > Servers, abra NPS-HQ-RADIUS y ejecute Test connection con el usuario piloto. Al mismo tiempo, compruebe en NPS o en los registros del otro sistema remoto que:

• la solicitud procede de la dirección esperada del firewall;
• la procesa la política correcta;
• el resultado es Access-Accept;
• están presentes los atributos de respuesta esperados.

La prueba confirma las credenciales y la comunicación con el servidor. Todavía no confirma el orden de los servicios, la política de VPN, el grupo local ni la regla de firewall.

2. Probar el servicio real

A continuación, inicie sesión con el mismo usuario a través del servicio previsto. Captive Portal, SSL VPN, IPsec, User Portal y WebAdmin tienen requisitos diferentes. En WebAdmin, el usuario externo también debe recibir el perfil de administrador previsto; una autenticación RADIUS correcta no concede por sí sola permisos de administrador. Las vías que no sean necesarias deben permanecer sin cambios. Para SSL VPN, configurar el acceso remoto SSL VPN en Sophos Firewall explica la política, Device Access y la regla de firewall.

Después de iniciar sesión correctamente, compruebe:

1. En Authentication > Users, el usuario local, el dominio y el Main Group efectivo.
2. En Current activities > Live users, la sesión activa; si es necesario, puede finalizarla allí con Disconnect.
3. En Log viewer, situado en la parte superior derecha de WebAdmin, abra el módulo Authentication y filtre por usuario, IP de origen y un intervalo de prueba reducido.
4. En el registro de tráfico, la Firewall Rule ID efectiva y únicamente el recurso de destino permitido.
5. El caso negativo con un usuario que no pertenezca a la política NPS autorizada.

Si el inicio de sesión funciona, pero no se puede acceder a la aplicación, compruebe la zona, el grupo de direcciones IP de VPN, el grupo, la posición de la regla, NAT y el enrutamiento. La regla de Sophos Firewall no se aplica: comprobar las causas recorre esta ruta de datos. Si la identidad, la selección del servicio o el Main Group ya presentan dudas, consulte solucionar sistemáticamente los errores de autenticación de Sophos Firewall.

Acotar los errores según lo observado

No llega ninguna solicitud al sistema remoto

Compruebe primero los valores configurados en Server IP y Authentication port. A continuación, revise el enrutamiento y la regla que permite el tráfico UDP 1812 entre la dirección de origen utilizada por el firewall y 10.20.30.15. Un objeto de servidor RADIUS no crea automáticamente una regla de firewall de tránsito.

Para una red inalámbrica administrada por SFOS, Sophos documenta un caso especial muy limitado: si el servidor RADIUS está conectado al firewall a través de un túnel IPsec, se necesita una asignación de Source NAT para las redes de los puntos de acceso. Esta traduce la IP de origen exactamente a la dirección IP del firewall que este utiliza para acceder al servidor RADIUS. La ayuda de Wireless remite para ello a una configuración mediante la shell con sys-traffic-nat; sin embargo, no proporciona aquí un comando completo que pueda ejecutarse. Antes de realizar un cambio, deben verificarse y documentarse las redes de los puntos de acceso, la dirección de origen realmente utilizada, la dirección del firewall para la traducción de origen, el túnel, la ruta de retorno y los registros de RADIUS. Sin una sintaxis confirmada para este fin, la configuración concreta de la shell, incluidas su comprobación y reversión, debe ser objeto de una escalación técnica específica. Para otras vías RADIUS, esta guía inalámbrica no demuestra que exista un requisito general de NAT. Una regla de LAN a VPN o un ejemplo de Forwarding-IPsec-Route no sustituye este procedimiento de tráfico del sistema.

NAT del tráfico del sistema para una vía Wireless-IPsec confirmada

La ayuda independiente de la CLI de SFOS 22 y 23 documenta la siguiente sintaxis. Complementa el caso especial inalámbrico anterior; no sustituye la comprobación de las redes de los AP ni la planificación del túnel y de la ruta de retorno.

⚠️ Antes del cambio: Una modificación de NAT puede interrumpir la autenticación y otros servicios del sistema hacia el mismo destino. Prepare una copia de seguridad, una ventana de mantenimiento y un acceso de administrador independiente. El destino RADIUS, la IP de origen observada, la IP del firewall necesaria, los selectores IPsec o la ruta, la ruta de retorno y la dirección del cliente NPS deben concordar. Si esta vía no está confirmada, sigue siendo necesaria una escalación técnica.

Acceda a la Command-line console con permisos administrativos y seleccione 4 – Device Console, no Advanced Shell. Primero guarde la configuración existente mediante este comando de solo lectura:

show advanced-firewall

El siguiente ejemplo IPv4 solo es válido si 10.20.30.15 es el servidor RADIUS y 10.40.50.1 es exactamente la IP del firewall prevista para esta vía. Sustituya ambas direcciones. 255.255.255.255 limita el destino a un host; una máscara más amplia incluye otros destinos. El comando no tiene filtro de red de origen ni de puerto: no selecciona únicamente una red de AP o UDP 1812. Sin interface, la asignación se aplica al tráfico hacia este destino a través de cualquier interfaz del firewall. Un parámetro interface <interface> verificado puede limitar el alcance; no adivine el nombre de la interfaz. No sobrescriba ni elimine asignaciones existentes o solapadas sin comprobarlas.

Añada la asignación solo si se han autorizado expresamente estos efectos y no existe ya una asignación adecuada:

set advanced-firewall sys-traffic-nat add destination 10.20.30.15 netmask 255.255.255.255 snatip 10.40.50.1
show advanced-firewall

Después, utilice un cliente Wi-Fi real de prueba para comprobar 802.1X, Accounting-Start y el cierre de sesión normal con Accounting-Stop. Los registros de RADIUS deben mostrar la IP de origen esperada del firewall, la decisión Access-Accept y el accounting recibido; compruebe también el túnel, la ruta de respuesta y otros servicios hacia el mismo destino. Que aparezca la asignación NAT no demuestra por sí solo que el inicio de sesión funcione. Si hay diferencias, no amplíe las reglas de acceso.

Para revertir solo la asignación de ejemplo recién añadida, utilice los mismos valores adaptados con delete; si añadió interface, conserve ese mismo parámetro al eliminarla:

set advanced-firewall sys-traffic-nat delete destination 10.20.30.15 netmask 255.255.255.255 snatip 10.40.50.1
show advanced-firewall

Compare con el estado inicial guardado y vuelva a probar la autenticación original y los servicios del sistema afectados. Un error de consola o una entrada poco clara exige detenerse, no realizar un restablecimiento general.

NPS responde con Access-Reject

Un rechazo indica que la ruta de red y el puerto funcionan en principio. Compruebe ahora en NPS el Reason Code, la Network Policy aplicable, el estado del usuario y el método de autenticación permitido. En cambio, un Shared Secret incorrecto provoca respuestas ausentes, no válidas o que no pueden verificarse.

Test connection funciona, pero el inicio de sesión en el servicio no

En Authentication > Services, compruebe la sección correcta, los controles de vinculación, el orden de los servidores y Apply. Para Captive Portal, revise además Device access y la regla de firewall basada en usuarios. En SSL VPN, deben ser correctos el Policy Member, el acceso de SSL VPN en Device Access y la regla de firewall necesaria.

El inicio de sesión funciona, pero se aplica el grupo equivocado

En Authentication > Users, revise el dominio y el Main Group. A continuación, compare Group name attribute, los atributos de respuesta del sistema remoto y Default group. Una autenticación correcta no demuestra que la autorización sea la esperada. Por ello, debe comprobarse que el usuario de la prueba negativa no cumple la condición del grupo o de NPS.

Una notificación push o un desafío agota el tiempo de espera

Utilice el cliente real y compare las marcas de tiempo de los registros del firewall, NPS y el proveedor de MFA. Aumente el tiempo de espera de SFOS únicamente dentro del intervalo de 1 a 60 segundos y elija el valor más bajo que cubra de manera fiable el flujo normal del desafío. En VPN Portal, la MFA RADIUS basada en desafíos no puede corregirse ampliando el tiempo de espera, ya que Sophos no admite esta vía.

Revertir la configuración de forma segura

Si la prueba piloto falla, restaure en la sección afectada de Authentication > Services la lista de servidores anotada previamente, incluido su orden, así como los controles de vinculación y el valor de Default group; después, seleccione Apply. A continuación, inicie sesión con el usuario de referencia mediante el método original y compruebe el superadministrador local.

Solo cuando todos los servicios afectados vuelvan a funcionar debe eliminar NPS-HQ-RADIUS de las demás asignaciones de servicios. El objeto de servidor de Authentication > Servers solo debe eliminarse si ya no se prevé utilizarlo. En NPS, restaure el cliente, la política y el Shared Secret al estado anterior documentado. Los objetos de usuario locales que ya se hayan creado deben revisarse por separado; eliminarlos no finaliza automáticamente todas las sesiones existentes, por lo que también debe comprobar Current activities > Live users.

Operación

RADIUS es un servicio de identidad de producción. Después de modificar NPS, el proveedor de MFA, AD o el orden de los servicios, la validación debe incluir un inicio de sesión real positivo y otro negativo. El Shared Secret debe documentarse de forma protegida y rotarse según lo planificado. Configure la supervisión del sistema remoto y defina el periodo de conservación de sus registros de decisiones. Así podrá determinarse si un error se produjo antes del firewall, durante la autenticación o solo en la autorización.

FAQ