Организация пользователей в домене Windows Server 2008

Вам не нужна многодоменная среда. Вы можете использовать многодоменную среду только тогда, когда это необходимо (разные политики паролей для разных пользователей в среде Windows 2003, использование домена в качестве границы репликации для двух или более очень больших сред). Среда с одним доменом - путь.

Вы правы поставить хотя бы один DC в каждом физическом месте. Обязательно настройте конфигурацию AD "Сайт" и "Подсеть", чтобы AD мог принимать интеллектуальные решения по репликации, а (что более важно) клиентские компьютеры могли принимать интеллектуальные решения о том, с каким DC они общаются во время входа в систему. Оба DC должны быть помечены как серверы "Глобального каталога" и должны предоставлять службы DNS для ПК по их местонахождению. (Вы должны указать удаленный DC в качестве вторичного DNS-сервера для ПК, но вы бы хотели, чтобы они сначала поговорили с DC в своем местоположении.)

Организация пользователей, компьютеров, групп и других объектов в подразделения в Active Directory (AD) основана на двух критериях:

• Делегирование управления административными задачами в AD
• Применение групповой политики

В качестве третичной задачи вы могли бы организовать объекты в AD так, чтобы их было визуально легко найти, но это строго эстетическая задача.

Делегирование управления связано с изменением разрешений по умолчанию в AD, чтобы другие пользователи могли выполнять административные задачи. Представьте себе сценарий, в котором у вас есть филиал за пределами площадки и "опытный ИТ-пользователь" в этом офисе, который хочет выполнить сброс пароля для пользователей, которые забыли свой пароль в своем офисе.

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

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

Групповая политика обычно применяется к пользователям или компьютерам путем связывания объектов групповой политики с подразделениями. (Можно использовать групповую политику без каких-либо OU, но это большая боль и нереалистичная стратегия развертывания.) Если вам нужно было установить приложение с помощью "Политики установки программного обеспечения" на все ПК в бухгалтерии, например, имея ПК, организованные в подразделения, представляющие департаменты, позволят вам легко настроить целевой объект на всех этих ПК.

Применение групповой политики может контролироваться другими средствами (членство в группе пользователя или компьютера, фильтрация WMI, IP-подсеть посредством объектов групповой политики, связанных с объектами "Сайт"), тогда как делегирование управления может работать только на основе OU, Таким образом, делегирование контроля является вашей первой главной задачей при проектировании (т. Е. Убедитесь, что предложенный макет OU работает для желаемой вами стратегии делегирования управления), а применение групповой политики (которое является более гибким) является вторичной задачей.

Возможно, вам стоит попросить кого-нибудь, знакомого с Active Directory, сесть с вами на пару часов и задать вам несколько вопросов о том, как вы хотите использовать AD для разработки предложенного проекта. Похоже, что довольно простая среда и сети OU легко перестроить в будущем, но хороший консультант по AD может дать вам отличные идеи, которые по мере роста позволяют минимизировать затраты на администрирование и оптимизировать предоставление функциональности пользователям,

Редактировать:

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

Группы безопасности используются для предоставления разрешений таким ресурсам, как общие папки. (Вы также можете указывать имена отдельных пользователей в разрешениях, но вы не должны, за исключением крайних случаев, таких как домашние каталоги.) Подразделения не являются "субъектами безопасности"- то есть с ними не связан идентификатор безопасности (SID), и поэтому не может быть названо в разрешениях.

Иерархия AD OU используется для управления применением групповой политики.

Разрешения, установленные для иерархии подразделений (и структуры иерархии под этими разрешениями), управляют делегированием административных обязанностей в Active Directory.

Иногда возникает ощущение дублирования, когда приходится создавать, скажем, подразделение "Бухгалтерский учет" и группу безопасности "Бухгалтерский учет". К сожалению, именно так был разработан продукт. Я не могу сказать, что я сталкивался с подобной ситуацией, хотя во многих случаях.

Немного ошеломляет то, что группа безопасности является объектом AD, и поэтому ее разрешения могут быть изменены, чтобы позволить произвольному набору пользователей контролировать членство в группе. Эта группа, в свою очередь, может использоваться для управления другими типами доступа (например, разрешениями для общих папок или разрешениями на выполнение дополнительных административных задач в AD). Самая легкая для понимания группа этой природы - "Администраторы домена". Делегирование кому-либо прав на управление членством в группе "Администраторы домена" может (преднамеренно или непреднамеренно) предоставить этому делегированному администратору право поднять кого-либо (возможно, себя) на роль "Администратора домена".

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