Мы хотим добавить логическую структуру в нашу (Win 2003) иерархию AD. У нас один домен и около 500 пользователей. В настоящее время все пользователи и компьютеры объединены в одно подразделение. Все группы безопасности и рассылки находятся во втором OU. Членство в группах, по сути, зависит от индивидуальных пользователей без вложенности групп.
Мои вопросы:
Вот основные принципы рекомендаций Microsoft по логическому проектированию AD:
Сначала проектируйте делегирование управления, потому что оно основано на разрешениях AD и является наиболее негибкой осью для изменения. Если вы не выполняете делегирование управления, не беспокойтесь об этом (но я бы все равно это спланировал - даже в такой маленькой организации вам могут потребоваться назначенные пользователи в филиалах, чтобы иметь возможность сбрасывать пароли, и т.д).
Второй дизайн для применения групповой политики. Фильтрация приложения групповой политики по членству в группе безопасности позволяет применять GPO только к подмножеству объектов пользователя или компьютера ниже точки, на которую он связан в каталоге, поэтому эта ось обладает большей гибкостью, чем разрешения AD.
Дизайн, наконец, для организации и простоты использования. Упростите поиск вещей для себя и других администраторов.
Обдумывайте каждое из этих соображений при разработке, расставляя их по приоритетам согласно рекомендациям. Позже легко что-то изменить (сравнительно), и вы никогда не «сделаете это правильно» с первой попытки. Прежде чем я начну использовать DCPROMO в своем первом контроллере домена, я обычно рисую предлагаемую структуру на бумаге или доске и просматриваю возможные сценарии использования, чтобы увидеть, «выдерживает» ли мой дизайн. Это отличный способ избавиться от проблем в дизайне.
(Не забывайте также о применении групповой политики к объектам сайта. Вы должны быть осторожны с применением междоменного GPO, когда вы связываете GPO на сайтах, но если вы представляете среду с одним доменом, вы можете получить много отличных функциональность за счет связывания объектов групповой политики с сайтами. Проработайте с ним несколько примеров сценариев - я считаю, что он отлично подходит для загрузки программного обеспечения, в котором есть "специфичные для сайта" настройки, или предоставления пользователям определенных сценариев входа в систему при входе на компьютеры в определенных физические местоположения, посредством обработки групповой политики обратной петли.)
Я всегда разделял пользователей, компьютеры и группы на отдельные подразделения по той простой причине, что это упрощает управление.
Если у вас нет веских причин для конкретной структуры AD, спроектируйте свою AD с административной точки зрения. Подумайте о том, где вы собираетесь применять политику.
Если вы применяете большую часть своих политик на уровне отдела, используйте Department \ Location \ Object
Если вы применяете большую часть своих политик на уровне местоположения, используйте Location \ Department \ Object
Если бы вы сделали это по-другому, это означало бы, что вам придется связать свои политики в нескольких подразделениях, что потребует ненужной работы.
Вложенные группы - это прекрасно и, опять же, значительно упрощают управление AD.
Я предпочитаю проектировать структуры AD, имея в виду «облегчение управления», а не отражать физическую структуру компании, однако они часто совпадают.
Думаю, если бы мне снова пришлось переделывать свой AD, я бы сделал несколько вещей по-другому, но я обнаружил, что:
Пользователи - разделите тезисы на отделы, но также с областями для временного персонала или сотрудников агентства. Местоположение для них не так важно, поскольку, несомненно, люди будут перемещаться.
Компьютеры - разделите их на местоположения и вспомогательные местоположения. Т.е. OfficeComputers / LondonOffice / Room103 (Финансы). Это означает, что вы можете применить настройки к одному местоположению или офису - например, другому прокси-серверу или другим настройкам антивируса (конечно, только если программа управления AV использует AD) - без реорганизации, и, надеюсь, вам не придется открывать банку червей, которая является обработкой обратной связи.
Я также считаю полезным не использовать встроенные группы пользователей или компьютеров, никаких технических проблем, а просто так, чтобы вы могли легко увидеть, где чего не должно быть.
Наконец, разделите и ваши серверы, я выбрал местоположение / роль, что, похоже, сработало довольно хорошо.
Как уже было сказано, вот мой небольшой пример. Имейте в виду, что нет правильного или неправильного, все зависит от потребностей - то есть в первую очередь от организации или местоположения? Я предпочитаю в первую очередь организационную роль даже для ролей компьютеров / серверов. Мне также нравится возможность указать одно подразделение, чтобы получить всех сотрудников, и не было мусора для заполнения списков сотрудников в интрасети. Не стесняйтесь редактировать!
В этом случае я бы просто разделил их по местоположению. Результирующая структура OU будет выглядеть примерно так:
Location1
-Computers
-Groups
-Users
Location2
-Computers
-Groups
-Users
и т.п.
Я действительно не вижу здесь необходимости в дополнительных разделах, например отделом, так как это приведет к дополнительным накладным расходам администратора, не дав при этом ничего взамен. Однако разделение по местоположению позволит вам реализовать делегирование на каждом сайте.
Я использую следующие рекомендации: Пользователи; организовать согласно группам графиков кадров; организовать в соответствии с рабочим процессом Компьютеры; организовать по географическому положению
Однако другие ответы в этой теме тоже очень хороши.