Apa akun IUSR dan IWAM di IIS?


23

Saya mencari penjelasan yang bagus tentang akun IUSR dan IWAM yang digunakan oleh IIS untuk membantu saya mengonfigurasi lingkungan hosting kami dengan lebih baik:

  • Kenapa mereka ada di sana?
  • Apa perbedaan di antara mereka?
  • Apakah namanya berarti sesuatu yang bermakna?
  • Apakah ada perubahan praktik terbaik yang harus saya lakukan?
  • IIS juga memberi saya opsi untuk menjalankan kumpulan aplikasi sebagai Layanan Jaringan, Layanan Lokal atau Sistem Lokal. Haruskah saya?
  • Server web saya adalah bagian dari domain, bagaimana hal ini mengubah banyak hal?

Tampaknya umum untuk membuat versi Anda sendiri dari akun-akun ini ketika menyebarkan beberapa situs ke server yang menimbulkan beberapa pertanyaan tambahan:

  • Kapan saya ingin membuat akun IUSR dan IWAM saya sendiri?
  • Bagaimana cara saya membuat akun tambahan ini sehingga mereka memiliki izin yang benar?

Saya menggunakan IIS 6 dan dan IIS 7 dengan sebagian besar konfigurasi default.

Jawaban:


33

IUSR dan IWAM kembali ke masa-masa awal IIS ketika Anda menginstalnya secara terpisah (bukan sebagai komponen OS). Secara default, jika situs web mengizinkan otentikasi anonim, akun IUSR digunakan sehubungan dengan izin pada OS. Ini dapat diubah dari default. Ada beberapa rekomendasi keamanan untuk setidaknya mengganti nama akun, jadi itu bukan akun "dikenal", seperti ada rekomendasi untuk mengubah nama akun administrator di server. Anda dapat mempelajari lebih lanjut tentang IUSR dan otentikasi di MSDN .

IWAM dirancang untuk semua aplikasi yang keluar dari proses dan hanya digunakan di IIS 6.0 ketika Anda berada dalam mode isolasi IIS 5.0. Anda biasanya melihatnya dengan objek COM / DCOM.

Sehubungan dengan identitas kumpulan aplikasi, standarnya adalah berjalan sebagai Layanan Jaringan. Anda tidak boleh berjalan sebagai Sistem Lokal karena akun itu memiliki hak yang lebih besar daripada administrator. Sehingga pada dasarnya membiarkan Anda ke Layanan Jaringan, Layanan Lokal, atau akun lokal / domain selain keduanya.

Seperti apa yang harus dilakukan, itu tergantung. Satu keuntungan meninggalkannya sebagai Layanan Jaringan adalah ini adalah akun privilege terbatas di server. Namun, ketika mengakses sumber daya di seluruh jaringan, itu muncul sebagai Domain \ ComputerName $, yang berarti Anda dapat menetapkan izin yang memungkinkan akun Layanan Jaringan untuk mengakses sumber daya seperti SQL Server berjalan pada kotak yang berbeda. Selain itu, karena ini muncul sebagai akun komputer, Jika Anda mengaktifkan otentikasi Kerberos, SPN sudah ada jika Anda mengakses situs web dengan nama server.

Suatu kasus di mana Anda akan mempertimbangkan untuk mengubah kumpulan aplikasi ke akun domain Windows tertentu jika Anda ingin akun tertentu mengakses sumber daya jaringan seperti akun layanan yang mengakses SQL Server untuk aplikasi berbasis web. Ada opsi lain dalam ASP.NET untuk melakukan ini tanpa mengubah identitas kumpulan aplikasi, jadi ini tidak lagi diperlukan lagi. Alasan lain Anda mempertimbangkan untuk menggunakan akun pengguna domain adalah Anda melakukan otentikasi Kerberos dan Anda memiliki beberapa server web yang melayani aplikasi web. Contoh yang baik adalah jika Anda memiliki dua atau lebih server web yang melayani Layanan Pelaporan SQL Server. Ujung depan mungkin ke url umum seperti report.mydomain.com atau reporting.mydomain.com. Dalam hal ini, SPN hanya dapat diterapkan ke satu akun dalam AD. Jika Anda memiliki kumpulan aplikasi yang berjalan di bawah Layanan Jaringan di setiap server, itu tidak akan berfungsi, karena ketika mereka meninggalkan server, mereka muncul sebagai Domain \ ComputerName $, yang berarti Anda akan memiliki banyak akun seperti server yang melayani server aplikasi. Solusinya adalah membuat akun domain, mengatur identitas kumpulan aplikasi di semua server ke akun pengguna domain yang sama dan membuat satu SPN, sehingga memungkinkan otentikasi Kerberos. Dalam hal aplikasi seperti SSRS, di mana Anda mungkin ingin meneruskan kredensial pengguna ke server database back-end, maka otentikasi Kerberos adalah suatu keharusan karena Anda harus mengkonfigurasi delegasi Kerberos. d memiliki akun sebanyak yang Anda punya server melayani aplikasi. Solusinya adalah membuat akun domain, mengatur identitas kumpulan aplikasi di semua server ke akun pengguna domain yang sama dan membuat satu SPN, sehingga memungkinkan otentikasi Kerberos. Dalam hal aplikasi seperti SSRS, di mana Anda mungkin ingin meneruskan kredensial pengguna ke server database back-end, maka otentikasi Kerberos adalah suatu keharusan karena Anda harus mengkonfigurasi delegasi Kerberos. d memiliki akun sebanyak yang Anda punya server melayani aplikasi. Solusinya adalah membuat akun domain, mengatur identitas kumpulan aplikasi di semua server ke akun pengguna domain yang sama dan membuat satu SPN, sehingga memungkinkan otentikasi Kerberos. Dalam hal aplikasi seperti SSRS, di mana Anda mungkin ingin meneruskan kredensial pengguna ke server database back-end, maka otentikasi Kerberos adalah suatu keharusan karena Anda harus mengkonfigurasi delegasi Kerberos.

Saya tahu itu banyak yang harus diterima, tetapi jawaban singkatnya adalah, kecuali untuk Sistem Lokal, itu tergantung.


Perlu dicatat bahwa rekomendasi untuk mengganti nama akun ini tidak berasal dari Microsoft. Akun sistem memiliki SID statis dan terdokumentasi dengan baik dan mudah diretas terlepas dari nama tampilan.
Thomas

9

IUSR = Pengguna Internet, yaitu setiap pengunjung anonim, tidak terautentikasi ke situs web Anda (yaitu hampir semua orang)

IWAM = Internet Web Application Manager, yaitu semua aplikasi ASP dan .NET Anda akan berjalan di bawah akun ini

Secara umum, IUSR dan IWAM HANYA harus memiliki akses ke apa yang mereka butuhkan. Mereka tidak boleh diberi akses ke hal lain, jika akun ini dikompromikan maka mereka tidak dapat mengakses hal-hal penting.

Hanya itu yang bisa saya bantu dari daftar pertanyaan Anda, yang lain dengan lebih banyak pengalaman dalam administrasi IIS mungkin dapat membantu Anda lebih jauh!


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.