Menggunakan ICACLS untuk mengatur izin pada direktori pengguna


16

Saya mencoba untuk mengatur ulang izin pada direktori pengguna dan mengalami sedikit masalah dengan langkah terakhir skrip saya. Skrip saya pada dasarnya mengambil kepemilikan dari seluruh direktori pengguna, mengatur ulang izin pada semua file dan folder untuk direktori, secara eksplisit memberikan izin yang saya butuhkan, menghentikan semua warisan izin dari folder induk, menetapkan pemilik yang sah (pengguna tertentu) untuk semua file dan folder, dan kemudian menghapus izin yang saya berikan kepada diri saya sendiri sehingga saya bisa beroperasi pada file. Saya perlu langkah terakhir ini untuk menghapus diri saya dari SEMUA file dan subfolder, tetapi saat ini hanya menghapus saya dari% userDir% dan meninggalkan semua izin yang diwarisi di bawah ini. Ini merupakan kekurangan yang jelas dalam ICACLS. Adakah yang tahu cara lain untuk mencapai ini?

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F /grant:r "SYSTEM":(OI)(CI)F /grant:r "MYDOMAIN\%username%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%" /inheritance:r
ICACLS "E:\Home Directories\%userDir%" /setowner "MYDOMAIN\%userDir%" /T
ICACLS "E:\Home Directories\%userDir%" /remove "MYDOMAIN\%username%"

Saya bermain-main dengan skrip XCACLS.vbs yang tidak didukung yang dibuat oleh Microsoft dan saya beruntung menggunakannya untuk baris terakhir skrip saya. Alih-alih ICACLS ini "E: \ Direktori Rumah \% userDir%" / hapus "MYDOMAIN \% nama pengguna%" Saya telah menggantinya dengan cscript.exe xcacls.vbs "e: \ Test" / E / R "MYDOMAIN \% username% "Ini berfungsi, tetapi saya benar-benar ingin menghindari penggunaan XCACLS.vbs karena memiliki masalah kinerja yang parah. Ada ide lain?
pk.

Jawaban:


18

Pengamatan pertama: Setiap kali Anda memblokir warisan Anda memotong diri Anda dari fleksibilitas masa depan. Saya menghindari pemblokiran warisan dengan cara apa pun.

Jika Anda memerlukan pengguna untuk dapat membuat daftar isi folder "E: \ Home Directories" tingkat atas, misalnya, pertimbangkan izin berikut:

  • SISTEM - Kontrol Penuh - Diterapkan ke folder ini, sub-folder, dan file
  • BUILTIN \ Administrator - Kontrol Penuh - Diterapkan ke folder ini, sub-folder, dan file
  • BUILTIN \ Pengguna yang Diautentikasi - Baca dan Jalankan - Hanya berlaku untuk folder ini

Izin terakhir tidak diwariskan ke dalam subfolder. Di setiap subfolder, warisan tetap diaktifkan dan Anda cukup menentukan pengguna dengan hak "Modifikasi" atau "Kontrol Penuh" (tergantung pada bagaimana perasaan Anda tentang pengguna yang dapat mengatur izin di dalam direktori home mereka). (Biasanya saya menetapkan izin terakhir dengan menambahkan "Pengguna yang Diotentikasi" di lembar properti Keamanan non-"Advanced", hapus centang pada kotak centang "Baca" dan "Baca dan Jalankan". Saya kemudian melanjutkan ke dialog "Lanjutan" dan mengubah Pengaturan "Terapkan ke" untuk ACE itu untuk "Hanya folder ini". Itu tentang cara termudah, dalam hal jumlah klik, untuk mengaturnya.)

Kemudian, skrip Anda menjadi:

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%" /setowner "MYDOMAIN\%userDir%" /T

Saya sangat curiga bahwa penambahan izin "Pengguna yang Diotentikasi" yang telah saya jelaskan di atas dengan pewarisan yang diatur ke "Hanya folder ini" akan memberi Anda apa yang Anda cari dalam fungsionalitas dan akan memberi Anda fleksibilitas di masa mendatang jika Anda mengetahuinya. Anda harus menetapkan izin yang mungkin perlu diwariskan ke semua direktori home pengguna di masa mendatang.

Ini adalah SOP saya untuk direktori home user, diarahkan kembali "My Documents", "Desktop", folder dll, dan untuk roaming direktori profil pengguna. Ini bekerja dengan baik.

Edit

re: komentar Anda tentang akses BUILTIN \ Administrator

Saya memiliki berbagai argumen dengan orang-orang tentang pendapat saya tentang pemberian akses BUILTIN \ Administrator selama bertahun-tahun, dan pendapat saya adalah ini:

  • Lebih mudah untuk memecahkan masalah kelas pengguna tertentu jika Anda dapat membuka file mereka. Sungguh menyakitkan untuk "mengambil kepemilikan" dan bisa sangat lambat jika ada banyak file juga.

  • Seperti yang Anda lihat dengan ICACLS, BUILTIN \ Administrator dapat "menetapkan" kepemilikan (selain "mengambilnya") sehingga tidak ada "keamanan" yang ditambahkan dengan tidak memiliki file yang dapat diakses oleh BUILTIN \ Administrator.

  • Kecuali jika Anda menggunakan audit (dan memilah-milah entri palsu-positif yang berpotensi besar) tidak akan ada jejak audit ketika pengguna BUILTIN \ Administrator mengambil kepemilikan file yang seharusnya tidak dapat diakses, menyalinnya, lalu mengembalikan file kembali ke pemilik dan izin "semestinya".

  • Di dunia Microsoft, Encrypting filesystem (EFS) dimaksudkan untuk menyelesaikan masalah menjaga akses BUILTIN \ Administrator yang tidak sah terjadi. ACL NTFS tidak memecahkan masalah itu. (Jelas, EFS bukan satu-satunya acara di kota. Enkripsi adalah jawaban nyata untuk memecahkan masalah "membatasi akses administrator jaringan" tidak peduli bagaimana Anda mengirisnya.)

Menurut saya, tidak menentukan BUILTIN \ Administrator dengan akses ke direktori home user (dan, pada kenyataannya, folder apa pun) berarti bahwa Anda meningkatkan kompleksitas dan waktu yang diperlukan untuk menyelesaikan masalah sambil memberikan kurang dari tidak ada keamanan nyata ("kurang dari tidak ada "Karena itu menanamkan rasa aman palsu di mana tidak ada).

Saya sudah menyerah untuk memenangkan pertengkaran dengan orang-orang melalui logika. Tampaknya menjadi masalah emosional dengan beberapa orang. Ini seperti ACE konyol "Tolak / Terima Sebagai" yang ditempatkan di akar organisasi Exchange untuk mencegah kelompok istimewa tertentu dari membuka kotak pesan pengguna. Ini tidak menawarkan keamanan nyata (karena tanpa audit seseorang dapat menghapus / menerapkan kembali ACE seperlunya), rasa aman yang salah, dan menghalangi ketika memecahkan masalah nyata.

Bahkan jika Anda tidak menyukai argumen saya tentang BUILTIN \ Administrator yang memiliki akses, Anda ingin menjaga hierarki warisan tetap utuh dengan menggunakan warisan "Folder ini saja" jika diperlukan. Memblokir warisan dalam hierarki izin adalah tanda pasti bahwa sesuatu tentang desain "rusak" (terbalik, dll.).


1
Apakah Anda merekomendasikan memberi BUILTIN \ Administrator akses penuh ke seluruh struktur direktori? Saya berpendapat bahwa kami (administrator) seharusnya tidak memiliki akses penuh ke direktori / profil pengguna semua orang tanpa mengambil kepemilikan.
pk.

+1, suka poin tentang rasa aman yang salah ...
DCookie

1

Pertama, terima kasih untuk kutipan skrip Anda. Saya telah mengerjakan hal yang sama tetapi terjebak di tempat yang berbeda. Pada kotak SBS 2008 saya, kode di bawah ini berfungsi untuk saya (tentu saja dengan asumsi menjalankannya meningkat). Saya melakukan icacls% userdir% / t dari folder pengguna baru (default) yang dibuat oleh OS, dan membandingkannya dengan icacls% userdir% / t dari folder setelah menjalankan skrip ini dan sepertinya semua "O's dan "Itu benar. Semoga itu akan bekerja untuk Anda juga.

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(oi)(ci)f
ICACLS "E:\Home Directories\%userDir%\*.*" /grant:r "SYSTEM":(OI)(CI)F /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F /grant:r "MYDOMAIN\%username%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%\*.*" /inheritance:r
ICACLS "E:\Home Directories\%userDir%\*.*" /setowner "MYDOMAIN\%userDir%" /T
ICACLS "E:\Home Directories\%userDir%" /remove "MYDOMAIN\%username%" /t

Salam Hormat,

 -d

Pastikan Anda memverifikasi baris terakhir skrip Anda. Menurut pengalaman saya, ICACLS tidak akan berhasil menghapus izin yang diwarisi. Ini menghapus entri pada folder "MYDOMAIN \% username%", tetapi izin dari subfolder tidak tersentuh. Oleh karena itu, "MYDOMAIN \% username%" masih akan memiliki akses ke subfolder jika diakses secara langsung, Anda tidak akan dapat menjelajahinya. XCACLS.vbs menyelesaikan ini untuk saya. cscript.exe xcacls.vbs "e: \ Test" / E / R "MYDOMAIN \% username%"
pk.

Di situlah . bagian masuk di edit saya. melakukan / inheritance: r pada folder induk, saya memiliki masalah yang sama. tetapi melakukannya terus . di folder induk sepertinya melakukan trik. Setelah menjalankan di atas,% userdir% memiliki% username%, sistem, dan administrator, tetapi semua yang ada di bawahnya hanyalah% username% dan sistem, yang merupakan cara server mengaturnya pada awalnya - persis seperti yang saya inginkan.

-1

Saya butuh bantuan Anda untuk memodifikasi perintah ini sesuai dengan kebutuhan saya jika itu secara teknis memungkinkan.

Ini strukturnya

\ Server \ Parent \ UserA \ unix

\ Server \ Parent \ UserB \ unix

\ Server \ Parent \ UserC \ unix .... dan seterusnya ..

Di bawah masing-masing folder $ Pengguna ada folder bernama "unix".

Saya ingin menambahkan pengguna atau grup dengan izin penuh pada semua folder $ Pengguna terdaftar di bawah folder "Induk" (nama diambil pada struktur di atas) tetapi ingin mengecualikan izin hanya pada folder "unix".

Saya memiliki perintah ini yang berfungsi dengan baik untuk saya dalam perspektif penerapan izin yang diperlukan tetapi saya tidak dapat menambahkan fungsi kecualikan dalam hal ini.

icacls "\\ Server \ Parent \ UserA" / hibah Domain \ Group: (OI) (CI) F / T

Apakah Anda dapat memandu dalam skenario ini?


1
Halo dan selamat datang di Server Fault! Tolong jangan bertanya melalui jawaban. Gunakan tombol Tanya Pertanyaan untuk mengirim permintaan Anda.
Tuan Shunz
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.