Проектирование и реализация инфраструктуры подразделений (OU) и разрешений AD DS. Лекция 4

1.

Проектирование и реализация инфраструктуры подразделений (OU)
и разрешений AD DS
OU (Organizational Units) – это концентрация определенных типов ресурсов –
пользователей и компьютеров, а в реальной жизни – людей и средств
производства.

2.

Планирование делегирования административных задач.
Делегирование объектов Active Directory
Более чем очевидно, что практически в каждой организации ИТ-подразделение
включает в себя нескольких администраторов, и различные административные
задачи должны быть распределены среди администраторов, либо, скажем, среди
членов службы поддержки.
А вот те разрешения, которые можно назначать пользователям, группам или
компьютерам, иначе говоря принципалам безопасности, называются записями
контроля доступа (Access Control Entry, ACE). Следовательно, с помощью ACL
модифицируются разрешения доступа для объекта.

3.

Списки ACL вы можете просматривать непосредственно при помощи таких
оснасток как:
1.
«Active Directory – пользователи и компьютеры»
2.
«Центр администрирования Active Directory»
3.
«Active Directory – Сайты и службы»
4.
«Редактор ADSI»
5.
«LDP»
Если же говорить о разрешениях контроля доступа к объектам AD, то сразу
следует отметить, что они разделены на стандартные разрешения и на особые
разрешения.
Особые разрешения представляют собой гранулированные опции, которые
применяются к конкретному объекту, а стандартные разрешения доступа уже
составляются из набора особых разрешений, которые разрешают, либо, наоборот,
запрещают определенную функцию.

4.

Исключительно в качестве примера можно выделить такое стандартное
разрешение как чтение, ведь на самом деле оно включает в себя записи таких
особых
разрешений
как
чтение
разрешений,
список
содержимого,
а
также прочитать все свойства.
Собственно, все записи ACE располагаются в дискреционном списке контроля
доступа, иначе говоря, в оригинале это звучит как Discretionary Access Control
List, или же, проще говоря, в списке DACL.

5.

ACE (сокр. от англ. Automatic Computing Engine, Автоматическая вычислительная
машина) — проект первого британского компьютера, разработанный Аланом Тьюрингом в
1946 году.
Проектировался исключительно для военных нужд (из всех функций, заявленных
разработчиком машины в 1945 году, только одна могла быть условно названа гражданской:
«Подсчёт военнослужащих по отдельным гражданским специальностям, подлежащих
демобилизации,
на
основе
статистических
данных,
предоставленных
армией».
Министерство обороны Великобритании уделяло особое внимание работе А. Тьюринга над
данным проектом

6.

Сам по себе список DACL является составляющей списка ACL самого объекта,
который еще содержит системный список контроля доступа, другими словами
System Access Control List, SACL. Этот список определяет параметры аудита для
объекта, включая все принципалы безопасности и операции, для которых должен
выполняться аудит.
DACL (англ. Discretionary Access Control List) — список избирательного
управления доступом, контролируемый владельцем объекта и регламентирующий
права пользователей и групп на действия с объектом (чтение, запись, удаление
и т. д.). Состоит из набора ACE’ов (англ. Access Control Entry — элемент списка).
Таким образом, возвращаясь к самой теме данного раздела, делегированием
административных задач называется наследование разрешений родительского
объекта для принципала безопасности, созданного в Active Directory.

7.

Пример делегирование административных полномочий
Следовательно, нужно выполнить следующие действия:
1.
Для начала следует на контроллере домена открыть оснастку «Active
Directory – пользователи и компьютеры». Здесь необходимо создать
глобальную группу безопасности, члены которой смогут присоединять
компьютеры пользователей к домену.

8.

Другими словами, эта группа будет выглядеть следующим образом:

9.

2. Следующим делом необходимо указать, что компьютеры присоединять к
домену могут только лишь пользователи, входящие в созданную на предыдущем
этапе глобальную группу безопасности.
Для этого следует открыть оснастку «Управление групповой политикой» и
перейти к редактору GPME для созданного по умолчанию объекта GPO «Default
Domain Controllers Policy» (Политика Контроллеров Домена по Умолчанию),
который располагается в подразделении «Domain Controllers».
В
отобразившейся
оснастке
следует
перейти
к
узлу
компьютера\Политики\Конфигурация
безопасности\Локальные
политики\Назначение
«Конфигурация
Windows\Параметры
прав
пользователей»
и
локализовать параметр политики, который называется «Добавление рабочих
станций к домену».

10.

Открыв диалоговое окно данного параметра политики, вы сразу сможете
обнаружить, что по умолчанию там указана группа «Прошедшие проверку»,
благодаря
которой
присоединять
компьютеры
к
домену может каждый
пользователь.
Теперь, для того, чтобы разрешить присоединять к домену компьютеры только
пользователям из группы безопасности «Поддержка», следует удалить группу,
указанную в этом параметре политики по умолчанию, а затем при помощи
кнопки «Добавить пользователя или группу» и диалога поиска объектов Active
Directory, следует добавить созданную ранее глобальную группу безопасности.

11.

Процесс добавления такой группы изображен на следующей иллюстрации:

12.

3. Теперь, несмотря на то, что немного ранее было описано, в каких сценариях
выполняется делегирование, и что в большинстве случаев делегирование
выполняется на уровне подразделений, в данном случае для предоставления
возможности
присоединения
компьютеров
к
домену,
нам
следует
в
оснастке «Active Directory – пользователи и компьютеры» вызвать мастер
делегирования непосредственно для уровня всего домена.

13.

Следовательно,
в
оснастке
«Active
Directory
–
пользователи
и
компьютеры» необходимо в области дерева самой оснастки вызвать контекстное
меню для домена и выбрать опцию «Делегирование управления», как показано
ниже:

14.

4. На первой странице мастера можно просто ознакомиться с основной задачей
данного средства и, ввиду того, что на первой странице нельзя выполнять какиелибо действия, следует просто нажать на кнопку «Далее».
На второй странице мастера, странице «Пользователи и группы», нужно
локализовать группу, для которой необходимо делегировать управление.

15.

В данном примере следует нажать на кнопку «Добавить» и при помощи
соответствующего диалога выбрать группу «Поддержка», как показано на
следующей иллюстрации:

16.

5. Страница «Делегируемые задачи» позволяет вам определить конкретные
операции, которые должны выполнять в доменных службах Active Directory
пользователи
или
группы
пользователей,
которые
были
добавлены
на
предыдущей странице мастера.
Так как в данном примере делегируется задача присоединения компьютеров к
домену
и
такую
задачу
можно
найти
в
предоставленном
списке
распространенных задач, следует напротив задачи «Присоединение компьютера
к домену» установить флажок и нажать на кнопку «Далее».

17.

Создание особой задачи будет показано далее в этой статье, а делегирование
задачи присоединения компьютера к домену изображено на следующей
иллюстрации:

18.

6. На последней странице мастер повторно проинформирует о том, что работа
мастера была успешно выполнена и определенной группе пользователей было
передано управление для присоединения компьютеров к домену, что, собственно,
и являлось поставленной перед нами задачей:
Теперь,
после
выполнены
все
того
эти
как
были
действия,
присоединять компьютеры к домену
смогут только лишь те пользователи,
которые
являются
членами
созданной ранее глобальной группы
безопасности «Поддержка».

19.

Определение задач, для которых было предоставлено делегирование
Все возможные варианты просмотра задач, для которых было передано
делегирование, в рамках одной статьи рассматривать просто бессмысленно,
поэтому далее в данной статье будут представлены несколько основных
вариантов:
1.
Первый метод – это использование оснастки «Active Directory –
пользователи и компьютеры». Прежде всего, для того чтобы просмотреть
задачи, которые были делегированы, следует в меню «Вид» включить для
самой оснастки отображение дополнительных компонентов.
После этого необходимо перейти к диалоговому окну свойств подразделения, для
которого
выполнялось
делегирование.
Так
как
в
предыдущем
разделе
выполнялось делегирование для уровня всего домена, в данном примере
открывается диалоговое окно свойств домена.

20.

В отобразившемся диалоговом окне следует перейти на вкладку «Безопасность»,
а
затем
оттуда
вызвать
диалоговое
окно
дополнительных
параметров
безопасности.
Здесь, в отобразившемся диалоговом окне, вы можете обнаружить все записи
ACE, которые были заданы как по умолчанию, так и при помощи мастера
делегирования.

21.

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

22.

2. Теперь рассмотрим более изощренный метод, а именно использование LDP.exe.
На этот раз следует выполнить следующие действия:
а) Откройте инструмент LDP и при помощи меню «Подключение» подключитесь
к контроллеру домена по порту 389, как показано на следующей иллюстрации:

23.

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

24.

в) Теперь можно подключиться к необходимому подразделению или же сразу ко
всему домену, выбрав команду «Дерево» из меню «Вид».
В том случае, если следует просмотреть весь домен, можно оставить поле
пустым, однако если вы планируете просматривать конкретное подразделение,
следует указывать различающееся имя в следующем формате:
«OU=имя OU, DN=domain…».

25.

г) Затем для того, чтобы увидеть, кому было предоставлено делегирование,
следует просмотреть всю структуру в древовидном представлении.
Уже находясь в привычной области дерева, необходимо выбрать подразделение,
предоставление прав к которому следует проверить, а затем из контекстного меню
выбрать команду «Дополнительно» и «Дескриптор безопасности».

26.

В отобразившемся диалоговом окне обязательно удостоверьтесь в том, что у вас
выбран правильный DN, а также в том, что установлен флажок на опции «Список
ACL», как показано на следующей иллюстрации:

27.

д) При необходимости вы также можете отредактировать либо удалить
делегируемые разрешения, воспользовавшись соответствующими кнопками.
Диалоговое окно дескрипторов безопасности, как и окно редактирования
делегируемых разрешений, отображены на следующей иллюстрации:

28.

Третий вариант в какой-то степени можно назвать более модернистическим, так
как сейчас мы определим, какие разрешения были назначены этой же группе
поддержки, но уже при помощи оснастки «Центр администрирования Active
Directory».
Для этого следует открыть данное средство, выбрать в дереве оснастки
подразделение, для которого следует просмотреть, кому было предоставлено
делегирование, а затем перейти к свойствам выбранного объекта, например, как
показано на следующей иллюстрации, непосредственно из контекстного меню:

29.

После работы с оснасткой «Active Directory – пользователи и компьютеры» вы
сможете сразу определиться, что нужно сделать.
В отобразившемся диалоговом окне следует перейти к группе «Разрешения», и
просто останется лишь выбрать требуемую группу и перейти к диалогу
дополнительных параметров безопасности.

30.

Группа разрешений отображена ниже:

31.

4. Если вы любитель командной строки, то вас никто не ограничивает. Для
просмотра разрешений, позволяющих контролировать действия пользователей в
Active Directory, предусмотрена такая утилита командной строки как DSACLS.
Зачастую данная команда выполняется с отличительным именем объекта.
Например, для того, чтобы узнать, у кого есть разрешения ко всему домену,
следует выполнить команду:
DSACLS DC=331zone,DC=com

32.

Результат выполнения команды виден на следующей иллюстрации:

33.

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

34.

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

35.

Диалоговое окно данной страницы мастера делегирования изображено на
следующей иллюстрации:
После этого, на следующей
странице
мастера,
странице «Разрешения» —
следует
указать,
что
делегируется
разрешение
«Запись»,
этого будет достаточно.
и

36.

Так как задачу по перемещению можно разделить на две части – удаление объекта
из контейнера «Computers» и последующее создание объекта в другом
подразделении – исключительно в качестве примера, создание объектов в
специально созданном подразделении для учетных записей компьютеров будет
продемонстрировано
безопасности
для
средствами
требуемого
изменения
подразделения
дополнительных
(подобные
параметров
действия
были
рассмотрены в предыдущем разделе).
Сейчас, в том случае, если вы закрывали оснастку «Active Directory –
пользователи и компьютеры», нужно включить для нее отображение
дополнительных компонентов, а затем перейти к диалоговому окну свойств
подразделения, в которое должны перемещаться учетные записи компьютеров. В
моем случае это подразделение «Клиенты».

37.

В диалоговом окне свойств данного подразделения следует перейти ко
вкладке «Безопасность», а затем открыть диалоговое окно дополнительных
параметров безопасности.
В отобразившемся диалоговом окне следует локализовать добавленную ранее
группу и удостовериться, что сотрудникам группы поддержки разрешается
присоединять компьютеры к домену, но разрешения, связанные с удалением
объектов, здесь отсутствуют, а затем перейти к диалогу изменения разрешений
посредством нажатия на кнопку «Добавить».

38.

В
отобразившемся
Computers»
диалоговом
необходимо
добавить
окне
группу,
«Элемент
которой
разрешения
будут
для
применяться
разрешения. Другими словами, нажмите на ссылку «Выберите субъект» и при
помощи соответствующего диалогового окна локализуйте группу «Поддержка».
Так как внутри созданного ранее подразделения могут находиться дочерние
подразделения с различной разбивкой (например, компьютеров по отделам), из
раскрывающегося списка «Применяется к» следует выбрать опцию «Этот
объект и все дочерние объекты», что и установлено по умолчанию.

39.

Осталось только выбрать требуемое разрешение. Так как нам нужно разрешить
перемещать компьютеры, а это означает, что объекты будут создаваться внутри
данного и всех вложенных контейнеров, следует установить флажок напротив
разрешения «Создание объектов: Компьютер», после чего сохранить все
внесенные изменения. Диалоговое окно «Элемент разрешения для «Клиенты»»
показано ниже:

40.

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

41.

Исследование существующей инфраструктуры DNS
Первый шаг в проектировании инфраструктуры DNS должен состоять в
исследовании уже имеющейся инфраструктуры DNS. В большинстве случаев
служба DNS в Active Directory должна взаимодействовать с имеющейся
инфраструктурой DNS.
Это может означать просто конфигурирование ретранслятора в существующем
сервере DNS, использование имеющегося DNS-сервера как основного для Active
Directory или отсутствие развертывания DNS в Windows Server 2003.
Active Directory требует, чтобы работала служба DNS, однако существует
несколько вариантов ее развертывания.

42.

При исследовании существующей инфраструктуры DNS необходимо выполнить
следующие действия:
1.
задокументировать все DNS-имена доменов, используемые в настоящее время
в пределах компании. Сюда входят имена, встречающиеся в Интернете, а
также внутренние имена;
2.
задокументировать
все
дополнительные
имена,
которые
компания
зарегистрировала для возможности использования в Интернете;
3.
задокументировать существующую конфигурацию серверов DNS. Эта
документация должна включать типы DNS-серверов, в настоящее время
развернутых в сети. Кроме того, конфигурация DNS должна содержать
информацию о ретрансляторах, о делегировании зон и о конфигурации
основных и дополнительных серверов.

43.

Выбор доменных имен DNS
При настройке DNS-серверов рекомендуется сначала выбрать и зарегистрировать
уникальное родительское имя DNS, которое будет представлять организацию в
Интернете. Это имя является доменом второго уровня внутри одного из доменов
верхнего уровня, используемых в Интернете.
Прежде чем задавать родительское имя DNS для организации, необходимо
убедиться, что это имя не присвоено другой организации. Родительское
имя DNS можно соединить с именем местоположения или подразделения внутри
организации для формирования других имен доменов следующих уровней.

44.

Для внедрения Active Directory существуют два вида пространств имен
(внутреннее и внешнее), при этом пространство имен Active Directory совпадает с
заданным зарегистрированным пространством имен DNS или отличается от него:
1.
Совпадающие внутреннее и внешнее пространства имен
2.
Отличающиеся внутреннее и внешнее пространства имен

45.

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

46.

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

47.

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

48.

Можно создать иерархию ОП в домене: в отдельном домене разместить
пользователей и
ресурсы,
повторив
структуру компании
в
конкретном
подразделении.
Таким образом, можно создать логичную и осмысленную модель организации и
делегировать административные полномочия на любой уровень иерархии.

49.

В каждом домене разрешается внедрять собственную иерархию ОП. Если организация
имеет несколько доменов, то можно создать структуры ОП внутри каждого домена
независимо от структуры в других доменах.
Организационное подразделение позволяет:
1.
Отразить структуру компании и организации внутри домена. Без ОП все
пользователи поддерживаются и отображаются в одном списке независимо от
подразделения, местоположения и роли пользователя;
2.
Делегировать управление сетевыми ресурсами, но сохранить способность
управлять ими,
то
есть
присваивать
административные
полномочия
пользователям или группам на уровне ОП;
3.
Изменять организационную структуру компании;
4.
Группировать объекты так, чтобы администраторы легко отыскивали сетевые
ресурсы.

50.

Не следует создавать структуру OU исключительно ради того, чтобы просто
иметь какую-то структуру: OU используются в определенных целях.
К этим целям относятся:
1.
Делегирование административного управления объектами
2.
Ограничение видимости объектов
3.
Управление применением групповой политики

51.

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

52.

Ограничение видимости объектов
В некоторых организациях определенные объекты должны быть скрыты от
определенных администраторов или пользователей.
Даже если запретить изменение атрибутов объекта, пользователи, имеющие
доступ к контейнеру с таким объектом, все равно смогут видеть, существует ли
этот объект.
Однако можно скрыть объекты, поместив их в OU и ограничив круг
пользователей, которые имеют разрешение на список содержимого (List Contents)
для этой OU. Тогда объекты, помещенные в контейнер, будут невидимы
пользователям, не имеющим этого разрешения.

53.

Управление применением групповой политики
Групповая политика позволяет применять одни и те же параметры конфигурации
сразу к нескольким объектам. С ее помощью можно определять параметры
пользователей (например, ограничения, налагаемые на пароли) или компьютеров.
При
использовании
групповой
политики
создается
объект
групповой
политики (Group Policy Object, GPO) - объект, связанный с доменом, сайтом или
OU и содержащий параметры конфигурации, которые требуется применить.
Возможности ОП облегчат обеспечение безопасности и выполнение любых
административных задач.
Первый
этап
проектирования
административной
структуры
защиты
планирование использования организационных единиц (OU) в каждом домене.
-

54.

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

55.

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

56.

Существует много способов структурирования ОП в организации. На этапе
планирования развертывания Active Directory важно определить, какая модель
ляжет в основу иерархии ОП.
Например, существуют следующие модели классификации ОП в иерархии ОП:
1.
Модель деления на ОП согласно выполняемым задачам.
ОП можно создавать, учитывая функции, которые необходимо выполнять внутри
организации.
подразделениям
Верхний
уровень
компании,
при
ОП
может
соответствовать
этом
следующие
уровни
ОП
бизнес-
это
функциональные подразделения внутри бизнес-подразделений.
2. Географическая модель деления на ОП. Иногда при создании ОП
учитывается местоположение филиалов компании.
Верхний уровень ОП соответствует региональным подразделениям организации,
а второй уровень представляет физическое местоположение офисов компании.

57.

3.
Модель
деления
на
ОП
согласно
выполняемым
задачам
и
географическому местоположению.
В некоторых случаях две описанные выше модели создания ОП совмещают.
Верхний уровень ОП учитывает, где географически расположены офисы
компании.
Второй
уровень
ОП
построен
на
основе
функциональных
особенностей каждого подразделения внутри организации.
4. Физические участки.
В филиалах, физически расположенных в разных местах (особенно, когда
компания действует на обширной территории, например в нескольких странах),
часто имеются свои ИТ-отделы, поэтому у филиалов разные требования к
администрированию.
Создание отдельного OU верхнего уровня для каждого филиала - один из
вариантов
архитектуры,
основанной
на
задачах;
в
зависимости
местонахождения определяются разные административные задачи.
от

58.

5. Типы административных задач.
Структура
верхнего
уровня,
основанная
на
административных
задачах,
относительно постоянна. Какие бы реорганизации не происходили в компании,
основные типы административных задач вряд ли сильно изменятся.
6. Типы объектов.
Как и структура, основанная на задачах, структура, в которой OU верхнего уровня
соответствуют типам объектов, обеспечивает устойчивость архитектуры к
изменениям.
При планировании структуры OU верхнего уровня для среды с несколькими
доменами есть смысл подумать о создании структуры верхнего уровня, которая
будет одной и той же для каждого домена сети.
Создание структуры OU, одинаковой для различных доменов, позволяет
реализовать единый подход к администрированию и поддержке сети.

59.

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

60.

Стандартные модели структуры OU
Наряду с перечисленными выше моделями классификации ОП в иерархии ОП
можно использовать следующую терминологию для стандартных моделей:
1.
Модель структуры OU на основе местоположения.
2.
Модель структуры OU на основе структуры организации.
3.
Модель структуры OU на основе функций.
4.
Смешанная модель структуры OU - сначала по местоположению, затем по
структуре организации.
5.
Смешанная модель структуры OU - сначала по структуре, затем по
местоположению.

61.

62.

Проектирование и внедрение стратегии групп AD DS
Гибкость Active Directory позволяет создать структуру сети, оптимизированную
для вашей организации. Здесь рассказывается о планировании внедрения Active
Directory.
Вы сможете:
1.
Спланировать структуру домена
2.
Спланировать пространство имен домена
3.
Спланировать структуру ОП
4.
Спланировать структуру сайта

63.

Планирование структуры домена
Поскольку основным звеном логической структуры в Active Directory является
домен, который может хранить миллионы объектов, важной задачей является
тщательное планирование его структуры.
При этом вы должны принять во внимание:
1.
Структуру логической и физической среды вашей организации
2.
Требования администрирования
3.
Требования к структуре домена

64.

Оценка логической среды
Для определения логической структуры организации необходимо понимать, как
организация работает. Например, на рис. 18 показано воображаемое деление
фирмы Microsoft по функциональному и географическому признакам.
Фирма состоит из функциональных подразделений Administration (Управление),
Purchasing (Закупка), Sales (Продажа) и Distribution (Распространение). Фирма
имеет офисы в городах Канзас-Сити, Сент-Паул, Чикаго и Коламбус.

65.

66.

Требования пользователей и сети
Для каждого функционального и географического подразделения выясните:
1.
Количество сотрудников
2.
Темпы роста
3.
Планы расширения
Для оценки сетевых требований для каждого географически изолированного
подразделения определите:
1.
Организацию сетевых соединений
2.
Скорость каждого сетевого соединения
3.
Использование сетевых соединений
4.
Подсети TCP/IP

67.

Например, на рисунке (Слайд №68) показаны требования для Microsoft. В четырех географически изолированных подразделениях организации работает
примерно одинаковое количество служащих.
Однако, если рассматривать функциональные подразделения, то больше
сотрудников занято в группе Administrators. В ближайшие 5 лет планируется 3-
процентный рост всех подразделений.
Офис в Чикаго является концентратором ГВС. Сетевые соединения используются
умеренно, не большая нагрузка приходится на соединение Канзас-Сити — Чикаго

68.

69.

Оценка требований управления
Оценка управления сетевыми ресурсами помогает планировать структуру домена.
Определите способ сетевого
администрирования
вашей организации по
следующим направления администрирования:
1.
Централизованное
администрирование.
поддерживается
одной
используется
небольших компаниях
в
группой
Функционирование
администраторов.
Этот
метод
сети
часто
с ограниченным количеством
подразделений и функций.
2.
Децентрализованное администрирование. Сеть обслуживают несколько
администраторов или групп администраторов. Группы могут делиться в
зависимости
от
местоположения
или
функций,
выполняемых
подразделениями.
3.
Выборочное администрирование. Администрирование части ресурсов
осуществляется централизованно, а части — децентрализовано.

70.

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

71.

Имеет смысл создавать более одного домена, если:
1.
Сетевое администрирование — децентрализованное
2.
Выполняется контроль репликации
3.
Организации предъявляют различные требования к паролям
4.
Имеется множество объектов
5.
В сети используются различные доменные имена Интернета
6.
Необходимо выполнять некие международные требования
7.
Внутренние требования политик различаются

72.

В приведенном примере фирме Microsoft требуются несколько доменов, так как:
1.
В чикагском офисе требования к паролям — более жесткие
2.
Необходимо контролировать репликацию активно используемого соединения
Чикаго — Канзас-Сити
3.
В течение ближайших двух лет планируется создание нового подразделения в
Фарго (Северная Дакота)

73.

Способы организации домена
Если вы решили, что вашей организации нужно несколько доменов, организуйте
домены в иерархию в соответствии с потребностями организации. Можно
организовать домены в виде дерева или леса.
Помните: домены в деревьях и лесах имеют одну и ту же конфигурацию, схему и
глобальный каталог. Совместно использовать ресурсы в таком случае позволяют
двусторонние доверительные отношения.
Основное различие между деревьями и лесами доменов отражено в структуре их
доменных имен (Domain Name Service, DNS). Все домены в дереве имеют
связанное пространство имен DNS.

74.

Если вашу организацию можно представить как группу подразделений, в сети,
вероятно, применяется непрерывное пространство имен DNS, и вам следует
создавать несколько доменов в одном дереве доменов.
Если вы собираетесь объединить организации с уникальными доменными
именами, создавайте лес. Его можно также использовать для разделения зон DNS.
Каждое дерево в лесе имеет свое уникальное пространство имен.
В нашем примере организационная структура фирмы Microsoft привязана к
группе доменов в дереве домена. Microsoft не является подразделением другой
организации, и в будущем не планируется создание подразделений.