Kenapa ketika saya menambahkan IIS_IUSRS RW akses ke folder, itu tidak secara otomatis mengizinkan akses ISUR RW?


11

Saya menggunakan IIS7 (Windows Server 2008 x64) dan saya memiliki pengaturan situs web menggunakan otentikasi anonim. Identitas pengguna langsung dikonfigurasi sebagai IUSR. Aplikasi menulis file ke folder dan saya memberikan IIS_IUSRS grup RW izin ke folder. Ini tidak berhasil. Saya harus secara eksplisit memberikan izin IUSR RW untuk memungkinkan aplikasi menulis ke folder.

Saya memahami bahwa identitas kumpulan aplikasi secara otomatis ditambahkan ke grup IIS_IUSRS. Saya berasumsi bahwa IUSR (atau identitas pengguna anonim) juga merupakan anggota tersirat dari grup IIS_IUSRS. Tampaknya ini bukan masalahnya.

Saat pemecahan masalah, saya menggunakan Monitor Proses untuk melihat akses ke folder dan menetapkan bahwa Layanan Jaringan (identitas kumpulan aplikasi) meniru IUSR (ini yang saya harapkan) tetapi memberikan izin RW ke grup IIS_IUSRS tidak mengizinkan IUSR untuk mengakses file (Akses Ditolak).

Adakah yang bisa menjelaskan apakah IUSR adalah anggota kelompok IIS_IUSRS atau bukan?

Saya telah meninjau dokumentasi berikut dan tidak menemukan jawaban yang jelas:

Memahami Akun Pengguna dan Grup yang Terpasang di IIS 7

Identitas Kumpulan Aplikasi

Jawaban:


14

Itu karena ini adalah dua hal yang berbeda. IIS_IUSRS adalah grup untuk Akun Proses Pekerja IIS . Ini berarti identitas bahwa kumpulan aplikasi itu sendiri berjalan di bawah. IUSR adalah identitas pengguna anonim. Itu berarti identitas yang IIS yakini sebagai pengguna yang mengakses situs.

Sekarang meskipun Anda tidak mengatakannya, coba saya tebak - aplikasi ini adalah asp klasik? (Kalau tidak, jika itu. Net maka Anda harus menggunakan peniruan). Apa pun yang terjadi, sumber daya diakses sebagai identitas palsu, makna, pengguna anonim dalam kasus Anda, yang berarti IUSR. Itu sebabnya Anda harus memberinya hak. Di .Net, jika Anda mematikan peniruan, Anda akan menemukan bahwa IIS_IUSRS akan ikut bermain seperti yang Anda harapkan. Dalam ASP Klasik (dan untuk file statis), Anda tidak punya pilihan, peniruan selalu "diaktifkan"; jadi selalu identitas pengguna yang digunakan, bukan identitas pool. Jadi karena IIS_IUSRS adalah untuk identitas kumpulan, itu tidak dimainkan.


Edit setelah OP menambahkan informasi lebih lanjut:

Sangat mudah untuk membingungkan IUSR dan IIS_IUSRS karena nama mereka. Cara melihat mereka berbeda adalah dengan mengingat bahwa IIS_IUSRS adalah pengganti IIS_WPG di IIS6, yang merupakan Worker Process Group. Untuk grup-grup ini Anda menambahkan akun yang ingin Anda gunakan untuk menjalankan kelompok Anda, bukan identitas pribadi, dan hak istimewa seharusnya lebih terbatas. misalnya. terkadang Anda mungkin ingin menggunakan akun domain untuk menjalankan kumpulan delegasi kerberos ke sumber daya jaringan lainnya. Maka Anda akan menambahkan akun layanan itu ke grup ini.

Ketika peniruan diaktifkan, kumpulan / proses berpura-pura menjadi pengguna karena disuruh. Dalam kasus anon auth (kasus Anda), pengguna itu adalah IUSR. Dalam hal windows auth, itu akan menjadi identitas windows \ domain pengguna. Ini juga mengapa Anda mendapatkan kinerja yang mengesankan dengan peniruan, karena proses harus beralih ke identitas yang berbeda untuk akses sumber daya.

Jika Anda menggunakan .NET dan otentikasi anonim, maka saya tidak melihat mengapa Anda akan mengaktifkan peniruan. Jika Anda tidak menggunakan atau tidak perlu peniruan, Anda harus mengetahui beberapa tipu daya dalam kasus IIS7: Anda dapat membuat IUSR Anda pergi sepenuhnya dan mengakhiri semua kebingungan. Saya pikir Anda akan menyukainya, dan itu metode yang saya sukai juga. Yang harus Anda lakukan adalah mengatakannya untuk menggunakan kembali identitas kumpulan sebagai identitas anonim .

Jadi setelah ini, Anda hanya perlu berurusan dengan grup IIS_IUSRS. Tapi jangan bingung, ini masih tidak berarti bahwa keduanya sama! Dimungkinkan untuk identitas proses untuk menggantikan IUSR, tetapi tidak sebaliknya!

Beberapa tipu daya IIS7 yang perlu diperhatikan: jika Anda melihat IIS_IUSRS, itu mungkin kosong. Itu karena identitas virtual pool Anda secara otomatis ditambahkan padanya ketika pool dimulai, jadi Anda tidak perlu khawatir tentang hal-hal ini.

Tabel ini harus membantu memperjelas lebih baik bagaimana identitas pelaksanaan utas ditentukan:

Peniruan Sumber Akses Anonim Diakses Sebagai

Diaktifkan Diaktifkan IUSR_computer di IIS5 / 6 atau,
                                       IUSR di IIS7 atau,
                                       Jika Anda mengubah akun pengguna anon 
                                       di IIS, apa pun yang Anda atur di sana
Diaktifkan Dinonaktifkan, MYDOM \ MyName
Dinonaktifkan Diaktifkan NT Authority \ Layanan Jaringan (kumpulan identitas)
Dinonaktifkan Dinonaktifkan NT Authority \ Layanan Jaringan (kumpulan identitas)


Kami pasti menggunakan Net. (Target 3.5) tetapi mungkin menggunakan peniruan. Saya harus memeriksa dengan pengembang saya untuk memastikan. Kebingungan saya berasal dari kenyataan bahwa saya berasumsi (keliru kelihatannya) bahwa identitas pengguna anonim secara otomatis adalah anggota grup IIS_IUSRS. Karena dia tidak mengizinkan saya untuk mengklarifikasi dan perbaiki saya jika saya bekerja.

1) Menggunakan ASP klasik, izin akses file menggunakan identitas pengguna anonim. Di IIS 7 atau lebih baru, pengguna ini bukan anggota grup IIS_IUSRS secara default. 2) Menggunakan ASP.Net, izin akses file menggunakan identitas pengguna anonim jika peniruan diaktifkan. Di IIS 7 atau lebih baru, pengguna ini bukan anggota grup IIS_IUSRS secara default. 3) Menggunakan ASP.Net, izin akses file menggunakan identitas proses pekerja jika peniruan dinonaktifkan. Di IIS 7 atau lebih baru, pengguna ini selalu menjadi anggota grup IIS_IUSRS secara default.

Ya benar benar di semua titik! Agar sangat jelas, di # 1 dan # 2 Anda harus menambahkan "jika IIS anon auth diaktifkan", yang saya tidak harus sertakan sebelumnya karena Anda sudah mengatakan Anda menggunakan anon. Lihat tabel yang saya tambahkan untuk lebih menjelaskan hal ini.
Amit Naidu

Terima kasih banyak telah menjelaskan ini. Itu setuju dengan apa yang saya temukan melalui trial and error tetapi saya belum melihat ini didokumentasikan dengan sangat jelas di mana pun. Sangat penting bagi admin yang menggunakan LUA di server mereka ketika mengatur aplikasi IIS yang membutuhkan izin menulis.
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.