Mehrere Bereiche und mehrere TGTs unter MIT Kerberos für Windows

Mein lokaler Computer verwendet Windows 7 Pro und gehört zu Realm LR, das von AD-Servern verwaltet wird. Ich melde mich bei meinem Computer an, während ich mit dem Netzwerk dieses Bereichs verbunden bin. Ich kann das TGT mit MIT Kerberos für Windows ver anzeigen. 4.0.1.

Ich möchte auf Ressourcen in einem fremden Bereich zugreifen, FR. Es gibt keine Kerberos-Vertrauensstellung zwischen LR und FR, aber sie ermöglichen TCP-Verkehr untereinander. Ich fordere ein TGT für FR mit seinem KDC (Red Hat IdM / FreeIPA) an und gebe mein Passwort erfolgreich ein, wenn ich dazu aufgefordert werde. Wieder kann ich das TGT mit MIT Kerberos für Windows ver anzeigen. 4.0.1. Ich kann jetzt über SSH auf Ressourcen in FR zugreifen, ohne nach einem Passwort gefragt zu werden, obwohl ich von LR stamme.

Das Problem ist, wenn ich die TGT für FR erhalte, verschwindet die TGT für meinen LR-Principal. In MIT Kerberos ist nur das FR TGT sichtbar. Wenn ich meinen Computer sperre und dann mit meinem Passwort entsperre, ist der FR TGT jetzt weg und wird durch einen neuen LR TGT ersetzt.

Es scheint, dass MIT Kerberos für Windows jeweils nur ein TGT speichern kann. Jedes TGT arbeitet in jeder Hinsicht vollständig für sein Reich. Wie kann ich MIT Kerberos so konfigurieren, dass ich zwei TGTs gleichzeitig habe, eine für jeden Bereich? Ist es möglich, mehrere Client-Instanzen zu "unterteilen", die jeweils auf eine andere KRB5_CONFIG und ein anderes lokales Keytab verweisen? Wenn ich nicht kann, gibt es eine alternative Windows-Implementierung von clientseitigem Kerberos 5, die dies auch dann tut, wenn keine Inter-Realm-Vertrauensstellungen vorhanden sind?

PS: Ich will kein Vertrauen. Ich kann kein Vertrauen bekommen.

UPDATE: Ich habe einige dieser Details früher weggelassen, weil ich dachte, dass dies das Problem verwirren könnte. Aber basierend auf Brads Antwort könnte dies gerechtfertigt sein. Ich gehe davon aus, dass die meisten lokalen Programme die integrierte Windows-Implementierung von Kerberos verwenden und immer die LR-Keytab verwenden.

Power-User wie ich nutzen jedoch heimdal unter Cygwin, um SSH in FR zu bringen. Ich erwarte, dass alles, was Cygwin-DLLs durchläuft, heimdal verwendet und das LR-TGT nie sieht (was zumindest standardmäßig nicht der Fall ist). Ich kinit explizit und gehe weiter.

Der schwierige Teil kommt für Nicht-Power-User, die ich unterstützen muss und die Cygwin nicht verwenden, aber PuTTY verwenden. Mit PuTTY können Sie sowohl den Bibliothekspfad als auch die DLL angeben, für die die GSSAPI-Implementierung verwendet werden soll. Zum Beispiel konfiguriere ich SSH-Sitzungen so, dass MIT Kerberos-DLLs anstelle von integrierten Windows-DLLs verwendet werden. Ich hatte die Hoffnung, dass es da draußen eine DLL gibt, die entweder nie versucht hat, das LR-TGT (wie heimdal) zu finden, oder mehrere TGTs aus mehreren Bereichen zugelassen hat. Es muss kein GUI-Fenster wie MIT Kerberos haben, aber es hilft.

Nun, ich werde nicht sagen, dass dies mit Windows nicht möglich ist, aber ich werde sagen, dass die Einschränkung sitzungsbasiert ist. Das Problem ist dann, dass Windows für jede Sitzung ein Ticket zwischenspeichert. Wenn Sie Ihren Computer sperren und dann entsperren, wird eine weitere Sitzung eingeleitet und ein neuer Schlüssel vom KDC angefordert. Das gleiche passiert, wenn Sie sich abmelden und wieder an Ihrem Computer anmelden. Mit dieser Methode werden Benutzerberechtigungen auch für Serversitzungen festgelegt. Dies bedeutet , dass der Schlüssel / das Ticket zwischengespeichert werden kann, sodass Sie bei jeder von Ihnen initiierten Serverressource oder Sitzung nicht nach Ihrem Kennwort gefragt werden müssen, aber ich habe noch nie gehört / gelesen / recherchiert, um mehr als eine zwischenspeichern zu können.

Jetzt wissen Sie wahrscheinlich bereits, dass ich es aufgrund Ihres Wissens, das Sie in Ihrer Frage angezeigt haben, aufgrund der Tatsache, dass Windows den Schlüssel speichert, den Sie erhalten, wenn ein TGT ausgestellt wird und sitzungsbasiert ist, nicht weiß Ich denke, es ist mit nur Windows möglich. Mit MIT Kerberos für Windows können möglicherweise zwei Sitzungen unter einem Benutzer initiiert werden, aber selbst dann bin ich mir nicht sicher, wie die Ressourcen, auf die Sie zugreifen, wissen, welches Ticket / Schlüssel-Paar verwendet werden soll. Ist das sinnvoll?

Hier finden Sie eine Beschreibung, wie Windows TGTs / Schlüsselpaare speichert.

Sehr gute Frage übrigens.

OK, ich habe eine funktionierende Lösung gefunden, die etwas mehr Politur benötigt und daher möglicherweise nicht in allen Umgebungen funktioniert.

Dies funktioniert mit:

1. MIT Kerberos für Windows 4.0.1 mit Windows-Supporttools (KSETUP.EXE, KTPASS.EXE)
2. PuTTY 0,63
3. Windows 7 SP1

Ich habe in der MIT Kerberos-Quelle gesucht und bin auf die README für Windows gestoßen . Von besonderem Interesse waren die unterschiedlichen Werte für den Credentials Cache . Es verwendet einen Standardwert von API : , aber ich habe meine Registrierung überraschenderweise stattdessen mit MSLSA: gefunden .

Ich habe mit verschiedenen Werten von ccname unter herumgespieltHKEY_CURRENT_USER\Software\MIT\Kerberos5 . Ich habe MEMORY ausprobiert : zuerst, was zu einem interessanten Verhalten führte. Beim Öffnen einer PuTTY-Sitzung wurde mein MIT Kerberos Ticket Manager-Fenster wiederhergestellt und in den Vordergrund gerückt. Ich wurde aufgefordert, Anmeldeinformationen einzugeben. Wow! Das ist noch nie passiert, aber leider würde PuTTY es ablehnen. Der Wert, der den Trick für mich tat, war FILE:C:\Some\Full\File\Path. Ich bin mir nicht ganz sicher, wie ich den Zugriff auf die angegebene Datei sichern soll, daher überlasse ich dies dem Leser als Übung. Ich habe das gleiche Verhalten von Fenster zu Vordergrund, nur PuTTY hat es diesmal gefallen. Das Ticket Manager-Fenster zeigte schließlich auch die LR- und FR-Tickets an. Die Tickets erwiesen sich als weiterleitbar und überlebten mehrere Windows Lock / Unlocks. HINWEIS:Stellen Sie sicher, dass Sie den Ticket Manager zwischen den Registrierungsänderungen vollständig beenden und neu starten. Ich habe noch keinen cc-Namen der API ausprobiert .

Ich weiß nicht, ob das einen Unterschied macht oder nicht, aber ich habe auch mit KSETUP herumgespielt, bevor dies funktioniert hat. Ein parameterloses KSETUP würde mir zunächst nur Informationen zum LR anzeigen. Ich habe einige Informationen zum FR auf meiner lokalen Workstation hinzugefügt.

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

Für mich sieht es ein bisschen so aus, als ob es tatsächlich einen Fehler in Kerberos für Windows gibt.

Ich habe folgendes gefunden:

Wenn ich die Option "Ticket erhalten" im KfW 4.0.1-Fenster verwende, funktioniert es einfach (TM). Ich kann auf die Schaltfläche "Ticket erhalten" klicken und zusätzliche Tickets zu den Originaltickets erwerben , die ich beim Anmelden erhalten habe.

Wenn ich die „Standard festlegen“ Option in der KfW Fenster schlagen, dann von diesem Zeitpunkt an jedes Mal traf ich „Ticket“, das neue Ticket ersetzen was auch immer Ticket der Standard ist, anstatt einen weiteren Eintrag in die Liste der bekannten Tickets . Wenn Sie die Registrierung zu diesem Zeitpunkt ccnameüberprüfen, wird angezeigt, dass ein Eintrag (wie in Toddius 'Antwort) hinzugefügt wurde. Durch das Entfernen dieses Eintrags wird überraschenderweise das vorherige Verhalten beim Zulassen mehrerer Tickets wiederhergestellt.

Nach der Antwort von Toddius habe ich einen Mitarbeiter in einer ähnlichen Situation (Windows 7 Enterprise 64-Bit, verbunden mit einer AD-Domäne, auf der auch MIT Kerberos für Windows 4.0.1 ausgeführt wird): Seine Kopie des Kerberos Ticket Managers würde Erlaube ihm nur einen Principal / einen TGT zu haben. Immer wenn er die Schaltfläche "Ticket erhalten" verwendete, um eine TGT für einen anderen Principal zu erhalten, verschwand der vorherige Principal.

Ich habe die README- Datei überprüft und die meisten Registrierungsschlüssel wurden wie erwartet festgelegt, mit Ausnahme des Schlüssels ccname am Pfad HKEY_CURRENT_USER\Software\MIT\Kerberos5. Dieser Schlüssel wurde auf den Wert gesetzt MSLSA:. Unser Fix war, das zu ändern API:. Insbesondere waren die Schritte:

1. Beenden Sie den Kerberos Ticket Manager zusammen mit allen anderen Anwendungen (da Sie neu starten).
2. Bei Registrierungspfad HKEY_CURRENT_USER\Software\MIT\Kerberos5, ändern Sie die ccname Schlüssel API:(API, dann Doppelpunkt).
3. Beenden Sie regedit und starten Sie neu.
4. Führen Sie nach dem erneuten Anmelden den Kerberos Ticket Manager aus und verwenden Sie die Schaltfläche Ticket abrufen, um die TGT Ihres Nicht-AD-Principals abzurufen.

Mit den obigen Schritten hat alles funktioniert, und mein Mitarbeiter kann jetzt mehrere Principals / TGTs gleichzeitig sehen.

Übrigens bringt MIT Kerberos für Windows seine eigenen Befehlszeilenprogramme (wie klist) mit, und diese Programme unterstützen mehrere Caches für Anmeldeinformationen. Wenn ich auf meinem 64-Bit-System "C:\Program Files\MIT\Kerberos\bin\klist.exe" -A"nach dem Abrufen mehrerer TGTs ausgeführt werde, wird mein Active Directory-Prinzipal im MSLSA-Cache angezeigt, und für jeden weiteren Prinzipal steht ein API-Cache zur Verfügung.

PS Dies ist mein erster Eintrag auf dieser Seite, daher konnte ich ihn nicht als Kommentar zu Toddius 'Antwort hinzufügen. Entschuldigung!