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

Question

Mi computadora local usa Windows 7 Pro y pertenece al dominio 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 ámbito extranjero, FR. No existe 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 mi contraseña con éxito cuando me cuestionan. Nuevamente, puedo ver el TGT con MIT Kerberos para Windows ver. 4.0.1. Ahora puedo acceder a recursos en FR a través de SSH sin que me pidan una contraseña, a pesar de ser originario de LR.

El problema es que cuando obtengo el TGT para FR, el TGT para mi principal de LR desaparece. Sólo el FR TGT es visible en MIT Kerberos. Si bloqueo mi computadora y luego la desbloqueo con mi contraseña, ahora el FR TGT desaparecerá y será reemplazado por un nuevo LR TGT.

Parece que MIT Kerberos para Windows sólo puede almacenar un TGT a la vez.Cada TGT trabaja completamente para su ámbito 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 y una tabla de claves local diferente? Si no puedo, ¿existe una implementación alternativa de Windows de Kerberos 5 del lado del cliente que lo haga, incluso cuando no haya confianzas entre dominios?

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

ACTUALIZAR:Omití algunos de estos detalles antes porque pensé que podría confundir el tema. Pero según la respuesta de Brad, podría estar justificado. EsperomayoríaEl software local usaría la implementación incorporada de Kerberos en Windows y siempre usaría la tabla de claves LR.

Sin embargo, los usuarios avanzados como yo usamos 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 (lo cual no es así, al menos no de forma predeterminada). Lo hago explícitamente y sigo adelante.

La parte complicada viene para los usuarios no avanzados a los que tengo que apoyar y que no usan Cygwin pero sí PuTTY. PuTTY le permite especificar tanto la ruta de la biblioteca como la DLL para qué implementación GSSAPI usar. Por ejemplo, estoy configurando sesiones SSH para usar archivos DLL de MIT Kerberos en lugar de archivos DLL integrados de Windows. Tenía la esperanza de que hubiera una DLL que nunca intentara encontrar el LR TGT (como heimdal) o permitiera múltiples TGT de múltiples reinos. No es necesario que tenga una ventana GUI como MIT Kerberos, pero ayuda.

Answer 1

Bueno, no diré que NO SE PUEDE hacer con Windows, pero sí diré quela limitación se basa 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 cierras la sesión y luego vuelves a conectarte a tu computadora. En realidad, este método también es la forma en que se determinan 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 oído/leído/investigado sobre ello para poder almacenar en caché más de uno.

Ahora, probablemente ya lo sepas, dado el conocimiento que has mostrado en tu pregunta, así que diré que, basándose en el hecho de que Windows almacena la clave que obtienes cuando se emite un TGT y se basa en una sesión, no lo sé. Creo que es posible SÓLO con Windows. El MIT Kerberos para Windows puede tener una forma de iniciar dos sesiones con un solo usuario, pero incluso entonces, no estoy seguro de cómo los recursos a los que accede sabrán qué ticket/par de claves usar. ¿Tiene sentido?

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

Muy buena pregunta por cierto.

Answer 2

Bien, se me ocurrió una solución funcional que necesita un poco más de pulido, por lo que es posible que no funcione en todos los entornos.

Esto funciona con:

1. MIT Kerberospara Windows 4.0.1 con herramientas de soporte de Windows (KSETUP.EXE, KTPASS.EXE)
2. Masilla0,63
3. Windows 7 SP1

Estaba buscando en la fuente de MIT Kerberos y encontré elLÉAME para Windows. De particular interés fueron los diferentes valores paraCaché de credenciales. Adopta un valor predeterminado deAPI:, pero sorprendentemente encontré mi registro usandoMSLSA:en cambio.

Jugué con diferentes valores deccnombrebajo HKEY_CURRENT_USER\Software\MIT\Kerberos5. Lo intentéMEMORIA:al principio, lo que conduce a un comportamiento interesante. Al abrir una sesión de PuTTY, mi ventana del Administrador de tickets de MIT Kerberos se restauraba y pasaba al primer plano, pidiéndome que ingresara las credenciales. ¡Guau! Eso nunca había sucedido antes, pero, por desgracia, PuTTY lo rechazaría. El valor que funcionó 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 en primer plano, solo que esta vez a PuTTY le gustó. Finalmente, la ventana del Administrador de boletos también mostró los boletos LR y FR. Se demostró que los tickets se podían reenviar 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 unccnombredeAPI:todavía.

No sé si esto hace una diferencia o no, pero también jugué conKSETUPantes 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

Answer 3

Para mí, parece como si realmente hubiera un error en Kerberos para Windows.

Encontré lo siguiente:

Si uso la opción "obtener ticket" en la ventana de KfW 4.0.1, simplemente funciona(TM); Puedo presionar el botón "Obtener boleto" y adquiriradicionalboletos a los boletos originales que obtuve cuando inicié sesión.

Si presiono la opción "predeterminar" en la ventana de KfW, a partir de ese momento cada vez que presiono "obtener boleto", el nuevo boleto aparecerá.reemplazarcualquier ticket sea el predeterminado, en lugar de agregar otra entrada a la lista de tickets conocidos. Verificar el registro en ese momento mostrará que ccnamese ha agregado una entrada (como en la respuesta de Toddius).EliminandoEsa entrada, sorprendentemente, restablecerá el comportamiento anterior de permitir múltiples tickets.

Answer 4

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 Kerberos Ticket Manager sería solo le permite tener un principal/un TGT. Cada vez que usaba el botón "Obtener ticket" para obtener un TGT para un principal diferente, el principal anterior desaparecía.

revisé elLÉAME, y la mayoría de las claves de registro se configuraron como se esperaba,exceptoPara elccnombreclave en la ruta 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 Ruta del Registro HKEY_CURRENT_USER\Software\MIT\Kerberos5, cambie elccnombreclave para 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 entidad principal que no sea de AD.

Con los pasos anteriores, todo funcionó y mi compañero de trabajo ahora puede ver varios 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 varios TGT, veo mi entidad principal de Active Directory en la caché MSLSA y luego tengo una caché API para cada entidad principal adicional.

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