Kerberos Debugging

Wenn Sie die Funktionsweise von Kerberos und der Vergabe von Tickets auf Kerberosgrundlagen verstanden haben, dann können Sie schon fast alleine die Stellen identifizieren, an denen Sie Probleme eingrenzen können. Für eine Analyse sind die Fehlerbilder natürlich sehr vielfältig, so dass Sie zuerst ermitteln sollten, ob der Fehler auf dem Dienstservers, dem Client oder dem KDC liegt.

Fehlersuchbaum

Die Fehlersuche mit Kerberos ist nicht immer einfach, aber wenn Sie strukturiert vorgehen, sollten sie jede Umgebung ans Laufen bekommen. Hier eine Vorgehensweise für den Zugriff auf eine Webseite per Webbrowser. Sicher ist auch eine andere Reihenfolge möglich.

Ausgangs-Situation Prüfung Hilfs-Programm Analyse
Start Bekomme ich ein Ticket ? Kerbtray

Das Programm Kerbtray ist eine einzelne EXE, die jeder Benutzer ohne Installation einfach starten kann. Es zeigt die im lokalen Ticketspeicher vorhanden Kerberos Tickets an und ist damit ein idealer, weil schneller und einfacher Test

Starten Sie auf dem System mit dem Benutzernamen, der einen Zugriff auf eine Ressource durchführen will das Programm. Sie sehen zumindest ein einer Windows Umgebung immer ein paar Tickets. Schon durch die Anmeldung sollten die ein TGT haben, mit den Sie sich an Kerberos Distribution Service ausweisen, um weitere Tickets zu bekommen:

  • Kerbtray ist leer
    Dann gibt es ein grundlegendes Problem mit Kerberos in ihrem LAN und es stellen sich Fragen wie:
    • Ist ihr PC Mitglied der Domäne?
    • Sind sie als Benutzer der Domäne und nicht als lokaler Benutzer angemeldet
    • Kann er sich mit den DCs verbinden (NetDiag)
    • Nutzen Sie den richtigen DNS-Server (z.B.: um die Kerberos Server aufzulösen)
    • Stimmt die Uhrzeit der Server und des Clients (Datum nicht übersehen)
    • Sind sie in sehr vielen Gruppen (-> TicketSize)
    • Blockiert eine voreilige Firewall oder ein Virenscanner mit Filterfunktion die Verbindung.
  • KerbTray zeigt ein passendes Ticket an
    Dann brauchen Sie nicht mehr auf dem Client zu suchen, sondern müssen beim Server z.B.: über das Eventlog oder andere Mittel herausfinden, warum dieser das Ticket nicht annimmt oder bekommt. Folgende Fragen stellen sich:
    • Blockiert das Netzwerk die Übertragung, weil das Ticket zu groß ist
    • Verwirft der Server das Ticket, weil es zu groß ist ? (z.B.: IIS Request Buffer)
    • Das das Ticket für den Server schon abgelaufen (-> Zeit auf dem Server und Client prüfen)
  • Kerbtray hat Tickets aber das erforderliche Ticket ist nicht dabei
    Dann sollten Sie die weiteren Schritte abarbeiten, um die Ursache zu ermitteln

Wenn sie ein passendes Ticket bekommen haben, dann ist die Fehlersuche hier schon beendet, denn Sie haben ein Ticket. Dann könnte es nur noch m Server liegen, der mit dem Ticket nichts anfangen kann (z.B.: falsche Zeit etc.)
Kein Ticket Erreichbarkeit IPCONFIG
NSLookup
Telnet

Sie möchten eine Ressource im Netzwerk erreichen. wenn wir mal Verbindungen über Proxy Server außen vor lassen und die Anmeldung an internen Ressourcen betrachten, dann sollte der Hostname, der angegeben wird per NSLOOKUP auflösbar sein und die Verbindung zum TCP-Port auch mit einem TELNET möglich sein.

Zuerst prüfen wir daher, ob der Servername auflösbar ist. Starten Sie dazu aus einer DOS-Box:

nslookup servername

NSLookup sollte die IP-Adresse oder einen Alias zum richtigen Servername liefern. Ist der Name nicht auflösbar, dann brauchen Sie nicht weiter bei Kerberos zu suchen.

Ist der Name auflösbar, sollten wie einfach einmal eine Verbindung zu dem Server versuchen. Starten Sie dazu aus einer DOS-Box einen:

Telnet servername port

Ein Webserver ist in der Regel auf Port 80 oder 443 erreichbar. SQL antwortet meist auf 1433. Sie sollten in den meisten Fällen ein "Leeres schwarzes Fenster" bekommen. welche einige Zeit stehen bleibt. Kommt ein "nicht erreichbar", dann kann dies daran liegen, dass der Dienst nur mit dem Protokoll UDP arbeitet oder der Zugriff nur über einen Proxy möglich ist.
Erreichbarkeit sichergestellt Authentifizierung Netmon (wenn kein SSL)

Nehmen wir nun an, dass die Verbindung möglich ist und ihre Client (z.B. ein Internet Explorer) auf den Dienst zugreifen kann. Die meisten Programme greifen immer erst einmal "anonym" zu, woraus der Webserver mit einem 401.3-Fehler antwortet und dabei auch mitliefert, welche Authentifizierungsverfahren er unterstützt. Genau diese Information ist relevant, weil Sie damit zuverlässig erkennen können, ob der Server überhaupt "Kerberos" (NEGOTIATE) anbietet.
Für Verbindungen auf Webserver ist NETMON wieder ein gutes Mittel, solange die Verbindung nicht per SSL verschlüsselt ist. Sie sehen hier sehr einfach die Antwort des Webservers auf die erste Anfrage.

  • NEGOTIATE ist nicht enthalten
    Prüfen Sie auf dem Webserver, ob die "Integrierte Authentifizierung" aktiv ist. Eventuell müssen mit mit ADSUTIL.VBS in der Metabase prüfen, ob Negotiate eingestellt ist. Bei SQL-Servern ist zu prüfen, ob Kerberos aktiviert etc.
  • NEGOTIATE ist enthalten
    In diesem Fall bietet der Service die Anmeldung per Kerberos an und nun stellt sich wieder die Frage, was am Client nicht passt.
Ich bekomme kein Ticket Fragt mein Client überhaupt ? Netmon

Installieren Sie auf dem Client oder auf allen DCs, die einen Kerberos Distribution Center betreiben und vom Client gefragt werden, den Microsoft Netzwerk Monitor und setzen Sie einen Capture Filter auf "KerberosV5". Wann immer sie auf die Ressource zugreifen, sollten Sie die Anfrage an den Kerberos Distribution Service sehen und die Antwort darauf:

  • Ich sehe keine Kerberos-Anfrage
    • Prüfen sie noch einmal, ob der Dienst wirklich Kerberos als Authentifizierungsverfahren anbietet.
    • Prüfen Sie, ob ihre Anwendung auf den FQDN als Server zugreift. Viele Produkte nutzen Kerberos nicht mit kurzen Hostnamen
    • Zoneneinstellungen
      Der Internet Explorer nutzt Kerberos nur, wenn das Ziel vertrauenswürdig ist
  • Ich sehe die Anfrage aber keine Antwort
    • Kontrollieren Sie das Eventlog auf dem KDC auf Fehler.
    • Prüfen Sie mit dem NETMON auf dem DC, ob dieser das Paket versendet. Eventuell hindert eine Firewall oder eine VPN-Fragmentierung den Verkehr.
  • Antwort enthält Kerberos Ticket
    Dann gehen Sie noch mal einen Schritt zurück und schauen sie, warum das Ticket in Kerbtray nicht drin sein sollte. Vielleicht sehen Sie es hier nur nicht, weil der Prozess mit einem anderen Benutzer läuft ?
  • Antwort enthält Fehler und Kerberos Ticket wird nicht ausgestellt
    Dann ist die Fehlermeldung interessant, die in NETMON einfach zu sehen ist. Vielleicht "findet" der KDC einfach den gesuchten ServicePrincipalName nicht. Dann müssen Sie den SPN im AD eintragen. Abhängig von der Fehlermeldung sollten Sie erkennen, warum kein Ticket erstellt wird und dieses Problem lösen.

Diese Liste ist nur eine kurze Übersicht der Prüfungen und Abfolge. Die folgenden Kapitel gehen näher auf die verwendeten Tools ein: 

Kerbtray

Es gibt einfache Dinge, die sie bei der Fehlersuche mit Kerberos zuerst auf dem Client tun sollten. Mein erster Test ist immer die Kontrolle des lokalen Kerberos ticket Cache mit  KERBTRAY

Kerbtray
Win2003 http://www.microsoft.com/Downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en
Win2000 http://www.microsoft.com/downloads/details.aspx?familyid=4E3A58BE-29F6-49F6-85BE-E866AF8E7A88&displaylang=en

Dieses kleine Tool des Windows Ressource Kit sollte auf keinen USB.Stick des Helpdesk fehlen oder am besten direkt auf alle Clients verteilt werden (Wie NETDIAG, NLTest und andere hilfreiche Tools). Starten Sie das Tool und schauen sie, ob sie überhaupt ein Ticket für die gewünschte Ressource erhalten haben.

Kerbtray erscheint beim Start in der Taskleiste nur als kleines grünes Icon ohne "Splash-Screen" o.ä. Über "List Tickets" sehen Sie dann die aktuell vorhandenen Tickets auf dem Client:

In meinem Cache sind hier zwei Tickets, von denen eines ein "Host-Ticket für den Zugriff auf den Server srv01.msxfaq.local ist. Man sieht den Servicename und die Gültigkeitsdauer

JA ich habe ein gültiges Ticket (Name und Datum ok) NEIN ich habe kein Ticket

Dann können alle Punkte von Uhrzeit, KDC, Namensauflösung, ServicePrincipalName etc. als erledigt abgehakt werden. Es ist davon auszugehen, dass der Client das erhaltene Ticket auch an die Gegenstelle sendet und dort das Problem liegt.

  • IIS Authentifizierung

Dann ist allerdings die Liste länger: Hier ein paar Prüfpunkte:

  • AD: ServicePrincipalName
    Erster Blick sollte eine Suche im Active Directory nach dem SPN sein. Alternativ können Sie mit DumpSPN die Namen auch exportieren.
  • Server: Eventlog
    Prüfen Sie, ob Kerberos im Eventlog vielleicht etwas meldet
  • Client: DNS-Cache
    Gerade mit Browsern können Sie mit "IPCONFIG /DisplayDNS" sehr einfach die Liste der vor kurzem abgefragten DNS-Namen erhalten. Hier sollte der von ihnen angefragte Host auch auftauchen (wenn Sie nicht über einen HTTP-Proxy gehen)
  • Uhrzeit
    Kerberos Tickets haben eine Gültigkeitsdauer. Kerberos ist von korrekten Zeitdaten abhängig (Siehe auch Zeitsynchronisation in Netzwerken) Es kostet sie nur einen Blick auf die Uhr und Zeitzone, um diesen Anfängerfehler zu beheben. Das gilt später auch für die Server. Gerade "virtuelle Server" weichen auch gerne mal einige Minuten von der "Netzwerkzeit" ab.

Fehlersuche bei Webseiten

Wenn der Client aber durchaus einige Tickets im Cache hat oder der Zugriff auf andere Webseiten mit Authentifizierung funktioniert, dann scheint der entsprechende Dienst ein Problem zu haben. Für so einen einfachen Test reicht es ja schon ein Laufwerk mit einem Windows Server zu verbinden oder auf einem anderen Webserver mit IIS ein Unterverzeichnis der DefaultWebSeite anzulegen und nur "Integrierte Authentifizierung" zuzulassen und darin eine einfache default.htm anzulegen.

IIS Testverzeichnis

Das muss immer gehen. Leider sieht man im IISLog selbst dann nur, dass der Anwender angemeldet, aber nicht welches Protokoll verwendet wurde. Die "Integrierte Authentifizierung" beinhaltet nämlich sowohl Negotiate (Kerberos) als auch NTLM. Sie sollten dann aber für diese Webseite ein Ticket erhalten haben.

Wenn Sie ohne SSL arbeiten, dann ist ein Netzwerk-Trace mit NetMon3 o.ä. möglich. Damit können Sie genauer die HTTP-Requests an den Webserver und dessen Antworten mitschneiden. Die erste Anfrage des Browsers erfolgt dabei anonym, worauf er sich eine 403.4 Fehler einfängt. In dieser Fehlermeldung liefert der Webserver aber auch die möglichen Anmeldeverfahren mit. Sofern der Client noch kein Ticket hat, muss er nun ein Ticket vom KDC anfordern, was man ebenfalls sehr einfach mit einem Netzwerkmonitor mitlesen kann. Das erhaltene Ticket wird dann im Kerberos Ticketcache abgelegt und der Browser antwortet dann auf diese Fehlermeldung mit einer authentifizierten Anfragen.

Selbst wenn Sie nicht in die Pakete selbst hineinschauen können Sie die Anfrage an einen KDC (TCP Port 88) sehen. Fehlt dieses Anfrage, dann fordert der Client überhaupt kein Ticket an. Bei WebBrowsern wie dem Internet Explorer kann das durchaus auch an der Zoneneinstellung liegen. Der IE erlaubt eine "automatische Anmeldung" nur in bestimmten Zonen:

Oft liefern Webserver sogar sehr aussagekräftige Fehlermeldungen, die aber moderne Browser gerne hinter ihrer eigenen "schönen" Fehlerseite verbergen. So liefert ein IIS oder Apache durchaus eine "400 Request Bufer size exceeded", was ein deutlichen Zeichen für ein "zu großes" Ticket ist. (Siehe auch Kerberos Ticketsize). Um zuverlässig hier den Fehler einzukreisen, sollten sie auf dem IE die "freundlichen Fehlermeldungen" abschalten und vielleicht mit dem NetMon3 nachschauen, was wirklich übertragen wird. 

Fehlersuche im Eventlog

Wenn ein Client eine Ressourcen erreichen will und diese eine Anmeldung per Kerberos anbietet, dann muss sich der Client von einem KDC im Netzwerk erst ein Ticket besorgen. Auch diese Anfragen des Clients an den KDC können fehlerhaft sein. Über entsprechende Einträge in der Registrierung können Sie den KDC bzw. die Kerberos-Komponente zur Ausgabe von Debug-Meldungen konfigurieren. Dazu gibt es zwei Stellen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"LogLevel"=dword:00000001
"KerbDebugLevel"=dword:00ffffff

Ein Wert von "ffffffhex" aktiviert alle Einstellungen, die aber erst wirken, wenn der LogLevel auf einen Wert <>0 gesetzt wird. Die Details des Debuglevel finde Sie in "837361 Kerberos protocol registry entries and KDC configuration keys in Windows Server 2003" beschrieben.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kdc]
"KdcExtraLogLevel"=dword:00000002
"KdcDebugLevel"=dword:00000001

Die Bedeutung von "KdcDebugLevel" ist in "837361 Kerberos protocol registry entries and KDC configuration keys in Windows Server 2003" genauer beschrieben. Mit einer "1" werden Anfragen für unbekannte SPNs geloggt. Mit dem Wert "31dec" werden alle Fehler geloggt.

Kerberos Fehlersuche mit NETMON

Der Microsoft Netzwerk Monitor ist eine sehr effektive Software um Fehlern in der Konfiguration auf die Schliche zu kommen. Am einfachsten ist die Überwachung des Datenverkehr des betroffenen Clients. Wenn Sie den NETMON nicht auf dem Client installieren oder vom Switch keinen SPiegel-Port erhalten können, dann können Sie natürlich auch auf den Domänen Controllern die Zugriffe des Clients mitschneiden. Sie müssen dann allerdings meist auf mehreren DCs die Pakete mitschneiden.

Damit die Datenmenge sie nicht überflutet ist hier ein Capture-Filter angebracht. Netmon 3.3 kann schon beim Mitschneiden nur erwünschte Pakete puffern. Hier ein Beispiel einer erfolgreichen Ticketanforderung:

Sie sehen in Zeile 51 die Anforderung, welche in Zeile 52 beantwortet wird. Unten in der Datenausgabe sehen Sie, dass die ein Ticket für einen Zugriff auf den LDAP-Server NAWDC002 ist.

Ehe Sie ein Ticket für einen Server erhalten können, brauchen Sie ein MasterTicket (Ticket Granting Ticket, TGT). Hier sehen Sie diesen Handshake, bei dem mein Benutzer ein TGT anfordert, zuerst einen Fehler "PRE_AUTH_REQUIRED" bekommt und dann sich authentifiziert und letztlich in Zeile 8 das TGT bekommt.

Und hier sehen Sie eine Anfrage nach einem Ticket für eine Ressource, die kein Kerberos unterstützt oder für die es keinen Service Principal Name gibt, so dass der KDC kein Ticket ausstellen kann:

Das owa.netatwork.de natürlich nur ein "Alias" ist, der aber nicht als Service Principal Name im AD bei einem Computerobjekt hinterlegt ist, kann der KDC dafür natürlich kein Ticket ausstellen.

Weitere Links

Keywords: Kerberos