Mengapa menggunakan Kerberos dan bukan NTLM di IIS?

Ini adalah sesuatu yang saya tidak pernah bisa menjawab sebaik yang saya suka: Apa keuntungan sebenarnya dari menggunakan otentikasi Kerberos di IIS daripada NTLM?

Saya telah melihat banyak orang benar-benar berjuang untuk mengaturnya (termasuk saya sendiri) dan saya belum dapat menemukan alasan yang bagus untuk menggunakannya. Pasti ada beberapa keuntungan yang cukup signifikan, jika tidak, tidak akan sepadan dengan semua kesulitan untuk mengaturnya, bukan?

Dari perspektif Windows saja:

NTLM

• bekerja dengan baik eksternal (non-domain) dan internal yang klien
• berfungsi dengan akun domain dan akun pengguna lokal di kotak IIS
  • menggunakan akun domain, hanya server yang membutuhkan konektivitas langsung ke pengontrol domain (DC)
  • menggunakan akun lokal, Anda tidak perlu konektivitas di mana saja :)
  • Anda tidak perlu masuk sebagai pengguna yang dipermasalahkan untuk menggunakan kredensial
  • Selain : itu tidak jarang untuk DC kewalahan oleh NTLM server sibuk (IIS, Exchange, TMG / ISA, dll) dengan volume permintaan NTLM (untuk mengurangi: MaxConcurrentAPI, AuthPersistSingleRequest(palsu) ., Lebih cepat DC) ( Self bonus referensial .)
• memerlukan konektivitas klien hanya ke server IIS (pada port situs, tidak ada yang lain. yaitu Semuanya terjadi melalui HTTP (atau HTTPS).)
• dapat melintasi proxy apa pun yang mendukung HTTP Keep-Alive s
  • Anda mungkin dapat menggunakan TLS / SSL untuk mengatasi yang lain
• membutuhkan beberapa perjalanan bolak-balik untuk mengautentikasi, dengan paket kecil
  • (pola log adalah 401.2, 401.1, 200 dengan nama pengguna)
• tidak dapat digunakan dalam skenario di mana otentikasi hop ganda diperlukan
  • yaitu kredensial pengguna harus diteruskan ke layanan di komputer lain
• mendukung klien lama (<Win2000)
• Rentan terhadap perbedaan LM Auth Level (tidak cocok lmcompatibilitylevel)
• digunakan sebagai mundur oleh paket Negosiasi jika Curb gagal.
  • ( bukan "jika akses ditolak dengan Curb", Curb harus memutuskan untuk menggunakan NTLM - biasanya ini sepertinya tidak mendapatkan tiket. Jika klien mendapatkan tiket dan itu tidak sempurna, itu tidak menyebabkan mundur.)

Kerberos

• bekerja dengan saat ini klien domain-bergabung hanya
  • membutuhkan konektivitas klien ke AD DC (tcp / udp 88) DAN server (tiket diambil oleh klien dari DC melalui port Curb, dan kemudian diberikan ke server menggunakan HTTP)

• mungkin dapat melintasi proxy, tetapi lihat titik DC di atas: Anda masih harus berada di jaringan yang sama dengan DC aktif, seperti halnya server .

  • jadi secara teori jika Anda memiliki domain di mana klien yang terhubung internet mengobrol langsung ke DC yang terhubung internet, itu bisa diterapkan. Tapi jangan lakukan itu kecuali jika Anda sudah tahu itu.
  • Dalam skenario reverse proxy (ISA / TMG), yang protokol transisi kebutuhan server yang berada di jaringan itu, yaitu tidak klien ... tapi kemudian klien tidak benar-benar orang yang melakukan Kerberos sedikit (tentu - berpikir Formulir auth untuk Curb transisi).

• tiket berumur panjang (10 jam) yang berarti lebih sedikit komunikasi DC selama masa tiket - dan untuk menekankan: ini bisa menghemat ribuan hingga jutaan permintaan per klien selama masa itu - ( AuthPersistNonNTLMmasih merupakan hal; validasi Keracos PAC dulu adalah sesuatu)

• membutuhkan perjalanan bolak-balik tunggal untuk mengotentikasi, tetapi ukuran muatan otentikasi relatif besar (biasanya 6-16K) ( 401 , {(ukuran kode) token ukuran} 200 )
• dapat digunakan dengan delegasi (tolong, selalu dibatasi ) untuk mengaktifkan otentikasi Windows dari pengguna yang terhubung ke layanan berikutnya
  • misalnya, untuk memungkinkan UserAakses IIS, dan menggunakan akun pengguna yang sama ketika IIS mengakses SQL Server, ini adalah "delegasi otentikasi".
  • ( Terkendala dalam konteks ini berarti "tetapi tidak apa-apa", mis. Exchange atau kotak SQL lain)
• saat ini paket keamanan utama untuk Negosiasi otentikasi
  • berarti anggota domain Windows lebih suka ketika mereka bisa mendapatkannya
• membutuhkan pendaftaran SPN , yang bisa rumit. Aturan yang membantu .
• membutuhkan penggunaan nama sebagai target, bukan alamat IP
• alasan Curb mungkin gagal:
  • menggunakan alamat IP alih-alih nama
  • tidak ada SPN yang terdaftar
  • duplikat SPN terdaftar
  • SPN terdaftar dengan akun yang salah ( KRB_ERR_AP_MODIFIED)
  • tidak ada konektivitas DNS / DC klien
  • pengaturan proxy klien / Zona Intranet Lokal tidak digunakan untuk situs target

Sementara kami melakukannya:

Dasar

• bisa multi-hop. Tetapi melakukannya dengan memaparkan nama pengguna dan kata sandi Anda langsung ke aplikasi web target
  • yang kemudian dapat melakukan apa saja dengan mereka. Apa saja .
  • "Oh, apakah Admin Domain hanya menggunakan aplikasi saya? Dan apakah saya baru saja membaca email mereka? Kemudian setel ulang kata sandi mereka? Awww. Kasihan. "
• membutuhkan keamanan lapisan transport (yaitu TLS / SSL) untuk segala bentuk keamanan.
  • dan kemudian, lihat masalah sebelumnya
• bekerja dengan browser apa pun
  • (tapi lihat edisi pertama )
• membutuhkan perjalanan bolak-balik tunggal untuk mengotentikasi ( 401 , 200 )
• dapat digunakan dalam skenario multi-hop karena Windows dapat melakukan masuk interaktif dengan kredensial dasar
  • Mungkin perlu LogonTypedikonfigurasikan untuk mencapai hal ini (pikirkan default diubah ke network cleartext antara 2000 dan 2003, tetapi mungkin salah ingat)
  • tapi sekali lagi , lihat masalah pertama .
  • Mendapatkan kesan bahwa masalah pertama benar-benar penting? Ini.

Untuk menyimpulkan:

Curb mungkin rumit untuk diatur, tetapi ada banyak panduan ( satu saya ) di luar sana yang mencoba menyederhanakan proses, dan alat-alat telah meningkat pesat dari 2003 hingga 2008 ( SetSPNdapat mencari duplikat, yang merupakan masalah paling umum ; gunakanSETSPN -S kapan saja Anda melihat panduan untuk menggunakan -A, dan hidup akan lebih bahagia).

Delegasi yang terkekang sepadan dengan biaya masuk.

• Kerberos memiliki reputasi sebagai mekanisme otentikasi yang lebih cepat dan lebih aman daripada NTLM.
• Ini juga secara historis lebih mudah untuk terhubung melalui server proxy daripada NTLM, karena sifat berbasis koneksi NTLM.
• Yang mengatakan, seperti yang Anda perhatikan, Kerberos lebih sulit untuk bangun dan berjalan, dan membutuhkan koneksi ke AD yang tidak selalu praktis.

Pendekatan lain adalah mengatur otentikasi untuk negotiatedan menggunakan keduanya, bukan satu, bukan yang lain.

Dari Verifikasi Aplikasi Microsoft , yang mendeteksi kesalahan pengembang umum. Salah satu kesalahan itu adalah penggunaan NTLM :

NTLM adalah protokol otentikasi yang ketinggalan zaman dengan kelemahan yang berpotensi membahayakan keamanan aplikasi dan sistem operasi. Kekurangan yang paling penting adalah kurangnya otentikasi server, yang dapat memungkinkan penyerang menipu pengguna agar terhubung ke server palsu. Sebagai akibat dari otentikasi server yang hilang, aplikasi yang menggunakan NTLM juga dapat rentan terhadap jenis serangan yang dikenal sebagai serangan "refleksi". Yang terakhir ini memungkinkan penyerang untuk membajak percakapan otentikasi pengguna ke server yang sah dan menggunakannya untuk mengotentikasi penyerang ke komputer pengguna. Kerentanan NTLM dan cara-cara mengeksploitasinya adalah target meningkatnya aktivitas penelitian di komunitas keamanan.

Meskipun Kerberos telah tersedia selama bertahun-tahun banyak aplikasi masih ditulis untuk menggunakan NTLM saja. Ini tidak perlu mengurangi keamanan aplikasi. Namun Kerberos tidak dapat menggantikan NTLM di semua skenario - terutama di mana klien perlu mengautentikasi ke sistem yang tidak bergabung ke domain (jaringan rumah mungkin yang paling umum dari ini). Paket keamanan Negosiasi memungkinkan kompromi yang kompatibel dengan mundur yang menggunakan Kerberos bila memungkinkan dan hanya kembali ke NTLM ketika tidak ada pilihan lain. Mengalihkan kode untuk menggunakan Negosiasi alih-alih NTLM akan secara signifikan meningkatkan keamanan bagi pelanggan kami sambil memperkenalkan sedikit atau tidak ada kompatibilitas aplikasi. Bernegosiasi dengan sendirinya bukan peluru perak - ada kasus di mana penyerang dapat memaksa downgrade ke NTLM tetapi ini secara signifikan lebih sulit untuk dieksploitasi. Namun, satu peningkatan segera adalah bahwa aplikasi yang ditulis untuk menggunakan Negosiasi dengan benar secara otomatis kebal terhadap serangan refleksi NTLM.

Dengan kata terakhir hati-hati terhadap penggunaan NTLM: dalam versi Windows mendatang akan dimungkinkan untuk menonaktifkan penggunaan NTLM di sistem operasi. Jika aplikasi memiliki ketergantungan yang sulit pada NTLM mereka hanya akan gagal untuk mengotentikasi ketika NTLM dinonaktifkan.

Anda harus menambahkan poin yang sangat penting:

Kerberos telah menjadi protokol standar dan terbuka di Unix selama lebih dari 20 tahun sedangkan NTLM adalah solusi murni milik Microsoft dan hanya diketahui oleh Microsoft.

Kerberos diperlukan jika Anda perlu menyamar sebagai pengguna untuk mengakses sumber daya yang tidak ada di server iis.