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

Структурирование OU для правильного моделирования организационной иерархии

Я экспериментирую с использованием подразделений в Active Directory и групповой политике моей сети. Однако у меня возникли небольшие проблемы с определением правильного способа структурирования моих подразделений, чтобы у меня были отдельные отделы, но при этом пользователи более высокого уровня управления получали все права отделов более низкого уровня в иерархии организации.

Допустим, у меня есть 4 организационных подразделения

У каждого отдела есть собственное сопоставление дисков, которое я настроил с помощью индивидуальных групповых политик внутри подразделений отдела. Однако единственным исключением из этой структуры является Должностное лицо отдел. Это руководители компании, поэтому я хотел бы, чтобы пользователи в этом подразделении получили доступ ко ВСЕМ сопоставлениям дисков, а не только к одному диску. Однако, поскольку у подразделения может быть только один родительский элемент, я не знаю, как это настроить, чтобы исполнительное подразделение могло наследовать политики сопоставления дисков от всех отделов.

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

Другая мысль, которая у меня возникла, заключалась в том, чтобы просто использовать группы безопасности в качестве объектов в каждом подразделении и назначать пользователей отдела в группу безопасности вместо подразделения (например, DOMAIN \ Marketing). Однако, похоже, это не работает так, как я ожидал. Групповые политики кажутся примененными к пользователю только после того, как он был добавлен в соответствующее подразделение, и не имеет значения, в какой группе безопасности он находится.

Единственное другое решение, которое я могу придумать, - это просто переместить политики отдела из подразделений и вместо этого полагаться на фильтрацию безопасности для применения политик к разным группам. Однако похоже, что это не тот способ, которым большинство примеров и руководств обрабатывают управление своими объектами политики, вместо этого отдавая предпочтение этим подразделениям подразделения, как я перечислил выше.

Как я могу правильно структурировать объекты групповой политики для достижения того, что мне нужно?

Правильный способ справиться с этим - использовать единую групповую политику для карт дисков в вашей организации с использованием настроек групповой политики.

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