Warum Kerberos besser ist

Seit dem Jahr 2000 ist Kerberos in einer Windows Umgebung mit "Active Directory" das primäre Verfahren, um sich gegenüber Diensten auszuweisen. Natürlich ist Kerberos nichts "Windows spezifisches" sondern offen und kann auch von anderen Systemen verwendet werden.

Ticket statt Kennwort

Der größte Unterschied zwischen Kerberos und anderen Anmeldeverfahren wie "Basic" und "NTLM" ist, dass keine Kennworte mehr übertragen werden. Wenn Sie auf einen WebServer, Dateishare oder andere Ressource zugreifen, dann fordert sie das System zur Authentifizierung auf. Lange Zeit war es selbstverständlich einen Benutzernamen und ein Kennwort zu übermitteln. Das ist auch im Jahr 2017 immer noch möglich und im Internet sogar immer noch Standard. Dieses Verfahren hat aber auch den Nachteil, dass das Zielsystem nun die Zugangsdaten überprüfen muss. Bei lokalen Benutzern oder applikationsspezifischen Anmeldungen kann dies das Zielsystem schnell erledigt. Wenn mehrere Systeme sich einer zentralen Datenbank wie dem Active Directory bedienen, dann müssen diese Verzeichnisserver viele Anfragen beantworten können. Dieser zusätzliche Schritt verlangsamt die eigentliche Anmeldung. Wenn Sie nun noch über Trusts und über Standorte hinweg sich anmelden, kommt es schnell mal zu Engpässen.

ein Kerberos-Ticket können Sie sich wie einen Fahrschein im Nahverkehr vorstellen, der sie zur Benutzung einer Ressource berechtigt. Der Schaffner braucht gar nicht zu wissen, wie und wo sie die Karte gekauft haben. Er kontrolliert nur, ob sie gültig ist, d.h. der Inhaber, der Zeitraum und die Strecke passt. Ein Kerberos-Ticket wird auch vom Domain Controller ausgestellt. Die Anforderung kommt aber vom Anwender, der auf ein Zielsystem zugreifen will. Das Zielsystem prüft nur noch das Ticket aber fragt selbst nicht mehr den Domain Controller. Da Tickets einige Zeit (Default 6h) gültig sind, spart das jede Menge Arbeit und beschleunigt die Zugriffe. Ein Windows Dateiserver erhält also per Kerberos eine gesicherte Information über meine Identität und z.B. meine Gruppenmitgliedschaften. Der Server muss aber selbst z.B. über das Dateisystem NTFS prüfen, was ich denn nun real erreichen darf. (Autorisierung)

Übrigens: Kerberos funktioniert erst mal nur innerhalb ihres Forests aber natürlich nicht im "Internet". Aber auch hier gibt es immer mehr "Ticketsysteme", um eine vergleichbare Technik zu nutzen. In der Windows Welt heißt das System ADFS und wird z.B. für Office 365 aber auch andere Dienste genutzt.

Die eigentliche Anmeldung erfolgt also nur zwischen dem Anwender und "seinem" Domaincontroller. Hier kommen natürlich weiterhin Benutzername/Kennwort oder auch Zertifikate zum Einsatz. Aber das war es dann auch.

Weitere Gründe

.Es gibt eine ganze Menge von Gründen, warum sie Kerberos den anderen Anmeldeverfahren vorziehen sollten bzw. viele Dienste von sich aus schon "Negotiate" nutzen.

• NTLM-Anfragen an einen Server erfordern, dass dieser Server einen "Secure Channel" zu einem DC aufbaut. Die Anzahl dieser Channels auf einem DC ist aber beschränkt. Das ist also ein Problem z.B. für Server mit vielen Clients wie z.B. Dateiserver, Webserver, Exchange CAS-Server
• Für jeden Dienst ist nur ein Kerberos Token erforderlich. Bei NTLM muss für jede Session (auch zum gleichen Dienst und Outlook nutzt viele Sessions) ein eigenes Token erstellt werden
• Kerberos ist sicherer als NTLM und andere noch schwächere Anmeldeverfahren.
• DCs haben nur eine beschränkte Anzahl von Threads zur Bearbeitung von NTLM-Anfragen (Default = 2, Max = 150, siehe auch KB975363)
• Performance
  Die für NTLM erforderlichen Rückfragen vom Server zum DC etc. sind zusätzliche Pakete und vor allem bedeuten diese zusätzliche Verzögerungen und kosten Performance.

Aber es gibt auch Umfelder, in denen Kerberos nicht funktioniert, z.B. wenn ein Client aus dem Internet ohne Verbindung zum KDC arbeiten muss. Dann kann er kein Ticket erhalten. Dazu zählen aber nicht Clients, die per VPN oder Direct Access einen KDC erreichen können