Для каждой Организационной Единицы, отражающей какой-либо набор структурных подразделений организации, должен быть сформирован индивидуальный набор групповых политик. Общие настройки, характерные для всех пользователей, например указание настроек прокси-сервера, целесообразно выделить в групповую политику, привязываемую на уровне домена или сайта. Следует отметить, что для OU ASU_TP и Finance необходимо создать групповую политику, запрещающую пользователям, не принадлежащим к этим OU, регистрироваться на рабочих станциях и серверах этих OU. И наоборот.
2.7.1 ГП уровня сайта. На уровне сайта целесообразно создать и привязать групповую политику, определяющую настройки браузера Интернет для данного сайта. Если каким-нибудь группам пользователей потребуется доступ в Интернет отличный от стандартного в этом сайте, групповую политику можно будет отфильтровать на уровне групп.
2.7.2 ГП уровня домена. На уровне домена целесообразно создать и привязать следующие групповые политики:
• Политика перенаправления папок. Чтобы обеспечить независимость пользователей от физических машин, на которых они работают, сократить время простоя в случае выхода машины из строя и обеспечить возможность централизованного резервного копирования и восстановления пользовательских данных используются перемещаемые пользовательские профили и перемещаемые папки пользователей. • Правила перемещения папок определяются групповой политикой Folder Redirection, которая привязывается на уровне домена. Правом управления этими политиками обладают только Администратор Домена и Администратор Предприятия. • Политика применения паролей. ГП, определяющая размер паролей пользователей, правила составления и срок актуальности. • Административная политика. ГП, включающая или удаляющая администратора домена в группу локальных администраторов машин. • Политика распространения обновлений системного ПО.
2.7.3 ГП уровня Организационной Единицы. На уровне OU целесообразно создать и привязать следующие групповые политики:
• Политика настроек «рабочего стола». ГП, определяющая «вид рабочего» стола ОС пользователя, доступность элементов настройки. • Политики распространения ПО на рабочие станции. • Политика разрешенного ПО. ГП, определяющая наборы прикладного ПО разрешенного для запуска на рабочих станциях пользователей. • Политика авторизации пользователей. Политика, ограничивающая возможность разных групп пользователей авторизоваться на рабочих станциях других подразделений. • Политики гостей и сторонних разработчиков.
2.8 Делегирование административных прав. Делегирование прав применяется для достижения двух целей:
• Назначение отдельного администратора для управления OU Finance; • Делегирование отдельных административных полномочий ИТ персоналу для уменьшения рутинной нагрузки на Администратора Домена.
2.8.1 Делегирование прав администратора OU В ряде структурных подразделений организации, существует своя независимая информационная политика. Для поддержания ИТ инфраструктуры, пользователей и специфического ПО Организационных Единиц, соответствующих этим подразделениям, существует выделенный администратор. Учетная запись этого администратора должна обладать всеми правами и полномочиями для администрирования объектов в своем OU. Так же этот администратор должен обладать ограниченными правами в рамках всего домена, позволяющими ему просматривать активный каталог, копировать необходимые шаблоны и переносить некоторые объекты из контейнеров поумолчанию в свой OU.
2.8.2 Делегирование прав ИТ персоналу. Для снижения нагрузки на администратора Домена и возможности выполнять некоторые простейшие операции в его отсутствие часть административных прав делегируется ИТ персоналу без предоставления членства в группе Domain Admins. К таким правам можно отнести создание учетных записей пользователей по шаблонам, включение учетных записей в группы и OU, копирование шаблонов.
2.9 Разработка политик аудита. При разработке политик аудита будет решен следующий круг вопросов:
• Определение списка контролируемых ресурсов: файловых папок, объектов каталога, компьютеров; • Определение статуса контролируемого события для ресурсов, Success или Fail; • Определение действий системы при превышении допустимых пороговых значений событий: отправка сообщения администратору, блокирование доступа к объекту и т.п.
2.10 Определение пути миграции. В процессе проектирования предстоит сделать выбор пути, по которому от существующей в настоящей момент структуры будет сделан переход к новой единой Службе каталога. Для обсуждения предлагается следующий путь миграции.
• Выстраивается новая доменная структура; • Служба каталога наполняется объектами; • В пилотной зоне проверяется работоспособность всех служб и сервисов новой структуры • Проводится постепенный перевод пользователей и ресурсов в новую структуру, это потребует обновления парка рабочих станций пользователей. • Параллельно продолжает существовать служба каталога Novell NDS, что потребует ведения двойных баз данных учетных записей.
