NTLM-Auth: die grausamen Details

Ich schreibe gerade mit meinem Freund und Kollegen Daniel einen Artikel über Squid-Proxys mit NTLM-Auth für das Linux-Magazin.
In den Logfiles des Proxys wimmelt es bei eingeschaltetem NTLM-Auth von "TCP DENIED/407", obwohl aus Sicht des Benutzers als bestens funktioniert. Im Squid-Wiki gibt es dazu eine Erklärung mit dem Titel "NTLM Auth: the gory details". Hier ist, ziemlich frei übersetzt, die deutsche Fassung:


Der NTLM Auth-Mechanismus

1. Der Client verbindet sich auf den Proxy und setzt eine Anfrage ohne jegliche Auth-Informationen ab. Das macht er für jede Anfrage von neuem - normalerweise wäre es üblich, dass eine einmalige Authetifizierung für eine definierte Zeitspanne ausreicht.

2. Der Server antwortet mit dem Statuscode 407 und einem Header Proxy-Authenticate: NTLM - kein Windows-Domänenname oder weitere Informationen. Möglicherweise gibt es weitere Header, die auf andere unterstützte Auth-Mechanismen hinweisen. Es gibt einen Bug -oder ein Feature - im MSIE (alle Versionen), der dazu führt, dass NTLM zuerst von allen unterstützten Mechanismen genannt werden muss, sonst wird er ignoriert.
Das steht im Widerspruch zu RfC 2616, der besagt: "Der User Agent muss von allen angebotenen Auth-Mechanismen den stärksten auswählen, den er unterstützt".

3. An diesem Punkt baut Squid die Verbindung ab und zwingt den Client, eine neue zu initiieren.

4. Der Client baut die Verbindung neu auf und übergibt diesmal einen zusätzlichen Header "Authorization: NTLM weiteres_zeug", wobei weiteres_zeug ein base64-Klumpen ist, der dazu dient, das Weitere auszuhandeln.
Der Server antwortet wieder mit einem 407er ("proxy auth required") und schickt dabei den Header "Proxy-Authenticate NTLM noch_mehr_zeug", wobei noch_mehr_zeug ein Challenge-Paket in base64 ist.
Von hier an muss die TCP-Verbindung aufrechterhalten werden - sollte sie abreißen, geht das komplette Auth-Tänzchen von vorne los.

5. Der Client schickt einen neuen GET-Request mit dem "Header Proxy-Authenticate: NTLM nimm_dies", wobei nimm_dies die Antwort auf das Challenge-Päckchen, den Benutzernamen, Passwort (letzteres möglicherweise sogar zweimal, in unterschiedlichen Encodings) und Domänennamen enthält.

6. Wenn ein Fehler aufgetreten ist (zB falsches Passwort), geht alles nochmal von vorne los. War alles korrekt, führt der Proxy jetzt den GET-Befehl aus und fragt, solange die TCP-Verbindung besteht, nicht mehr weiter nach.
Bei der nächsten TCP-Verbindung geht allerdings alles wieder auf Anfang.