☰

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

tag-icon • tag-icon kerberos
Mehrere Realms und mehrere TGTs unter MIT Kerberos für Windows

Mein lokaler Computer verwendet Windows 7 Pro und gehört zum Bereich LR, der 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 Version 4.0.1 anzeigen.

Ich möchte auf Ressourcen in einem fremden Realm, FR, zugreifen. Zwischen LR und FR besteht kein Kerberos-Vertrauen, aber sie erlauben TCP-Verkehr untereinander. Ich fordere ein TGT für FR mit seinem KDC (Red Hat IdM / FreeIPA) an und gebe bei Aufforderung erfolgreich mein Passwort ein. Auch hier kann ich das TGT mit MIT Kerberos für Windows ver. 4.0.1 anzeigen. Ich kann jetzt über SSH auf Ressourcen in FR zugreifen, ohne nach einem Passwort gefragt zu werden, obwohl es von LR stammt.

Das Problem ist, dass, wenn ich das TGT für FR bekomme, das TGT für meinen LR-Hauptbenutzer verschwindet. Nur das FR-TGT ist in MIT Kerberos sichtbar. Wenn ich meinen Computer sperre und dann mit meinem Passwort entsperre, ist das FR-TGT jetzt weg und durch ein neues LR-TGT ersetzt.

Es scheint, dass MIT Kerberos für Windows immer nur ein TGT gleichzeitig speichern kann.Jedes TGT funktioniert im Grunde genommen vollständig für seinen Bereich. Wie kann ich MIT Kerberos so konfigurieren, dass ich zwei TGTs gleichzeitig haben kann, eines für jeden Bereich? Ist eine „Abschottung“ mit mehreren Clientinstanzen möglich, von denen jede auf eine andere KRB5_CONFIG und einen anderen lokalen Keytab verweist? Wenn dies nicht möglich ist, gibt es eine alternative Windows-Implementierung von clientseitigem Kerberos 5, die dies auch dann tut, wenn keine Vertrauensstellungen zwischen den Bereichen bestehen?

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

AKTUALISIEREN:Ich habe einige dieser Details vorhin ausgelassen, weil ich dachte, es könnte die Sache verwirren. Aber basierend auf Brads Antwort könnte es gerechtfertigt sein. Ich erwarteam meistenLokale Software würde die integrierte Windows-Implementierung von Kerberos nutzen und immer die LR-Keytab verwenden.

Power-User wie ich verwenden jedoch heimdal unter Cygwin, um per SSH auf FR zuzugreifen. Ich gehe davon aus, dass alles, was über Cygwin-DLLs läuft, heimdal verwendet und nie das LR TGT sieht (was es nicht tut, zumindest nicht standardmäßig). Ich kinit explizit und mache weiter.

Der schwierige Teil kommt für die Nicht-Power-User, die ich unterstützen muss und die Cygwin nicht verwenden, aber PuTTY. PuTTY lässt Sie sowohl den Bibliothekspfad als auch die DLL angeben, für die die GSSAPI-Implementierung verwendet werden soll. Ich konfiguriere beispielsweise SSH-Sitzungen so, dass sie MIT Kerberos-DLLs anstelle der integrierten Windows-DLLs verwenden. Ich hatte gehofft, dass es eine DLL gibt, die entweder nie versucht, das LR TGT zu finden (wie heimdal) oder mehrere TGTs aus mehreren Bereichen zulässt. Sie muss kein GUI-Fenster wie MIT Kerberos haben, aber es hilft.

Antwort1

Ich sage nicht, dass es mit Windows NICHT geht, aber ich sage, dassdie Einschränkung ist sitzungsbasiert. 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 initiiert und ein neuer Schlüssel vom KDC angefordert. Dasselbe passiert, wenn Sie sich von Ihrem Computer abmelden und dann wieder anmelden. Mit dieser Methode werden tatsächlich auch Benutzerberechtigungen für Serversitzungen bestimmt.Das bedeutet, dass der Schlüssel/das Ticket zwischengespeichert werden kann, sodass Sie nicht bei jeder Serverressource oder Sitzung, die Sie starten, nach Ihrem Kennwort gefragt werden müssen. Ich habe jedoch nie davon gehört/gelesen/recherchiert, dass es möglich ist, mehr als eines zwischenzuspeichern.

Nun, das wissen Sie wahrscheinlich schon, da Sie in Ihrer Frage Ihr Wissen unter Beweis gestellt haben. Ich sage also, dass ich aufgrund der Tatsache, dass Windows den Schlüssel speichert, den Sie erhalten, wenn ein TGT ausgestellt wird, und dass er sitzungsbasiert ist, nicht glaube, dass dies NUR mit Windows möglich ist. Das MIT Kerberos für Windows bietet möglicherweise eine Möglichkeit, zwei Sitzungen unter einem Benutzer zu initiieren, aber selbst dann bin ich mir nicht sicher, wie die Ressourcen, auf die Sie zugreifen, wissen würden, welches Ticket/Schlüsselpaar zu verwenden ist. Ist das sinnvoll?

Eine Beschreibung, wie Windows TGTs/Schlüsselpaare speichert, finden Sie hier.

Sehr gute Frage übrigens.

Antwort2

OK, ich habe eine funktionierende Lösung gefunden, die noch etwas ausgefeilt werden muss und daher möglicherweise nicht in allen Umgebungen funktioniert.

Dies funktioniert mit:

  1. MIT Kerberosfür Windows 4.0.1 mit Windows-Supporttools (KSETUP.EXE, KTPASS.EXE)
  2. Kitt0,63
  3. Windows 7 SP1

Ich habe in der Kerberos-Quelle des MIT nachgesehen und bin auf dieREADME für WindowsVon besonderem Interesse waren die unterschiedlichen Werte fürCache für Anmeldeinformationen. Es befürwortet einen Standardwert vonAPI:, aber ich habe überraschenderweise meine Registrierung mitMSLSA:stattdessen.

Ich habe mit verschiedenen Werten herumgespielt vonccnameunter HKEY_CURRENT_USER\Software\MIT\Kerberos5. Ich habe es versuchtERINNERUNG:was zu einem interessanten Verhalten führte. Beim Öffnen einer PuTTY-Sitzung wurde mein MIT Kerberos Ticket Manager-Fenster wiederhergestellt und in den Vordergrund gestellt, wobei ich aufgefordert wurde, Anmeldeinformationen einzugeben. Wow! Das war noch nie zuvor passiert, aber leider lehnte PuTTY es ab. Der Wert, der bei mir funktionierte, war FILE:C:\Some\Full\File\Path. Ich bin mir nicht ganz sicher, wie ich den Zugriff auf die angegebene Datei sichern kann, also überlasse ich das dem Leser als Übung. Ich bekam dasselbe Fenster in den Vordergrund, nur dass es PuTTY diesmal gefiel. Das Ticket Manager-Fenster zeigte schließlich auch sowohl die LR- als auch die FR-Tickets an. Die Tickets erwiesen sich als weiterleitbar und überstanden mehrere Windows-Sperren/-Entsperrungen.NOTIZ:Stellen Sie sicher, dass Sie den Ticket Manager zwischen den Registrierungsänderungen vollständig beenden und neu starten. Ich habe noch keineccnamevonAPI:noch.

Ich weiß nicht, ob das einen Unterschied macht oder nicht, aber ich habe auch herumgespielt mitKSETUPbevor dies funktionierte. Zuerst zeigte mir ein parameterloses KSETUP nur Informationen zum LR. Ich habe auf meiner lokalen Workstation einige Informationen zum FR hinzugefügt.

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

Antwort3

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

Ich habe Folgendes gefunden:

Wenn ich die Option "Ticket holen" im KfW 4.0.1-Fenster verwende, funktioniert es einfach(TM); ich kann auf die Schaltfläche "Ticket holen" klicken undzusätzlichTickets zu den Originaltickets, die ich beim Anmelden erhalten habe.

Wenn ich im KfW-Fenster die Option „Als Standard festlegen“ auswähle, wird ab diesem Zeitpunkt jedes Mal, wenn ich auf „Ticket abrufen“ klicke, das neue Ticketersetzenwelches Ticket auch immer die Standardeinstellung ist, anstatt einen weiteren Eintrag zur Liste der bekannten Tickets hinzuzufügen. Wenn Sie an dieser Stelle die Registrierung überprüfen, wird angezeigt, dass ein ccnameEintrag (wie in Toddius‘ Antwort) hinzugefügt wurde.Entfernendieser Eintrag stellt überraschenderweise das vorherige Verhalten der Zulassung mehrerer Tickets wieder her.

Antwort4

Im Anschluss an Toddius' Antwort habe ich einen Kollegen in einer ähnlichen Situation (Windows 7 Enterprise 64-Bit, Mitglied einer AD-Domäne, ebenfalls mit MIT Kerberos für Windows 4.0.1): Seine Kopie des Kerberos Ticket Managers erlaubte ihm nur einen Principal/ein TGT. Immer wenn er die Schaltfläche „Ticket abrufen“ verwendete, um ein TGT für einen anderen Principal abzurufen, verschwand der vorherige Principal.

Ich überprüfte dieLiesmichund die meisten Registrierungsschlüssel wurden wie erwartet gesetzt,außerfür dieccnameSchlüssel bei Pfad HKEY_CURRENT_USER\Software\MIT\Kerberos5. Dieser Schlüssel war auf den Wert eingestellt MSLSA:. Unsere Lösung bestand darin, diesen in zu ändern API:. Genauer gesagt waren die Schritte:

  1. Beenden Sie den Kerberos Ticket Manager sowie alle anderen Anwendungen (da ein Neustart erfolgt).
  2. Ändern Sie unter Registrierungspfad HKEY_CURRENT_USER\Software\MIT\Kerberos5dieccnameSchlüssel zu API:(API, dann Doppelpunkt).
  3. Beenden Sie regedit und starten Sie neu.
  4. Führen Sie nach der erneuten Anmeldung den Kerberos Ticket Manager aus und verwenden Sie die Schaltfläche „Ticket abrufen“, um das TGT Ihres Nicht-AD-Prinzipals abzurufen.

Mit den oben genannten Schritten hat alles funktioniert und mein Kollege kann nun mehrere Auftraggeber/TGTs gleichzeitig sehen.

Übrigens bringt MIT Kerberos für Windows einen eigenen Satz von Befehlszeilenprogrammen (wie klist) mit, und diese Programme unterstützen mehrere Anmeldeinformations-Caches. Auf meinem 64-Bit-System "C:\Program Files\MIT\Kerberos\bin\klist.exe" -A"sehe ich beim Ausführen nach dem Abrufen mehrerer TGTs meinen Active Directory-Prinzipal im MSLSA-Cache, und dann habe ich einen API-Cache für jeden zusätzlichen Prinzipal.

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

verwandte Informationen