Workshop: Squid mit Benutzeranmeldung am Active Directory ausstatten

In vielen Unternehmen läuft der Zugang zum Web über Proxys. Die digitalen Mittelsmänner machen es den Admins einfach, den durchlaufenden HTML-Code und die Downloads der Benutzer einem Virencheck zu unterziehen. Oft fordert die Firmenpolicy auch, dass Benutzer sich am Proxy anmelden müssen. Auf diese Weise bekommen einzelne User oder Gruppen Rechte, zum Beispiel den Zugang zum Intranet oder Extranet, zugewiesen. Beim Browser poppt dann ein Fenster auf, das die Kennung und ein Passwort einfordert (Abbildung 2).

Aber eine Anmeldung am Proxy bedeutet für jeden PC-Arbeiter einen weiteren Benutzernamen und noch ein Passwort, die er sich merken muss. Das ist auch technisch betrachtet ärgerlich, wenn man eigentlich eine Single-Sign-on-Lösung im Hause hat - oft als Active Directory vom geliebten Mitbewerber Microsoft. Dann keimt schnell der Wunsch auf, den Proxy dazu zu überreden, die Anmeldeinformationen etwa des Windows-Domänencontrollers mit zu benutzen.

Dieser Artikel gibt eine Schritt-für-Schritt-Anleitung, um einen oder mehrere Squid-Server [1] mit ein wenig Unterstützung aus dem Samba-Projekt [2] so zu konfigurieren, dass sich die Benutzer mittels ihrer Active-Directory-Kontos (AD) geregelt den Zugang zum Internet verschaffen. Prinzipiell wäre die Squid-Authentifizierung gegen ein AD auch ohne die Weltenwanderer von Samba machbar. Das entsprechende Projekt ist aber im Jahr 2000 sanft entschlafen [3].

Teil 1: Samba konfigurieren

Außer Squid benötigen Sie Samba 3.x, Samba-Client, Samba-Winbind [2] und das Kerberos-Paket, das in den meisten Distributionen »krb5« oder ähnlich heißt. Sind alle Komponenten an Bord, können Sie mit der Konfiguration loslegen. Den Anfang macht die Samba-Konfigurationsdatei »smb.conf«, die Sie dem Listing 1 entsprechend umgestalten.

01 [global]
02 workgroup = myworkgroup   # Windows-Domänenname
03 security = ADS
04 realm = example.com       # FQDN der Domäne
05 password server = *       # Alle Password-Server in der Domäne akzeptieren
06 encrypt passwords = true  # Verschlüsselte Passwortübertragung
07 dns proxy = yes           # Domänen-Daten vom DNS beziehen
08 idmap uid = 10000-20000   # Lokaler reservierter UID-Bereich f. d. Domänenbenutzer
09 idmap gid = 10000-20000   # Lokaler reservierter GID-Bereich f. d. Domänengruppen
10 winbind separator = +     # Wie der Domänensuffix vom User getrennt wird, z.B.: myworkgroup+meier
[...]

Die zweite Datei, »/etc/nsswitch.conf«, ist nach der Samba-Installation oft schon angepasst. Dem prüfenden Blick sollte sie sich so präsentieren:

passwd: files winbind
group: files winbind

Als Nächstes können Sie den Server zur Windows-Domäne hinzufügen:

net join -U Domänen-Administrator

Nach Eingabe des Admin-Passworts sollte folgende Ausgabe den Erfolg bestätigen:

Using short domain name - myworkgroup
Joined 'HOSTNAME' to realm 'example.com'

Ein Tipp, falls das Hinzufügen zur Domäne nicht auf Anhieb funktioniert: Kontrollieren Sie sowohl auf dem Proxy als auch auf dem Domänencontroller die Uhrzeit! Stimmen sie nicht überein, kommt das Kerberos-Ticketsystem schnell aus dem Tritt. Am besten spendieren Sie allen Beteiligten einen NTP-Daemon.

Der NTLM-Auth-Mechanismus

Die NTLM-Authentifizierung (NT LAN Manager, [4]) macht nicht den Eindruck einer exakten Wissenschaft. Ein Beispiel dafür findet sich in den Logs, die mit Fehlern vom Typ »TCP-DENIED/407« geradezu gepflastert sind (Abbildung 1), obwohl aus Sicht des Benutzers alles funktioniert. Es handelt sich dabei um Kollateralschäden aus den einzelnen Anmeldeschritten des NTLM-Protokolls. Der gesamte Prozess, der zu den seltsamen Log-Einträgen führt, ist im Squid-Wiki ([5], deutsche Übersetzung [6]) erläutert. Der Titel "The gory details" (etwa: "Die grausamen Einzelheiten") trifft den Sachverhalt recht gut: 1. Der Client verbindet sich auf den Proxy und setzt eine Anfrage ohne alle Auth-Informationen ab. Das macht er für jede Anfrage von Neuem - gängig wäre, wenn eine Authentifizierung für eine definierte Zeitspanne gälte. 2. Der Server antwortet mit dem Statuscode »407« und einem »Proxy-Authenticate: NTLM Windows-Domänenname oder weitere Informationen«. Möglicherweise gibt es weitere Header, die auf andere Auth-Mechanismen hinweisen. Ein dem RFC 2616 widersprechender Bug im Internet Explorer (oder ein Feature?) fordert, von allen unterstützten Mechanismen zuerst NTLM zu nennen, sonst ignoriert ihn der IE. 3. Jetzt baut Squid die Verbindung ab und zwingt den Client eine neue zu initiieren. 4. Der Client baut sie auf und übergibt zusätzlich einen Header »Authorization: NTLM Base64-kodierte_Message«. Der Server antwortet wieder mit einem 407er (»proxy auth required«) und schickt dabei den Header »Proxy-Authenticate NTLM Base64-kodiertes_Challenge-Paket«. Von hier an muss die TCP-Verbindung aufrechterhalten bleiben. 5. Der Client schickt einen neuen GET-Request mit dem Header »Proxy-Authenticate: Base64-kodierte_NTLM-Antwort_auf_Challenge«, der den Benutzernamen, das Passwort (möglicherweise sogar in unterschiedlichen Encodings) und den Domänennamen enthält. 6. Wenn ein Fehler aufgetreten ist, geht es zum Punkt 1 zurück. Andernfalls führt der Proxy den »GET«-Befehl aus und fragt nicht mehr nach, solange die TCP-Verbindung besteht. Abbildung 1: Ein Blick ins Squid-Log fördert jeder Menge »TCP-DENIED/407«-Fehlermeldungen ans Licht – Funktionen sind jedoch nicht beeinträchtigt.

Abbildung 2: Der normale Benutzer bekommt von seinem Webbrowser ein Pop-up-Fenster gezeigt, wenn er sich authentifizieren muss.

Verbindung zum DC checken

Jetzt sind Sie soweit mit Samba durch - Sie dürfen dessen Daemon und den von Winbind (neu) starten:

/etc/init.d/smb restart
/etc/init.d/winbind start

Dank der Dienste präsentieren die beiden Kommandos

wbinfo -u
wbinfo -g

Listen aller gültiger Server-, System- und Domänenbenutzer (»-u«) und -gruppen (»-g«). Jetzt können Sie prüfen, ob E der Domänencontroller Sie als gültigen Benutzer mit definierter Gruppenzugehörigkeit erkennt.

Die dazu notwendigen Werkzeuge »ntlm_auth« und »wbinfo_group.pl« befinden sich durch Ihre Paketauswahl schon auf dem System. Auf dem Domänencontroller dürfen Gruppennamen übrigens Umlaute enthalten. Damit Squid in einem solchen Fall nicht stolpert, müssen erstens das Proxy-System UTF-8 unterstützen und zweitens Sie das eben genannte Skript »wbinfo_group.pl« geringfügig modifizieren (Listing 2).

01 # Original:
02 
03 # $user =~ s/%([0-9a-fA-F][0-9a-fA-F])/pack("c",hex($1))/eg;
04 # # test for each group squid sent in its request
05 # foreach $group (@groups) {
06 # group =~ s/%([0-9a-fA-F][0-9a-fA-F])/pack("c",hex($1))/eg;
07 
08 # Nach der Modifikation:
09 
10 $user =~ s/%([0-9a-fA-F][0-9a-fA-F])/pack("U",hex($1))/eg;
11 # test for each group squid sent in its request
12 foreach $group (@groups) {
13 $group =~ s/%([0-9a-fA-F][0-9a-fA-F])/pack("U",hex($1))/eg;