Configuraciones para admitir el blindaje Kerberos

¡Atención!

Para que se utilice el blindaje Kerberos, las cuentas de administrador deben colocarse en el grupo Protected Users.
Esto obliga a utilizar el protocolo de autenticación Kerberos en lugar de NTLM. La Edge Gateway debe configurarse previamente para admitir la autenticación Kerberos.

Configurar la Edge Gateway para admitir la autenticación Kerberos con cuentas colocadas en Protected Users

El blindaje Kerberos aporta un cifrado adicional a los intercambios iniciales entre el cliente y el KDC (Kerberos Domain Controller), a partir de información vinculada a una cuenta de equipo.

CyberElements se ejecuta preferentemente en máquinas Debian no conectadas a un dominio AD, lo que significa que no dispone de ninguna información de cuenta de equipo en el AD.
La configuración necesaria para admitir el blindaje Kerberos consta de dos etapas:

• La creación de una cuenta de equipo de servicio en el AD
• La configuración del blindaje Kerberos en la Edge Gateway a partir de la cuenta creada previamente

Crear una cuenta de equipo de servicio

Información

Esta página utiliza como ejemplo una cuenta de servicio llamada svc_cyberelements. Adapte los comandos siguientes al nombre de su propia cuenta de servicio.

¡Atención!

Si desea utilizar puestos PAW, coloque esta cuenta de servicio en el mismo silo que los puestos PAW de destino.

Desde el controlador de dominio, empiece por crear una cuenta de equipo con una contraseña que se utilizará para generar los tickets Kerberos.

Para crear esta cuenta, puede utilizar el comando Powershell siguiente desde un controlador de dominio (adapte el nombre de la cuenta de servicio, svc_cyberelements en el ejemplo, y la OU deseada, OU=Service_accounts,DC=domain,DC=local en el ejemplo, para crear la cuenta de servicio):

New-ADComputer -Name svc_cyberelements -SAMAccountName 'svc_cyberelements$' -AccountPassword $Null -Path 'OU=Service_accounts,DC=domain,DC=local'-KerberosEncryptionType AES256 -PasswordNeverExpires $True -Enabled $True

Utilice el comando siguiente para comprobar que la cuenta de equipo se ha creado (sustituya svc_cyberelements por el nombre de la cuenta creada previamente):

Get-ADComputer -Identity svc_cyberelements -Properties Enabled

Utilice después la herramienta de Windows ktpass para exportar un archivo keytab que contendrá las claves de cifrado que permitirán a la pasarela recuperar el TGT.

Ejemplo

Ejemplo de creación de un archivo svc_cyberelements.keytab con la cuenta de equipo:

ktpass /princ 'svc_cyberelements$@DOMAIN.LOCAL' /mapuser 'svc_cyberelements$@DOMAIN.LOCAL' +rndPass /out svc_cyberelements.keytab /crypto AES256-SHA1 /ptype KRB5_NT_SRV_HST /mapop set

No olvide incluir los símbolos $ al final de los nombres de cuenta ni escribir el nombre del dominio en mayúsculas (obligatorio).

Acepte las eventuales solicitudes de confirmación introduciendo y.

Vuelva a establecer después el valor del atributo UserPrincipalName con el comando PowerShell siguiente:

Set-ADComputer 'svc_cyberelements$' -UserPrincipalName 'svc_cyberelements$@DOMAIN.LOCAL'

Configurar el blindaje Kerberos en la Edge Gateway

Recupere el archivo keytab generado previamente y cópielo en el servidor Edge Gateway.
Si se han generado varios archivos keytab que deben utilizarse en la misma Edge Gateway, combine los archivos keytab en uno solo.

Atención

El archivo keytab contiene claves de cifrado. Si un atacante se hace con él, puede suplantar la cuenta de equipo asociada y reducir así la seguridad de la infraestructura.
Por ello, este archivo no debe conservarse en ningún otro lugar que no sea la Edge Gateway.

Coloque el archivo en el directorio /etc/ipdiva/cleanroom/.

Cambie los propietarios del archivo keytab por ipdivacareuser para el usuario y carerecord para el grupo, y modifique después los permisos del archivo (adapte el nombre del archivo keytab al suyo):

chown ipdivacareuser:carerecord /etc/ipdiva/cleanroom/svc_cyberelements.keytab
chmod 640 /etc/ipdiva/cleanroom/svc_cyberelements.keytab

Modifique el archivo de configuración /etc/ipdiva/cleanroom/xrdprecord.ini de la Edge Gateway para indicar, mediante el parámetro keytab=, la ruta del archivo keytab preparado previamente.

Ejemplo

keytab=/etc/ipdiva/cleanroom/svc_cyberelements.keytab

Llegados a este punto, la conexión a las aplicaciones RDP privilegiadas en modo sin agente (HTML5 o no) debería funcionar con cuentas de usuario pertenecientes a Protected Users y que exigen, por tanto, una autenticación fuerte Kerberos. La configuración de la aplicación RDP debe cumplir determinados requisitos previos.

Probar la configuración Kerberos

Depuración

Los comandos kinit siguientes pueden generar más registros tras ejecutar el comando siguiente (válido hasta la desconexión de la sesión SSH o de consola):

export KRB5_TRACE=/dev/stdout

Empecemos por recuperar un ticket Kerberos con un comando similar al siguiente:

kinit -k -t /etc/ipdiva/cleanroom/svc_cyberelements.keytab 'svc_cyberelements$@DOMAIN.LOCAL' -c /tmp/test_kerberos

No olvide sustituir la ubicación del archivo keytab, el nombre de la cuenta de servicio creada y su dominio asociado.

Si la recuperación del ticket Kerberos se ha realizado correctamente, el comando siguiente debería indicar la existencia de un ticket para la cuenta de servicio:

klist -c /tmp/test_kerberos

Si la recuperación se realiza correctamente, es necesario intentar recuperar un ticket para un usuario con un comando similar al siguiente:

kinit -T /tmp/test_kerberos user@DOMAIN.LOCAL

Sustituya user@DOMAIN.LOCAL por un usuario susceptible de conectarse mediante RDP y blindaje Kerberos. Tenga en cuenta que se solicitará la contraseña de dicho usuario.
Si la recuperación del ticket se realiza correctamente, el comando siguiente lo mostrará:

klist -c

Si aparece el error KDC policy rejects request while getting initial credentials, significa que el KDC ha rechazado la solicitud de ticket. Causas posibles:

• kinit no ha podido utilizar el ticket /tmp/test_kerberos (si kinit no puede utilizarlo, continúa sin mensaje de error con una solicitud de ticket básica)
• La cuenta de servicio no está presente en el silo del usuario probado. Esto ocurre cuando el AD está compartimentado y exige colocar la cuenta de equipo de servicio en el silo adecuado.

Puede encontrarse información adicional en los registros de eventos Seguridad del controlador de dominio (KDC) utilizado.

Tras las pruebas, se recomienda eliminar los tickets generados:

kdestroy
kdestroy -c /tmp/test_kerberos

Combinar varios archivos keytab en uno solo

Si la arquitectura CyberElements se basa en una única Edge Gateway que dará acceso a varios terceros, es necesario fusionar en un solo archivo keytab todos los archivos keytab generados para las distintas cuentas de servicio.

Nota

En esta sección se parte de los archivos keytab siguientes: /root/t0.keytab, /root/t1.keytab y /root/t2.keytab. Estos archivos deben haberse enviado previamente a la Edge Gateway.

Para fusionar los archivos keytab, conéctese a la Edge Gateway como root y utilice después los comandos siguientes:

ktutil
rkt /root/t0.keytab
rkt /root/t1.keytab
rkt /root/t2.keytab
wkt /root/unified.keytab

Los comandos rkt permiten cargar tantos archivos keytab como sea necesario, y el comando wkt genera un nuevo archivo keytab.
Adapte las rutas de los archivos a las suyas.

Pulse la tecla q para salir de la utilidad ktutil.

Recupere el archivo unified.keytab y siga la sección Configurar el blindaje Kerberos en la Edge Gateway.