Plusieurs domaines et plusieurs TGT sous MIT Kerberos pour Windows

Mon ordinateur local utilise Windows 7 Pro et appartient au domaine LR, géré par les serveurs AD. Je me connecte à mon ordinateur lorsque je suis connecté au réseau de ce domaine. Je peux afficher le TGT avec MIT Kerberos pour Windows ver. 4.0.1.

Je souhaite accéder à des ressources sur un domaine étranger, FR. Il n'y a pas d'approbation Kerberos entre LR et FR, mais ils autorisent le trafic TCP entre eux. Je demande un TGT pour FR avec son KDC (Red Hat IdM / FreeIPA) et saisis mon mot de passe avec succès. Encore une fois, je peux afficher le TGT avec MIT Kerberos pour Windows ver. 4.0.1. Je peux maintenant accéder aux ressources en FR via SSH sans qu'on me demande un mot de passe, malgré l'origine de LR.

Le problème est que lorsque j'obtiens le TGT pour FR, le TGT pour mon principal LR disparaît. Seul le FR TGT est visible dans MIT Kerberos. Si je verrouille mon ordinateur puis le déverrouille avec mon mot de passe, maintenant le FR TGT est parti, remplacé par un nouveau LR TGT.

Il semble que MIT Kerberos pour Windows ne puisse stocker qu'un seul TGT à la fois. Chaque TGT fonctionne complètement pour son domaine à toutes fins utiles. Comment puis-je configurer MIT Kerberos pour me permettre d'avoir deux TGT à la fois, un pour chaque domaine? Est-il possible de "compartimenter" avec plusieurs instances clientes, chacune pointant vers un KRB5_CONFIG différent et un keytab local? Si je ne peux pas, existe-t-il une implémentation Windows alternative de Kerberos 5 côté client qui le fera, même en l'absence d'approbation inter-domaines?

PS - Je ne veux pas de confiance. Impossible d'obtenir une confiance.

MISE À JOUR: J'ai omis certains de ces détails plus tôt parce que je pensais que cela pourrait confondre le problème. Mais d'après la réponse de Brad, cela pourrait être justifié. Je m'attends à ce que la plupart des logiciels locaux utilisent l'implémentation Windows intégrée de Kerberos et utilisent toujours le keytab LR.

Cependant, les utilisateurs expérimentés comme moi utilisent heimdal sous Cygwin pour SSH en FR. Je m'attends à ce que tout ce qui passe par les DLL Cygwin utilise heimdal et ne voit jamais le LR TGT (ce qui n'est pas le cas, du moins pas par défaut). Je kinit explicitement et je passe à autre chose.

La partie délicate vient pour les utilisateurs non avertis que je dois soutenir qui n'utilisent pas Cygwin mais utilisent PuTTY. PuTTY vous permet de spécifier à la fois le chemin d'accès à la bibliothèque et la DLL pour laquelle l'implémentation GSSAPI doit être utilisée. Par exemple, je configure des sessions SSH pour utiliser les DLL MIT Kerberos au lieu des DLL Windows intégrées. J'espérais qu'il y avait une DLL qui n'essayait jamais de trouver le LR TGT (comme heimdal) ou autorisait plusieurs TGT à partir de plusieurs domaines. Il n'a pas besoin d'avoir une fenêtre GUI comme MIT Kerberos, mais cela aide.

Eh bien, je ne dirai pas que cela NE PEUT PAS être fait avec Windows, mais je dirai que la limitation est basée sur la session. Le problème est que, pour chaque session, Windows met en cache un ticket. Lorsque vous verrouillez votre ordinateur puis le déverrouillez, une autre session est lancée et une nouvelle clé est demandée au KDC. La même chose se produit lorsque vous vous déconnectez puis vous reconnectez à votre ordinateur. Cette méthode est en fait la façon dont les autorisations utilisateur sont également déterminées pour les sessions serveur, ce qui signifie que la clé / ticket peut être mis en cache afin que chaque ressource serveur ou session que vous lancez n'ait pas à vous demander votre mot de passe, mais je n'ai jamais entendu / lu / recherché pour pouvoir en mettre en cache plusieurs.

Maintenant, vous savez probablement déjà que, compte tenu de vos connaissances que vous avez affichées dans votre question, je dirai que sur la base du fait que Windows stocke la clé que vous obtenez lorsqu'un TGT est émis et est basé sur une session, je ne le fais pas pense que c'est possible avec JUST Windows. Le MIT Kerberos pour Windows peut avoir un moyen d'initier deux sessions sous un seul utilisateur, mais même dans ce cas, je ne sais pas comment les ressources auxquelles vous accédez sauront quel ticket / paire de clés utiliser. Cela a-t-il du sens?

Veuillez consulter ceci pour une description de la façon dont Windows stocke les TGT / paires de clés.

Très bonne question d'ailleurs.

OK, j'ai trouvé une solution qui nécessite un peu plus de polissage, donc peut ne pas fonctionner dans tous les environnements.

Cela fonctionne avec:

1. MIT Kerberos pour Windows 4.0.1 avec les outils de support Windows (KSETUP.EXE, KTPASS.EXE)
2. PuTTY 0,63
3. Windows 7 SP1

Je cherchais dans la source MIT Kerberos et suis tombé sur le fichier README pour Windows . Les différentes valeurs du cache d'informations d' identification étaient particulièrement intéressantes . Il épouse une valeur par défaut d' API :, mais j'ai trouvé de façon surprenante mon registre en utilisant MSLSA: à la place.

J'ai joué avec différentes valeurs de ccname sous HKEY_CURRENT_USER\Software\MIT\Kerberos5. J'ai essayé MEMORY: au début, ce qui a conduit à un comportement intéressant. Lors de l'ouverture d'une session PuTTY, ma fenêtre MIT Kerberos Ticket Manager se restaurait et venait au premier plan, me demandant d'entrer les informations d'identification. Hou la la! Cela ne s'était jamais produit auparavant, mais hélas, PuTTY le rejetterait. La valeur qui a fait l'affaire pour moi était FILE:C:\Some\Full\File\Path. Je ne sais pas exactement comment sécuriser l'accès au fichier spécifié, je vais donc laisser cela comme un exercice pour le lecteur. J'ai eu le même comportement de fenêtre au premier plan, seul PuTTY l'a aimé cette fois. La fenêtre Ticket Manager a également finalement affiché les tickets LR et FR. Les tickets se sont avérés transmissibles et survivraient à plusieurs verrouillages / déverrouillages Windows. REMARQUE:assurez-vous de quitter complètement et de redémarrer le gestionnaire de tickets entre les modifications du registre. Je n'ai pas encore essayé de ccname d' API .

Je ne sais pas si cela fait une différence ou non, mais j'ai également joué avec KSETUP avant que cela ne fonctionne. Au début, un KSETUP sans paramètre ne ferait que me montrer des informations sur le LR. J'ai ajouté quelques informations sur le FR sur mon poste de travail local.

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

Pour moi, il semble qu'il y ait en fait un bogue dans Kerberos pour Windows.

J'ai trouvé ce qui suit:

Si j'utilise l'option "obtenir un ticket" dans la fenêtre KfW 4.0.1, cela fonctionne simplement (TM); Je peux cliquer sur le bouton "Obtenir un ticket" et acquérir des tickets supplémentaires par rapport aux tickets originaux que j'ai reçus lorsque je me connecte.

Si je clique sur l'option "par défaut" dans la fenêtre KfW, à partir de ce moment, à chaque fois que je clique sur "get ticket", le nouveau ticket remplacera le ticket par défaut, plutôt que d'ajouter une autre entrée à la liste des tickets connus. . La vérification du registre à ce stade montrera qu'une ccnameentrée (comme dans la réponse de Toddius) a été ajoutée. La suppression de cette entrée restaurera, de manière surprenante, le comportement précédent consistant à autoriser plusieurs tickets.

Suite à la réponse de Toddius, j'ai un collègue dans une situation similaire (Windows 7 Enterprise 64 bits, joint à un domaine AD, exécutant également MIT Kerberos pour Windows 4.0.1): sa copie de Kerberos Ticket Manager serait lui permettent seulement d'avoir un principal / un TGT. Chaque fois qu'il utilisait le bouton "Get Ticket" pour obtenir un TGT pour un principal différent, le principal précédent disparaissait.

J'ai examiné le fichier README et la plupart des clés de registre ont été définies comme prévu, à l' exception de la clé ccname sur le chemin HKEY_CURRENT_USER\Software\MIT\Kerberos5. Cette clé a été définie sur la valeur MSLSA:. Notre solution était de changer cela en API:. Plus précisément, les étapes étaient les suivantes:

1. Quittez Kerberos Ticket Manager, ainsi que toutes les autres applications (puisque vous allez redémarrer).
2. Dans le chemin du Registre HKEY_CURRENT_USER\Software\MIT\Kerberos5, remplacez la clé ccname par API:(API, puis deux-points).
3. Quittez regedit et redémarrez.
4. Après vous être reconnecté, exécutez Kerberos Ticket Manager et utilisez le bouton Obtenir le ticket pour obtenir le TGT de votre principal non-AD.

Avec les étapes ci-dessus, tout a fonctionné et mon collègue est désormais en mesure de voir plusieurs principaux / TGT à la fois.

Soit dit en passant, MIT Kerberos pour Windows apporte son propre ensemble de programmes en ligne de commande (comme klist), et ces programmes prennent en charge plusieurs caches d'informations d'identification. Sur mon système 64 bits, lorsque "C:\Program Files\MIT\Kerberos\bin\klist.exe" -A"j'exécute après avoir obtenu plusieurs TGT, je vois mon principal Active Directory dans le cache MSLSA, puis j'ai un cache d'API pour chaque principal supplémentaire.

PS C'est ma première entrée sur ce site, donc je n'ai pas pu l'ajouter en tant que commentaire à la réponse de Toddius. Toutes mes excuses!