Configuración del Protocolo de Autenticación Kerberos
Nombrado en honor a un perro de tres cabezas que guardaba las puertas del Hades en mitos griegos antiguos, el protocolo Kerberos proporciona un servicio de autenticación segura para redes de computadoras. Realiza la autenticación mutua entre el usuario y el servidor con la ayuda de un Centro de Distribución de Claves (KDC) de tercera parte de confianza que proporciona servicios de autenticación y concesión de tickets. Los principales sistemas operativos, incluyendo Microsoft Windows, Linux, Apple OS X y FreeBSD, soportan el protocolo Kerberos.
Los mensajes del protocolo Kerberos están protegidos contra ataques de repetición y espionaje mediante criptografía de clave compartida. El propósito principal de Kerberos es evitar la transmisión de contraseñas cifradas a través de la red. Elimina la amenaza de capturadores de paquetes y mejora la seguridad general de la red.
Aunque el proveedor de soporte de seguridad de Kerberos trata efectivamente con amenazas de seguridad severas, puede ser difícil de implementar debido a una variedad de limitaciones:
- Si el servidor Kerberos está caído, los usuarios no pueden iniciar sesión. El problema se puede resolver utilizando mecanismos de autenticación de respaldo y múltiples servidores Kerberos.
- Los relojes de los hosts involucrados deben estar sincronizados. De lo contrario, la autenticación fallará, ya que los tickets de Kerberos tienen un cierto período de disponibilidad.
- Kerberos no puede usarse cuando los usuarios desean conectarse a servicios desde sistemas no confiables.
- En caso de que se use criptografía simétrica, el compromiso de la infraestructura de autenticación permitirá a un atacante hacerse pasar por cualquier usuario.
- Cada servicio de red que requiere un nombre de host diferente necesitará su propio conjunto de claves Kerberos.
Cómo Funciona la Autenticación Kerberos
Un Centro de Distribución de Claves consiste en un Servidor de Autenticación (AS) y un Servidor de Concesión de Tickets (TGS). TGT es un Ticket de Concesión de Tickets.
- El usuario ingresa el nombre de usuario y la contraseña. El ID de usuario en texto claro se envía al Servidor de Autenticación (AS) con una solicitud de servicios en nombre del usuario.
- AS verifica si el nombre de usuario está en la base de datos. Si hay información sobre ese usuario, entonces AS puede generar una clave secreta del cliente de acuerdo con el ID y la contraseña del usuario. AS envía al usuario:
- La clave de sesión del cliente/TSG (cifrada con la clave secreta del cliente);
- TGT incluyendo el ID del usuario, dirección de red y período de validez del ticket + clave de sesión Cliente/TGS (cifrada con la clave secreta de TGS).
- El usuario decodifica el primer mensaje pero no puede decodificar el segundo, porque el usuario no tiene la clave secreta de TSG. El cliente envía un mensaje al TGS:
- El TGT recibido de AS + ID del servidor + clave secreta TGS/Cliente (cifrada con la clave secreta de TGS);
- El autenticador incluyendo el ID del cliente y la marca de tiempo (cifrada con la clave de sesión Cliente/TSG).
- El TGS descifra el primer mensaje, obtiene el TGT + clave de sesión TGS/Cliente, con la cual descifra el segundo mensaje. El TGS verifica si el ID del usuario del primer mensaje coincide con el ID del segundo mensaje y si la marca de tiempo no excede el período de validez del ticket. Si todo está en orden, el TSG envía al usuario:
- El ID del usuario, dirección de red, período de validación del ticket + clave de sesión Cliente/Servidor (cifrada con la clave secreta del servidor);
- La clave de sesión cliente/servidor (cifrada con la clave secreta Cliente/TGS).
- El cliente envía lo siguiente al servidor al que intenta acceder:
- El ID del usuario, dirección de red, período de validación del ticket + clave de sesión Cliente/Servidor (cifrada con la clave secreta del servidor);
- El autenticador incluyendo el ID y la marca de tiempo (cifrada con la clave de sesión Cliente/Servidor).
- El servidor objetivo descifra los mensajes del usuario, verifica si el ID del usuario en ambos mensajes tiene el mismo valor y si el período de validez no está excedido, luego envía al cliente el siguiente parámetro para confirmar su identidad:
- Marca de tiempo + 1 (cifrada con la clave de sesión Cliente/Servidor).
El cliente verifica si el valor de la marca de tiempo es marca de tiempo + 1, lo que muestra la verdadera identidad del servidor. Si es así, el cliente puede confiar en el servidor y comenzar a trabajar con él.
Configurando el Protocolo de Autenticación Kerberos
Para configurar el protocolo Kerberos, necesita hacer lo siguiente:
- Crear un usuario de Active Directory (también puede usar uno existente).
- Inicie sesión en el servidor del controlador de dominio, haga clic en Inicio → Herramientas administrativas, y lance Usuarios y Computadoras de Active Directory.
- Si aún no está seleccionado, haga clic en el nodo de su dominio (domain.com).
- Haga clic derecho en Usuarios, señale Nuevo, y luego haga clic en Usuario.
- En el cuadro de diálogo Nuevo Objeto → Usuario especifique los parámetros del nuevo usuario. Podría ser un usuario regular, no es necesario proporcionar al usuario privilegios adicionales. La cuenta de usuario debe estar activa (El cuadro Cuenta deshabilitada desmarcado), y la contraseña para la cuenta debe ser perpetua (El cuadro La contraseña nunca expira marcado).
- Asigne los nombres principales con las claves cifradas en la máquina del controlador de dominio. Para máquinas en Linux, cree un archivo keytab que contenga pares de principales Kerberos y claves cifradas. Un archivo keytab se usa para autenticarse en varios sistemas remotos utilizando Kerberos sin ingresar una contraseña.
- Cree un keytab con la primera entrada utilizando la herramienta ktpass:
ktpass /princ [email protected] /mapuser user1_backend /pass /crypto all /ptype KRB5_NT_PRINCIPAL /out C:\Users\user1\Desktop \datasunrise.keytab -setupn
/princ El nombre principal del servicio (SPN) en el siguiente formato: @ /mapuser Asigna el nombre del principal Kerberos, especificado por el parámetro princ, a la cuenta de dominio especificada. /pass Especifica la contraseña para el nombre de usuario principal. /ptype Especifica el tipo de principal. Use KRB5_NT_PRINCIPAL. /crypto Especifica las claves que se generan en el archivo keytab. /out Asigna un directorio y un nombre para el archivo *.keytab de salida. -setupn No establece el nombre principal del usuario junto con el nombre principal del servicio. - Cree una segunda entrada en el archivo keytab para conectarse a la base de datos utilizando el usuario de Active Directory.
El ejemplo se da para crear entradas keytab para conectarse a la base de datos Vertica utilizando el usuario de Active Directory. Para otras bases de datos o autenticación GUI, realice el mismo comando con el nombre del servicio correspondiente en el parámetro /princ.
ktpass /out ./datasunrise.keytab /princ vertica/[email protected] /mapuser user1 /mapop set /pass /ptype KRB5_NT_PRINCIPAL /crypto RC4-HMAC-NT
- Necesitará transferir el archivo keytab a la máquina Linux.
- Cree un keytab con la primera entrada utilizando la herramienta ktpass:
- Configurar la delegación de Active Directory.
- En la máquina del controlador de dominio, vaya a Usuarios y Computadoras de Active Directory, localice la cuenta de la máquina que desea configurar con Kerberos.
- En la sección de Propiedades, vaya a la pestaña Delegación y seleccione Confiar en este equipo para delegación solo a servicios especificados y haga clic en Agregar.
- En la ventana Usuarios y Computadoras, especifique la cuenta de usuario que se ha utilizado para iniciar la base de datos o el nombre del servidor donde está instalado el RDBMS.
- Opcionalmente, puede utilizar Verificar nombres para comprobar si existe un usuario o computadora especificado y haga clic en OK, luego seleccione el servicio requerido y haga clic en OK.
- Instale y configure el cliente Kerberos en su máquina.
sudo apt-get install krb5-user libpam-krb5 libpam-ccreds auth-client-config
Edite el archivo /etc/krb5.conf para agregar el nombre completo del dominio, el nombre del controlador de dominio y el parámetro realm
Importante: No deje ningún comentario etiquetado con el signo “#” en el archivo de configuración.[libdefaults] default_realm = DOMAIN.COM # parámetro específico del dominio (nombre completo del dominio) clockskew = 300 ticket_lifetime = 1d forwardable = true proxiable = true dns_lookup_realm = true dns_lookup_kdc = true [realms] DOMAIN.COM = { kdc = hostname.domain.com # parámetro específico del dominio (nombre del controlador de dominio) admin_server = hostname.domain.com # parámetro específico del dominio (nombre del controlador de dominio) default_domain = DOMAIN.COM # parámetro específico del dominio (nombre completo del dominio) } [domain_realm] .domain.com = DOMAIN.COM # parámetro específico del dominio (nombre del dominio para nombres DNS) domain.com = DOMAIN.COM # parámetro específico del dominio (nombre del dominio para nombres DNS) [appdefaults] pam = { ticket_lifetime = 1d renew_lifetime = 1d forwardable = true proxiable = false retain_after_close = false minimum_uid = 0 debug = false }
Para máquinas con el sistema operativo Windows, no necesita instalar y configurar el protocolo Kerberos, pero debe estar en el dominio de Active Directory. También, para establecer los nombres principales del servicio se utiliza el comando setspn. A continuación, se muestra un ejemplo de configuración de una máquina con Windows para conectarse a la base de datos MS SQL Server utilizando las credenciales del usuario de Active Directory.
La dirección del proxy debe coincidir con el SPN registrado del servicio MSSQLSvc. Use la herramienta SetSPN para registrar los dos SPN necesarios para la cuenta de la computadora para la cual ha permitido la delegación:
setspn -A MSSQLSvc/proxy-host:proxy-port proxy-host
setspn -A MSSQLSvc/full-fqdn-proxy-host:proxy-port proxy-host
La lista de todos los SPN registrados se puede obtener con el siguiente comando:
setspn -L proxy-host
Para eliminar el proxy SPN, haga lo siguiente:
setspn -D MSSQLSvc/proxy-host:proxy-port proxy-host
Para probar el esquema de autorización, ejecute el siguiente comando después de conectarse al servidor:
select auth_scheme from sys.dm_exec_connections where session_id=@@spid
El resultado corresponderá al esquema de autenticación que ha sido utilizado por el servidor: SQL, NTLM o KERBEROS.
En caso de que obtenga el error “Cannot generate SSPI context”, consulte las instrucciones de soporte de Microsoft sobre cómo solucionar el problema con la interfaz del proveedor de soporte de seguridad.
DataSunrise puede funcionar como un proxy de autenticación para bases de datos en la nube y locales para minimizar los riesgos de acceso no autorizado de usuarios, manteniendo las políticas de autenticación de Active Directory de Microsoft y el protocolo Kerberos.
¿Su base de datos o almacenamiento en la nube contiene información sensible que requiere protección? ¿Necesita cumplir con las regulaciones GDPR, SOX o HIPAA? Descubra las soluciones innovadoras de DataSunrise para auditoría de bases de datos, seguridad y enmascaramiento de datos. Pruebe nuestro software gratis o programe una demostración en línea hoy mismo.