** GPO - Як заблокувати створення папки та файлів у кореневому каталозі в Windows 10

0

Я хотів би використовувати налаштування GPO, щоб блокувати користувачів для створення папок і файлів у кореневому каталозі в Windows 10. Пошук в Інтернеті я знайшов налаштування

Конфігурація комп'ютера -> Політика -> Установки Windows-> Налаштування безпеки-> Файлова система

де я створив запис для% SystemDrive% \, де автентифіковані користувачі мають " Заборонити " на " Створення файлів / запис даних " та " Створення папок / додавання даних ", застосованих до "Тільки цієї папки ".

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

Будь-яка ідея, що може бути не так? будь-які інші пропозиції для досягнення того ж результату?

дуже дякую.

windows-10 filesystems group-policy

— ЯК
джерело

Це коментар, оскільки він не відповідає на ваше запитання: Вам не потрібно використовувати GPO для блокування створення папок. Все, що вам потрібно зробити - це змінити параметри безпеки. Пам’ятайте, що адміністратор ЗАВЖДИ може скасувати зміни або обійти їх. Крім того, якщо ви хочете позбавити права на root, пам’ятайте, що це поширюватиме всі папки, тож вам доведеться змінити дозволи на кожну підпапку та відключити успадкування.

— LPChip

Я забув зазначити, що я перебуваю у корпоративному середовищі, і цей GPO буде застосований до 10 000 робочих станцій. Мені потрібно використовувати групову групу. І права не слід поширювати, оскільки я спеціально згадав "Тільки ця папка".

— ЯК

0

Ми можемо спробувати усунути неполадки, як показано нижче:

Якщо Windows 10 знаходиться в доменному середовищі? Якщо він знаходиться в домені, ми можемо запустити звіт gpresult у Windows 10, щоб побачити, чи застосовується політика. Якщо він застосований, але він не може блокувати папки та файли створення, перейдіть до кроку 2.
Блокуйте інші папки в кореневому каталозі, щоб побачити, чи ми можемо успішно застосувати групову політику. Якщо ми можемо, можливо, ми не можемо встановити дозвіл кореневого каталогу системи.
Якщо Windows 10 не перебуває у доменному середовищі, майте на увазі, що цей процес доступний лише для домену з сервером, на якому функціонує Управління груповою політикою ... автономним системам та робочим групам все одно потрібно вручну призначити ці дозволи! Тож ми можемо спробувати встановити дозвіл вручну.

Довідка:

Призначення дозволів на використання файлів і папок за допомогою групової політики

https://www.linkedin.com/pulse/assign-file-folder-permissions-via-group-policy-farid-soltani

Створення групових груп безпеки файлової системи

https://library.netapp.com/ecmdocs/ECMP1401220/html/GUID-A8D101D3-729F-4299-A591-4AC55A5DD12E.html

Групова політика - приклади GPResult

https://blog.thesysadmins.co.uk/group-policy-gpresult-examples.html

— Дейзі Чжоу
джерело

Я бачу, що GPO застосовується до комп'ютера за допомогою gprsult, але, схоже, GPO не робить ніякого ефекту. Я також намагався створити локальну політику разом із редактором політики місцевої групи, і варіант не існує. Останнім моїм тестом було спробувати вручну змінити дозволи користувачів на C: \, і я отримав помилку через те, що деякі файли використовуються, як, наприклад, hiberfil.sys.

— ЯК

0

Погана ідея. Не їдь туди.
Якщо ВСІ ваші системи повністю не заблоковані, нікому ніколи нічого не потрібно буде встановлювати.
Блокування створення папки / файлів у корені systemdrive призведе до порушення багатьох програм, особливо інсталяторів для драйверів пристроїв, оскільки вони часто створюють робочі папки безпосередньо з кореня накопичувача.
Також оновлення для Windows 10 InPlace (і, можливо, деякі інші оновлення Windows) також потрібно записати в кореневу папку.
І деякі системні процеси, такі як Hibernate, ймовірно, теж не люблять цього

І "DENY автентифіковані користувачі", як деякі люди пропонують в інших відповідях, ТАКОЖ це ДЕНЬ для адміністраторів. ДЕНІ перекриває все. Адміністратор може скасувати це, але це вимагає вручну втручання, що не може зробити WindowsUpdate тощо.

У керованому програмному середовищі (наприклад, SCCM) ви можете обмотати щось як обгортку навколо кожного інсталятора, але це велика робота.
Або ви можете використовувати локальний (недоменний) обліковий запис адміністратора для SCCM та обмежити доступ до папок для "Користувачі домену". Але це також важко налаштувати і, можливо, ризик для безпеки. (Вам потрібно буде встановити індивідуальні паролі для цього облікового запису на кожному комп’ютері та зберігати їх десь для використання SCCM. Якщо ви використовуєте один і той же пароль скрізь, якщо один піддається компрометові, кожен комп'ютер є.)
Насправді: Компанія, в якій я працюю, насправді робить це наприклад, з SCCM та окремими локальними обліковими записами адміністратора на кожному комп’ютері (близько 200.000 систем), але ми недостатньо божевільні, щоб зафіксувати кореневий диск. Занадто великий потенціал, щоб викликати всілякі дивні побічні ефекти / проблеми.

— Тоні
джерело

Привіт Тоні. Дякую за відповідь. Я бачу вашу думку, але я намагаюся запобігти атакам, як commonexploits.com/unquoted-service-paths . наприклад: якщо на шляху "c: \ program files \ ..." є служба, що вразлива, і шкідливий користувач створює папку під назвою "Program" і просто розміщує зловмисне програмне забезпечення в тому ж шляху та з назвою, що і оригінал один. При наступному перезавантаженні зловмисне програмне забезпечення буде виконуватися замість оригінального.

— ЯК