suatu ketika, ada hutan virtual yang indah dan hangat di Amerika Selatan, dan server cumi-cumi tinggal di sana. berikut ini adalah gambar persepsi jaringan:
<the Internet>
|
|
A | B
Users <---------> [squid-Server] <---> [LDAP-Server]
Ketika Users
permintaan akses ke Internet, squid
tanyakan nama dan paspor mereka, otentikasi mereka dengan LDAP
dan jika ldap menyetujuinya, maka dia memberikan mereka.
Semua orang senang sampai beberapa sniffer mencuri paspor di jalur antara pengguna dan squid [jalur A]. Bencana ini terjadi karena cumi menggunakan Basic-Authentication
metode.
Orang-orang hutan berkumpul untuk memecahkan masalah. Beberapa kelinci menawarkan penggunaan NTLM
metode ini. Ular lebih disukai Digest-Authentication
saat Kerberos
direkomendasikan oleh pohon.
Lagi pula, banyak solusi yang ditawarkan oleh orang-orang hutan dan semuanya bingung! Sang Singa memutuskan untuk mengakhiri situasi. Dia meneriakkan aturan untuk solusi:
- Haruskah solusinya aman!
- Solusi akan berfungsi untuk sebagian besar browser dan perangkat lunak (mis. Perangkat lunak unduhan)
- Haruskah solusinya sederhana dan tidak perlu subsistem besar lainnya (seperti server Samba)
- Tidak akan metode tergantung pada domain khusus. (mis. Direktori Aktif)
Kemudian, solusi yang sangat resonable-komprehensif-pintar yang ditawarkan oleh monyet, menjadikannya raja hutan yang baru!
dapatkah Anda menebak apa solusinya?
Tip:
Jalur antara squid
dan LDAP
dilindungi oleh singa, sehingga solusinya tidak harus mengamankannya.
Catatan: maaf jika ceritanya membosankan dan berantakan, tetapi sebagian besar itu nyata! =)
/~\/~\/~\ /\~/~\/~\/~\/~\ ((/~\/~\/~\/~\/~\)) (/~\/~\/~\/~\/~\/~\/~\) (//// ~ ~ \\\\) (\\\\( (0) (0) )////) (\\\\( __\-/__ )////) (\\\( /-\ )///) (\\\( (""""") )///) (\\\( \^^^/ )///) (\\\( )///) (\/~\/~\/~\/) ** (\/~\/~\/) *####* | | **** /| | | |\ \\ _/ | | | | \_ _________// Thanks! (,,)(,,)_(,,)(,,)--------'
Memperbarui:
Massimo menjelaskan bahwa metode otentikasi antara Users
- squid
dan squid
- LDAP
tidak harus sama. kita dapat menggunakan metode arbiter untuk mendapatkan informasi otentikasi dari pengguna dan metode arbiter untuk mengautentikasi data yang dikumpulkan.
Tetapi ada masalah: input / output dari semua jenis autentikator tidak sama. Sebagai contoh:
- sebuah
Basic
authenticator harus membaca "username password" pasangan dalam garis dan membalas sebuahOK
jika pengguna-pass benar atauERR
- sebuah
Digest
authenticator harus membacausername:realm
dan membalas hex-encoded dariHA(A1)
atauERR
.
Meskipun tidak ada hubungan langsung antara metode client-squid dan metode squid-ldap, data yang dikumpulkan dari klien harus kompatibel dengan metode yang digunakan di bagian squid-ldap. Karena itu, jika kita mengubah metode otentikasi di sisi pengguna, kita mungkin juga harus mengubah autentikator.
Jadi masalahnya disederhanakan menjadi:
Di tingkat pertama, saya (monyet!) Sedang mencari metode otentikasi yang baik di sisi pengguna. Metode mana yang Anda rekomendasikan yang aman dan didukung oleh sebagian besar browser ? Saya bingung antara
NTLM
,Kerberos
danDigest
.Di mana saya dapat menemukan autentikator yang mendukung informasi kredensial dari metode yang dipilih dan mengautentikasi melalui LDAP.
Jawaban:
Kerberos bukan opsi untuk otentikasi HTTP. NTLM tidak didukung dengan baik di peramban apa pun selain IE. Basic tidak aman kecuali Anda meletakkannya di belakang HTTPS yang tidak dapat dilakukan oleh squid AFAIK. Jadi Anda pergi dengan Digest.
sumber
digest_ldap_auth
(dilengkapi dengan squid) terhadap server LDAP.Negotiate
mekanisme; Saya telah berhasil menggunakannya dengan Apache dan Squid. SSL juga merupakan opsi untuk Squid, hanya Debian yang tidak mengaktifkannya karena masalah lisensi.Salah satu fitur menarik yang dapat membantu Anda di sini adalah bahwa metode yang digunakan Squid untuk meminta otentikasi klien (jalur A) sama sekali tidak perlu dikaitkan dengan metode yang digunakannya untuk benar-benar memvalidasi kredensial yang diberikan oleh pengguna (jalur B ). Ini berarti, fe, bahwa Anda dapat membuat Squid "berbicara" NTLM dengan browser klien, tetapi kemudian itu bisa sangat memvalidasi pengguna terhadap basis data pengguna internal Linux (/ etc / passwd). Tidak ada kebutuhan untuk kredensial yang diperoleh menggunakan NTLM (di jalan A) untuk benar-benar divalidasi terhadap domain Windows (pada jalur B). Hal yang sama berlaku untuk setiap kemungkinan kombinasi metode otentikasi sisi klien dan yang otentikasi sisi server.
Apa artinya ini dalam kasus Anda, adalah bahwa Anda dapat dengan aman mengkonfigurasi Squid untuk meminta otentikasi NTLM dari browser klien, dan bukannya otentikasi dasar, dan ini tidak akan mengharuskan Anda untuk benar-benar menggunakan Samba / WinBind / AD / apa pun.
Jadi Anda dapat memilih metode apa pun yang Anda inginkan untuk otentikasi sisi klien, namun tetap tetap memvalidasi pengguna terhadap server LDAP setelah mereka memberikan kredensial mereka menggunakan metode yang Anda pilih.
Keajaiban terjadi, tentu saja, di
squid.conf
:Setiap
auth_param
arahan memungkinkan otentikasi spesifik untuk browser klien (jalur A), sedangkan bagian "program" menentukan apa yang sebenarnya akan digunakan Squid untuk memvalidasi kredensial yang diberikan oleh pengguna. Anda dapat menggunakan program autentikator apa pun yang Anda inginkan di sini (bahkan yang ditulis khusus), asalkan dapat menerima id pengguna dan kata sandi dan menjawab "ya" atau "tidak".Anda hanya perlu mengambil autentikator apa pun yang Anda gunakan untuk melakukan permintaan LDAP Anda dan memasukkannya ke dalam pernyataan "auth_param ntlm" atau "auth_param digest", alih-alih dengan "auth_param basic" yang ada sekarang.
Memperbarui:
Anda pasti harus menggunakan squid_ldap_auth sebagai autentikator Anda, tetapi saya tidak bisa memberi tahu Anda secara persis bagaimana tanpa detail tentang server LDAP tertentu yang Anda gunakan.
Mengenai otentikasi sisi klien, siapa pun harus baik; Saya cukup senang dengan NTLM, dan sebagian besar browser mendukungnya saat ini.
Konfigurasi seperti itu akan terlihat seperti ini di squid.conf:
Ini akan meminta kredensial pengguna (jalur A) menggunakan NTLM, kemudian memvalidasinya terhadap server LDAP (jalur B); tetapi "parameter" tersebut sangat tergantung pada implementasi dan konfigurasi LDAP Anda.
Ini juga bisa membantu: http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html .
sumber
NTLM
?Kerberos
? yang mana dari mereka yang didukung pada sebagian besar browser dan sudah memiliki 'authenticator' yang mendukung ldap?auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters>
tidak berfungsi untuk saya, squid macet dan memulai kembali setiap kali pengguna mencoba untuk mengotentikasi. Mungkin karena menggunakan yang salahparameters
, tapi saya menggunakan parameter yang sama denganbasic
dan berfungsi ok. Ada ide?