Autenticación de masilla Kerberos / GSSAPI

Configuré algunos servidores Linux para autenticarme con Active Directory Kerberos usando sssd en RHEL6. También habilité la autenticación GSSAPI con la esperanza de inicios de sesión sin contraseña.

Pero parece que no puedo hacer que Putty (0.63) se autentique sin una contraseña.

GSSAPI funciona entre sistemas Linux (cliente openSSH) que están configurados para autenticación AD, utilizando la configuración .ssh / config para habilitar GSSAPI.

También funciona desde Cygwin (cliente openSSH), utilizando la misma configuración .ssh / config, así como ejecutando el comando kinit para obtener un ticket.

También Samba comparte en todos los sistemas Linux, incluidos los directorios de inicio que funcionan desde el Explorador de Windows sin requerir una contraseña (no estoy seguro de si GSSAPI entra en juego allí)

¿Qué tipo de cosas puedo tratar de solucionar esto? La mayoría de mis usuarios usan Putty. Además, no soy un administrador de Windows, así que no puedo hacer nada en los controladores de dominio. Mi cuenta solo tiene privilegios para agregar servidores al dominio AD.

Encendí el registro de paquetes SSH de masilla. Encontré este tipo de interesante, todavía no estoy seguro de qué hacer con esta información:

Event Log: Server version: SSH-2.0-OpenSSH_5.3
Event Log: Using SSH protocol version 2
Event Log: We claim version: SSH-2.0-PuTTY_Release_0.63
Outgoing packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Incoming packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Event Log: Doing Diffie-Hellman group exchange
Outgoing packet #0x1, type 30 / 0x1e (SSH2_MSG_KEX_DH_GEX_REQUEST)
Incoming packet #0x1, type 31 / 0x1f (SSH2_MSG_KEX_DH_GEX_GROUP)
Event Log: Doing Diffie-Hellman key exchange with hash SHA-256
Outgoing packet #0x2, type 32 / 0x20 (SSH2_MSG_KEX_DH_GEX_INIT)
Incoming packet #0x2, type 33 / 0x21 (SSH2_MSG_KEX_DH_GEX_REPLY)
Outgoing packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA1 client->server MAC algorithm
Outgoing raw data at 2014-11-25 00:21:08
Incoming packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA1 server->client MAC algorithm
Outgoing packet #0x4, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)
Incoming packet #0x6, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.
Event Log: Using SSPI from SECUR32.DLL
Event Log: Attempting GSSAPI authentication
Outgoing packet #0x6, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x7, type 60 / 0x3c (SSH2_MSG_USERAUTH_GSSAPI_RESPONSE)
Event Log: GSSAPI authentication initialised
Outgoing packet #0x7, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Incoming packet #0x8, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Event Log: GSSAPI authentication initialised
Event Log: GSSAPI authentication loop finished OK
Outgoing packet #0x8, type 66 / 0x42 (SSH2_MSG_USERAUTH_GSSAPI_MIC)
Incoming packet #0x9, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.

En las máquinas Windows que forman parte de un dominio de Active Directory, los usuarios reciben su boleto de concesión de tickets Kerberos cuando inician sesión en Windows, y PuTTY puede usarlo para la autenticación si la autenticación GSSAPI está habilitada en PuTTY Configuration Connection | SSH | Auth | GSSAPI (y otros métodos de autenticación que intenta antes de GSSAPI, como la clave pública a través del concurso, no están configurados o deshabilitados en Connection | SSH | Auth).

[Si también necesita delegación de tickets (p. Ej., Para montar sistemas de archivos kerberizados en el servidor después de iniciar sesión), asegúrese de que la delegación GSSAPI también esté habilitada en PuTTY, y que los servidores en los que inicia sesión estén marcados en Active Directory en la pestaña Delegación como " Confíe en esta computadora para la delegación a cualquier servicio (solo Kerberos) ", que no son por defecto. Es extraño que esta última configuración de confianza en AD solo sea necesaria para que la delegación funcione desde clientes de Windows como PuTTY; no es necesario para clientes Linux "ssh -K".]

En máquinas Windows (personales) autogestionadas que no son parte de un dominio de Active Directory, aún puede usar la autenticación Kerberos / GSSAPI (y la delegación de tickets) a través de PuTTY, pero debe obtener el ticket usted mismo. Desafortunadamente, Windows 7 no viene instalado con ningún equivalente del programa kinit (para que usted solicite manualmente un ticket), y PuTTY tampoco le solicita su contraseña de Kerberos si no tiene un ticket. Por lo tanto, debe instalar MIT Kerberos para Windowspaquete, que incluye las herramientas habituales de línea de comandos kinit / klist / kdestroy, así como una herramienta GUI ordenada "MIT Kerberos Ticket Manager". Úselos para obtener su boleto, y luego PuTTY usará automáticamente la biblioteca MIT GSSAPI en lugar de la SSPI de Microsoft, y todo debería funcionar. Si el "MIT Kerberos Ticket Manager" se está ejecutando, le pedirá automáticamente su contraseña de Kerberos cuando PuTTY necesite un ticket, por lo que es una buena idea vincularlo desde la carpeta Inicio.

Primero verifique que su salida de klist en el cuadro de Windows que ejecuta PuTTY muestre un TGT válido. Luego, en la configuración de su sesión PuTTY, asegúrese de que la autenticación Intento GSSAPI esté habilitada Connection - SSH - Auth - GSSAPI. Finalmente, asegúrese de que esté configurado para iniciar sesión con su nombre de usuario automáticamente Connection - Data. Puede especificar explícitamente el nombre de usuario o seleccionar el botón de radio para Usar nombre de usuario del sistema .

Históricamente, eso es todo lo que necesito hacer para que el inicio de sesión SSH sin contraseña funcione a través de Kerberos.

El problema estaba en la configuración de Windows Kerberos. Creo que nuestro Active Directory está configurado de forma original, realmente no sé si no soy un administrador de Windows.

Pero solucioné el problema configurando manualmente Kerberos usando ksetup en la CLI de Windows 7.

Después de reiniciar mi estación de trabajo remota, no pude iniciar sesión en mi PC. Esto se debe a que en la configuración original, la parte de TLD de mi dominio de dominio siempre estuvo ausente (dominio \ usuario), pero después de configurarla manualmente tuve que cambiar mi dominio de inicio de sesión para reflejar el nombre de dominio de dominio completo (dominio.TLD \ usuario) y Pude iniciar sesión en mi PC con Windows, aunque ahora parece que me lleva más tiempo autenticarme.

Antes de los cambios, la salida de ksetup solo mostraba mi reino predeterminado, y estaba en minúsculas.

Usé "nslookup -type = SRV _kerberos._tcp.domain.TLD" para obtener todos los servidores kdc de mi reino.

No puse ninguna bandera.

Configuré mapeado mi nombre de usuario "ksetup / mapuser user@domain.TLD user"

Recursos que utilicé: https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC

https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html

Si alguien tiene alguna sugerencia que pueda darle a la gente de administración de Windows sobre cómo pueden solucionar esto (¿está roto?), Lo pasaré.