Структурирование подразделения для правильного моделирования организационной иерархии
Я экспериментирую с использованием подразделений в Active Directory и групповой политике моей сети. Однако у меня возникли небольшие проблемы с поиском правильного способа структурирования моих подразделений таким образом, чтобы я мог иметь отдельные отделы, но при этом пользователи с более высоким уровнем управления получают все права отделов ниже по иерархии организации.
Допустим, у меня есть 4 организационные единицы
- Продажи
- маркетинг
- бухгалтерский учет
- Должностное лицо
У каждого отдела есть свое собственное сопоставление дисков, которое я настраивал с помощью отдельных групповых политик в подразделениях подразделения. Однако единственным исключением из этой структуры является исполнительный департамент. Это лидеры компании, поэтому я хотел бы, чтобы пользователи в этом подразделении получили доступ ко ВСЕМ сопоставлениям дисков, а не только к одному диску. Однако, поскольку в OU может быть только один родитель, я не знаю, как я мог бы настроить это так, чтобы OU Executive мог наследовать политики сопоставления дисков от всех отделов.
Одна мысль будет иметь индивидуальные политики для каждого сопоставления дисков, а затем просто связать политики сопоставления дисков с каждым отделом, к которому я хотел иметь доступ. В этом случае подразделение Executive будет иметь 4 ссылки, по одному для каждого сопоставления диска. Хотя это в определенной степени имеет смысл, это не похоже на самое приемлемое решение. Каждый раз, когда был добавлен отдел или если существующим отделам были предоставлены дополнительные политики, мне нужно было бы дублировать эту ссылку и в подразделении Executive.
Другая мысль, которая у меня возникла, заключалась в том, чтобы просто использовать группы безопасности в качестве объектов в каждом подразделении и назначать пользователей подразделений группе безопасности вместо подразделения (например, DOMAIN\Marketing). Тем не менее, это не работает так, как я ожидаю. Кажется, что групповые политики применяются к пользователю только после того, как они были добавлены в соответствующее подразделение, и не имеет значения, в какой группе безопасности они находятся.
Единственное другое решение, о котором я могу подумать, - это просто удалить политики отделов из подразделений и вместо этого использовать фильтрацию безопасности для применения политик к различным группам. Тем не менее, похоже, что большинство примеров и учебных пособий не управляют объектами их политики, а предпочитают такие подразделения OU, как я перечислил выше.
Как мне правильно структурировать объекты групповой политики для достижения того, чего я хочу?
1 ответ
Надлежащим способом решения этой проблемы является использование единой групповой политики для карт накопителей в вашей организации с использованием предпочтений групповой политики.
Затем вы можете настроить правила таргетинга на каждой карте дисков в соответствии со своей собственной схемой безопасности. Я бы, вероятно, не использовал OU в качестве правила таргетинга, поскольку вам понадобятся группы безопасности независимо от того, что именно.