Cómo NetScaler implementa Kerberos para la autenticación de clientes
Importante
La autenticación Kerberos/NTLM solo se admite en la versión nCore 9.3 de NetScaler o posterior, y solo se puede utilizar para la autenticación, la autorización y la auditoría de los servidores virtuales de administración del tráfico.
NetScalergestiona los componentes que intervienen en la autenticación Kerberos de la siguiente manera:
Centro de distribución clave (KDC)
En Windows 2000 Server o versiones posteriores, el controlador de dominio y el KDC forman parte de Windows Server. Si el servidor Windows está activo y en ejecución, indica que el controlador de dominio y el KDC están configurados. El KDC también es el servidor de Active Directory.
Nota
Todas las interacciones de Kerberos se validan con el controlador de dominio Kerberos de Windows.
Negociación de protocolos y servicios de autenticación
Un dispositivo NetScaler admite la autenticación Kerberos en los servidores virtuales de autenticación, autorización y auditoría de la administración del tráfico. Si se produce un error en la autenticación Kerberos, NetScaler utiliza la autenticación NTLM.
De forma predeterminada, Windows 2000 Server y las versiones posteriores de Windows Server utilizan Kerberos para la autenticación, la autorización y la auditoría. Si crea una directiva de autenticación con NEGOCIATE como tipo de autenticación, NetScaler intenta utilizar el protocolo Kerberos para la autenticación, autorización y auditoría y, si el explorador del cliente no recibe un tíquet Kerberos, NetScaler utiliza la autenticación NTLM. Este proceso se denomina negociación.
El cliente puede no recibir un tíquet Kerberos en cualquiera de los siguientes casos:
- El cliente no admite Kerberos.
- Kerberos no está activado en el cliente.
- El cliente se encuentra en un dominio distinto del KDC.
- El cliente no puede acceder al directorio de acceso del KDC.
Para la autenticación Kerberos/NTLM, NetScaler no utiliza los datos que están presentes localmente en el dispositivo NetScaler.
Autorización
El servidor virtual de administración del tráfico puede ser un servidor virtual de equilibrio de carga o un servidor virtual de conmutación de contenido.
Auditoría
El dispositivo NetScaler admite la auditoría de la autenticación Kerberos con el siguiente registro de auditoría:
- Registro de auditoría completo de la actividad del usuario final de gestión del tráfico
- SYSLOG y registro TCP de alto rendimiento
- Registro de auditoría completo de los administradores del sistema
- Todos los eventos del sistema
- Formato de registro programable
Entorno compatible
La autenticación Kerberos no necesita ningún entorno específico en NetScaler. El cliente (navegador) debe proporcionar soporte para la autenticación Kerberos.
Alta disponibilidad
En una configuración de alta disponibilidad, solo el NetScaler activo se une al dominio. En caso de conmutación por error, el daemon lwagent de NetScaler une el dispositivo NetScaler secundario al dominio. No se requiere ninguna configuración específica para esta funcionalidad.
Proceso de autenticación Kerberos
La siguiente figura muestra un proceso típico de autenticación Kerberos en el entorno NetScaler.
Figura 1. Proceso de autenticación Kerberos en NetScaler
La autenticación Kerberos se realiza en las siguientes etapas:
El cliente se autentica en el KDC
- El dispositivo NetScaler recibe una solicitud de un cliente.
- El servidor virtual de administración del tráfico (equilibrio de carga o conmutación de contenido) del dispositivo NetScaler envía un desafío al cliente.
- Para responder al desafío, el cliente recibe un ticket Kerberos.
- El cliente envía al servidor de autenticación del KDC una solicitud de un tíquet de concesión de tíquets (TGT) y recibe el TGT. (Consulte 3, 4 en la ilustración, Proceso de autenticación Kerberos.)
- El cliente envía el TGT al servidor de concesión de tíquets del KDC y recibe un tíquet Kerberos. (Consulte 5, 6 en la ilustración, Proceso de autenticación Kerberos.)
Nota
El proceso de autenticación anterior no es necesario si el cliente ya tiene un tíquet Kerberos cuya vida útil no ha expirado. Además, los clientes como Servicios web, .NET o J2EE, que admiten SPNEGO, obtienen un tíquet Kerberos para el servidor de destino, crean un token SPNEGO e insertan el token en el encabezado HTTP cuando envían una solicitud HTTP. No pasan por el proceso de autenticación del cliente.
El cliente solicita联合国检修io.
- El cliente envía el ticket Kerberos que contiene el token SPNEGO y la solicitud HTTP al servidor virtual de administración del tráfico de NetScaler. El token SPNEGO tiene los datos GSSAPI necesarios.
- El dispositivo NetScaler establece un contexto de seguridad entre el cliente y NetScaler. Si NetScaler no puede aceptar los datos proporcionados en el ticket de Kerberos, se le pedirá al cliente que obtenga un ticket diferente. Este ciclo se repite hasta que los datos de la GSSAPI sean aceptables y se establezca el contexto de seguridad. El servidor virtual de administración del tráfico de NetScaler actúa como un proxy HTTP entre el cliente y el servidor físico.
El dispositivo NetScaler completa la autenticación.
- Una vez finalizado el contexto de seguridad, el servidor virtual de administración del tráfico valida el token SPNEGO.
- Del token SPNEGO válido, el servidor virtual extrae el ID de usuario y las credenciales GSS y las pasa al demonio de autenticación.
- Una autenticación correcta completa la autenticación Kerberos.