Kerberos oder nicht, das ist hier die Frage?
In dem heutigen Blogbeitrag möchten wir uns dem oft als sehr kompliziert dargestellten Thema Kerberos widmen. Es soll Klarheit über die Hintergründe und Auswirkungen im Projekt und das Troubleshooting im Fehlerfall schaffen. Eines gleich vorweg: Es ist nicht so komplex, wie oft behauptet, doch im Detail gibt es ein paar Stolpersteine. Aber warum dann überhaupt Kerberos? Ganz einfach, es bietet in großen Netzwerken die größtmögliche Sicherheitsstufe bei Anmeldevorgängen mit den Bordmitteln von Microsoft Windows Serverbetriebssystemen und ist Voraussetzung, sobald mehrere, getrennte Server Applikationsteile bereitstellen. Als weiteres Stichwort ist hier auch Single Sign-On zu nennen.
Zunächst ein bisschen Theorie. Bei Kerberos handelt es sich um ein Netzwerkauthentifizierungsprotokoll, entstanden Mitte der 1980er Jahre am Institut für Technologie Massachusetts (kurz: MIT). Die immer noch aktuelle Version 5 wurde 1993 verabschiedet und wird seitdem eingesetzt. Es ist also nichts Neumodisches und auch kein speziell für DeltaMaster entwickeltes Stück Software.
Nun ein kurzer Blick auf die generelle Funktionsweise:
Abb. 1: Generelle Funktionsweise
Wer fragt da jetzt was an? Der Anmeldeprozess sieht im Detail wie folgt aus (dies ist durchaus wichtig für das Verständnis insbesondere der anschließenden Szenarien für DeltaMaster):
- Der Benutzer meldet sich am Netzwerk mit seinem Benutzernamen und Passwort an.
- Die Authentifizierungskomponente (AS) des Key Distribution Centers (KDC) fragt das Active Directory mit den Kontoinformationen des Benutzers ab, um die Daten zu verifizieren.
- Der KDC stellt ein sogenanntes TGT (Ticket Getting Ticket) aus, mit dessen Hilfe der Benutzer berechtigt ist, Service Tickets innerhalb der Domäne anzufordern, ohne erneut seine Anmeldeinformationen eingeben zu müssen (ein TGT ist in der Standardkonfiguration für 10 Std. gültig).
- Sobald der Benutzer einen Dienst auf einem Server innerhalb der Domäne anfragt, wird das TGT erneut an den KDC geschickt, um von diesem ein Service Ticket zu bekommen.
- Die Ticket Granting Service (TGS) Komponente authentifiziert das TGT und vergibt bei Erfolg das Service Ticket. Dieses setzt sich aus einem Ticket und einem Sitzungsschlüssel zusammen.
Der Client nimmt nun das Service Ticket und fordert den Dienstserver zur Herstellung einer Sitzung auf. Der Server wiederum benutzt den Sitzungsschlüssel, um die Informationen des TGS zu entschlüsseln. Dadurch ist nun der Benutzer gegenüber dem Dienst authentifiziert. Das jetzt folgende Schaubild veranschaulicht uns mögliche Auswirkungen für unsere Kundenprojekte. Etwas komplizierter wird der Ablauf nämlich, wenn die Daten nur über getrennte Server im Netzwerk erreicht werden können (Typisches Szenario beim Einsatz der DeltaMaster WebOption).
Abb. 2: Kerberos Double Hop
Zusammenfassend bedeutet das, dass eine ganze Menge an Anfragen im Netzwerk hin- und her geschickt werden, und dabei können Fehler entstehen. Wir wollen uns hier und heute ein paar Szenarien entwickeln, um das Verständnis für den genannten Mechanismus zu verstehen und unsere Kunden an den entsprechenden Stellen korrekt beraten zu können. Grundsätzlich gilt, bei verteilten Anwendungen (Applikationen und Server) muss der Einsatz zumindest gedanklich geprüft werden. Überall dort, wo Sicherheitsprinzipale weitergereicht werden müssen, um zum Beispiel Berechtigungen durchzusetzen, kann Kerberos die Lösung sein. Bei den von uns eingesetzten OLAP-Anwendungen geht es auch ohne Kerberos (Stichwort: Effective UserName), sobald wir aber eine relationale Anwendung (z.B. erweiterte Stammdatenpflege über die WebOption) im Einsatz haben, kann Kerberos eine Voraussetzung werden.
Szenario 1 (DeltaMaster OLAP- und rel. DB-Anwendung, Zugriff per RichClient):
Anforderung:
- SQL + OLAP-DBs laufen auf einer gemeinsamen Maschine
- Berechtigungen relational in DeltaMaster-Anwendung und dynamisch in Analysis Services Rollen überführt oder
- direkt in SSAS-Rollen gepflegt
- Analysis Services Dienstkonto läuft unter Netzwerkdienst-Konto, muss weitreichende Rechte auf den Datenbanken besitzen
- Sicherheitsbedarf „normal“, nicht genauer vom Kunden spezifiziert
Konsequenz:
- NTLM-Authentifizierung reicht aus
Szenario 2 (DeltaMaster OLAP-Anwendung, Zugriff über DeltaMaster Web-Option):
Anforderung:
- SQL + OLAP-DBs laufen auf einer gemeinsamen Maschine, zusätzlich läuft auch hier der Internet Information Server (kurz: IIS)
- Benutzerberechtigungen müssen durchgesetzt werden
Konsequenz:
- NTLM-Authentifizierung reicht aus
Szenario 2 (DeltaMaster OLAP-Anwendung, Zugriff über DeltaMaster Web-Option):
Anforderung:
- SQL + OLAP-DBs laufen auf einer gemeinsamen Maschine, zusätzlich läuft auch hier der Internet Information Server (kurz: IIS)
- Benutzerberechtigungen müssen durchgesetzt werden
Konsequenz:
- Kerberos = Nein
Szenario 3 (DeltaMaster OLAP-Anwendung und rel. DB-Anwendung, Zugriff über DeltaMaster RichClient und/oder Web-Option):
Anforderung:
- SQL + OLAP-DBs laufen auf einer gemeinsamen Maschine
und
- IIS läuft auf dediziertem Webserver
- Berechtigungen relational in DeltaMaster-Anwendung gepflegt und dynamisch in Analysis Services Rollen überführt oder direkt in SSAS-Rollen gepflegt
- Hoher Sicherheitsbedarf an Zugriffsberechtigungen der Dienstkonten
Konsequenz:
- Kerberos für SQL und SSAS, da Rechtedelegierung notwendig
- Domänenkonto für SQL- und SSAS-Dienst
Um nun die DeltaMaster Web-Option mit Kerberos einsetzen zu können, sind ein paar Einstellungen in der DeltaMaster.Service.Exe.Config und bei der IIS-Konfiguration zu beachten. Diese sind bereits in der internen Dokumentation unseres Entwicklungsteams nachzulesen. Zusätzlich sind in einem der letzten Kundenprojekte noch ein paar Einstellungen am Internet Information Server notwendig gewesen, diese möchten wir nicht vorenthalten und sind in diesem Dokument abgelegt.
Handelt es sich bei der DeltaMaster-Anwendung um eine relationale Erfassungs-/Planungsanwendung, muss auch ein ServicePrincepalName (kurz: SPN) für den SQL-Datenbankdienst erstellt werden:
Setspn.exe –a MSSQLSvc/<servername(FQDN)> und Setspn.exe –a MSSQLSvc/<servername(NETBIOS)>
Achtung: Das Ausführen der setspn-Befehle erfordert Domänenadmin- oder Enterpriseadmin-Rechte, diese werden wir mit den bei Kunden für uns bereitgestellten Benutzern in den seltensten Fällen haben. Man kann nur empfehlen, die Einstellungen von der IT-Abteilung des Kunden umsetzen zu lassen, da im Zweifel wir als Berater nicht wissen können, ob nicht doch noch ein anderes System mit den relevanten Diensten kommuniziert, so können ungebetene Seiteneffekte vermieden werden.
Sollte es dennoch zu Fehlern kommen, hilft ein Tool zur Nachverfolgung der Kerberos-Tickets (Kerbtrayist an dieser Stelle durchaus zu empfehlen). Es kann darüber hinaus hilfreich sein, neben der Service.trace des DeltaMasterService auch weitere Protokollierungen des IIS zu aktivieren. Eine übrigens bekannte Meldung in Kombination IIS und Kerberos ist:
„HTTP 400 – Bad Request (Request header too long)“
Die Ursache liegt hier an der sogenannten MaxTokenSize, diese ist per RegistryKey änderbar, aber auch dabei gilt es, Vorsicht an den Tag zu legen: Selbst IIS 7.5 kann nur mit einer maximalen TokenSize von 16k umgehen, andere Applikationen unterstützen durchaus die von Microsoft empfohlene Maximalgröße von 64k. Und ob Sie es glauben oder nicht, in gewachsenen Active Directories kann das tatsächlich passieren, nämlich wenn die Gruppenmitgliedschaften zig-fach verschachtelt sind, so geschehen in dem oben angesprochenen Kundenprojekt.
Wir hoffen mit diesem Blogbeitrag ein wenig Licht ins Dunkel um den „griechischen Höllenhund (Cerberus)“ gebracht zu haben. Zum Ende noch ein paar nützliche Links und Quellen:
Grundlegendes Vorgehen:
http://technet.microsoft.com/de-de/library/cc754628(v=WS.10).aspx
Allgemeine Funktion von Kerberos:
http://blogs.technet.com/b/askds/archive/2008/03/06/kerberos-for-the-busy-admin.aspx
http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx
Troubleshooting:
http://serverfault.com/questions/396428/spns-kerberos-and-iis
Konfiguration und Details zu WindowsAuthentication Mode:
http://www.iis.net/configreference/system.webserver/security/authentication/windowsauthentication
Übersicht AD-Attribute und deren Bedeutung (Werte):
