Múltiples reinos y TGT múltiples en MIT Kerberos para Windows

Mi computadora local usa Windows 7 Pro y pertenece al reino LR, administrado por servidores AD. Me conecto a mi computadora mientras estoy conectado a la red de ese reino. Puedo ver el TGT con MIT Kerberos para Windows ver. 4.0.1.

Quiero acceder a recursos en un reino extranjero, FR. No hay confianza Kerberos entre LR y FR, pero permiten el tráfico TCP entre sí. Solicito un TGT para FR con su KDC (Red Hat IdM / FreeIPA) e ingreso con éxito mi contraseña cuando se me solicita. De nuevo, puedo ver el TGT con MIT Kerberos para Windows ver. 4.0.1. Ahora puedo acceder a los recursos en FR a través de SSH sin que se me solicite una contraseña, a pesar de originarse en LR.

El problema es que cuando obtengo el TGT para FR, el TGT para mi principal LR desaparece. Solo el FR TGT es visible en MIT Kerberos. Si bloqueo mi computadora y luego desbloqueo con mi contraseña, ahora el FR TGT se ha ido, reemplazado por un nuevo LR TGT.

Parece que MIT Kerberos para Windows solo puede almacenar un TGT a la vez. Cada TGT funciona completamente para su reino para todos los efectos. ¿Cómo puedo configurar MIT Kerberos para que me permita tener dos TGT a la vez, uno para cada reino? ¿Es posible "compartimentar" con múltiples instancias de cliente, cada una apuntando a un KRB5_CONFIG diferente y una tabla de teclas local? Si no puedo, ¿existe una implementación alternativa de Windows de Kerberos 5 del lado del cliente que lo hará, incluso cuando no haya fideicomisos entre reinos?

PD: no quiero un fideicomiso. No puedo obtener un fideicomiso.

ACTUALIZACIÓN: dejé algunos de estos detalles anteriormente porque pensé que podría confundir el problema. Pero según la respuesta de Brad, podría estar justificado. Espero que la mayoría del software local use la implementación incorporada de Windows de Kerberos y siempre use la pestaña LR.

Sin embargo, los usuarios avanzados como yo usan heimdal bajo Cygwin para SSH en FR. Espero que cualquier cosa que pase por las DLL de Cygwin use heimdal y nunca vea el LR TGT (que no lo hace, al menos no de manera predeterminada). Yo explícitamente me remito y sigo adelante.

La parte difícil viene para los usuarios no avanzados que tengo que apoyar y que no usan Cygwin pero sí usan PuTTY. PuTTY le permite especificar tanto la ruta de la biblioteca como la DLL para la implementación de GSSAPI a utilizar. Por ejemplo, estoy configurando sesiones SSH para usar DLL MIT Kerberos en lugar de las DLL integradas de Windows. Tenía la esperanza de que hubiera una DLL por ahí que nunca intentó encontrar el LR TGT (como heimdal) o permitió múltiples TGT de múltiples reinos. No tiene que tener una ventana GUI como MIT Kerberos, pero ayuda.

Bueno, no diré que NO PUEDE hacerse con Windows, pero diré que la limitación está basada en la sesión. El problema, entonces, es que para cada sesión, Windows almacena en caché un ticket. Cuando bloquea su computadora y luego la desbloquea, se inicia otra sesión y se solicita una nueva clave al KDC. Lo mismo sucede cuando cierra sesión y luego vuelve a iniciar sesión en su computadora. Este método es en realidad cómo se determinan también los permisos de usuario para las sesiones del servidor, lo que significa que la clave / ticket se puede almacenar en caché para que cada recurso del servidor o sesión que inicie no tenga que pedirle su contraseña, pero nunca he escuchado / leído / investigado para poder almacenar en caché más de uno.

Ahora, probablemente ya sepa que dado su conocimiento que ha mostrado en su pregunta, diré que debido a que Windows almacena la clave que obtiene cuando se emite un TGT y se basa en la sesión, no creo que es posible con SOLO Windows. El Kerberos de MIT para Windows puede tener una forma de iniciar dos sesiones con un solo usuario, pero aun así, no estoy seguro de cómo los recursos a los que está accediendo sabrían qué par de ticket / clave usar. ¿Tiene sentido?

Consulte esto para obtener una descripción de cómo Windows almacena los TGT / pares de claves.

Muy buena pregunta por cierto.

OK, se me ocurrió una solución de trabajo que necesita más pulido, por lo que podría no funcionar en todos los entornos.

Esto funciona con:

1. MIT Kerberos para Windows 4.0.1 con herramientas de soporte de Windows (KSETUP.EXE, KTPASS.EXE)
2. PUTTY 0.63
3. Windows 7 SP1

Estaba buscando en la fuente MIT Kerberos y encontré el archivo README para Windows . De particular interés fueron los diferentes valores para Caché de credenciales . Defiende un valor predeterminado de API: pero sorprendentemente encontré mi registro usando MSLSA: en su lugar.

Jugué con diferentes valores de ccname debajo HKEY_CURRENT_USER\Software\MIT\Kerberos5. Intenté MEMORIA: al principio, lo que condujo a un comportamiento interesante. Al abrir una sesión PuTTY, mi ventana del Administrador de tickets de Kerberos del MIT se restablecería y pasaría a primer plano, pidiéndome que ingrese las credenciales. ¡Guauu! Eso nunca sucedió antes, pero desgraciadamente, PuTTY lo rechazaría. El valor que hizo el truco para mí fue FILE:C:\Some\Full\File\Path. No estoy exactamente seguro de cómo asegurar el acceso al archivo especificado, así que lo dejaré como ejercicio para el lector. Obtuve el mismo comportamiento de ventana a primer plano, solo que a PuTTY le gustó esta vez. La ventana del Administrador de tickets también finalmente muestra los tickets LR y FR. Se demostró que los boletos eran reenviables y sobrevivirían a múltiples bloqueos / desbloqueos de Windows. NOTA:asegúrese de salir completamente y reiniciar el Administrador de tickets entre las ediciones del registro. No he probado un ccname de API: todavía.

No sé si esto hace la diferencia o no, pero también jugué con KSETUP antes de que esto comenzara a funcionar. Al principio, un KSETUP sin parámetros solo me mostraría información sobre el LR. Agregué información sobre el FR en mi estación de trabajo local.

ksetup /AddKdc FOREIGN.REALM KDC.FOREIGN.REALM
ksetup /AddRealmFlags FOREIGN.REALM TcpSupported Delegate NcSupported

Para mí, parece que en realidad hay un error en Kerberos para Windows.

Encontré lo siguiente:

Si uso la opción "obtener ticket" en la ventana KfW 4.0.1, simplemente funciona (TM); Puedo presionar el botón "Obtener boleto" y adquirir boletos adicionales para los boletos originales que recibí cuando inicio sesión.

Si presiono la opción "hacer predeterminado" en la ventana KfW, a partir de ese momento cada vez que presiono "obtener boleto", el nuevo boleto reemplazará cualquier boleto predeterminado, en lugar de agregar otra entrada a la lista de boletos conocidos . Verificar el registro en ese punto mostrará que ccnamese ha agregado una entrada (como en la respuesta de Toddius). Sorprendentemente, eliminar esa entrada restaurará el comportamiento anterior de permitir múltiples tickets.

Siguiendo con la respuesta de Toddius, tengo un compañero de trabajo en una situación similar (Windows 7 Enterprise de 64 bits, unido a un dominio AD, que también ejecuta MIT Kerberos para Windows 4.0.1): su copia del Administrador de tickets de Kerberos solo permita que tenga un director / un TGT. Cada vez que usaría el botón "Obtener boleto" para obtener un TGT para un director diferente, el director anterior desaparecería.

He revisado el README , y la mayor parte de las claves del Registro estuviera configurado como se esperaba, exceptuar de la ccname clave en el camino HKEY_CURRENT_USER\Software\MIT\Kerberos5. Esa clave se estableció en el valor MSLSA:. Nuestra solución fue cambiar eso a API:. Más específicamente, los pasos fueron:

1. Salga de Kerberos Ticket Manager, junto con todas las demás aplicaciones (ya que reiniciará).
2. En la ruta del Registro HKEY_CURRENT_USER\Software\MIT\Kerberos5, cambie la clave ccname a API:(API, luego dos puntos).
3. Salga de regedit y reinicie.
4. Después de volver a iniciar sesión, ejecute Kerberos Ticket Manager y use el botón Obtener ticket para obtener el TGT de su principal no AD.

Con los pasos anteriores, todo funcionó, y mi compañero de trabajo ahora puede ver múltiples directores / TGT a la vez.

Por cierto, MIT Kerberos para Windows trae su propio conjunto de programas de línea de comandos (como klist), y esos programas admiten múltiples cachés de credenciales. En mi sistema de 64 bits, cuando ejecuto "C:\Program Files\MIT\Kerberos\bin\klist.exe" -A"después de obtener múltiples TGT, veo mi principal de Active Directory en el caché de MSLSA, y luego tengo un caché de API para cada principal adicional.

PD: Esta es mi primera entrada en este sitio, por lo que no pude agregarla como un comentario a la respuesta de Toddius. Disculpas!