Стратегия AD для пользователей в нескольких отделах
Я работаю в колледже с почти тысячей пользователей (преподавателей и сотрудников). Многие сотрудники также преподают неполный рабочий день, а многие преподаватели преподают на разных факультетах.
Зная, что пользователь и / или компьютер могут существовать только в одном подразделении, какая стратегия позволит создать хорошую иерархическую структуру и при этом быть достаточно гибкой, чтобы различные групповые политики департаментов могли применяться к одному и тому же пользователю.
Это не может быть слишком необычным для сценария, но я просто пока не вижу простейшего или самого чистого макета.
1 ответ
Без какого-либо объяснения конкретных сценариев, которые вы ищете, трудно дать вам "шаг за шагом".
На применение групповой политики пользователя влияют:
- Отличительное имя (DN) объекта пользователя в объектах Active Directory и GPlink в объектах подразделения организации в родительском пути DN объекта пользователя
- Объекты GPlink в объекте сайта AD, содержащие IP-адрес компьютера, на котором происходит вход пользователя
- Атрибут "Блочное наследование" подразделений в родительском пути DN объекта пользователя или объекта сайта AD
- Атрибут "Принудительное" / "Без переопределения" объектов GPlink, связанных с подразделениями в родительском пути объекта пользователя или объекта сайта AD
- Членство в группе безопасности учетных записей пользователей и разрешение, которое им предоставляется в отношении применения объектов групповой политики или применения определенных параметров политики или параметров в объекте групповой политики, к которым могут быть прикреплены списки ACL (политики установки программного обеспечения и параметры предпочтения групповой политики имеют списки ACL в пределах GPO, например)
- Включение обработки групповой политики Loopback на компьютерах (в режиме слияния или замены)
Это все механизмы для управления приложением групповой политики пользователя. Между всеми этими функциями вы можете создавать достаточно сложные сценарии развертывания.
Ваша иерархия OU всегда должна быть разработана в первую очередь на основе запланированного делегирования контроля. Вы получаете только одну иерархию подразделений, и нет хороших механизмов для отделения делегирования управления от иерархии подразделений. Дизайн для делегирования управления первым, применение групповой политики второе.
Я фокусируюсь на использовании членства в группах безопасности для фильтрации пользовательских приложений групповой политики. Никогда не забывайте, что некоторые параметры в объектах групповой политики имеют списки управления доступом отдельно от самого объекта групповой политики. Функции "Наследование блоков" и "Принудительное" / "Без переопределения" следует использовать с осторожностью и, как правило, указывают на неисправный дизайн. Обработка групповой политики Loopback может быть очень мощным и полезным инструментом, но его немного сложно понять.
Вы сосредотачиваетесь на пользователях, но я также упомяну компьютеры. Приложение групповой политики компьютеров имеет те же функции фильтрации, что и пользовательская групповая политика, но также включает фильтрацию WMI. Фильтрация WMI позволяет назначать объекты групповой политики конкретным аппаратным или операционным атрибутам компьютеров. Я часто вижу, что фильтрация групп безопасности игнорируется при фильтрации групповой политики компьютера.
Есть некоторые вещи, которые вы можете выполнить как с помощью фильтрации WMI, так и фильтрации групп безопасности для групповой политики компьютера. Фильтрация WMI имеет дополнительную возможность динамического расчета для каждого приложения групповой политики (в отличие от членства в группах безопасности, которое необходимо изменить вручную, чтобы повлиять на фильтрацию). Фильтрация групп безопасности все еще может быть полезной, если у вас есть компьютеры, расположенные в разнородных подразделениях без фильтруемого атрибута WMI, к которым должны применяться общие объекты групповой политики. Я часто использую фильтрацию групп безопасности на компьютерах для управления политикой установки программного обеспечения (в которой у меня есть объект групповой политики с несколькими назначенными пакетами программ, каждый с уникальным списком ACL, включающим группу для управления установкой программного обеспечения).
Самое важное, что вы можете сделать, откладывая в сторону все, что я сказал выше, это убедиться, что вы полностью понимаете, как клиент групповой политики рассчитывает результирующий набор политик, и, используя эти знания, проведите мозговой штурм и протестируйте возможные проекты, прежде чем вводить их в эксплуатацию. Я твердо верю, что тестирование должно начинаться с ручки и бумаги (белая доска и т. Д.), А не программного обеспечения. Вы должны иметь достаточно организационных знаний, чтобы иметь возможность разрабатывать реалистичные сценарии и тестировать их. Вовлеките другие группы в вашей ИТ-организации (и за ее пределами, если это необходимо). Например, ваша группа технической поддержки будет иметь делегирование управляющих потребностей, которые будут управлять физической иерархией OU. У вашей группы поддержки настольных компьютеров могут возникнуть потребности в установке программного обеспечения, которые управляют фильтрацией групповой политики компьютеров. Существует множество возможных сценариев, которые необходимо обсудить, разработать на бумаге и, наконец, протестировать в лабораторном сценарии, прежде чем вводить в эксплуатацию.