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.
- Client geht auf http://servername.domain.tld/verzeichnis/datei
- Browser macht DNS "Namensauflösung"
- DNS Stack liefert A-Record oder CNAME
Kontrolle mit IPCONFIG Displaydns oder NSLOOKuP - Browser verbindet sich mit A-Record Hostname:80 und
fordert Content anonym an
Kontrolle per Netmon wenn kein SSL - Webserver sendet 401: "bitte anmelden mit "negotiate""
Kontrolle per Netmon wenn kein SSL - Browser prüft automatische Anmeldung möglich ist:
z.B. ist Ziel in Zone "lokales Intranet"
Browser prüft ob integrierte Anmeldung überhaupt aktiv - Browser fordert TIcket vom DC für HTTP/a-recordname
Kontrolle per Netmon wenn kein SSL - KDC schaut im AD nach SPN: HTTP/a-Recordname
Test mit ldapsuche "(serviceprincipalname=http://a-recordname)" - KDC erstellt Ticket und liefert aus
Kontrolle per Netmon wenn kein SSL
Mit aktivem Debugging kann der Prozess im Eventlog erkannt werden - Windows Client übernimmt Ticket
Kontrolle per Netmon wenn kein SSL
Kontrolle per KERTRAY - Browser fordert Content mit Ticket vom Webserver mit
Ticket an
Kontrolle per Netmon wenn kein SSL - Webserver validiert Ticket und wenn OK -> liefert Daten aus
- 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:
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 |
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.
cscript adsutil.vbs get w3svc/1/root/NTAuthenticationProviders
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:
|
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.
|
Dann ist allerdings die Liste länger: Hier ein paar Prüfpunkte:
|
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.
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" %>
- Quelle: Things to check when Kerberos
authentication fails using IIS/IE…
http://blogs.msdn.com/b/friis/archive/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iis-ie.aspx
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:
Komponente | Beschreibung |
---|---|
Kerberos Client |
Der Client fordert entsprechende Tickets vom Server an. Für eine Protokollierung ins lokale Eventlog können Sie folgende Einstellung aktivieren: 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
|
KDC |
Ein Mittschnitt auf dem Server ist aufwändiger, da Sie keine Client-IPs o.ä. filtern können und daher viele Logs erzeugt werden: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kdc] "KdcExtraLogLevel"=dword:00000002 "KdcDebugLevel"=dword:00000001 Mit einer "KdcDebugLevel=1" werden Anfragen für unbekannte SPNs geloggt. Mit dem Wert "31dez" werden alle Fehler geloggt.
|
Auf dem Server gibt es im Eventlog auch die Option, ein Logging zu aktivieren.
- 262177 How to enable Kerberos event logging
- Kerberos-Protokoll Registrierungseinträge und
KDC-Konfigurationsschlüssel in Windows
https://docs.microsoft.com/de-de/troubleshoot/windows-server/windows-security/kerberos-protocol-registry-kdc-configuration-keys - Aktivieren der Kerberos-Ereignisprotokollierung auf
einem bestimmten Computer
https://docs.microsoft.com/de-de/troubleshoot/windows-server/identity/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.4 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 DC02 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
- Kerberos SPN
- DumpSPN - Analyse der ServicePrincipalNamen, die der KDC sucht
- NetMon 3.4
- TokenSZ
www.microsoft.com/downloads/details.aspx?FamilyID=4A303FA5-CF20-43FB-9483-0F0B0DAE265C&displaylang=en - Kerbtray
www.microsoft.com/downloads/details.aspx?familyid=4E3A58BE-29F6-49F6-85BE-E866AF8E7A88 - Kerberos Authentication problems – Service Principal Name (SPN)
issues - Part 1
http://blogs.technet.com/askds/archive/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1.aspx -
How Kerberos Authentication - Tickets
http://technet.microsoft.com/en-us/library/cc961966.aspx - Troubleshooting Kerberos Errors
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx - 264921 How IIS authenticates browser clients
- 216052 How to Enable Kerberos Debugging in Windows 2000
- 262177 How to enable Kerberos event logging.
- 215383 How to configure IIS to support both the Kerberos protocol and the NTLM protocol für network authentication
- 837361 Kerberos protocol registry entries and KDC configuration keys in Windows Server 2003
- 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 - Using Kerberos with a Client Access Server Array or a Load-Balancing
Solution
http://technet.microsoft.com/en-us/library/ff808313.aspx - Configuring Kerberos Authentication für Load-Balanced Client Access
Servers
http://technet.microsoft.com/en-us/library/ff808312.aspx - RFC1510 - The Kerberos Network Authentication Service (V5)
http://www.faqs.org/rfcs/rfc1510.html - SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft
Windows
http://www.rfc-archive.org/getrfc.php?rfc=4559 - Kerberos Authentication Problem with Active Directory
http://blogs.technet.com/b/surama/archive/2009/04/06/kerberos-authentication-problem-with-active-directory.aspx