Використання ICACLS для встановлення дозволів на каталоги користувачів


16

Я намагаюся скинути дозволи на каталоги користувачів і в мене є певні проблеми з останнім кроком мого сценарію. Мій сценарій в основному приймає право власності на весь каталог користувачів, скидає дозволи на всі файли та папки для каталогу, явно надає потрібні мені дозволи, припиняє успадкування дозволів з батьківських папок, встановлює справжнього власника (вказаного користувача) для всіх файлів і папки, а потім видаляє дозвіл, який я дав собі, щоб я міг працювати над файлами. Мені потрібен цей останній крок, щоб видалити себе з ВСІХ файлів і підпапок, але на даний момент він просто видаляє мене з% userDir% і залишає всі спадкові дозволи нижче. Це очевидний недолік у ICACLS. Хтось знає якийсь інший спосіб досягти цього?

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%"

Я граю з непідтримуваним сценарієм XCACLS.vbs, створеним Microsoft, і мені пощастило використовувати його для останнього рядка мого сценарію. Замість цього ICACLS "E: \ Домашні каталоги \% userDir%" / видалити "MYDOMAIN \% username%" Я замінив його на cscript.exe xcacls.vbs "e: \ Test" / E / R "MYDOMAIN \% ім'я користувача% "Це працює, але я дуже хотів би уникати використання XCACLS.vbs, оскільки він має серйозні проблеми з продуктивністю. Будь-які інші ідеї?
пк.

Відповіді:


18

Спочатку спостереження: кожен раз, коли ви блокуєте спадщину, ви позбавляєте себе від майбутньої гнучкості. Я уникаю блокування спадщини за будь-яку ціну.

Якщо вам потрібно, щоб користувачі могли перелічити вміст папки "E: \ Домашні каталоги" верхнього рівня, наприклад, врахуйте такий дозвіл:

  • СИСТЕМА - Повний контроль - застосовується до цієї папки, підпапок та файлів
  • BUILTIN \ Administrators - Повний контроль - Застосовується до цієї папки, підпапок та файлів
  • BUILTIN \ Автентифіковані користувачі - читання та виконання - застосовано лише до цієї папки

Останній дозвіл не успадковується у підпапках. У кожній підпапці успадкування залишається увімкненою, і ви просто вказуєте користувача за допомогою прав "Змінити" або "Повний контроль" (залежно від того, як ви ставитесь до того, що користувачі можуть встановлювати дозволи всередині свого домашнього каталогу). (Зазвичай я встановлюю цей останній дозвіл, додаючи "Автентифіковані користувачі" на аркуші властивостей, що не мають "Розширені", знімаючи прапорці "Читати" та "Читати та виконувати". Потім я переходжу до діалогового вікна "Додатково" та змінюю Налаштування "Застосувати на" для цього ACE для "Тільки цієї папки". Це приблизно простий спосіб встановити її за кількістю кліків.)

Потім ваш сценарій стає:

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

Я сильно підозрюю, що додавання дозволу "Аутентифіковані користувачі", який я описав вище, із спадщиною, встановленим на "Ця папка", дасть вам те, що ви шукаєте у функціональності, і надасть вам майбутню гнучкість, якщо ви дізнаєтесь про це що вам доведеться встановити дозвіл, який може знадобитися успадкувати всі домашні каталоги користувачів у майбутньому.

Це мій SOP для домашніх каталогів користувачів, перенаправлених папок "Мої документи", "Настільний стіл" тощо, а також для роумінгових каталогів профілю користувачів. Це чудово працює.

Редагувати

re: ваш коментар про доступ до BUILTIN \ Administrators

У мене були різні аргументи з людьми щодо того, що я можу взяти участь у наданні BUILTIN \ Administrators доступу, і я вважаю, що це:

  • Простіше вирішити певний клас проблем користувачів, якщо ви можете перейти до їх файлів. Болісно "взяти на себе право" і може бути досить повільним, якщо також присутня велика кількість файлів.

  • Як ви бачили з ICACLS, BUILTIN \ Administrators можуть "призначити" право власності (окрім "взяти" це), щоб не було додано "безпеки", якщо вони не мають файлів, доступних BUILTIN \ Administrators в першу чергу.

  • Якщо ви не використовуєте аудит (і просіюєте потенційно величезну кількість помилково-позитивних записів), аудиторський слід не буде, коли користувач BUILTIN \ Administrators отримає право власності на файли, до яких вони не мають доступу, копіюють їх, а потім повертає файли їх "належному" власнику та дозволу.

  • У світі Microsoft Шифрування файлової системи (EFS) призначена для вирішення проблеми заборонити доступ до несанкціонованого доступу BUILTIN \ Administrators. ACL-адреси NTFS не вирішують цю проблему. (Очевидно, що EFS - не єдине шоу в місті. Шифрування - це справжня відповідь на вирішення проблеми "обмежити доступ адміністратора мережі", незалежно від того, як ви її вирізаєте.)

На мій погляд, не вказати BUILTIN \ Administrators для доступу до домашніх каталогів користувачів (і, власне, до будь-якої папки) означає, що ви збільшуєте складність та час, необхідний для вирішення проблем, забезпечуючи при цьому менше, ніж ніякої реальної безпеки ("менше, ніж жодна "тому що вона надає помилкове почуття безпеки там, де його немає).

Я відмовився від спроби перемогти аргументацію з людьми логікою. Здається, це емоційна проблема з деякими людьми. Це як дурний ACE "Заборонити / приймати як", який розміщується в корені організації Exchange, щоб запобігти певним привілейованим групам відкривати поштові скриньки користувачів. Він не забезпечує реальної безпеки (оскільки без аудиту можна було зняти / повторно застосувати ACE за необхідності), помилкове почуття безпеки та перешкоджає вирішенню реальних проблем.

Навіть якщо вам не подобається мій аргумент про доступ до BUILTIN \ Administrators, ви хочете зберегти ієрархію спадщини недоторканою, використовуючи спадщину "Лише ця папка", де це доречно. Блокування спадкування в ієрархіях дозволів - це вірний знак того, що щось про дизайн "порушено" (перевернуто тощо).


1
Чи рекомендуєте ви надати BUILTIN \ Administrators повний доступ до всієї структури каталогів? Я вважаю, що ми (адміністратори) насправді не повинні мати повний доступ до каталогів / профілів користувачів, не маючи права власності.
пк.

+1, люблю пункти про помилкове почуття безпеки ...
DCookie

1

По-перше, дякую за ваш уривок сценарію. Я працював над тим самим, але застряг в іншому місці. У моєму вікні SBS 2008 нижченаведений код працює для мене (припустимо, звичайно, що він працює підвищеним). Я зробив icacls% userdir% / t абсолютно нової (за замовчуванням) папки користувача, створеної ОС, і порівняв її з icacls% userdir% / t папки після запуску цього сценарію, і це виглядає як усі "O і Я "правильні. Сподіваємось, це буде працювати і для вас.

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

З повагою,

 -d

Переконайтеся, що ви підтвердили заключний рядок свого сценарію. З мого досвіду, ICACLS не буде успішно видаляти успадковані дозволи. Він видаляє запис у папці "MYDOMAIN \% username%", проте дозволи допапок не торкаються. Тому "MYDOMAIN \% username%" все одно матиме доступ до підпапок, якщо матимете доступ до них безпосередньо, ви просто не зможете їх переглядати. XCACLS.vbs вирішив це для мене. cscript.exe xcacls.vbs "e: \ Test" / E / R "MYDOMAIN \% ім'я користувача%"
pk.

Ось де . частина зайшла до моєї редакції. робити / успадкування: r у батьківській папці у мене була така ж проблема. але робити це далі . у батьківській папці, здавалося, зробили трюк. Після виконання вищезазначеного,% userdir% має% username%, систему та адміністраторів, але все під цим - лише% username% та система, саме так сервер їх налаштував спочатку - саме те, що я хотів.

-1

Мені потрібна ваша допомога, щоб змінити цю команду відповідно до моєї вимоги, якщо це технічно можливо.

Ось структура

\ Сервер \ Батько \ КористувачA \ unix

\ Сервер \ Батько \ Користувач \ \ unix

\ Сервер \ Батьків \ UserC \ unix .... і так далі ..

Під кожною папкою User $ є папка під назвою "unix".

Я хочу додати користувача або групу з повними дозволами на всі папки User $, перелічені в папці "Parent" (імена, взяті з вищезгаданої структури), але хочу виключити дозволи лише в папці "unix".

У мене є ця команда, яка добре працює для мене з точки зору застосованості необхідних дозволів, але я не можу додати функцію виключення в цьому.

icacls "\\ Сервер \ Батько \ КористувачA" / надавати Домен \ Група: (OI) (CI) F / T

Чи зможете ви керуватися в цьому сценарії?


1
Привіт і ласкаво просимо до помилки сервера! Будь-ласка, не задавайте питань у відповідь. Використовуйте кнопку Задати питання, щоб опублікувати ваш запит.
Містер Шунц
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.