Authentication Portal y MFA

Resumen

User-ID identifica a los usuarios que inician sesión en el dominio. Pero hay tráfico de personas que el firewall no puede identificar así: equipos Linux o Mac, invitados, dispositivos que no pertenecen al dominio. Para ellos existe el Authentication Portal (antes llamado Captive Portal): cuando alguien sin identificar intenta navegar y coincide con una regla que lo exige, el firewall lo intercepta, le muestra una página de inicio de sesión (o le pide un certificado, o usa Kerberos de forma transparente) y, al autenticarse, aprende su IP y su usuario.
Para decidir cómo se autentica se usan Authentication Profiles (LDAP, RADIUS, SAML, Kerberos, base local) y, si quieres reforzar el acceso, MFA (multi-factor authentication), por ejemplo con Duo: además de la contraseña, el usuario debe confirmar con un segundo factor. Todo esto se aplica con una Authentication Policy: reglas que dicen a qué tráfico se le exige autenticarse y con qué método. Esta nota cubre el Authentication Portal, los perfiles y la política de autenticación con MFA.

Requisitos previos

• User-ID funcionando y la zona de usuarios con Enable User Identification (ver User-ID)
• Un Server Profile (LDAP, RADIUS, SAML o MFA) y su conectividad desde el firewall (ver Admin Authentication y RBAC para LDAP)
• Una interfaz de la zona de usuarios con un Interface Management Profile que permita Response Pages (y User-ID si aplica), porque el portal se sirve por esa interfaz (ver L3 Interfaces, Subinterfaces y DHCP)
• Un certificado para el portal y un SSL/TLS Service Profile, para evitar advertencias del navegador (ver Certificates y PKI)
• Para MFA con Duo u otro proveedor: cuenta del proveedor, integración creada y sus datos (API hostname, integration key, secret key)
• Para Kerberos transparente: un keytab y un nombre de host resolvible
• Decryption para HTTPS, o el portal solo puede interceptar tráfico web HTTP (ver Decryption Forward Proxy)

Cómo funciona

graph TD
    A["Usuario sin identificar<br/>intenta navegar"] --> B{"¿Coincide con una regla<br/>de Authentication Policy?"}
    B -- No --> Z["Sigue la Security Policy normal"]
    B -- Sí --> C["Firewall redirige al<br/>Authentication Portal"]
    C --> D["Usuario se autentica<br/>(Authentication Profile)"]
    D --> E{"¿Se requiere MFA?"}
    E -- Sí --> F["Segundo factor (Duo, etc.)"]
    E -- No --> G["Se crea el mapeo IP-usuario"]
    F --> G
    G --> H["Se aplica la Security Policy<br/>con el usuario identificado"]

Método del portal	Cómo se identifica al usuario
Web Form	Página de inicio de sesión con usuario y contraseña
Browser Challenge (Kerberos o NTLM)	Transparente: el navegador responde sin pedir datos (requiere configuración)
Client Certificate Authentication	El navegador presenta un certificado de cliente
Multi-Factor Authentication	Se añaden uno o más factores adicionales

Configuración (Ejemplo, Lab PCNSA)

1. Authentication Profile

1. Device > Authentication Profile > Add. Name AD-Auth.
2. Authentication tab: Type LDAP, Server Profile AD-LDAP (el de User-ID), Login Attribute sAMAccountName.
3. User Domain: OGIT (formato NetBIOS), y Username Modifier %USERDOMAIN%\%USERINPUT% si quieres que se anteponga el dominio.
4. Advanced tab > Allow List: all o los grupos permitidos.
5. OK.

2. Authentication Portal Settings

1. Device > User Identification > Authentication Portal Settings > engranaje.
2. Enable Authentication Portal marcado.
3. Idle Timer y Timer (cuánto dura la sesión autenticada).
4. SSL/TLS Service Profile: el que usa tu certificado del portal.
5. Authentication Profile: AD-Auth (u otro). Para Client Certificate Authentication, elige también un Certificate Profile (Device > Certificate Management > Certificate Profile) con la CA que emite los certificados de cliente.
6. Mode: Redirect (recomendado: redirige a un nombre de host del firewall, funciona mejor con navegadores y cookies) o Transparent (hace pasar por el sitio destino; puede dar advertencias de certificado).
7. Redirect Host: el nombre o IP de la interfaz del firewall en la zona de usuarios que sirve el portal (por ejemplo fw.ogit.local).
8. OK y Commit.

Si usas Redirect con un nombre, ese nombre debe resolver desde los clientes.

3. Permitir Response Pages en la interfaz

1. Network > Network Profiles > Interface Mgmt > Add. Name Portal-Mgmt.
2. Marca Response Pages (y User-ID si usarás agente en esa interfaz).
3. Network > Interfaces > (interfaz de la zona de usuarios) > Advanced > Management Profile Portal-Mgmt.
4. Commit.

4. Authentication Enforcement object

1. Objects > Authentication > Add. Name Web-Auth.
2. Authentication Method: web-form (o browser-challenge, no-captive-portal, según el caso).
3. Authentication Profile: AD-Auth.
4. Message: texto opcional que verá el usuario.
5. OK.

5. Authentication Policy

1. Policies > Authentication > Add. Name Auth-Unknown.
2. Source: Source Zone inside, Source User unknown (solo los que el firewall no ha podido identificar).
3. Destination: Destination Zone outside.
4. Service/URL Category: service-http y service-https (o any si procede).
5. Actions: Authentication Enforcement Web-Auth.
6. OK y Commit.

Las reglas de Authentication Policy se evalúan antes de la Security Policy. Una vez autenticado, la Security Policy se aplica con el usuario ya identificado.

6. MFA con un proveedor (ejemplo: Duo)

1. Device > Server Profiles > Multi Factor Authentication > Add. Name Duo-MFA, Certificate Profile (para validar al proveedor), Type Duo v2.
2. Value: API Host (el que da Duo), Integration Key, Secret Key, Timeout, y Duo Mode si aplica.
3. OK.
4. Device > Authentication Profile > (tu perfil, por ejemplo AD-Auth) > Factors tab > Enable Additional Authentication Factors > Add Duo-MFA.
5. OK y Commit.
6. El usuario verá primero la contraseña y luego la solicitud de Duo (notificación push, llamada o código, según Duo).

La configuración exacta del proveedor puede variar según el servicio y la versión; revísala en su documentación y en la consola de tu versión de PAN-OS.

7. Probar

1. Desde un cliente sin identificar, abre un sitio HTTP (por ejemplo http://example.com).
2. Debe aparecer la página de inicio de sesión.
3. Inicia sesión con un usuario del directorio.
4. Confirma el segundo factor si hay MFA.
5. Verifica el mapeo con show user ip-user-mapping all (el origen aparece como CP, de Captive Portal).

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
Navegar a un sitio HTTP desde un cliente sin identificar	La página de login del portal	Si no aparece, revisa la Authentication Policy, la interfaz y Response Pages
show user ip-user-mapping all	La IP con su usuario y origen CP (u otro)	Si no aparece, la autenticación falló o no se completó
Monitor > Logs > Authentication	Intentos de autenticación, con éxito o error y el método	Si hay error, el mensaje indica la causa (contraseña, servidor, MFA)
Monitor > Logs > Traffic: Source User	El usuario autenticado	Si sigue vacío, no se creó el mapeo
Policies > Authentication: hit count	Sube con cada intento	Si no sube, la regla no coincide con el tráfico
show authentication allow-list / Device > Authentication Profile > Allow List	El usuario o grupo permitido	Si no está permitido, falla aunque la contraseña sea correcta
test authentication authentication-profile AD-Auth username <usuario> password (verificar con Tab o ?)	Resultado Authentication succeeded	Si falla, el problema está en el perfil o el servidor, no en el portal
Navegador: certificado del portal	Candado sin advertencia	Revisa el certificado, el SSL/TLS Service Profile y el nombre en Redirect Host

Errores comunes

No aparece la página de login

• Causa: la regla de Authentication Policy no coincide (zona, usuario, servicio), el tráfico es HTTPS sin decryption, o la interfaz no tiene Response Pages permitido.
• Revisa: Policies > Authentication (hit count) y el Interface Management Profile.
• Solución: usa tráfico HTTP para la prueba (o abre primero un sitio HTTP o el portal directamente), configura decryption si necesitas que HTTPS dispare el portal, activa Response Pages en la interfaz y ajusta la regla.

El navegador muestra advertencia de certificado en el portal

• Causa: el certificado del portal no es de confianza, o el nombre del Redirect Host no coincide con el del certificado.
• Solución: usa un certificado emitido por tu CA, con el nombre correcto en el SAN (ver Certificates y PKI), y asígnalo en el SSL/TLS Service Profile del portal.

El usuario se autentica pero no pasa el tráfico

• Causa: la Security Policy no permite a ese usuario, o hay un bucle entre la Authentication Policy y la Security Policy.
• Revisa: show user ip-user-mapping all y Monitor > Logs > Traffic.
• Solución: permite al usuario o grupo en la Security Policy; no exijas autenticación al tráfico que el usuario necesita antes de autenticarse (DNS, el propio portal).

Falla la autenticación con un usuario válido

• Causa: Login Attribute incorrecto, usuario no incluido en el Allow List, dominio mal formado o servidor LDAP inalcanzable.
• Revisa: Monitor > Logs > Authentication y test authentication.
• Solución: corrige el Login Attribute, agrega al usuario o grupo al Allow List y comprueba el formato del dominio.

El portal pide autenticación otra vez a cada rato

• Causa: Timer o Idle Timer cortos, o el mapeo caduca.
• Solución: ajusta los timers en Authentication Portal Settings.

Duo no envía la solicitud, o falla el segundo factor

• Causa: datos de integración incorrectos, el firewall no alcanza el host de Duo, o el usuario no está inscrito.
• Revisa: Monitor > Logs > Authentication y conectividad hacia el API Host.
• Solución: verifica Integration Key, Secret Key y API Host; confirma la inscripción del usuario y la conectividad.

Los dispositivos sin navegador (impresoras, IoT) quedan bloqueados

• Causa: no pueden autenticarse en un portal.
• Solución: exclúyelos de la Authentication Policy con una regla no-captive-portal por IP o sitio, y permite su tráfico con una regla de Security Policy específica.