Kerberos Debugging

Ein sehr interessanter BLOG-Beitrag: Kerberos Authentication Problem with Active Directory
http://blogs.technet.com/b/surama/archive/2009/04/06/kerberos-authentication-problem-with-active-directory.aspx

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.

  • Fehler auf dem Dienstservers...
    .. betreffen meist alle Clients, egal wo diese stehen.
  • Fehler auf dem Client oder Benutzer ...
    .. lassen sich meist auf wenige Clients festlegen, d.h. einige Benutzer können arbeiten während andere nicht zugreifen können
  • Fehler beim KDC oder Active Directory...
    .. wirken sich oft nur auf einen Server auf. Dann ist ein doppelter oder fehlender SPN eine häufige Ursache. In ganz schlimmen Fällen wird gar kein Ticket ausgestellt (z.B. wenn der KDC nicht funktioniert oder das AD nicht online ist. Solch ein Ausfall dürfte aber sehr deutlich an jeder Ecke ihres Netzwerks zu bemerken sein, so dass Sie schon alleine auf dem Server nachschauen.

Grundlegende Funktionsweise

Einen Fehler findet man am einfachsten, wenn man die Schritte abläuft, die bei der Nutzung durchgeführt werden. Hier eine Kurzfassung eines Browsers auf einem Client, welcher sich bei einem Webserver per Kerberos anmelden möchte.

  1. Client geht auf http://servername.domain.tld/verzeichnis/datei
  2. Browser macht DNS "Namensauflösung"
  3. DNS Stack liefert A-Record oder CNAME
    Kontrolle mit IPCONFIG Displaydns oder NSLOOKuP
  4. Browser verbindet sich mit A-Record Hostname:80 und fordert Content anonym an
    Kontrolle per Netmon wenn kein SSL
  5. Webserver sendet 401: "bitte anmelden mit "negotiate""
    Kontrolle per Netmon wenn kein SSL
  6. Browser prüft automatische Anmeldung möglich ist:
    z.B. ist Ziel in Zone "lokales Intranet"
    Browser prüft ob integrierte Anmeldung überhaupt aktiv
  7. Browser fordert TIcket vom DC für HTTP/a-recordname
    Kontrolle per Netmon wenn kein SSL
  8. KDC schaut im AD nach SPN:  HTTP/a-Recordname
    Test mit ldapsuche "(serviceprincipalname=http://a-recordname)"
  9. KDC erstellt Ticket und liefert aus
    Kontrolle per Netmon wenn kein SSL
    Mit aktivem Debugging kann der Prozess im Eventlog erkannt werden
  10. Windows Client übernimmt Ticket
    Kontrolle per Netmon wenn kein SSL
    Kontrolle per KERTRAY
  11. Browser fordert Content mit Ticket vom Webserver mit Ticket an
    Kontrolle per Netmon wenn kein SSL
  12. Webserver validiert Ticket und wenn OK -> liefert Daten aus
  13. Anzeige im Browser

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.

cscript adsutil.vbs get w3svc/1/root/NTAuthenticationProviders

  • 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.

215383 How to configure IIS to support both the Kerberos protocol and the NTLM protocol für network authentication

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.

Wer auf dem IIS auch ASP installiert hat, kann mit einem kleinen ASP-Script die Authentifizierung anzeigen lassen

<%
authType=UCase(Request.ServerVariables("AuTH_TYPE"))
authHeader=Request.ServerVariables("HTTP_AuTHORIZATION")
response.write " Authentication Method : " & authType & "<BR>"
LenAuthHeader = len(authHeader)
response.write " Protocol : "
if Len(authType ) =0 then response.write " Anonymous" 
else 
   if authType<>"NEGOTIATE" then response.write authType 
   else 
      if LenAuthHeader>1000 then response.write "Kerberos" 
      else response.write "NTLM"
%> 

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.

  • 262177 How to enable Kerberos event logging.

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