© complize, Photocase.com

Wenn Sie sich irgendwie ein Active Directory eingehandelt haben, wollen Sie auch von dem angebotenen Single Sign-on profitieren. Ist auch ein Squid im Spiel, der den Zugriff der Benutzer aufs Internet regelt, stoßen sehr verschiedene Welten aufeinander. Ein kleiner Leitfaden für Standesbeamte.

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;

Mitglied im Klub

Zuerst schauen Sie, ob das System den Benutzernamen (hier: »meier«) und das Passwort (»mysecret«) akzeptiert:

/usr/bin/ntlm_auth -helper-Uprotocol=squid-2.5-basic

Nach dem [Enter] übergeben Sie dem Tool, das eigentlich nicht für diese Art Benutzerinteraktion gedacht ist, auf der Konsole:

myworkgroup+meier mysecret

Wenn die Verbindung zum Domänencontroller funktioniert, antwortet es mit »OK«. Von der Angabe »squid-2.5« sollten Sie sich nicht irritieren lassen. Sie bezeichnet nur das verwendete Protokoll – das Beispiel funktioniert auch mit jüngeren Squid-Versionen (und nur mit diesen). Danach schauen Sie, ob das Setup den Benutzer als Mitglied der Gruppe »Internet« erkennt:

/usr/sbin/wbinfo_group.pl

Sie tippen wieder nach dem [Enter] direkt in die Konsole, diesmal:

myworkgroup+meier Internet

»wbinfo_group.pl« antwortet mit »OK«.

Das auf Dauer lästige Eingeben des Domänennamens (hier: »myworkgroup«) können Sie sich sparen, wenn Sie in der »smb.conf« die Zeile »winbind separator = +« auskommentieren und

winbind use default domain = yes

hinzufügen. Künftig gilt: Ist der Benutzer bereits an der Domäne angemeldet, übergeben Internet Explorer oder Firefox die Anmeldedaten direkt an den Proxy. Andernfalls erscheint ein Pop-up-Fenster, das den Benutzer zur Eingabe seines Namens und Passworts auffordert.

Am Ende des ersten Teils der Konfiguration passen Sie mit den beiden Kommandos

chmod 750 /var/lib/samba/winbindd_privileged 
chown root:nogroup /var/lib/samba/winbindd_privileged 

noch einige Rechte für Samba im Dateisystem an.

Teil 2: Squid konfigurieren

Was Sie im ersten Teil schon als Trockenübung absolviert haben, integrieren Sie jetzt Listing 3 entsprechend in die »squid.conf«. Hier fällt auf, dass »ntlm_auth« zweimal vorkommt, mit unterschiedlichen Helper-Protokollen. Squid versucht es zunächst mit »ntlmssp« (SSP, Security Support Provider). Dabei überträgt es Benutzernamen und Passwort verschlüsselt. Sollte es bei dem Schritt zu einem Fehler kommen, startet Squid einen zweiten Versuch (»basic«), bei dem es dann die Anmeldeinformationen im Klartext überträgt.

01 auth_param ntlm program /usr/bin/ntlm_auth -helper-protocol=squid-2.5-ntlmssp
02 auth_param ntlm children 5
03 auth_param basic program /usr/bin/ntlm_auth -helper-protocol=squid-2.5-basic
04 auth_param basic children 5
05 auth_param ntlm max_challenge_reuses 0              # Ab Squid 2.6
06 auth_param ntlm max_challenge_lifetime 60 minutes   # sind diese Zeilen
07 auth_param ntlm use_ntlm_autonegotiate on           # unnötig!
[...]

Feiner abgestimmte Rechte machbar

Im »ACL«-Abschnitt der »squid.conf« komplettieren die Zeilen aus Listing 4 die grundlegende Konfiguration. An dieser Stelle können Sie natürlich weitere Regeln für einen feiner granulierten Zugriff auf Basis der Gruppenzugehörigkeit definieren.

Gibt es zum Beispiel zwei Gruppen, von denen die eine (»Alles«) unbeschränkten Zugriff erhält, die zweite (»Intranet«) aber nur ins Firmennetz surfen darf, sähe die Konfiguration aus wie in Listing 5. Die Gruppen »internetusers« und »intranetusers« sind entsprechend auf dem Domänencontroller definiert.

01 acl AuthUsers proxy_auth REQUIRED  # Benutzeranmeldung verlangen
02 
03 http_access deny !AuthUsers        # unangemeldete User ablehnen
04 http_access deny all               # Clean-Up-Regel

01 acl whitelist.txt dstdomain "/etc/squid/whitelist.txt"
02 acl Alles external nt_group internetusers
03 acl Intranet external nt_group intranetusers
04 acl AuthUsers proxy_auth REQUIRED
05 
06 http_access allow whitelist.txt Intranet
07 http_access allow Alles
08 http_access deny !AuthUsers
09 http_access deny all

Glockengeläut und Vermählung

Wenn Ihre PC-Benutzer nun auf den Proxy gelangen, um ins Internet zu kommen, merken sie davon entweder gar nichts – dann sind sie nämlich schon an der Domäne angemeldet – oder sie bekommen ein Pop-up-Fenster wie in Abbildung 2 zu sehen, in das sie Username und Passwort eintragen. Im Hintergrund läuft ein recht kompliziertes Response-Challenge-Protokoll ab, das der Kasten “Der NTLM-Auth-Mechanismus” versucht zu würdigen.

Eine kleine Besonderheit gibt es noch zu beachten: In der Regel müssen Benutzer ihre Passwörter in einem festgelegten Intervall wechseln, zum Beispiel alle 30 Tage. Während eine normale Windows-Sitzung die Gültigkeit des Passworts nur beim Einloggen prüft, geschieht dies bei Squid mit aktivierter NTLM-Authentifizierung bei jedem Zugriff aufs Neue.

Wenn also das 30-Tage-Intervall am 15. März um 11.30 Uhr abgelaufen ist, präsentiert Squid dem User ab 11.31 Uhr ein galantes »Access Denied«, bis er das Passwort ändert. Das wird die Flitterwochen aber hoffentlich nicht beeinträchtigen. (jk)