Использование 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: \ Home Directories \% userDir%" / remove "MYDOMAIN \% username%" я заменил его на cscript.exe xcacls.vbs "e: \ Test" / E / R "MYDOMAIN \% username% "Это работает, но я бы очень хотел избежать использования XCACLS.vbs, так как он имеет серьезные проблемы с производительностью. Есть другие идеи?
шт.

Ответы:


18

Первое наблюдение: каждый раз, когда вы блокируете наследование, вы отсекаете себя от будущей гибкости. Я избегаю блокирования наследования любой ценой.

Если вам нужно, чтобы пользователи могли просматривать содержимое папки «E: \ Home Directories» верхнего уровня, например, рассмотрите следующее разрешение:

  • СИСТЕМА - Полный доступ - применяется к этой папке, подпапкам и файлам
  • BUILTIN \ Администраторы - Полный доступ - применяется к этой папке, подпапкам и файлам
  • BUILTIN \ Authenticated Users - чтение и выполнение - применяется только к этой папке

Последнее разрешение не наследуется в подпапках. В каждой подпапке наследование остается включенным, и вы просто указываете пользователя с правами «Изменить» или «Полный доступ» (в зависимости от того, что вы думаете о том, что пользователи могут устанавливать разрешения внутри своего домашнего каталога). (Обычно я устанавливаю это последнее разрешение, добавляя «Прошедшие проверку» в окне свойств, не относящихся к «Расширенным», снимая флажки «Чтение» и «Чтение и выполнение». Затем я перехожу в диалоговое окно «Расширенные» и изменяю Параметр «Применить к» для этого элемента управления доступом к «Только эта папка». Это самый простой способ, с точки зрения количества нажатий, установить его.)

Затем ваш сценарий становится:

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

Я сильно подозреваю, что добавление разрешения «Аутентифицированные пользователи», которое я описал выше с наследованием, установленным на «Только эта папка», даст вам то, что вы ищете в функциональности, и даст вам гибкость в будущем, если вы узнаете что вам нужно установить разрешение, которое может понадобиться для наследования во всех домашних каталогах пользователей в будущем.

Это моя СОП для домашних каталогов пользователей, перенаправленных папок «Мои документы», «Рабочий стол» и т. Д., А также для перемещаемых каталогов пользовательских профилей. Работает отлично.

редактировать

Re: Ваш комментарий о доступе BUILTIN \ Администраторы

У меня были разные споры с людьми по поводу моего подхода к предоставлению доступа BUILTIN \ Administrators на протяжении многих лет, и мой вывод таков:

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

  • Как вы видели в ICACLS, BUILTIN \ Administrators могут «назначать» владение (помимо «взятия»), поэтому не добавляется «безопасность», поскольку файлы не доступны в первую очередь для BUILTIN \ Administrators.

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

  • В мире Microsoft шифрованная файловая система (EFS) предназначена для решения проблемы предотвращения доступа неавторизованных пользователей BUILTIN \ Administrators. NTFS ACL не решают эту проблему. (Очевидно, что 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 \% username%"
стр.

Вот где . часть пришла на мое редактирование. делать / наследование: г на родительской папке, у меня была такая же проблема. но делаю это дальше . в родительской папке, похоже, сделали свое дело. После запуска вышеприведенного,% userdir% имеет% username%, систему и администраторов, но все, что под этим, - это просто% username% и system, как сервер изначально их настраивал - именно то, что я хотел.

-1

Мне нужна ваша помощь, чтобы изменить эту команду в соответствии с моими требованиями, если это технически возможно.

Вот структура

\ Server \ Родитель \ UserA \ Unix

\ Server \ Родитель \ UserB \ Unix

\ Server \ Parent \ 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.