System Center Internals

Hallo Community,

heute möchte ich die Kerberos v5 Authentifizierung vorstellen.
Es gibt fünf (optional sechs) Schritte bis ein User via Kerberos erfolgreich Authentifiziert wird und somit auf Ressourcen zugreifen kann.

KRB_AS_REQ:
Sobald sich ein Domainuser an einem Domaincomputer anmeldet, wird der KDC kontaktiert. Hier wird vom Client ein sogenanntes short-lived ticket auch TGT genannt angefordert. In diesem Ticket ist die Identität des Clients enthalten, bei Windows Clients ist hierbei die SID gemeint.

KRB_AS_REP:
Der AS (Authentication Service) erstellt anschließend ein TGT und einen Sitzungsschlüssel.
Mit dem Sitzungsschlüssel kann der Client die Kommunikation mit dem TGS entschlüsseln. Mit dem Erhalt des TGTs hat der Client jedoch noch keinen Zugriff auf Ressourcen. Ein TGT hat Standardmäßig eine Gültigkeit von 10 Stunden.

Nice to know:
Warum nutzt man TGT? Warum wird kein Ticket für die jeweilige Ressource ausgestellt?
Wenn der AS (Authentication Service) für alle Ressourcen ein eigenes Ticket ausstellen würde, müsste der User bei jeder neuen Verbindung zu einem Server oder Service erneut sein Password eingeben.
Das Erstellen eines TGTs gibt dem User ein gültiges Ticket um ein TGS beantragen zu können. Der Hauptvorteil des TGTs liegt also darin, dass User nur einmal das Kennwort eingeben müssen (SSO).

KRB_TGS_REQ:
Der Client benötigt Rechte für lokale sowie Netzwerkressourcen. Um Zugriff zu erlangen, schickt der Client eine Anfrage zum TGS um ein Ticket für die jeweilige Ressource zu erhalten. Dieses Ticket wird als Service Ticket bezeichnet. Um dieses Ticket zu erhalten, muss der Client das TGT, einen Authenticator und den Namen des Zielservers (SPN) bereitstellen.

KRB_TGS_REP:
Der TGS prüft das TGT und den Authenticator. Sofern dies akzeptiert wird, erstellt der TGS ein Service Ticket. Die Identität des Clients wird vom TGT auf das Service Ticket kopiert. Anschließend wird das Ticket an den Client geschickt.

Nice to know:
Der TGS kann nicht feststellen ob der User Zugriff auf den Zielserver erhält. Der Service stellt lediglich ein gültiges Ticket aus. Authentifizierung heißt nicht Autorisierung.

KRB_AP_REQ:
Nachdem der Client das Service Ticket besitzt, sendet er das Ticket mit einem neuen Authenticator zum Zielserver um Zugriff zu erlangen. Der Server entschlüsselt das Ticket, prüft den Authenticator und erstellt ein Zugriffstoken für den User auf Grundlage der SID im Ticket.

KRB_AP_REP:
Optional prüft der Client den Zielserver auf dessen Identität. Dieses Vorgehen wird „mutual authentication“ also Gegenseitige Authentifizierung genannt. Bei diesem Vorgehen nimmt der Ziel Server den Zeitstempel des Clients aus dem Authenticator. Anschließend wird dieser mit dem Sitzungsschlüssel der vom TGS bereitgestellt wurde entschlüsselt.

To be continued,
Phil