Es war einmal ein wunderschöner, warmer virtueller Dschungel in Südamerika, und dort lebte ein Squid-Server. Hier ist ein Wahrnehmungsbild des Netzwerks:
<the Internet>
|
|
A | B
Users <---------> [squid-Server] <---> [LDAP-Server]
Wenn Sie UsersZugriff auf das Internet anfordern, squidwerden Sie nach Ihrem Namen und Ihrem Pass gefragt, Sie werden per LDAP authentifiziert LDAPund wenn LDAP dies zulässt, wird es Ihnen gewährt.
Alle waren glücklich, bis ein paar Sniffer den Passport im Pfad zwischen Benutzern und Squid [Pfad A] stahlen. Dieses Desaster geschah, weil Squid Basic-Authenticationdie Methode verwendete.
Die Dschungelbewohner versammelten sich, um das Problem zu lösen. Einige Hasen boten die Verwendung NTLMeiner Methode an. Schlangen wurden bevorzugt Digest-Authentication, da KerberosBäume sie empfahlen.
Schließlich boten die Dschungelbewohner viele Lösungen an und alles war verwirrend! Der Löwe beschloss, der Situation ein Ende zu setzen. Er rief die Regeln für Lösungen:
- Soll die Lösung sicher sein!
- Funktioniert die Lösung mit den meisten Browsern und Softwares (z. B. Download-Software)?
- Soll die Lösung einfach sein und kein weiteres großes Subsystem (wie einen Samba-Server) benötigen?
- Die Methode darf nicht von einer speziellen Domäne abhängen (z. B. Active Directory).
Dann bietet ein Affe eine sehr vernünftige, umfassende und clevere Lösung an und macht ihn zum neuen König des Dschungels!
können Sie erraten, was die Lösung war?
Tipp:
Der Weg zwischen squidund LDAPwird durch den Löwen bewacht, daher ist keine Lösung erforderlich, um ihn zu sichern.
Notiz:entschuldigt, wenn die Geschichte langweilig und chaotisch ist, aber das meiste davon ist wahr! =)
/~\/~\/~\ /\~/~\/~\/~\/~\ ((/~\/~\/~\/~\/~\)) (/~\/~\/~\/~\/~\/~\/~\) (//// ~ ~ \\\\) (\\\\( (0) (0) )////) (\\\\( __\-/__ )////) (\\\( /-\ )///) (\\\( (""""") )///) (\\\( \^^^/ )///) (\\\( )///) (\/~\/~\/~\/) ** (\/~\/~\/) *####* | | **** /| | | |\ \\ _/ | | | | \_ _________// Thanks! (,,)(,,)_(,,)(,,)--------'
Aktualisieren:
Massimoerklärt, dass die Authentifizierungsmethode zwischen Users- squidund squid- LDAPnicht dieselbe sein muss. Wir können eine beliebige Methode verwenden, um Authentifizierungsinformationen von Benutzern zu erhalten, und eine beliebige Methode, um die gesammelten Daten zu authentifizieren.
Es gibt jedoch ein Problem: Die Eingabe/Ausgabe aller Authentifikatortypen ist nicht gleich. Beispiel:
- Ein
BasicAuthentifikator sollte das Paar „Benutzername/Passwort“ in einer Zeile lesen und antworten,OKob das Benutzerkennwort korrekt ist oderERR - Ein
DigestAuthentifikator sollte ein lesenusername:realmund als hexadezimal kodiertesHA(A1)oder ein antwortenERR.
Obwohl es keine direkte Beziehung zwischen der Client-Squid-Methode und der Squid-LDAP-Methode gibt, müssen die vom Client gesammelten Daten mit der im Squid-LDAP-Teil verwendeten Methode kompatibel sein. Wenn wir also die Authentifizierungsmethode auf der Benutzerseite ändern, sollten wir möglicherweise auch unseren Authentifikator ändern.
Das Problem vereinfacht sich also wie folgt:
Auf der ersten Ebene suche ich (der Affe!) nach einer guten Authentifizierungsmethode auf der Benutzerseite. Welche Methode empfehlen Sie, welcheist sicher und wird von den meisten Browsern unterstützt? Ich bin verwirrt zwischen
NTLM,KerberosundDigest.Wo finde ich einen Authentifikator, der die Anmeldeinformationen der ausgewählten Methode unterstützt und über LDAP authentifiziert?
Antwort1
Kerberos ist keine Option für die HTTP-Authentifizierung. NTLM wird in keinem anderen Browser als dem Internet Explorer gut unterstützt. Basic ist nicht sicher, es sei denn, Sie setzen es hinter HTTPS, was Squid meines Wissens nach nicht kann. Sie müssen also auf Digest zurückgreifen.
Antwort2
Eine interessante Funktion, die Ihnen hier helfen könnte, ist, dass die Methode, die Squid verwendet, um den Client-Browser zur Authentifizierung aufzufordern (Pfad A), überhaupt nichts mit der Methode zu tun haben muss, die es verwendet, um die vom Benutzer angegebenen Anmeldeinformationen tatsächlich zu validieren (Pfad B). Dies bedeutet beispielsweise, dass Sie Squid dazu bringen können, mit Client-Browsern NTLM zu „sprechen“, aber dann könnte es Benutzer sehr wohl anhand der internen Benutzerdatenbank von Linux (/etc/passwd) validieren. Es gibtNEINDie mit NTLM (auf Pfad A) erworbenen Anmeldeinformationen müssen tatsächlich anhand einer Windows-Domäne (auf Pfad B) validiert werden. Dasselbe gilt für jede mögliche Kombination von clientseitigen und serverseitigen Authentifizierungsmethoden.
In Ihrem Fall bedeutet dies, dass Sie beispielsweise Squid sicher so konfigurieren können, dass von Client-Browsern eine NTLM-Authentifizierung anstelle einer Basisauthentifizierung angefordert wird, und dass Sie dafür in keiner Weise Samba/WinBind/AD/was auch immer verwenden müssen.
Sie können also jede beliebige Methode zur clientseitigen Authentifizierung wählen und die Benutzer dennoch weiterhin anhand eines LDAP-Servers validieren, nachdem sie ihre Anmeldeinformationen mit der ausgewählten Methode angegeben haben.
Die Magie geschieht natürlich in squid.conf:
#auth_param negotiate program <uncomment and complete this line to activate>
#auth_param negotiate children 5
#auth_param negotiate keep_alive on
#auth_param ntlm program <uncomment and complete this line to activate>
#auth_param ntlm children 5
#auth_param ntlm keep_alive on
#auth_param digest program <uncomment and complete this line>
#auth_param digest children 5
#auth_param digest realm Squid proxy-caching web server
#auth_param digest nonce_garbage_interval 5 minutes
#auth_param digest nonce_max_duration 30 minutes
#auth_param digest nonce_max_count 50
#auth_param basic program <uncomment and complete this line>
#auth_param basic children 5
#auth_param basic realm Squid proxy-caching web server
#auth_param basic credentialsttl 2 hours
#auth_param basic casesensitive off
Jede auth_paramAnweisung ermöglicht eine spezifische Authentifizierungfür Client-Browser(Pfad A), während der „Programm“-Teil festlegt, was Squid tatsächlich zur Validierung der von Benutzern bereitgestellten Anmeldeinformationen verwenden wird. Sie können hier jedes beliebige Authentifizierungsprogramm verwenden (auch ein benutzerdefiniertes), solange es eine Benutzer-ID und ein Kennwort empfangen und mit „Ja“ oder „Nein“ antworten kann.
Sie müssen lediglich den Authentifikator nehmen, den Sie für Ihre LDAP-Abfrage verwenden, und ihn in die Anweisungen „auth_param ntlm“ oder „auth_param digest“ einfügen, statt in die Anweisung „auth_param basic“, wo er sich jetzt befindet.
Aktualisieren:
Sie sollten unbedingt verwendensquid_ldap_authals Authentifikator, aber ich kann Ihnen nicht genau sagenWieohne Angaben zu dem konkreten LDAP-Server, den Sie verwenden.
Was die clientseitige Authentifizierung betrifft, sollte jede Methode gut sein. Ich bin mit NTLM sehr zufrieden und die meisten Browser unterstützen es heutzutage.
Eine solche Konfiguration würde in squid.conf folgendermaßen aussehen:
auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters>
Dadurch werden die Benutzeranmeldeinformationen (Pfad A) mithilfe von NTLM abgefragt und anschließend anhand eines LDAP-Servers (Pfad B) validiert. Diese „Parameter“ hängen jedoch streng von Ihrer LDAP-Implementierung und -Konfiguration ab.
Das könnte auch helfen:http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html.