записки ремесленника

АЛЕКСАНДР ПРИХОДЬКО

Спецвыпуск: Хакер, номер #066, стр. 066-100-3

Начинаем править вновь созданный объект: правая кнопка мыши на объекте GPO «Бухгалтерия»> Edit. Так как нам необходимо, чтобы данная политика применялась к пользователю Балаганов и членам его группы, мы правим скрипт в User Configuration.

Открываем User Configuration> Windows Setting> Scripts (Startup/Shutdown). Как подключить файл скрипта к объекту политики, рассказано на этаже выше. Скрипт подключили, GPO Editor закрыли. Теперь настоим область распространения данной политики. В консоли видно, на кого сейчас распространяется данная GPO.

Теперь изменим ее. Выбираем Authenticated Users> кнопка Remove, добавляем новую область распространения: кнопка Add, в открывшемся окне вручную набираем слово «Бухгалтерия» и нажимаем ОК. Осталась самая малость — отключить ненужную ветвь политики, которая относится к настройкам компьютера. Переходим на закладку Details и в поле GPO Status выбираем значение «Computer configuration settings disabled». Теперь закладка Settings покажет результаты твоего труда.

Последнее шаманское действо — это привязка вновь созданной политики к существующему OU. Вновь в той же консоли правая кнопка мыши на OU «Бухгалтеры», в меню выбираем пункт Link an Existing GPO… В открывшемся списке доступных политик выбираем нашу — «Бухгалтерия». Теперь заставим контроллер домена форсированно обновить политики: Gpupdate /force. Перезагружаем машину Балаганова и смотрим, что получилось.

Получилось то, что и планировали. Теперь ты проделываешь аналогичные операции со всеми своими группами. Для каждой группы пишешь свой скрипт, создаешь свой OU, создаешь свой GPO, привязываешь GPO к OU, обновляешь политику в домене и получаешь автоматическое подключение сетевых ресурсов любому пользователю в домене. Если захочешь не по-детски напугать свое начальство, то на очередной вопрос «Чем вы заняты?» быстро произноси предыдущее предложение.

Еще одно замечание. Все пользователи, входящие в какой-либо OU, должны иметь право на чтение и применение политики. Главное — чтобы ты по ошибке не внес учетную запись Администратора в любое OU, где бы на Админа могла бы примениться политика. Рекомендую придумать учетную запись, сделать ее Enterprise Admins и проконтролировать то, чтобы на эту учетную запись не распространялось действие изобретенных тобой политик. Что именно применяется применяется к определенной учетной записи, просматриваем через Group Policy Management> закладка Delegation> кнопка Advanced. Тут выбираешь нужную запись и смотришь, что имеется в наличии.

Как видишь, учетная запись Enterprise Admins может создавать и удалять объекты, но политика на нее не применяется, так как сброшен флаг в поле Apply Group Policy. Таким образом, можно создавать политику под каждую конкретную задачу и накручивать ее вплоть до отдельного пользователя, но об этом чуть позже.

Все то, что я так долго рассказывал тебе, намного быстрее выполняется вручную. Главное — понять идею. Подведем итог: на уровне контроллера домена с помощью политики мы будем устанавливать сильно ограниченное количество значений, политику паролей, аудита, подключение общих для всех пользователей домена ресурсов. Все остальное, что необходимо делать на уровне домена, проделывается через отдельные объекты GPO. Думаю, после того как ты проделаешь все это для своих групп, твои вопросы о способах создания политик навсегда отпадут и ты оценишь инструменты, которые есть у тебя в руках.