2.5. Proxiable and Proxy Tickets (Proxy-fähige und Proxy-Tickets)

Überblick

Gelegentlich muss ein Principal einem Dienst erlauben, in seinem Namen eine Operation auszuführen. Der Dienst muss die Identität des Clients annehmen können, aber nur für einen bestimmten Zweck.

PROXIABLE-Flag

Das PROXIABLE-Flag in einem Ticket:

wird in der Regel nur vom Ticket-Granting Service ausgewertet
kann von Anwendungsservern ignoriert werden
teilt dem TGS bei gesetztem Flag mit, dass es in Ordnung ist, ein neues Ticket (aber kein TGT) mit einer anderen Netzwerkadresse auszustellen
wird gesetzt, wenn der Client es bei der anfänglichen Authentifizierung anfordert
standardmäßig fordert der Client, dass es bei Anforderung eines TGT gesetzt und bei Anforderung eines anderen Tickets zurückgesetzt wird

Anwendungsbeispiel

Ein Druckdienst-Client kann dem Druckserver einen Proxy geben, um auf die Dateien des Clients auf einem bestimmten Dateiserver zuzugreifen und so eine Druckanfrage zu erfüllen.

Netzwerkadressen

Kerberos-Tickets sind oft nur von den im Ticket ausdrücklich genannten Netzwerkadressen aus gültig
Als Richtlinienoption sind Tickets ohne angegebene Netzwerkadressen zulässig
Bei Erteilung eines Proxys MUSS der Client die neue Netzwerkadresse angeben oder anzeigen, dass der Proxy von beliebiger Adresse aus verwendet werden soll

PROXY-Flag

Das PROXY-Flag setzt der TGS in einem Ticket, wenn er ein Proxy-Ticket ausstellt. Anwendungsserver:

DÜRFEN dieses Flag prüfen
DÜRFEN vom Agenten, der den Proxy vorlegt, zusätzliche Authentifizierung verlangen, um eine Nachvollziehbarkeit (Audit Trail) zu ermöglichen

Referenz

Vollständige technische Details finden sich in RFC 4120 Abschnitt 2.5.