Отключение подсказки для “Нажатия на Continue для постоянного получения доступа к этой папке” (например, через GPO)
http://support.microsoft.com/en-us/kb/950934 описывает способ, которым, когда член Группы администраторов использует Проводник для навигации к папке, к которой Группа администраторов имеет разрешение, пользователю предложат "Нажать Continue для постоянного получения доступа к этой папке".
Когда они делают это, Проводник изменяет ACL папки, чтобы допустить что определенный пользовательский Полный контроль папке. Ссылка MS описывает точно конструктивное ограничение, которое требует, чтобы это было этим путем.
Однако это разрушает набор полномочий для той папки и делает централизованное управление полномочий эффективно невозможным. Например, если именованный пользователь позже удален из Группы администраторов, что запись ACL все еще существует, чтобы разрешить им доступ к той папке.
Я не надеюсь отключать контроль учётных записей (мне на самом деле нравится различие между поднятым и неподнятым), и я рад использовать альтернативные инструменты, чтобы переместиться и просмотреть файлы поднятым способом.
Возможное намерение состоит в том, чтобы выполнить одно из обходных решений, описанных в ссылке MS (или использование отдельного навигатора файла, который может работать поднятый, или определение отдельной группы для управления доступом к папкам в белом списке), но, все время Проводник продолжает ударять ACLs папки, по желанию, это лишает возможности определять, где эти обходные решения должны быть применены (за исключением регулярного аудита каждой папки для изменений ACL).
Я просто предпочел бы иметь стандартное сообщение "доступа запрещен", если я пытаюсь получить доступ к ограниченной папке когда выполнение, неподнятое в Проводнике.
Существует ли установка (или одноразовый на каждом поле, или через GPO), который удаляет, это "постоянно получает доступ" подсказка при сохранении других средств контроля учётных записей?
NB: который я полностью понимаю, почему эта подсказка существует, что это означает и почему поведение состоит в том, как это (хотя я не обязательно соглашаюсь с проектным решением). Однако я должен указать, что не надеюсь обсуждать обходные решения, касающиеся рабочей практики моих пользователей, ни достоинств/ловушек членства в Группе администраторов или контроля учётных записей.
Нет, не существует.
Единственное реальное решение - это использование для просмотра файлов чего-то кроме Windows Explorer (и, конечно же, для запуска с повышенным уровнем).
Проблема заключается в том, что explorer.exe изначально запускается с неадминистративным токеном доступа (для отображения GUI), и любые новые сеансы, даже запущенные от имени администратора, наследуют это ограниченное поведение токена доступа. Есть обходной путь, чтобы запустить этот начальный экземпляр проводника с маркером административного доступа, но затем все, что вы запускаете из GUI, наследует маркер административного доступа, фактически обнуляя UAC.
Можно просто запустить CMD или PowerShell от имени администратора.
dir *.* /w /s
или в PowerShell от имени администратора :
Folders :
Get-ChildItem -Recurse -Directory | Measure-Object | %{$_.Count}
Files :
Get-ChildItem -Recurse -File | Measure-Object | %{$_.Count}
PS: Get-ChildItem не работает с путями длиннее 260 символов
.На самом деле существует безопасный способ обойти это приглашение для административных пользователей, которые вошли в систему локально.
- Откройте диалоговое окно «Свойства»> «Безопасность» соответствующей папки, чтобы отредактировать ее ACL.
Затем добавьте участника безопасности ИНТЕРАКТИВНЫЙ и дайте ему разрешения на «Список содержимого папки», который автоматически включит следующее разрешения:
- Просмотр папки / выполнение файла
- Список папок / чтение данных
- Чтение атрибутов
- Чтение расширенных атрибутов
Причина, по которой это работает, заключается в том, что Windows больше не полагается на ваши привилегированные учетные данные / учетные данные администратора для просмотр структуры папок и перечисление содержимого папок. Так как «аутентификация» как ИНТЕРАКТИВНАЯ не требует оценки привилегированных учетных данных для перечисления папки, поэтому нет необходимости запускать приглашение UAC.
TL; DR: создайте другую группу параллельно с локальными администраторами group и добавьте всех, кто имеет право быть администратором в обе группы. Затем разрешите этой второй группе быть в ACL для всех файлов и папок. Не входите в систему и не работайте от имени встроенного администратора.
Эта проблема беспокоит меня довольно давно. Мне становится неприятно постоянно удалять себя из списков ACL папок (а также других пользователей, которые не убирали за собой), когда я просматриваю различные структуры папок. Итак, я прочитал статью, упомянутую в вопросе. Это дало мне понимание, необходимое для написания этого ответа, и я рекомендую прочитать его, прежде чем продолжить.
Суть первоначального вопроса, который меня обеспокоил, заключалась в утверждении авторов, что он «делает централизованное управление разрешениями практически невозможным». Вначале я согласился с этим, но, подумав, я вспомнил весь смысл принципа «Наименьших привилегий» . Одна из целей учетной записи локального администратора, а также локальной группы администраторов - нарушить этот принцип. В конце концов, вы не можете ничего отнять у этого пользователя или членов этой группы. Да, в ближайшей перспективе им можно отказать, но у них все еще есть возможность (без использования эксплойтов)победить отказ, предоставив себе доступ к любому запрещенному ресурсу. Таким образом, похоже, что Microsoft считает, что всегда должен быть хотя бы один пользователь, который всегда может каким-то образом получить доступ ко всему. Справедливо. Этот аргумент выходит за рамки данного ответа.
Итак, как это влияет на «централизованное управление разрешениями»? Казалось бы, чтобы соответствовать Принципу, вам нужно наполовину притвориться (половину я объясню позже), что локальный администратор и группа локальных администраторов не существуют. Помните, что их привилегии нельзя ограничивать, а это значит, что они нарушают Принцип. Вот почему пароль для этой учетной записи хранится так тайно, а членство в этой группе так желательно. Поэтому, если вам нужен такой же эффективный доступ, в корне каждого диска вам нужно иметь своего собственного пользователя или группу с полным доступом, которые (в идеале) унаследованы всеми их подпапками и файлами.
Однако мы знаем, что что на практике этому пользователю или группе обычно будет отказано в доступе, но это часть сути. «Администратор» должен быть окончательным арбитром в том, кто имеет и не имеет доступа к какому-либо файлу или папке. «Администратор» воплощен в этом фиксированном пользователе. Да, многие из нас для удобства действуют как «Администраторы», но, поступая так, мы нарушаем Принцип. Итак, чтобы справиться с этим, мы можем удобно помнить (это половина воображаемой части), что группа администраторов существует и что мы можем быть ее членами. Мы можем предоставить упомянутой выше группе (или пользователю) (который может быть самим собой) доступ к ресурсу (который должен унаследовать разрешение в первую очередь) и не беспокоиться о соответствии или требованиях безопасности, потому что эта группа (или пользователь) уже имеет авторизация для этого ресурса, потому что они уже авторизованы действовать как «Администраторы».
Однако в этом есть загвоздка. Я по-прежнему не хотел отказываться от удобства входа в систему как «Администратор», поэтому я добавил этого пользователя в группу - и он по-прежнему не работал. Этот пользователь является фиксированным пользователем, и он особенный, и, не отключив UAC, невозможно удалить это «особое» качество. Но в том-то и дело. Microsoft пытается подтолкнуть нас к соблюдению Принципа. Добавив своего пользователя в обе группы, я смог предоставить себе доступ к ресурсу, оставаться совместимым и защищенным и избежать раздражающего диалога.