4.4 Authentifizierung und Kerberos

Authentifizierung hört sich auf den ersten Blick nicht nach einem »großen Thema« an – einfach Passwort eingeben und fertig. So einfach ist es dann häufig doch nicht, insbesondere wenn komplexere Szenarien zu bewältigen sind, in denen zwingend Kerberos benötigt wird. Da Authentifizierung und speziell Kerberos ein übergreifendes Thema ist, wird es in diesem einführenden Kapitel besprochen.

4.4.1 Authentifizierung vs. Autorisierung

Bevor wir intensiv das Thema Kerberos angehen, halte ich es für notwendig, die Begriffe Authentifizierung und Autorisierung exakt abzugrenzen.

• Authentifizierung: Hierbei wird festgestellt, wer tatsächlich vor dem Bildschirm sitzt. Dies kann mittels Benutzername und Passwort, mit Zertifikaten, anhand biometrischer Merkmale oder auf eine beliebige andere Weise geschehen.
• Autorisierung : Möchte ein authentifizierter Benutzer auf eine Ressource, beispielsweise eine Datei, zugreifen, wird geprüft, ob er dazu überhaupt berechtigt (d. h. autorisiert) ist.

Falls Sie sich abstrakte Begriffe nicht so gut merken können, gibt es hier ein kleines Analogon, das Sie als Eselsbrücke verwenden können (Abbildung 4.34):

• Jemand besucht eine fremde Firma und meldet sich am Empfang. Dort nennt er seinen Namen und erhält einen entsprechenden Besucherausweis. Damit ist er authentifiziert und für jeden als Besucher zu erkennen.

  Im Serverbereich ist es mit dem Nennen des Namens nicht getan, im Allgemeinen wird ja noch ein Passwort erfragt – schließlich soll die Authentifizierung ja sicher sein. In diesem Beispiel könnte eine sichere Authentifizierung durch Kontrolle des Personalausweises oder dergleichen erfolgen.

  

  Abbildung 4.34 Ein analoges Szenario: Der Benutzer wird am Empfang »authentifiziert« (d. h., er bekommt einen Besucherausweis); für das Betreten der einzelnen Räume ist er autorisiert – oder eben auch nicht.

• Wenn der Besucher nun im Bürogebäude herumgeht, wird es einige Räume geben, die er betreten darf, beispielsweise den Empfang, die Garderobe, die Toilette oder den Besprechungsraum. Das Hochsicherheitslabor, das Lager oder die Fertigungshalle darf er als Besucher nicht betreten. Bei jedem Raum kann man also die Frage stellen, ob ein Mitglied der Gruppe »Besucher« Zutritt hat.

  Wichtig ist aber, dass er nicht mehrfach authentifiziert werden muss, denn seine Identität und damit die Rolle, nämlich Besucher, ist ja bereits beim Betreten des Gebäudes bestimmt worden.

Dieses kleine Beispiel könnte man natürlich beliebig ausbauen. Etwas technischer ausgedrückt, lauten die »Erkenntnisse«:

• Keine Autorisierung ohne Authentifizierung (Ausnahme: »anonyme Benutzer«) – bevor man entscheiden kann, ob jemand Zugriff bekommt, muss seine Identität bekannt sein.
• Ein einmaliges Authentifizieren sollte genügen – und damit ein Anmeldevorgang. Beim Besuch in einer Firma bekommt man ja auch nicht mehrere Besucherausweise.

Das hört sich alles trivial an? Ja, das ist es im Grunde genommen auch. Sie können einen ganz kleinen Test machen und auf Abbildung 4.35 schauen: Geht es hier um Authentifizierung oder Autorisierung? (Antwort, rückwärts lesen: gnureisirotuA).

Abbildung 4.35 Kleiner Test: Geht es hier um Authentifizierung oder Autorisierung? (Die Antwort finden Sie im Text.)

Sie werden im Laufe des Buchs immer wieder auf die Aufgabenstellung »Authentifizierung« stoßen, und nicht immer sind die Szenarien simpel; freuen Sie sich schon jetzt auf die Active Directory Federation Services.

4.4.2 Kerberos – Funktionsweise

In einer Active Directory-Umgebung wird (sofern alle beteiligten Systeme neuer als NT4 sind) Kerberos als Authentifizierungsprotokoll verwendet. Durch Kerberos wird verhindert, dass jede Ressource die zugreifenden Clients selbst mehr oder weniger umständlich authentifizieren muss. Die Funktionsweise ist vereinfacht in Abbildung 4.36 dargestellt.

1. Zunächst nimmt der Client Kontakt mit dem Domänencontroller auf, genauer gesagt mit dem dort laufenden Authentication Service des Key Distribution Centers (KDC). Das KDC wird bei der Installation der Rolle »Domänencontroller« installiert. Der Client weist seine Identität nach, wird also anhand eines definierten Verfahrens (z. B. Eingabe von Benutzernamen und Passwort, mittels Smartcard oder anhand von biometrischen Merkmalen) authentifiziert.
2. Nach der erfolgreichen Authentifizierung erhält er ein Ticket Granting Ticket (TGT), das im flüchtigen Speicher des Clients aufbewahrt wird. Das TGT hat standardmäßig eine Gültigkeitsdauer von 10 Stunden.
3. Möchte der Benutzer auf eine Ressource zugreifen, fordert er mit seinem Ticket Granting Ticket (TGT) beim Ticket Granting Service (TGS, ebenfalls Teil des Key Distribution Centers) ein Ticket zum Zugriff auf eine bestimmte Ressource an (Service Ticket).
4. Wenn das TGT des Benutzers gültig ist, stellt der TGS ein Service Ticket aus, das u. a. einen Session Key enthält, der für die Ressource gedacht ist, auf die der Benutzer zugreifen möchte.
5. Mit der Übersendung des Service Tickets beginnt der Client seine Kommunikation mit der Ressource. Da das Service Ticket kryptografisch nachweislich vom Ticket Granting Server signiert und für die Ressource verschlüsselt ist, traut die Ressource der Echtheit des zugreifenden Clients. Der Client muss also nicht erst gegen das Verzeichnis authentifiziert werden.
6. Da die Ressource zweifelsfrei weiß, wer Zugriff verlangt, kann der Zugriffswunsch geprüft und genehmigt oder abgelehnt werden (Autorisieren). Ist die Autorisierung erfolgreich, kann der Datenaustausch beginnen.

   

   Abbildung 4.36 Vereinfachte Darstellung der Funktionsweise der Authentifizierung mit Kerberos

Die Funktionsweise von Kerberos wurde hier recht vereinfacht dargestellt, die genaue Definition findet sich in RFC 1420 (http://tools.ietf.org/html/rfc4120). Um das Missbrauchsrisiko zu minimieren, ist die Gültigkeit eines Service Tickets zeitlich sehr eingeschränkt (wenige Minuten). Die Zeit bzw. möglichst exakte Uhren sind für das Funktionieren von Kerberos sehr wichtig.

Kerberos mit zwei Domänen

In einer größeren Umgebung ist es möglich, dass ein Client auf eine Ressource zugreifen möchte, die außerhalb seiner Domäne liegt. Prinzipiell kann ein Ticket Granting Service nur Service Tickets für Clients aus seiner eigenen Domäne und nur für den Zugriff auf Ressourcen seiner Domäne erstellen. Eine Lösung wird also benötigt – und die funktioniert so, wie in Abbildung 4.37 gezeigt.

Abbildung 4.37 Wenn ein Client auf eine Ressource außerhalb seiner Domäne zugreifen möchte, erhält er ein Referral Ticket, mit dem er beim TGS der Domäne der Ressource ein Servcie Ticket anfordert.

1. Der Client fordert beim Ticket Granting Service (TGS) seiner Domäne ein Service Ticket für den Zugriff auf eine Ressource an. Der TGS kann zwar kein Service Ticket für diese Ressource erstellen, da sie in einer fremden Domäne ist – er erstellt stattdessen ein Referral Ticket.
2. Mit diesem Referral Ticket greift der Client auf den TGS der Domäne zu, in der sich die Ressource befindet, und fordert hier ein Service Ticket an.
3. Der TGS erstellt nun für den Zugriff auf die Ressource ein Service Ticket.
4. Der Client kann mittels des Service Tickets auf die Ressource zugreifen – zumindest ist er authentifiziert; ob er für den Zugriff autorisiert wird, entscheidet die Ressource.

Kerberos mit beliebig vielen Domänen

In einem wirklich großen Unternehmen werden nicht nur zwei, sondern einige Dutzend Domänen zu finden sein. Auch in einem solchen Szenario muss der Benutzer sich nur einmal anmelden, nämlich beim Authentication Service in seiner Domäne. Wie Sie in Abbildung 4.38 sehen können, wird der Client mittels Referral Tickets so oft weitergeleitet, bis er einen TGS erreicht, der ein Service Ticket für die benötigte Ressource ausstellen kann.

Abbildung 4.38 Kerberos Transitive Trusts ermöglichen es, dass der Benutzer sich nach einmaligem Authentifizieren mit sämtlichen Ressourcen des Unternehmens verbinden kann.

Die Abbildung zeigt die Funktion des Kerberos Transitive Trusts: Die obere und die untere Domäne haben keine direkte Beziehung zueinander. Trotzdem traut die untere Domäne der von der oberen Domäne vorgenommenen Authentifizierung des Benutzers. Sie tut dies, weil die mittlere Domäne der oberen Domäne traut.

Das klingt für einen Kerberos-Neuling beim ersten Lesen vielleicht ein wenig verworren. Das ist nicht schlimm, das geht jedem so. Glücklicherweise kann man die Kerberos-Tickets sogar visualisieren, was beim Troubleshooting außerordentlich hilfreich ist. Im Windows Server 2003 Resource Kit ist eine kleine Anwendung namens Kerbtray.exe vorhanden, die übrigens auch ganz hervorragend unter Windows Vista/7/8/8.1 und Windows Server 2008/2012 funktioniert (ab Windows Server 2008 ist mit klist.exe ein eigenes Werkzeug enthalten, das allerdings »nur« ein Kommandozeilenprogramm ist). Kerbtray.exe zeigt die zwischengespeicherten Kerberos-Tickets im aktuellen Benutzerkontext. In Abbildung 4.39 ist Kerbtray.exe in Aktion zu sehen. Selektiert ist dort ein Ticket Granting Ticket, und etliche weitere Tickets zum Zugriff auf Ressourcen sind ebenfalls zu erkennen. Bereits anhand des Screenshots von Kerbtray.exe kann man einige ganz grundlegende Aspekte besprechen:

• Ein Ticket wird stets für den Zugriff auf einen bestimmten Dienst ausgestellt. Auf dem Screenshot sieht man auch Tickets zum Zugriff auf Webserver, also beispielsweise HTTP/ubinfwww3.ubinf.intra – das ist übrigens ein Service Principal Name, ein Begriff, der im Kerberos-Umfeld immer wieder genannt wird und in der Praxis oft zu Problemen führt.
• Ein Ticket hat lediglich eine begrenzte Gültigkeit, nach deren Ablauf es erneuert werden muss.
• Ein Ticket enthält mehrere Flags, die unter anderem spezifizieren, was mit dem Ticket möglich ist. Damit die im nächsten Abschnitt besprochene Kerberos-Delegierung funktioniert, muss das Ticket Forwardable sein.

  

  Abbildung 4.39 Kerberos-Tickets können mit der Anwendung »Kerbtray.exe« bequem untersucht werden.

4.4.3 Delegier ung

Abbildung 4.40 zeigt ein Szenario, das man in dieser oder ähnlicher Form zunehmend häufiger findet:

• Die Anwender melden sich mit ihrer Windows-Identität an einer Webapplikation an.
• Die Webapplikation nimmt die Identität des Benutzers an. Bei ASP.NET-Applikationen wird dies durch die in der Abbildung gezeigten Einstellungen in der web.config realisiert.
• Die Webapplikation greift auf weitere Netzwerkressourcen im Netz zu, wobei dies mit der Identität des angemeldeten Benutzers geschehen soll.

Das System in der »Mitte« muss nicht unbedingt ein Webserver sein, in vielen Anwendungsszenarien ist aber genau dies der Fall. Die Beschreibung des Szenarios sieht zunächst auch ganz einleuchtend aus, der Teufel steckt aber im Detail, weshalb ein solcher Aufbau in vielen Anwendungsszenarien einfach nicht klappt. Das ist Grund genug, die Hintergründe zu besprechen und einige interessante Details über Kerberos zu lernen.

Abbildung 4.40 In dem hier gezeigten Szenario ist eine Delegierung der Identität notwendig.

4.4.4 Der Service Principal Name (SPN)

Kerberos basiert, mal etwas vereinfacht gesagt, darauf, dass die Dienste, die miteinander kommunizieren sollen, sich gegenseitig finden und gegenseitig authentifizieren können. Die Betonung liegt dabei auf gegenseitig. Wie Sie weiter vorne auf Abbildung 4.39 (linkes Bild) unschwer erkennen können, wird ein Ticket für den Zugriff auf genau eine Ressource erstellt. Für diese Ressouce muss ein Service Principal Name (SPN) im Active Directory vorhanden sein, ansonsten kann keine Kerberos-Authentifizierung stattfinden. Wenn ein generischer SPN vorhanden ist, also beispielsweise host/ubinfwww2.ubinf.intra, ist das allerdings ausreichend.

Die Service Principal Names kann man auf verschiedene Weise abfragen. Zwei Varianten davon sind:

• SPNs können mit dem Kommandozeilenwerkzeug setspn.exe abgefragt, gesetzt und gelöscht werden. setspn.exe ist im Windows Server 2000 Resource Kit enthalten, läuft aber auch auf anderen Betriebssystemen. Bei Windows Server 2008/2012 ist es standardmäßig installiert. Die Ergebnisse der Abfrage der SPNs eines Webservers und eines SQL Servers sind in Abbildung 4.41 gezeigt. Der SPN für den MSSQLSvc-Dienst wird automatisch erzeugt.

  

  Abbildung 4.41 Abfrage von Service Principal Names mit »setspn.exe«

• Die SPNs sind im Active Directory als Attribut des jeweiligen Computerkontos gespeichert. Wie später gezeigt wird, können auch zu »normalen« Benutzerkonten, die als Dienstkonten verwendet werden, SPNs vorhanden sein. Abbildung 4.42 zeigt die SPNs im Attribut-Editor des Windows Server 2008 AD-Verwaltungswerkzeugs, alternativ kann ADSI-Edit oder ein anderer LDAP-Browser verwendet werden.

Mit den SPNs gibt es in der Praxis nun zwei »Hauptprobleme«:

• Wie man in Abbildung 4.41 sehen kann, wird beispielsweise für den Webserver automatisch ein SPN für den »kurzen« Servernamen sowie für den FQDN erzeugt. Es ist natürlich überhaupt kein Problem, einen weiteren DNS-Eintrag zu erzeugen (z. B. mit dem Namen WWW oder intranet) und diesen auf den Webserver verweisen zu lassen. Tippt man diesen neuen zusätzlichen Namen im Browser ein, erfolgt eine korrekte Namensauflösung – aber es gibt keinen Dienst HTTP/www.ubinf.intranet oder HOST/www.ubinf.intranet. Folglich kann keine Kerberos-Authentifizierung erfolgen. Der Benutzer bekommt davon im Normalfall nichts mit, denn die Authentifizierung erfolgt dann statt mit Kerberos mit NTLM, womit der Zugriff gewährleistet ist. In einem Szenario wie aus Abbildung 4.40 gibt es allerdings Probleme, weil die Kerberos-Delegierung nun einmal eine Kerberos-Authentifizierung voraussetzt.
• Ein zweites wesentliches Problem besteht darin, dass zusätzliche SPNs manuell (!) erzeugt werden müssen, wenn Dienste nicht unter einem der eingebauten Accounts (Netzwerkdienst, Lokales System) betrieben werden. Wie man in Abbildung 4.42 klar und deutlich sehen kann, ist ein SPN stets das Attribut eines Kontos – standardmäßig des Computerkontos. Läuft der Dienst unter einem der eingebauten Konten, ist es auch vollkommen in Ordnung, dass der SPN ausschließlich beim Computerkonto definiert ist. Wenn der Dienst (bzw. der Anwendungspool im IIS) unter einem Domänenbenutzerkonto betrieben wird, muss ein zusätzlicher SPN, der im Attribut dieses Kontos eingetragen ist, erstellt werden – beispielsweise mit setspn.exe.

  

  Abbildung 4.42 Die SPNs werden in einem Attribut des Computer- oder Benutzerobjekts gespeichert.

Läuft ein Dienst unter einem Domänenbenutzerkonto und ist kein passender SPN erstellt worden, erfolgt keine Kerberos-Authentifizierung. Sofern möglich, erfolgt eine NTLM-Authentifizierung, ansonsten schlägt der Vorgang mangels erfolgreicher Authentifizierung fehl.

Übrigens: Falls ein Dienst unter einem lokalen Benutzerkonto (d. h. kein Domänenkonto und auch kein Netzwerkdienst oder Lokales System) ausgeführt wird, ist grundsätzlich keine Kerberos-Authentifizierung möglich.

In der Praxis sind fehlende SPNs ein häufiges Problem. Genauso problematisch ist es aber auch, wenn SPNs doppelt vorhanden sind. Wird beispielsweise der SPN HTTP/www.ubinf.intranet sowohl beim Computerkonto als auch bei einem als Dienstkonto verwendeten Benutzerkonto eingetragen, könnte (und wird) es Probleme geben. Das für die Ressource ausgestellte Kerberos-Ticket wird mit dem Schlüssel des zum SPN gehörenden Dienstkontos verschlüsselt – und wenn der Domänencontroller aufgrund der SPN-Doublette für das falsche Konto verschlüsselt, schlägt die Kerberos-Authentifizierung fehl. Man könnte natürlich zufällig Glück haben, aber im Fußball wie auch in der IT gilt normalerweise: »Mal verliert man, und mal gewinnen die anderen.«

4.4.5 Kerberos-Delegierung verwenden

Aus den vorherigen Abschnitten kann man bereits dunkel erahnen, dass vor der ersten erfolgreichen Kerberos-Delegierung einige Voraussetzungen zu erfüllen sind. Zunächst das Offensichtliche: Alle beteiligten Systeme müssen sich innerhalb einer Active Directory-Gesamtstruktur befinden.

Im zweiten Schritt wird in den Eigenschaften des Computerkontos des Webservers (Konfigurationsapplikation: Active Directory-Benutzer und -Computer) eingestellt, dass dem Computer bei Delegierung vertraut wird. Der Dialog in Abbildung 4.43 stammt, passend zu diesem Buch, aus einer Windows Server 2012-Domäne. In einer Umgebung mit Windows Server 2000-Domänencontrollern (oder entsprechenden Funktionsebenen) wird der Dialog übrigens ein wenig anders aussehen, weil die Möglichkeiten für die eingeschränkte Delegierung (Constrained Delegation) noch nicht vorhanden sind.

Nachdem dem Server dieses Recht gewährt worden ist, muss er neu gestartet werden. Da in der Praxis immer wieder Fragen auftauchen: Dieses Recht muss nur dem Webserver gewährt werden, nicht der Ressource (Datenbank, AD etc.), auf die zugegriffen werden soll.

Sofern der Webserver oder die Ressource nicht ein eingebautes Konto (Netzwerkdienst, Lokales System) als Dienstkonto verwenden oder der Aufruf mit einem anderen Namen als dem Standardnamen des Servers erfolgt, müssen die entsprechenden Service Principal Names (SPN) gesetzt werden. Dies kann beispielsweise mit setspn.exe geschehen.

Auf dem Internet Information Server (IIS) darf die Kerberos-Authentifizierung nicht abgeschaltet sein. Dies ist standardmäßig nicht der Fall und kann nur mittels eines Skripts (adsutil.vbs), also nicht versehentlich erfolgen. Wenn an dem IIS aber bereits viel »herumgebastelt« worden ist, könnte es da eventuell Probleme geben. In der IIS-Konfiguration taucht Kerberos übrigens namentlich nicht auf, vielmehr muss Negotiate aktiviert sein (Negotiate = aushandeln; d. h., es wird automatisch entschieden, ob Kerberos oder NTLM verwendet werden soll).

Abbildung 4.43 In den Eigenschaften eines Computer- bzw. Benutzerkontos kann festgelegt werden, dass diesem für die Delegierung vertraut wird.

Auf dem IIS muss für die entsprechende Webanwendung Windows-Authentifizierung aktiviert sein, und der anonyme Zugriff muss deaktiviert sein. Abbildung 4.44 zeigt, wie dies im IIS 7 (Windows Server 2008) konfiguriert wird; für die Konfiguration auf dem IIS 6 existiert ein vergleichbarer Dialog.

Abbildung 4.44 Die Aktivierung der Windows-Authentifizierung auf dem IIS7 des Windows Servers 2008 (identisch für Server 2012)

Letztendlich gibt es auch auf dem Client einige Anforderungen: Das Client-Betriebssystem muss Windows 2000 oder höher sein. Die aufgerufene Website muss sich in der Lokalen Intranetzone befinden, außerdem muss die Integrierte Windows-Authentifizierung aktiviert sein (Internetoptionen · Erweitert, Abbildung 4.45).

Abbildung 4.45 Im Client-Browser muss die »Integrierte Windows-Authentifizierung« aktiviert sein.

Was muss seitens der eigentlichen Webapplikation beachtet werden? Wenn diese während der ganzen Dauer der Benutzersitzung mit der Identität des Benutzers arbeiten soll, genügt der <identity impersonate="true"/> -Eintrag in der web.config. Beispielsweise muss der Verbindungsstring zum Zugriff auf die Datenbank für die Verwendung der integrierten Sicherheit konfiguriert werden – that’s it!

4.4.6 Shoot the Trouble

Das Problem bei vielen IT-Projekten ist bekanntlich, dass auf Anhieb nur selten alles wie gedacht funktioniert. Dies gilt speziell auch für die Kerberos-Delegation, sodass ein kurzer Überblick über Vorgehensweisen beim Troubleshooting hilfreich sein dürfte. Zunächst lässt sich mit dem zuvor erwähnten Kerbtray.exe-Utility prüfen, ob auf dem Client-PC überhaupt ein Kerberos-Ticket zum Zugriff auf die Webanwendung erstellt wurde (siehe auch Abbildung 4.39). Existiert kein Kerberos-Ticket, kann man davon ausgehen, dass der Client gar nicht erst versucht, sich mittels Kerberos anzumelden. Mögliche Ursachen sind beispielsweise, dass kein Service Principal Name gefunden werden kann oder dass der Browser die aufgerufene Website in die Internet-Zone »einsortiert« hat.

Durchaus hilfreich bei der Einrichtung der Kerberos-Delegation kann eine kleine Testapplikation sein, die den Anmeldestatus eines Benutzers auf einem Webserver zeigt. In Abbildung 4.46 ist eine solche Anwendung zu sehen:

• In der oberen Abbildung wird »nur« eine NTLM-Anmeldung durchgeführt.
• Im unteren Bild meldet sich der Benutzer mit Kerberos an, außerdem ist die Delegierung zulässig – also alles, was man für das in Abbildung 4.40 gezeigte Szenario benötigt.

  

  Abbildung 4.46 Eine kleine Testanwendung kann den Anmeldestatus eines Benutzers auf dem Webserver feststellen.

Eine gute Idee ist auch, sowohl auf dem IIS als auch auf dem Ressourcenserver die Überwachung der Anmeldeereignisse und Anmeldeversuche zu aktivieren. Dies wird im Snap-In Lokale Sicherheitsrichtlinie konfiguriert (Lokale Richtlinie · Überwachungsrichtlinie). Die überwachten Ereignisse werden im Ereignisprotokoll, Kategorie Sicherheit, aufgezeichnet. In Abbildung 4.47 ist die Protokollierung eines Anmeldevorgangs gezeigt. Windows Server 2008/2012 protokolliert sehr detailliert, man erkennt auch klar und deutlich das verwendete Authentifizierungsprotokoll.

Abbildung 4.47 Im Ereignisprotokoll (Kategorie »Sicherheit«) kann überprüft werden, mit welchem Authentifizierungsprotokoll der Zugriff auf den Server erfolgt.

Wenn also feststeht, dass entweder keine Kerberos-Anmeldung durchgeführt wird oder aber die Delegierung nicht angezeigt wird, ist der erste Schritt, nochmals genau die Voraussetzungen (siehe weiter vorn) zu überprüfen. Vermutlich ist ein »Handgriff« vergessen worden.

An dieser Stelle sei auch darauf hingewiesen, dass es ein paar Minuten dauern kann, bis Änderungen von den Systemen übernommen und umgesetzt worden sind: Man denke beispielsweise an die Replikationsintervalle der Domänencontroller und dergleichen. Weiterhin könnte es sein, dass Benutzer sich einmal ab- und wieder anmelden müssen.

Wenn die Voraussetzungen geprüft und erfüllt sind, die Kerberos-Anmeldung aber trotzdem partout nicht klappen will, ist die Wahrscheinlichkeit sehr hoch, dass etwas mit den Service Principal Names nicht stimmt. Wie bereits weiter vorn ausführlich erläutert wurde, basiert Kerberos darauf, dass die Dienstnamen gefunden werden. Da diese Thematik in weiten Teilen der »IT-Bevölkerung« ganz oder teilweise unbekannt ist, passiert häufig Folgendes:

• Auf einem Server mit einem »komplizierten« Namen läuft eine Webapplikation. Damit die Anwender möglichst einfach darauf zugreifen können, wird ein »einfacher« Name im DNS eingetragen. Gegebenenfalls werden im IIS auch Host-Header konfiguriert und dergleichen mehr.
• Das Ergebnis wird sein, dass keine Kerberos-Authentifizierung zustande kommt.

Anhand eines Beispiels ist das einfacher zu verstehen: Der eigentliche Name des Servers sei ubinfWWW3, der im DNS eingetragene einfache Name sei WWW3. Damit die Kerberos-Anmeldung gelingen kann, muss der Dienst ermittelt werden können, wofür entweder der SPN HTTP/www3 oder der SPN HOST/www3 vorhanden sein muss. Wurde dies nicht manuell konfiguriert, wird keiner dieser SPNs vorhanden sein. Standardmäßig vorhanden ist lediglich der SPN für den eigentlichen Namen des Servers, nämlich HOST/ubinfWWW3. In Abbildung 4.46 können Sie übrigens genau das Ergebnis dieses Beispiels nachvollziehen:

• Wird ubinfWWW3 aufgerufen, findet die Kerberos-Authentifizierung statt.
• Wird WWW3 aufgerufen, geht nur NTLM, obwohl der DNS-Eintrag auf denselben Server zeigt. Es ist aber kein SPN vorhanden.

Der fehlende Service Principal Name kann mit dem setspn.exe-Werkzeug hinzugefügt werden. Dieses ist im Windows Server 2008/2012 standardmäßig vorhanden, bei den Vorgängerversionen findet es sich im Resource-Kit. Der Aufruf lautet:

setspn -a http/WWW3 ubinfWWW3

Es empfiehlt sich übrigens, den FQDN direkt auch zu registieren. Nach einer Wartezeit wird die Anmeldung mittels Kerberos-Protokoll erfolgen.

Das Nichtvorhandensein eines SPNs ist also eindeutig ein Problem. Ebenso ist es aber auch absolut kritisch, wenn derselbe SPN für mehrere Server registriert ist. Das kann im Eifer des Gefechts passieren, beispielsweise wenn eine Webanwendung von einem Server auf einen anderen verschoben wird und der für den ursprünglichen Server registrierte SPN-Eintrag nicht gelöscht wird.

Man kann nun ein wenig SPN-Diagnostik auf mehrere Arten betreiben:

• Das setspn-Utility bietet Abfragemöglichkeiten, wobei die zum Windows Server 2008/2012 gehörende Version deutlich mehr Möglichkeiten bietet als die Vorgängerversion.
• Die Active Directory-Benutzer und -Computer-Konfigurationsapplikation von Windows Server 2008/2012 bietet einen Attribut-Editor, mit dem Sie das entsprechende Attribut einsehen können (siehe auch Abbildung 4.42).
• Ganz hartgesottene Active Directory-Zauberer können natürlich auch mit einem ADSI-Editor an die Sache herangehen und LDAP-Suchanfragen formulieren.

4.4.7 Kernelmodus-Authentifizierung im IIS 7

Es weitere »Eigenart« ist noch zu beachten: Falls der Anwendungspool der Website nicht unter einem der eingebauten Konten, also Netzwerkdienst oder Lokales System läuft, muss der SPN für das entsprechende Konto registriert werden. Der Befehl lautet also beispielsweise:

setspn -a http/www3spec ubinf\kwwwService

Zu beachten ist, dass keine doppelten SPNs registriert werden, sonst klappt’s nicht – wie schon zuvor besprochen.

• Wenn man das Active Directory-Objekt des Benutzerkontos anschaut (z. B. mit einem LDAP-Browser), wird man den neuen SPN-Eintrag in dessen servicePrincipalName-Attribut finden.
• Damit die Delegierung funktioniert, muss dem Dienstkonto für die Delegierung vertraut werden. Das funktioniert genauso wie bei einem Computerkonto (siehe Abbildung 4.43).

Bei der Nutzung des im Windows Server 2008/2012 vorhandenen Internet Information Server 7/7.5/8/8.5 müssen Sie eine wichtige Abweichung von dem zuvor Gesagten beachten. Bei der Konfiguration der Windows-Authentifizierung kann die Kernelmodus-Authentifizierung aktiviert werden, was übrigens standardmäßig der Fall ist (Abbildung 4.48). Neben der versprochenen Verbesserung der Authentifizierungsleistung führt diese Option zu einem ganz wesentlichen anderen Ergebnis: Das Kerberos-Ticket wird vom Computerkonto und nicht vom Dienstkonto entschlüsselt. Demzufolge muss der SPN für das Computerkonto und nicht für das eigentliche Dienstkonto des Anwendungspools registriert werden. Also nochmals im Klartext:

• IIS 6: Wenn ein Domänenbenutzerkonto als Identität des Anwendungspools verwendet wird, muss der SPN für das Benutzerkonto registriert werden.
• IIS 7: Wenn ein Domänenbenutzerkonto als Identität des Anwendungspools verwendet wird und die Kernelmodus-Authentifizierung nicht (!) aktiviert ist, muss der SPN für das Benutzerkonto registriert werden.
• IIS 7: Ist die Kernelmodus-Authentifizierung hingegen aktiviert, muss der SPN für das Computerkonto registriert werden.

  Kernelmodus-Authentifizierung abschalten

  Das Abschalten der Kernelmodus-Authentifizierung führt schnell zum gewünschten Ergebnis und ist aus der grafischen Konfigurationsoberfläche heraus zu erledigen. Der bessere Weg ist allerdings, das Attribut useAppPoolCredentials auf true zu setzen. Das muss allerdings in der XML-Konfigurationsdatei der Anwendung erledigt werden. Nähere Informationen dazu finden Sie in Abschnitt 17.6.6, »Webanwendungen und Kerberos«.

Abbildung 4.48 Diese Einstellung des IIS7 ist entscheidend dafür, ob die SPNs beim Computerkonto oder beim Konto für die Identität des Anwendungspools registriert werden müssen.

Achten Sie, wie bereits erwähnt, darauf, dass es keine doppelten SPNs gibt: Das gibt in jedem Fall Chaos, weil das Kerberos-Ticket dann in der Hälfte der Fälle für das falsche Konto ausgestellt wird. Wenn das Kerberos-Ticket für das falsche Konto erstellt wird (sei es durch doppelte/falsche SPNs oder durch die falsche »Reaktion« auf die Kernelmodus-Authentifizierung), äußert sich das typischerweise in folgendem Verhalten:

• Obwohl sich die aufgerufene Website in der lokalen Intranetzone des Browsers befindet (also die Anmeldeinformationen mittels integrierter Authentifizierung übertragen werden), wird nach Anmeldeinformationen gefragt.
• Nach drei vergeblichen Anmeldeversuchen wird die in Abbildung 4.49 gezeigte Fehlermeldung im Browser eingeblendet.

Für dieses Problem kann es zwar auch ein Dutzend (wenn nicht mehr) andere Gründe geben – es kann aber nicht schaden, nochmals sehr sorgfältig die SPN-Konfiguration zu überprüfen.

Abbildung 4.49 Wenn beim Aufruf einer Website zunächst mehrfach Anmeldeinformationen abgefragt werden und dann diese Meldung kommt, ist das vermutlich ein Kerberos-Problem. Die mögliche Ursache dafür sind falsch registrierte SPNs.

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.