Смена OU для компьютеров по умолчанию в Active Directory. Что такое ou в ad


Cтруктура орг. подразделений(OU) служит для делегирования прав и назначения групповых политик – Сибирский ТАМ

Дерево орг. подразделений(OU) – это, прежде всего, рабочий инструмент администратора сети, поэтому структура должна быть понятной и удобной именно администратору для выполнения ежедневных операций. Организационное подразделение в Active Directory, как и обычная папка-контейнер, может содержать различные объекты: пользователей, группы, компьютеры, другие папки и организационные подразделения.

Возможность назначать групповые политик на орг. подразделения (OU) - основное отличие от обычного контейнера AD. Для OU, как и для обычного контейнера, можно гибко задавать права доступа и делегировать управление. Забавный факт, в оснастке Windows 2008 Active Directory Users’n’Computers просто так создать контейнер из меню New не получится, на выбор только объекты или орг. подразделение.

Таким образом, задачи OU, помимо хранения объектов в Active Directory это •    Делегирование управления другим администраторам компании •    Назначение групповых политик

Групповые политики имеют дополнительные методы контроля назначения – фильтрация по группам безопасности (как пользователей, так и компьютеров ) и WMI фильтрация. Так что получается, что делегирование прав и удобство ежедневного администрирования – это входные данные для оптимизации вашего дерева организационных подразделений.

Разрабатывайте дерево OU в первую очередь для делегирования прав и удобства работы

Вопрос какова “правильная структура Active Directory” конечно стандартный и очень частый, но достаточно дискуссионный, так как у всех организаций разные уровни зрелости ИТ, и всегда есть свои особенности администрирования ИТ-систем. В частности, важно знать: сколько людей сопровождают AD, какое количество площадок, каким образом все организовано административно-нормативно, какие есть принятые политики безопасности.

По аналогии с известной моделью оптимизации ИТ-инфраструктуры (IO модель) типовая эволюция дерева OU в разных компаниях примерно такая: 

  1. «Базовый уровень» - пользователей складываем в папку Users, иногда в специально созданные один или два контейнера OU без особого смысла. О том, что такое OU в теории никто ничего не знает, зачем завели - не помнят (достаточно много компаний). 

  2. «Стандартизованный уровень» - структура OU повторяет штатное расписание компании… ну без комментариев, кроме одного – иногда бывает, что такая «штатка» куда точнее отражает реальность, чем например известные документы в отделе кадров. Распространенность – многие компании, считающие себя продвинутыми в AD, но без географических особенностей. Скажем честно, усилия, которые тратятся на поддержание такой структуры, как правило, неоправданные. 

  3. «Рациональный уровень» - структура OU сформирована с учетом количества администраторов и делегирования полномочий на первом уровне вложенности, как правило, это география, а дальше повторяет штатное расписание из «стандартизованного уровня». Смысл в том, что в региональных отделениях компании есть свои админы, которые должны следить за своими пользователями – так что OU первого уровня заводят по географии, которая может несколько отличатся от структуры компании, но часто к ней крайне близка. 

  4. «Динамический уровень». Структура OU организована так, чтобы с минимальными усилиями решать известные задачи администрирования пользователей, компьютеров и групп, при этом имея возможность предлагать людям инструменты для гибкой самостоятельной работы.

По внешнему виду «динамическая» структура может оказаться весьма непростой для понимания новому человеку. Как пример, у нас мало кто из пользователей знает как выглядит дерево орг. подразделений, но есть спец. сайт для обычных людей, который дает возможность практически кому угодно создавать и добавлять группы AD или создавать рассылки Exchange, а также управлять членством людей в них простым и понятным способом для людей.

Организация OU на примере структуры AD -  встречается и в Windows SBS, и в больших распределенных каталогах Active Directory

За основу для проектированы своего дерева OU в Active Directory имеет смысл взять стандартный подход, который использует Microsoft в своих решениях. Этот подход можно увидеть и в реализации дерева OU MyBusiness в Small Business Server, и в больших штучных проектных решения MCS для конкретных заказчиков.

Единица администрирования и делегирования – ветвь дерева OU, внутри которой структура создана , прежде всего, для удобства ежедневной работы и групповых политик. Имеет смысл разделить на отдельные контейнеры пользователей, группы безопасности и рассылки, а также создать различные контейнеры для рабочих станций, лэптопов и серверов.

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

Помните, что делегировать доступ лучше всего, используя ролевую модель администрирования, т.е. предоставлять доступ для специально созданных ролевых групп безопасности, куда затем включать учетные записи администраторов. Для делегирования доступа, конечно же, надо использовать удобный, надежный и простой Мастер делегирования прав доступа Active Directory, который запускается из контекстного меню оснастки Active Directory Users’n’Computers.

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

Лучшее решение – решение удобное в реальной работе

Свою структуру можно создать вручную, можно ее существенно расширить или наоборот упростить по сравнении с примером на картинке. Иногда есть смысл использовать скрипты для генерации дерева OU из штатного расписания, а можно внедрить полноценное решение по оптимизации работы с идентификационной информацией, например MS Identity Lifecycle Management.

Какой бы из вариантов работы вы не выбрали – помните, что обычным людям все эти деревья OU совершенно неинтересны, нужно чтобы все работало быстро и надежно.

Успехов.

Для домашнего чтения

blogs.technet.microsoft.com

Администрирование Active Directory. Создание контейнера при помощи оснастки ADUC

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

Я создам у себя в AD, структуру такого плана:

  • На верху OU территориальной принадлежности. В моем случае это города
  • Дальше это OU серверы, пользователи и компьютеры
  • Дальше можно уже при необходимости делить на этажи, отделы и все такое, как вашей фантазии придет в голову.

Ну собственно начнем. Открываем Пуск-Администирование-ADUC

Администрирование Active Directory-1 часть. Создание контейнера при помощи оснастки ADUC.-01

Дальше правым кликом по имени нашего домена, выбрать меню Создать-Подразделение или нажать иконку сверху.

Администрирование Active Directory-1 часть. Создание контейнера при помощи оснастки ADUC.-02

Вводим название OU, в моем случае Город. Дальше подобным образом создаем нужное вам количество OU в нужной вам иерархии.

Администрирование Active Directory-1 часть. Создание контейнера при помощи оснастки ADUC.-03

У меня это выглядит вот так. Есть несколько городов, которые содержат в себе дополнительные организационные подразделения:

  • Пользователи
  • Группы рассылок
  • Группы
  • Системные учетные записи
  • Сервера
  • Компьютеры

Администрирование Active Directory-1 часть. Создание контейнера при помощи оснастки ADUC.-04

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

Администрирование Active Directory-1 часть. Создание контейнера при помощи оснастки ADUC.-05

Недостаточно привилегий для удаления организационного подразделения, или объект защищен от случайного удаления

Администрирование Active Directory-1 часть. Создание контейнера при помощи оснастки ADUC.-06

Для того чтобы, это поправить и у вас был в Active Directory порядок, идем меню "Вид-Дополнительные компоненты".

Администрирование Active Directory-1 часть. Создание контейнера при помощи оснастки ADUC.-07

Теперь кликаем правым кликом по нужному OU и выбираем свойства.

Администрирование Active Directory-1 часть. Создание контейнера при помощи оснастки ADUC.-08

Переходим на вкладку "Объект", и видим эту галочку, которая защищает OU. Сняв ее можно проводить манипуляции, совет как сделаете, что нужно поставьте галчку обратно.

Администрирование Active Directory-1 часть. Создание контейнера при помощи оснастки ADUC.-09

Как видите компания Microsoft сделала процесс создания объектов в Active Directory, очень тривиальным, так как многие вещи, системный администратор просто делегирует, например, на отдел кадров, которые заводят учетные записи. Если остались вопросы, то пишите их в комментариях, рад буду пообщаться.

Материал сайта Pyatilistnik.org

pyatilistnik.org

Смена OU для компьютеров по умолчанию в Active Directory

При включении компьютера в домен Active Directory при помощи GUI Windows или команды NETDOM.EXE,по умолчанию вновь созданный объект попадает в контейнер (OU) Computers, который является контейнером по-умолчанию для всех вновь созданный объектов типа «Computer».

Недостаток такого подхода заключается в том, что вы не можете назначить ни одной доменной групповой политики на OU Computers, и получается, что на новых компьютерах домена (потенциально небезопасных) вы просто не сможете применить специальные параметры безопасности (помимо стандартных для всего домена).

Разберемся, где же хранятся настройки, определяющие OU  по-умолчанию для компьютеров домена. Откройте консоль Active Directory Users and Computers (как установить оснастку Active Directory в Windows 7), или же консоль ADSI Edit, при помощи контекстного меню перейдите в свойства домена, а затем перейдите на вкладку Attribute Editor.

Контейнер AD, в который попадают по-умолчанию новые компьютеры, определяются в атрибуте wellKnownObjects.

Но при попытке дважды щелкнуть по этому атрибуту, появится окно с ошибкой о том, что нет зарегистрированного редактора для обработки такого типа атрибутов. Я предполагаю, что данный атрибут просто защищен от ручного внесения изменений. Поэтому для доступа к данному параметру, я воспользуюсь замечательной утилитой от Марка Русиновича — Active Directory Explorer.

Атрибут  wellKnownObjects содержит примерно такую информацию:

98 39 240 175 31 194 65 13 142 59 177 6 21 187 91 15, CN=redircomp.exeNTDS Quotas,DC=LABHOME,DC=local

244 190 146 164 199 119 72 94 135 142 148 33 213 48 135 219, CN=Microsoft,CN=Program Data,DC=LABHOME,DC=local

 

 

9 70 12 8 174 30 74 78 160 246 74 238 125 170 30 90, CN=Program Data,DC=LABHOME,DC=local

34 183 12 103 213 110 78 251 145 233 48 15 202 61 193 170, CN=ForeignSecurityPrincipals,DC=LABHOME,DC=local

24 226 234 128 104 79 17 210 185 170 0 192 79 121 248 5, CN=Deleted Objects,DC=LABHOME,DC=local

47 186 193 135 10 222 17 210 151 196 0 192 79 216 213 205, CN=Infrastructure,DC=LABHOME,DC=local

171 129 83 183 118 136 17 209 173 237 0 192 79 216 213 205, CN=LostAndFound,DC=LABHOME,DC=local

171 29 48 243 118 136 17 209 173 237 0 192 79 216 213 205, CN=System,DC=LABHOME,DC=local

163 97 178 255 255 210 17 209 170 75 0 192 79 215 216 58, OU=Domain Controllers,DC=LABHOME,DC=local

 

 

170 49 40 37 118 136 17 209 173 237 0 192 79 216 213 205, CN=Computers,DC=LABHOME,DC=local

 

169 209 202 21 118 136 17 209 173 237 0 192 79 216 213 205, CN=Users,DC=LABHOME,DC=local

Теперь, когда мы поняли, где хранится нужный нам параметр, попробуем изменить его. Как я уже говорил, атрибут wellKnownObjects  нельзя отредактировать при помощи консолей AD, наверное, это и к лучшему )). Для модификации этого параметра Microsoft разработала специальную утилиту, которая называется redircmp.exe, которая хранится в папке %SystemRoot%\System32 (на системах Windows Server 2003/2008).

Перед использованием утилиты redircmp.exe, создадим новый Organizational Unit, в который в дальнейшем будут  попадать объекты Computer. Для примера я создал OU StagedComputers.  Выполним следующую команду:

redircmp OU=StagedComputers,DC=LABHOME,DC=local

А затем при помощи Active Directory Explorer просмотрим содержимое атрибута wellKnownObjects (как вы увидите, оно изменилось):

170 49 40 37 118 136 17 209 173 237 0 192 79 216 213 205, OU=StagedComputers,DC=LABHOME,DC=local

98 39 240 175 31 194 65 13 142 59 177 6 21 187 91 15, CN=NTDS Quotas,DC=LABHOME,DC=local

244 190 146 164 199 119 72 94 135 142 148 33 213 48 135 219, CN=Microsoft,CN=Program Data,DC=LABHOME,DC=local

 

 

9 70 12 8 174 30 74 78 160 246 74 238 125 170 30 90, CN=Program Data,DC=LABHOME,DC=local

34 183 12 103 213 110 78 251 145 233 48 15 202 61 193 170, CN=ForeignSecurityPrincipals,DC=LABHOME,DC=local

24 226 234 128 104 79 17 210 185 170 0 192 79 121 248 5, CN=Deleted Objects,DC=LABHOME,DC=local

47 186 193 135 10 222 17 210 151 196 0 192 79 216 213 205, CN=Infrastructure,DC=LABHOME,DC=local

171 129 83 183 118 136 17 209 173 237 0 192 79 216 213 205, CN=LostAndFound,DC=LABHOME,DC=local

171 29 48 243 118 136 17 209 173 237 0 192 79 216 213 205, CN=System,DC=LABHOME,DC=local

163 97 178 255 255 210 17 209 170 75 0 192 79 215 216 58, OU=Domain Controllers,DC=LABHOME,DC=local

 

 

169 209 202 21 118 136 17 209 173 237 0 192 79 216 213 205, CN=Users,DC=LABHOME,DC=local

И наконец, с целью тестирования, я попробовал включить Windows XP (имя ПК VMXP-001) в домен LABHOME, действительно новый объект типа Computer появился в контейнере StagedComputers.

winitpro.ru

Основные термины и понятия Active Directory. Логическая структура - Active Directory - Каталог статей

Основные термины и понятия  Active Directory. Логическая структура

(продолжение начало тут)

Мы уже с вами начали переходить с "фишек" на нормальные термины и понятия которые используются в службе каталогов Active Directory. Но к сожалению то что мы с вами рассмотрели еще не сфффЁ. Давайте перечислим их еще раз, по взрослому, так как эти очень важные понятия а так же добавим новые понятия. 

Каталог (directory) — называется совокупность информации об объектах, которые тем или иным способом связаны друг с другом. 

Или

Каталог  — это информационный ресурс, используемый для хранения информации о каком-либо объекте или объектах.

Учетная запись пользователя (акаунт) - состоит из имени пользователя (логин) и пароля (пассФВорд) (например pupkin и пароль "d345rtНfa"). Не имея эти данные нельзя войти в сеть или работать на компе. Первый раз при входе в сеть пароль вам сообщит администратор и в зависимости от того как он настроим работу с паролем в Active Directory (мы это рассмотрим позже) вы можете сразу его сменить на ваш пароль который кроме вас никто не знает. Сетевой администратор очень МОГУЩЕСТВЕННЫЙ ЧЕЛОВЕК и он может изменить любые настройки вашей учетной записи, поэтому с ним надо дружит и почитать его...

Служба каталогов (directory service) - сетевая служба, которая идентифицирует все ресурсы сети и делает их доступными пользователям.

Или

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

Контролер домена - это компьютер на котором установлено Active Directory. 

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

Объект – это самостоятельная единица, которая представляет некий ресурс, существующий в сети. Объекты характеризуются атрибутами. 

Контейнер -  Контейнер аналогичен объекту в том смысле, что он также имеет атрибуты и принадлежит пространству имен. Однако, в отличие от объекта, контейнерне обозначает ничего конкретного: он может содержать группу объектов или другие контейнеры.

Пожалуй это все что мы постигли из описанного выше. Теперь давайте введем еще и другие термины и понятия которые нам будут необходимы для того что бы понять сердце Windows Server 2003 а именно службу каталога Active Directory. 

Еще в Active Directory предусмотрено ряд компонентов, помогающих выстроить структуру каталога в соответствии с нашими потребностями и делятся эти компоненты на логические и  физические компоненты. Рисунок 5.

Рисунок 5.

Логические деление производится на такие компонентами как домены, подразделения (OU organizational unit), деревьями и лесами. Физические делятся на контролеры домена и сайты. Логические и физические компоненты разделены.

Логические структуры

Логическая структура Active Directory по сути представляет собой контейнеры, которые используются для хранения объектов службы каталога (разделов каталога, доменов и лесов) на предприятии. Что бы это понять проще так и представляйте себе некий контейнер в котором хранится все остальное, в том числе и другие контейнеры, ну что то наподобие матрешки.Логическая структура иди группировка позволяет отыскивать сетевые ресурсы по именам, не запоминая их физическое местоположение. Исходя из того что все ресурсы сети группируются по логическому принципу физическая структура сети не видна пользователям. Отношения между доменами, подразделениями и лесами отражено на рисунке 6.

Рисунок 6  

Домены

Домены это базовые элементы, логической структуры службы каталога Active Directory. Устанавливая Active Directory вы хотите этого или нет, сразу создаете домен. Количество объектов входящих в домен может исчисляться миллионами. 

Домены — это объединения компьютеров, коллективно управляемых с помощью контроллеров домена, т. е. систем Windows Server 2003, регулирующих доступ к сети, базе данных каталога и общим ресурсам.

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

Active Directory может содержать от одного до большого количества доменов. Иногда домены проектируются в зависимости от физического местоположения. То есть к примеру если у нашего предприятия есть центральный офис и еще несколько филиалов к примеру на южном полюсе (где не жарко) и в Бразилии (где много Абизьян) то у нас будут три домена разделенные по физическому (в данном случае географическому) местоположению. 

Общие характеристики для всех доменов таковы:

  • Все объекты сети существуют в рамках того домена в котором они были включены.
  • Границами домена определяются границы безопасности.

Доступ к объектам домена осуществляется в базе так названых "списками управления доступом" (ACL - access control list) в которых содержатся информация о разрешениях на каждый объект домена. Эти разрешения определяют, к примеру, каким пользователям разрешен доступ к конкретному объекту в сети и какие права  каждого пользователя на данный объект.

Все настройки безопасности и политики (о политиках поговорим дальше) распространяются строго в границах домена. У администратора есть неограниченные права  в границах домена.

Домены еще характеризуются режимом работы. Режим работы домена (domain functional level). В Windows 2000 Server он называется режимом домена (domain mode).   Эти режимы работы домена позволяют Active Directory работать с доменами которые созданы в других операционных системах таких как Windows 2000 Server и Windows NT 4. Короче, они, режимы работы домена, созданы для совместной работы и совместимости предыдущих  доменов созданных в  перечисленные операционные системы с  доменами созданные в Active Directory Windows 2003 Server. Рисунок 7.

Рисунок 7. 

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

Домены Active Directory организованы в иерархическом порядке. Первый домен на предприятии становится корневым доменом леса, обычно он называется корневым доменом или доменом леса. Корневой домен является отправной точкой для пространства имен Active Directory. Например, первый домен в организации "рога и копыта" (RK) будет   — rk.com. Первый домен может быть назначенным (dedicated) или неназначенным (non-dedicated) корневым доменом. Назначенный корневой домен, называемый пустым корнем, является пустым доменом-заменителем, предназначенным для запуска Active Directory. Этот домен не будет содержать никаких реальных учетных записей пользователя (группы) и использоваться для назначения доступа к ресурсам. Единственные учетные записи, которые содержатся в назначенном корневом домене — это учетные записи пользователей и групп, заданных по умолчанию, таких как учетная запись Administrator (Администратор) и глобальная группа Domain Admins (Администраторы домена). Неназначенный корневой домен - это домен, в котором создаются учетные записи фактических пользователей и групп. Причины выбора назначенного или неназначенного корневого домена леса обсудим позже.

Остальные домены на предприятии существуют или как равные по положению (peers) по отношению к корневому домену, или как дочерние домены. Равные по положению домены находятся на том же иерархическом уровне, что и корневой домен. На рисунке 6 показана модель доменов. Простите слегка неудачный рисунок 6 но перерисовывать не буду так как и так будет понятно. Домены - "домен1" справа и "домен1" слева равных по положению. А домен - "домен2" и "домен n" дочерние по отношению к вышестоящему домену(домен1 в нашем рисунке) . 

Выше мы начали использовать такой термин как "общее пространство имен". Что бы понять проще что такое "общее пространство имен" попробуем привести пример и на основе примера понять этот термин и еще иерархию доменов. И напишем так:                            

  - все домены, устанавливаемые после корневого домена, становятся дочерними доменами. Дочерние домены используют одно и то же "пространство имен" Active Directory совместно с родительским доменом которому админ задает ему его имя (или произвольно или исходя из требований предприятия). Например, если первый домен в организации "рога и копыта" назван rk.com, то дочерний домен в этой структуре, допустим находящимся в Антарктиде может называться antarctida.rk.com. Если организация "рога и копыта"  достаточно большая, то могут потребоваться дополнительные дочерние домены, например, создать отдельный дочерний домен по сбору рогов (что в изобилии в Антарктики у участников различных экспедиций так как жены у них допустим в Европе), тогда мы сохраняя общее пространство имен создаем новый домен roga.arctida.rk.com.  На рисунке 8 показана родительско-дочерняя иерархия домена для организации rk.

Рисунок 8.

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

Пространство имен - это область, в которой может быть распознано данное имя (то есть данное имя приобретает какой-то смысл). 

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

И еще запомните что домены в Active Directory не совсем то же самое что и домены интернета. Так как скажем "интернетовский" домен – поддерево в пространстве доменных имен. Имя домена (в интернете) отражает положение и путь к сетевому устройству в системе DNS, а домен Active Directory это группа компов, подчиненные и управляемые Active Directory. 

Подразделения (OU-организационные единицы)  

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

На рисунке 9 показана гипотетическая компания в России "Рога и Копыта" которая имеет филиал в Антарктиде и занимается отпиливанием и сбором рогов у Антарктидских членов различных экспедиции. Компания родилась из того что рога у членов экспедиции особенно хорошо растут так как они в экспедиции по году и больше, а  жены одни дома и это приносит хорошую прибыль компании. В России, в центральном офисе находятся два подразделения. Первое "Администрация" (ну там директор и секретарши разные) а так же отдел по "сбору информации о женах", для передачи информации сотрудникам из Антарктиды, что бы он не искали и ждали,  а сразу знали у кого из членов различных экспедиций пилить рога, что сразу увеличивает производительность сотрудников (пильщиков рогов) из Антарктиды. В Антарктиде у компании есть такие отделы как производство, который занимается изготовлением из рогов художественных подделок. Производство основана в Антарктике потому что вес подделок меньше чем вес рогов непосредственно что уменьшает транспортные расходы. Также там находится художественный отдел, занимающийся разработкой новых форм изделий а также отдел бухгалтерии ведущий счет спиленным рогам и конечного продукта, и отдел непосредственно пильщиков рогов.  Вам как администратору сети необходимо было создать адекватную структуру подразделений (OU) которая соответствовало потребностям конторы "Рога и Копыта". И в конечном счете вы создали такую структуру подразделений (OU) которое по вашему мнению соответствует и отвечает требованиям конторы. Рисунок 9.

Рисунок 9

Здесь мы не будем обсуждать правильно или нет вы создали свои OU а просто показали что в OU "Антарктида" входят два OU "Производство"   и "Художественный". А соответственно в OU "Производство" входит OU "Бухгалтерия", а в OU "Художественный" OU "Отпильщики Рогов".  То есть можно говорит что одни OU вложены в другие. Что касается правильного построения логики Active Directory содержащих эти OU, с учетом нашей компании, то мы поговорим отдельно и исправим ошибки.

Так как подразделение или OU -организационные единицы  являются контейнерами, то естественно в него можно помещать и другие  объекты. Эти объекты которые можно поместить в контейнере "подразделение" (OU), следующие:

  • компьютеры;
  • контакты;
  • группы;
  • принтеры;
  • пользователи;
  • общедоступные папки;
  • организационные единицы.

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

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

Организационные единицы позволяют создать гибкую структуру назначения прав на доступ к объектам внутри OU. Прав на доступ к объектам называются "разрешениями". Сама организационная единица OU имеет список управления доступом (ACL — Access Control List), в котором можно назначать права на доступ к этой OU. Каждый объект в OU и каждый атрибут объекта имеет ACL-список. Это означает, что вы можете очень точно контролировать административные права, данные кому-либо в этом подразделении. Например, вы можете дать группе "AdvansUser" (Продвинутые Пользователи) право изменять пароли пользователей в этой OU, не при этом не изменяя любые другие свойства учетных записей пользователя если даже они захотят этого сделать. Можно дать отделу Human Resources (Отдел кадров) право изменять личную информацию, касающуюся любой учетной записи пользователя в любом OU, но не давать им никаких прав на другие объекты.

Еще одной важной функцией OU является объединение объектов в группы так, чтобы этими объектами можно было одинаково управлять. К примеру  группировка объектов в административных целях является ситуация, когда пользователи нуждается в одинаковой стандартной конфигурации рабочего стола компьютера и одинаковом наборе приложений. В этом случае пользователи объединяются в одну OU, и используется групповая политика (group policy) для конфигурирования рабочего стола и управления инсталляцией приложений. Не пугайтесь раньше времени, если пока что не понятно, мы все это обсудим позже.

Деревья

Если несколько доменов используют общие пространство имен Active Directory то в таком случае говорится о дереве Active Directory.

Деревом (tree) называется группировка или иерархическая структура одного или нескольких доменов использующая общие пространство имен Active Directory. 

Формируется дерево путем введения нескольких дочерних доменов в состав родительского или корневого домена. Рисунок 10.

Рисунок 10.

Иерархичность структуры имен как вы видите из рисунка 10 сохраняется путем добавление нового имени в иерархии имен путем разделения от корневого имени через точку. Если у нас корневой домен rk.com то дочерние домены второго уровня в данном случае (только в данном) сохраняют общие пространство имени и добавляют новое имя через точку. У нас домены второго уровня по отношению к корневому домену rk.com будут дочерние домены arctida.rk.com и office.rk.com. А домен третьего уровня в нашей иерархии с соблюдением пространства имен будет домен roga.arctida.rk.com. Повторяюсь - уровни доменов в данном случае взяты по отношению к корневому домену rk.com. Когда поговорим о DNS то тогда станет понятнее иерархия доменов вообще. А пока мы берем за отсчет корневой домен. Но тем не менее должен сказать что все имена формируются согласно стандарту DNS и согласно этому стандарту доменное имя дочернего домена формируется как относительное имя разделенная точкой от родительского домена.

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

Леса

Лесом (forest) - называют несколько деревьев принадлежащих одному предприятию или фирме, или сформулируем более академически.

Лесом - называется группировка или иерархическая система, состоящая из одного или нескольких полностью независимых друг от друга деревьев доменов. 

После того как мы уже знаем что такое дерево можем понять такое выражение. Имена в иерархии имен DNS бывают (а именно DNS определяет стандарт имен) бывают  смежными (contiguous) или несмежными (discontiguous). То есть если мы имеем дерево то имена смежные и прорастают от одного корня (родителя). Если лес то имена несмежные. Все домены и доменные деревья существуют в пределах одного или несколько лесов Active Directory.

Перечислим характеристики леса.

  • Все домены в составе леса построены на основе общей схемы. (Слово "схема" пока понимайте как построены одинаково т.е. по умолчанию, к понятию схема мы вернемся потом, пока оставим ее в покое что бы не запутается окончательно).
  • Общая конфигурация доверительных отношений. Все домены в лесу автоматически сконфигурированы так, чтобы доверять всем другим доменам леса. Более подробно о доверительных отношениях чуть позже. Все домены леса связаны неявными двухсторонними транзитивными отношениями.
  • Структура имен деревьев леса различаются в соответствие с доменами.
  • Домены в составе леса функционируют независимо друг от друга, но в то же время лес позволяет обменивается информацией между любыми доменами (в независимо от дерева в котором он состоит) в пределах всей организации которой принадлежит лес.

Пример леса на рисунке 11. Пусть наша фирма или предприятие "Рога и Копыта" разбогатела и приобрела фирму "Хвосты и Уши" у которой было сове дерево доменов. Что бы не ломать дерево администраторы решили новое дерево ввести в состав леса. И теперь у предприятия "Рога и копыта" лес состоящий из двух деревьев с родительскими доменами rk.com и xu.com 

Рисунок 11.

Там на рисунке написано репликация. Привыкайте к этому слову, потом о нем поговорим. 

Теперь как и в случае с доменом лес так же имеет свои режимы работы. Это связано с тем что бы обеспечит совместимость между различными Active Directory от прошлых сетевых операционных систем такие как NT4, 2000 и 2003. Режимы работы представлены на рисунке 12. 

Рисунок 12.

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

Теперь нам следует рассмотреть и физические структуры но сделаем это в следующей статье Active Directory. Физическая структура

alterego.ucoz.org

Создание объектов Organizational Unit в домене Active Directory.

Я рассмотрю вариант создание Organizational Unit средствами командной строки.

Данная заметка является продолжением статьи по работе с Active Directory.

Нажать сочетание клавиш “Win+R” для вызова диалогового окна “Run” (Выполнить) и набрать в нем команду “cmd”.

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

          Перед нами откроется окно командной строки, в нем наберем:

dsadd ou “ou=IT,dc=polygon,dc=local”

Для наглядного просмотра, что мы только, что сейчас сделали предлагаю воспользоваться Active Directory Users and Computers.

Из меню “Start” – “Control Panel” – “Administrative Tools” – запускаем оснастку “Active Directory Users and Computers”.

Такой способ более удобен если нужно создать структуру с помощью скрипта без запуска GUI интерфейса оснасток.

www.ekzorchik.ru

Dmitriy Poberezhniy IT technology

Сама структура Active Directory практически не изменилась, с того момента как была представлена в 2000 году. Не подверглось изменению и понятие “Организационная единица” (OU) в структуре AD.  Многие организации игнорируют и не уделяют большое внимание структуре OU, чтобы более эффективно управлять AD, повысить простоту управления. Давайте разберемся с дизайном OU, как это работает, и зачем нам вообще это нужно.

Сразу хочу сказать,  все что  тут изложено – мое личное мнение, и не претендует быть эталоном  и примером для подражания :) 

Что такое OU?

OU является объектом Active Directory, и используется для размещения других объектов, которые создаются и содержатся в инфраструктуре Active Directory. OU отличаются от Контейнеров, которые также являются неотъемлемой частью AD, тем  что с OU можно связать Объект Групповой Политики (GPO), а для Контейнера этого сделать нельзя. Казалось бы, что это мелочь – но это очень важная мелочь! Вот перечень Контейнеров:

В основном OU используются для размещения таких объектов:

  • User accounts
  • Group accounts
  • Computers
Можно конечно создать в контейнере  общие папки и принтеры, но пользы от таких объектов в AD мало.
OU по умолчанию
При первоначальной установки AD, создается только  одна OU. Default Domain Controllers  - является единственной OU по умолчанию которая создается, и предназначено доя размещения и управления контроллеров домена. Администратор домена может создавать неограниченное количество OU. Но со временем, слишком большое количество OU может затруднить управления ними.
Для чего создавать OU. Причина №1
Первая причина для создания OU – это управление объектами такими как: Учетные записи пользователей, Группы пользователей.  Меньше конечно требуется для управление объектов “Computer” (я имею ввиду  атрибуты AD). Примеры управления которые можно предоставить для Учетных записей и Групп пользователей:
  • Users - создание, удаление, изменение свойств пользователя
  • Groups - создание, удаление, изменение членства в группе
При использовании OU для раздачи определенных прав на объект, который расположен внутри – называется делегированием. Существует специальный мастер  для делегирования прав объектов, а также можно напрямую раздать права на OU. Но хочется отметить, что последний способ не самый лучший.

Рисунок 1: Мастер делегирования для OU.

Для чего создавать OU. Причина №2

Вторая причина для создания OU является развертывание объекта GPO. Когда объект групповой политики связан с OU, параметры объекта групповой политики применяются только к объектам в этом подразделении и к объектам которые расположены в дочерних подразделениях. Это позволяет легко и эффективно распространять групповые политики только для пользователей и компьютеров, которые нуждаются в настройках.Объекты групповой политики могут быть связаны с доменом и сайтами Active Directory, но тогда  труднее управлять и конфигурировать GPO. Более эффективно управлять и распространять GPO используя как раз OU.

Планирование структуры подразделений
Прежде чем начать планирование OU, приходится обговаривать много деталей. Намного легче планировать структуру подразделений с чистого листа, чем реорганизовать уже существующую структуру. Но реалии таковы, что мы часто перепроектируем структуру AD, вместо того чтобы продумать ее перед развёртыванием.Что же следует учесть проектируя структуру подразделений:

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

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

  • какие учетные записи должны иметь одинаковые настройки и учетные записи пользователей, у которых должны быть разные настройки?

    • эти параметры нужно разделить на категории, согласно требований для вашей организации. Категории могут включать в себя: подключение сетевых дисков,  настройки безопасности, настройки IE, настройки приложения и т.д.

  • какие учетные записи компьютеров должны иметь одинаковые настройки и  учетные записи компьютеров с разными настройками?

    • прежде всего нужно отделить сервера от настольных компьютеров

    • категории десктопов могут быть: IT, Руководители, Разработчики, Финансы, HR, HelpDesk и др.

    • категории на которые можно разделить сервера: DCs, SQL, Web, Intranet, Финансы, HR, и т.д.

Сколько нам нужно OUs?

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

И того…

OUs для AD просто необходимы. Без использования OUs решать вопросы связанные с управлением,  устранением неисправностей, намного сложнее. Постарайтесь не думать над дизайном, а логически подумайте, как вы хотите делегировать и как вы хотите развернуть объекты групповой политики. Не забывайте, что некоторые параметры объекта групповой политики (Group Policy Preferences ) позволяют связывать объект групповой политики в зависимости от ряда условий, при этом повышая эффективность применения групповой политики.

 

 

 

dimsan.blogspot.com

Организационные единицы в AD DS

Организационные единицы в AD DS

Организационной единицей (Organizational Unit — OU) называется контейнер админи­стративного уровня, подобный показанному на рис. 6.1, который используется для логиче­ской организации объектов в AD DS. Концепция организационной единицы происходит от стандарта облегченного протокола доступа к каталогам (Lightweight Directory Access Protocol — LDAP), на основании которого создавалась AD DS, хотя между самим LDAP и AD DS существуют концептуальные различия.

Объекты в Active Directory могут логически помещаться в организационные единицы в соответствии с указаниями администратора. Хотя объекты всех пользователей по умол­чанию помещаются в контейнер Users (Пользователи), а объекты всех компьютеров — в контейнер Computers (Компьютеры), они могут перемещаться оттуда в любой момент.

Используемые по умолчанию папки Users (Пользователи) и Computers (Компьютеры) в AD DS с технической точки зрения являются не организационными единицами, а скорее объектами класса Container. Это очень важно понимать, поскольку объекты класса Container ведут себя не так, как организационные единицы. Чтобы получить возможность должным образом использовать службы вроде групповых политик (Group Policies), работа которых зависит от функциональности организационных единиц, объ­екты пользователей и компьютеров рекомендуется перемещать из стандартных контей­неров в структуру OU.

На каждый объект в структуре AD DS можно ссылаться в запросах LDAP за счет ука­зания конкретного места, в котором он находится в структуре OU. Подобные ссылки бу­дут довольно часто встречаться при написании сценариев для модификации или создания пользователей в AD DS либо просто при выполнении LDAP-запросов к AD DS.

Организационные единицы в основном удовлетворяют потребность в делегировании прав на администрирование различным группам администраторов. Хотя существуют и другие возможные способы применения организационных единиц, делегирование прав на администрирование все-таки является главной причиной для создания OU в среде AD DS.

cmd4win.ru