Назад | Перейти на главную страницу

Стратегия AD для пользователей в нескольких отделах

Я работаю в колледже с почти тысячей пользователей (преподавателей и сотрудников). Многие сотрудники также преподают неполный рабочий день, и многие преподаватели преподают на разных факультетах.

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

Это не может быть слишком необычным сценарием, но я просто еще не вижу ни самого простого, ни самого чистого макета.

Без какого-либо объяснения конкретных сценариев, которые вы ищете, трудно дать вам какой-либо «шаг за шагом».

На применение групповой политики пользователей влияют:

  • Отличительное имя (DN) объекта пользователя в Active Directory и объекты GPlink в объектах организационной единицы в родительском пути DN объекта пользователя
  • Объекты GPlink в объекте сайта AD, содержащие IP-адрес компьютера, на котором происходит вход пользователя.
  • Атрибут «Block Inheritance» для подразделений в родительском пути DN объекта пользователя или в объекте сайта AD.
  • Атрибут «принудительно» / «без переопределения» объектов GPlink, связанных с подразделениями в родительском пути объекта пользователя или в объекте сайта AD.
  • Членство учетных записей пользователей в группе безопасности и предоставляемое им разрешение на применение объектов групповой политики или применение определенных политик или параметров предпочтений в рамках объекта групповой политики, к которым могут быть прикреплены списки контроля доступа (параметры политики установки программного обеспечения и параметры предпочтений групповой политики имеют списки контроля доступа в пределах GPO, например)
  • Включение обработки групповой политики Loopback на компьютерах (в режиме слияния или замены)

Это все механизмы для управления приложением групповой политики пользователя. Между всеми этими функциями вы можете создавать достаточно сложные сценарии развертывания.

Иерархия вашего подразделения должна всегда быть спроектированным в первую очередь на основе запланированного делегирования управления. У вас есть только одна иерархия OU, и нет хороших механизмов для отделения делегирования управления от иерархии OU. Во-первых, дизайн для делегирования управления, во-вторых, приложения групповой политики.

Я сосредоточен на использовании членства в группе безопасности для фильтрации приложения групповой политики пользователей. Никогда не забывайте, что некоторые настройки в объектах групповой политики имеют списки управления доступом отдельно от самого объекта групповой политики. Функции «Наследование блока» и «Принудительное» / «Без отмены» следует использовать с осторожностью и обычно указывают на неправильный дизайн. Обработка групповой политики Loopback может быть очень мощным и полезным инструментом, но его немного сложно понять.

Вы сосредоточены на пользователях, но я хочу упомянуть и компьютеры. Приложение компьютерной групповой политики имеет те же функции фильтрации, что и пользовательская групповая политика, но также включает фильтрацию WMI. Фильтрация WMI позволяет нацеливать объекты групповой политики на определенные атрибуты компьютеров, связанные с оборудованием или операционной системой. Я часто вижу, что фильтрация групп безопасности игнорируется при фильтрации групповой политики компьютера.

Есть некоторые вещи, которые можно выполнить как с помощью фильтрации WMI, так и с помощью фильтрации групп безопасности для групповой политики компьютера. WMI Filtering имеет добавленную функцию динамического расчета для каждого приложения групповой политики (в отличие от членства в группах безопасности, которое необходимо изменить вручную, чтобы повлиять на фильтрацию). Фильтрация групп безопасности все еще может быть полезной, если у вас есть компьютеры, расположенные в разных подразделениях без фильтруемого атрибута WMI, к которым необходимо применять общие объекты групповой политики. Я часто использую фильтрацию групп безопасности с компьютерами для управления политикой установки программного обеспечения (при этом у меня есть объект групповой политики с несколькими назначенными пакетами программного обеспечения, каждый из которых имеет уникальный ACL, который включает группу для управления установкой программного обеспечения).

Самое важное, что вы можете сделать, отбросив все, что я сказал выше, - это убедиться, что вы полностью понимаете, как клиент групповой политики вычисляет результирующий набор политик, и, обладая этими знаниями, проведите мозговой штурм и протестируйте возможные проекты перед их запуском в производство. Я твердо уверен, что тестирование следует начинать с ручки и бумаги (доски и т. Д.), А не с программного обеспечения. Вам необходимо обладать достаточными организационными знаниями, чтобы иметь возможность разрабатывать реалистичные сценарии и тестировать их. Привлекайте другие группы в вашей ИТ-организации (и за ее пределами, если необходимо). Например, ваша команда службы поддержки будет иметь потребности в делегировании контроля, которые будут управлять физической иерархией OU. У вашей группы поддержки настольных компьютеров может быть потребность в установке программного обеспечения, которое управляет фильтрацией групповой политики компьютеров. Существует множество возможных сценариев, которые следует обсудить, разработать на бумаге и, наконец, протестировать в лабораторных условиях перед запуском в производство.