Создание проекта инфраструктуры Active Directory крупной компании

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Содержание

Введение

Глава 1. Теоретические основы инфраструктуры Active Directory

1.1 Логическая структура Active Directory

1.1.1 Объекты

1.1.2 Домены

1.1.3 Деревья

1.1.4 Организационные единицы

1.2 Доверительные отношения

1.2.1 Внешнее доверие

1.2.2 Доверие к сокращению

1.2.3 Доверие к сфере

1.2.4 Доверие к лесу

1.2.5 Разбиение базы данных

1.2.6 Физическая структура сети

1.2.7 Контроллеры домена

1.2.8 Роли, действующие в границах леса

1.2.9 Обще доменные роли

1.2.10 Сайты

1.2.11 Репликация в Active Directory

1.2.12 Внутрисайтовая репликация (intrasite replication)

Глава 2. Проектирование инфраструктуры Active Directory

2.1 Постановка задачи

2.2 Построение географической модели

2.2.1 Локальная модель

2.2.2 Региональная модель

2.2.3 Национальная модель

2.2.4 Международная модель

2.2.5 Филиалы

2.2.6 Дочерние компании

2.2.7 Анализ географической модели

Глава 3. Проектирование моделей лесов и доменов

3.1 Применение одного домена

3.2 Применение нескольких доменов

3.2.1 Планирование текущей модели доменов

3.2.2 Проектирование структуры организационных единиц

3.2.3 Организационные единицы (OU)

3.2.4 Архитектура, основанная на объектах

Глава 4. Планирование стратегии репликации

4.1 Архитектура основная на задачах

4.2 Планирование структуры OU

4.2.1 Применение OU для ограничения видимости объектов

4.2.2 Применение OU для управления групповой политикой

4.2.3 Планирование наследования

4.2.4 Параметры программ

4.2.5 Параметры Windows

4.2.6 Разрешение GPO из нескольких источников

4.2.7 Проектирование топологии сайтов

4.2.8 Выбор структуры сайтов



Введение

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

Традиционный способ обращения с колоссальным объемом информации о сетевых ресурсах хранение ее в отдельных каталогах, которые обычно управляются приложением или компонентом операционной системы, использующим эту информацию. Например, всего несколько лет назад в версиях Windows, предшествующих Windows 2000. вы могли бы обнаружить несколько каталогов с информацией, разбросанной по серверам этой сети. Списки пользователей и управления доступом хранились в каталоге, который назывался базой данных Security Accounts Manager (SAM). Почтовые ящики Exchange Server и их сопоставления с пользователями размещались в каталоге Exchange. Прочие службы и приложения поддерживали свои каталоги. Хотя взаимодействие между этими каталогами в какой-то мере было возможным, по большей части они были изолированными.

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

Active Directory централизованная служба каталогов с единой базой данных сетевых ресурсов, которой легко управлять и в которой нетрудно вести поиск. Active Directory является масштабируемой, так как позволяет разбивать базу данных на разделы и распределять, ее по доменам сети, в то же время обеспечивая управление ею как единым каталогом, и Active Directory соответствует стандартам, поскольку к ее информации можно обращаться через LDAP (открытый стандарт Интернета, утвержденный IETF). Active Directory расширяема, что позволяет разработчикам использовать каталог для хранения информации своих приложений. Active Directory безопасна, так как тесно интегрирована с системой защиты Windows Server 2003. Active Directory абстрагирует логическую структуру сети и идентификацию сетевых ресурсов от ее физической структуры.

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

Настоящая курсовая работа предназначена для создания проекта инфраструктуры Active Directory крупной компании.



Глава 1. Теоретические основы инфраструктуры Active Directory

1.1 Логическая структура Active Directory

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

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

· объекты;

· домены;

· деревья;

· леса;

· организационные единицы

1.1.1 Объекты

Ресурсы хранятся в Active Directory как объекты. Объекты хранятся в Active Directory в виде иерархической структуры контейнеров и под контейнеров, упрощающей поиск, доступ и управление. Объект на самом деле представляет собой просто набор атрибутов. Например, объект пользователя (user object) состоит из таких атрибутов, как имя, пароль, телефонный номер, сведения о членстве в группах и т. д. Атрибуты, образующие объект, определяются классом объекта. В частности, класс пользователя описывает атрибуты, из которых состоит объект пользователя.

Классы помогают классифицировать объекты по сходным характеристикам. Все объекты пользователей относятся к классу Users. Когда создается новый объект, он автоматически наследует атрибуты от своего класса. Microsoft определяет исходный набор классов объектов (и атрибутов, которые они описывают), используемых Active Directory. Конечно, поскольку Active Directory расширяема, администраторы и приложения могут модифицировать доступные классы объектов и атрибуты, определенные в этих классах, в Active Directory Schema. Классы и атрибуты, определяемые ими, собирательно называются Active Directory Schema в терминологии баз данных схема (schema) это структура таблиц и полей, а также их взаимосвязи. Active Directory Schema можно считать набором данных (классов объектов), определяющим то, как организована и хранится реальная информация (атрибуты объекта) в каталоге.

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

1.1.2 Домены

Базовая организационная структура в сетевой модели - домен. Домен представляет административную единицу (administrative boundary). Компьютеры, пользователи и другие объекты внутри домена делят общую базу данных защиты (security database).

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

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

Например, полное доменное имя (fully qualified domain name, FQDN) сервера msnews в домене microsoft.com выглядело бы так: msnews.microsoft.com. сеть домен программа windows

1.1.3 Деревья

Несколько доменов организуется в иерархическую структуру, называемую деревом (tree). На самом деле, даже если в организации лишь один домен, у вас все равно имеется дерево. Первый домен, созданный в дереве, является корневым. Следующий домен считается дочерним по отношению к корневому. Это позволяет создавать в дереве множество доменов. Пример дерева показан на рис.1.1 Здесь microsoft.com первый домен, созданный в Active Directory, поэтому он считается корневым доменом

Рис. 1.1 Дерево

Единственное дерево достаточно для тех организаций, которые пользуются одним пространством имен DNS. Но для организаций, где задействовано несколько пространств имен DNS, одного дерева мало. Вот здесь и применяется такая концепция, как лес.

Лес - это группа из одного или более деревьев доменов, которые не образуют непрерывного пространства имен, но могут совместно использовать общую схему и глобальный каталог. В сети всегда есть минимум один лес, и он создается, когда в сети устанавливается первый компьютер с поддержкой Active Directory (контроллер домена). Первый домен в лесу, называемый корневым доменом леса (forest root domain), играет особую роль, так как на нем хранится схема, и он управляет именованием доменов для целого леса. Его нельзя удалить из леса, не удалив сам лес. Кроме того, в иерархии доменов леса нельзя создать домен, который находился бы над корневым.

На рис. 1.2 показан пример леса с двумя деревьями. У каждого дерева в лесу свое пространство имен. В данном случае microsoft.com это одно дерево, а contoso.com другое. Оба дерева находятся в лесу с именем microsoft.com.

Рис. 1.2. Деревья в лесу используют одну схему, но разные пространства имен

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

1.1.4 Организационные единицы

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

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

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

1.2 Доверительные отношения

Поскольку домены разграничивают зоны безопасности, специальный механизм, называемый доверительными отношениями (trust relationships), позволяет объектам в одном домене [доверяемом (trusted domain)] обращаться к ресурсам в другом [доверяющем (trusting domain)].

Windows Server 2003 поддерживает шесть типов доверительных отношений: в доверие к родительскому и дочернему доменам (parent and child trusts), а доверие к корневому домену дерева (tree-root trusts), доверие к внешнему домену (external trusts);

· доверие к сокращению (shortcut trusts);

· доверие к сфере (realm trusts);

· доверие к лесу (forest trusts).

Доверие к родительскому и дочернему доменам, а также к корневому домену дерева

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

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

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



1.2.1 Внешнее доверие

Внешнее доверие используется, когда нужно создать доверительные отношения между доменом Windows Server 2003 и доменом Windows NT 4.0. Поскольку ограниченные домены (down-level domains) (домены, не поддерживающие Active Directory) не могут участвовать в двусторонних транзитивных доверительных отношениях, следует использовать внешнее доверие. Внешнее доверие является односторонним. Доверяющий домен разрешает доступ к своим объектам пользователям из доверяемого домена, но в обратном направлении доверие не действует. Впрочем, вы можете создать два раздельных внешних доверия (действующих в противоположных направлениях) между двумя доменами для имитации двустороннего доверия.

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

1.2.2 Доверие к сокращению

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



Рис. 1.3. Хотя все домены связаны транзитивными доверительными отношениями, разрешение этих связей требует времени

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

1.2.3 Доверие к сфере

Доверие к сфере новшество Windows Server служит для подключения домена Windows Server к сфере Kerberos, которая не поддерживает Windows и использует протокол защиты Kerberos V5. Доверие к сфере может быть транзитивным или не транзитивным, одно или двусторонним.

1.2.4 Доверие к лесу

Доверие к лесу тоже новшество Windows Server упрощает управление несколькими лесами и обеспечивает более эффективное защищенное взаимодействие между ними. Этот тип доверия позволяет обращаться к ресурсам в другом лесу по той же идентификации пользователя (user identification, ID), что и в его собственном лесу.



1.2.5 Разбиение базы данных

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

Поскольку домены основные строительные блоки сети, имеет смысл разделять каталог по границам доменов. Каждый домен содержит раздел каталога, который хранит информацию об объектах в этом домене. Разделы из всех доменов леса образуют полный каталог Active Directory.

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

1.2.6 Физическая структура сети

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

1.2.7 Контроллеры домена

Контроллер домена - это сервер под управлением Windows Server 2003, на котором установлена и работает служба Active Directory. В домене можно создать любое число контроллеров. На каждом контроллере домена хранится полная копия раздела каталога данного домена. Контроллеры домена локально разрешают запросы на информацию об объектах в своем домене и пересылают в другие домены запросы на информацию, отсутствующую в данном домене. Контроллеры домена также отслеживают изменения в информации каталога и отвечают за репликацию этих изменений на другие контроллеры. А раз каждый контроллер домена хранит полную копию раздела каталога для своего домена, это означает, что контроллеры следуют модели репликации с несколькими хозяевами (multimaster model). То есть каждый контроллер просто хранит мастер копию раздела, и с его помощью можно модифицировать эту информацию.

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

1.2.8 Роли, действующие в границах леса

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

Хозяин схемы (Schema Master). Первый контроллер домена в лесу принимает роль хозяина схемы и отвечает за поддержку и распространение схемы на остальную часть леса. Он поддерживает список всех возможных классов объектов и атрибутов определяющих объекты, которые находятся в Active Directory. Если схему нужно обновлять или изменять, наличие Schema Master обязательно, и Хозяин именования доменов (Domain Naming Master). Протоколирует добавление и удаление доменов в лесу и жизненно необходим для поддержания целостности доменов. Domain Naming Master запрашивается при добавлении к лесу новых доменов. Если Domain Naming Master недоступен, добавление новых доменов невозможно; однако при необходимости эта роль может быть передана другому контроллеру.

1.2.9 Общедоменные роли

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

Хозяин RID [Relative Identifier (RID) Master]. Отвечает за выделение диапазонов относительных идентификаторов (RID) всем контроллерам в домене. Идентификатор защиты (security identifier, SID) уникальный идентификатор каждого объекта в домене. SID в Windows Server состоит из двух частей. Первая часть общая для всех объектов в домене для создания уникального S1D к этой части добавляется уникальный RID. Вместе они уникально идентифицируют объект и указывают, где он был создан.

Эмулятор основного контроллера домена [Primary Domain Controller (PDC) Emulator].

Отвечает за эмуляцию Windows NT 4.0 PDC для клиентских машин, которые еще не переведены на Windows 2000, Windows Server или Windows ХР и на которых не установлен клиент службы каталогов. Одна из основных задач эмулятора PDC регистрировать устаревшие клиенты. Кроме того, к эмулятору PDC происходит обращение, если аутентификация клиента оказалась неудачной. Это дает возможность эмулятору PDC проверять недавно измененные пароли для устаревших клиентов в домене, прежде чем отклонять запрос на вход.

Хозяин инфраструктуры (Infrastructure Master). Регистрирует изменения, вносимые в контролируемые объекты в домене. Обо всех изменениях сначала сообщается Infrastructure Master, и лишь потом они реплицируются на другие контроллеры домена. Infrastructure Master обрабатывает информацию о группах и членстве в них для всех объектов в домене. Еще одна задача Infrastructure Master передавать информацию об изменениях, внесенных в объекты, в другие домены.

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

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

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

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

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

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

1.2.10 Сайты

Сайт Windows Server - это группа контроллеров доменов, которые находятся в одной или нескольких IP-подсетях (о подсетях см. занятие 3) и связаны скоростными и надежными сетевыми соединениями. Под скоростным подразумеваются соединения не ниже 1 Мбит/с. Иначе говоря, сайт обычно соответствует границам локальной сети (local: network, LAN). Если в сети несколько LAN, соединенных региональной сетью (wide network, WAN), вы, вероятно, создадите по одному сайту для каждой LAN.

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

Сайты не являются частью пространства имён Active Directory. Когда пользователь просматривает логическое пространство имен, компьютеры и пользователи группируется в домены и OU без ссылок на сайты. Сайты содержат объекты только двух типов. Первые это контроллеры доменов в границах сайта, а вторые связи сайта (site links), сконфигурированные для соединения данного сайта с остальными.

Связи сайта. Внутри сайта репликация осуществляется автоматически. Для репликации между сайтами вы должны установить связь между ними. Связь состоит из двух частей: физического соединения между сайтами (обычно WAN-канала) и объекта связи сайта (site link object). Этот объект создается в Active Directory и определяет протокол передачи трафика репликации [Internet Protocol (IP) или Simple Mail Transfer Protocol SMTP)]. Объект связи сайта также инициирует выполнение запланированной репликации.

1.2.11 Репликация в Active Directory

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

В Windows Server применяется модель репликации с несколькими хозяевами (multimaster replication model), в которой все реплики (точные копии) базы данных Active Directory считаются равными хозяевами (equal masters). Мы можем вносить изменения в эту БД на любом контроллере домена, и изменения будут реплицированы на другие контроллеры доменов.

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

Пока мы не сконфигурируем свои сайты в Active Directory, все контроллеры доменов автоматически включаются в один сайт по умолчанию с именем «Default-First-Site- Name», который создается при создании первого домена.

Если нам нужно контролировать трафик репликации по более медленным WAN- каналам, создаём дополнительные сайты. Например, у нас есть группа контроллеров домена в основной LAN и несколько контроллеров домена в LAN филиала, как показано на рис.4. Эти две LAN соединены медленным WAN-каналом (256 Кбит/с). Внутри каждой LAN репликация между контроллерами домена может выполняться по мере необходимости, но репликацией по WAN-каналу следует управлять, чтобы не мешать передаче более приоритетного сетевого трафика. С этой целью мы могли бы создать два сайта: один включает все контроллеры домена в основной LAN, а второй - все контроллеры домена в удаленной LAN.

Рис. 1.4. Сайты позволяют управлять трафиком репликации по низкоскоростным соединениям

1.2.12 Внутрисайтовая репликация (intrasite replication)

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

Межсайтовая репликация (intersite replication). Все данные передаются в сжатом виде. Здесь учитывается вероятность того, что трафик будет передаваться по более медленным WAN-линиями связи, но нагрузка на серверы возрастает из-за необходимости компрессии/декомпрессии данных. Мы можем использовать не только сжатие, но и планировать репликацию на те периоды времени, которые наиболее оптимальны для нашей организации. Например, разрешать репликацию лишь в те часы, когда сетевой трафик между двумя сетями уменьшается. Конечно, такая задержка в репликации (на основе расписания) может приводить к рассогласованию информации на серверах, входящих в разные сайты.

Глава 2. Проектирование инфраструктуры Active Directory

2.1 Постановка задачи

В данной работе я должен спроектировать инфраструктуру Active Directory для предприятия Crazy занимающегося производством плазменных телевизоров. Crazy планируется как одна из ведущих международных компаний в этой области. Планируется расположить главный офис в городе Нижнем Новгороде. Заводы по производству комплектующих и завод по сборке плазменных телевизоров планируется разместить в городе Токио и его пригородах. Разработкой экранов и панели займется Американская компания, CrazyTM о приобретении которой заранее известно. Исследовательский центр по разработке плат планируется открыть в Москве.

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

Таблица 1

Города	Отделы	Количество пользователей
Нижний Новгород	Отдел управления	10
	Отдел маркетинга	20
	Финансовый отдел	20
	Юридический отдел	5
	Служба безопасности	3
Москва	Исследовательский отдел	15
	Отдел дизайна	5
	Отдел тестирования	10
	Отдел тех.поддержки	50
	Бухгалтерия	5
	Служба безопасности	7
Токио и пригороды	Производственно технический отдел (ПТО)	30
	Отдел хранения и транспортировка	35
	Отдел комплектации	10
	Контроль качества	5
	Бухгалтерия	10
	Служба безопасности	15
Чикаго	Отдел разработки	25
	Дизайнерский отдел	20
	Отдел тестирования	10
	Отдел тех. поддержки	40
	Производственно технический отдел	15
	Хранение и транспортировка	25
	Служба безопасности	8
	Контроль качества	5
	Юридический отдел	15
	Отдел управления	10
	Финансовый отдел	15

2.2 Построение географической модели

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

Microsoft определяет четыре основные географические модели: локальная, региональная, национальная и международная. Кроме того, существуют два других типа офисов, которые могут вам понадобиться, дочерние фирмы и филиалы (branch offices).

2.2.1 Локальная модель

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

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

2.2.2 Региональная модель

В региональной модели все участки находятся в пределах одной, четко очерченной территории. Пример региональной сети показан на рис. 2-1.

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



2.2.3 Национальная модель

Масштаб национальной модели на ступень выше региональной. Хотя одно ее название предполагает, что данная компания территориально охватывает всю страну (обычно так и бывает), еще одна отличительная особенность, которая позволяет отнести компанию к национальной модели, сложность сети. Компания, отвечающая национальной модели, скорее всего, располагает разными WAN-каналами от разных провайдеров. Наличие более медленных каналов (менее 512 Кбит/с) между несколькими участками также усложняет ваш проект и позволяет отнести сеть такой компании к национальной модели. Соединения удаленного доступа используются гораздо чаще и могут быть частично основаны на WAN-каналах. Возможно применение разных топологий сетей, например Asynchronous Transfer Mode (ATM) и Frame Relay.

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

· наличие офисов в нескольких часовых поясах;

· необходимость учета различий в местном законодательстве;

· большее число пользователей.

2.2.4 Международная модель

Главная отличительная характеристика компании, соответствующей международной модели, ее сети пересекают границы стран (рис. 2-2). Многое из того, что относится к национальной модели, распространяется и на международную. Тот факт, что такая компания использует каналы связи разных типов от разных провайдеров, осложняется тем, что соединения устанавливаются по международным линиям. Важно, чтобы мы понимали стоимость различных соединений и их надежность. Эта модель требует гораздо более тщательного планирования по сравнению с остальными.

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

2.2.5 Филиалы

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

Филиалы, как правило, не выступают в роли связующих звеньев, или хабов (hubs) между другими офисами; вместо этого каждый филиал соединяется с главным офисом напрямую (рис. 2-3). Конечно, бывают и исключения. В особо крупных, распределенных компаниях, например в сети универмагов (department stores), можно обнаружить, что региональные филиалы связаны с национальной штаб-квартирой. В свою очередь более мелкие филиалы могут подключаться к региональным филиалам, а не напрямую к главному офису. Это позволяет распределить полномочия в управлении структурой сети и работать эффективнее, так как каждый региональный филиал управляет более мелкими филиалами.

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

2.2.6 Дочерние компании

Дочерняя компания (subsidiary office) является частью основной компании, но не управляется ею. Классический пример - организация, купившая другую компанию, чтобы предлагать на рынке специфические услуги второй компании (возможно, в увязке со своими услугами).

Обычно дочерняя компания располагает собственным штатом администраторов и ИТ - отделом - в конце концов, раньше она была отдельным предприятием. Проектировщику

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

2.2.7 Анализ географической модели

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



Глава 3. Проектирование моделей лесов и доменов

3.1 Применение одного домена

Простейшая модель Active Directory - единственный домен (рис. 3-1). Подавляющее большинство сетей во всем мире позволяет использовать единственный домен, поэтому такая модель, хотя и может показаться не столь гибкой, как другие, обычно заслуживает самого тщательного рассмотрения. В сущности, при планировании структуры Active Directory полезно всегда исходить из предположения, что будет использоваться один домен, и пытаться остаться в рамках этой модели. Это хороший способ отличить соблазн создать более сложную структуру от действительной необходимости так поступить.

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

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

Домены Active Directory масштабируемы в гораздо большей мере, чем домены Windows NT. Поэтому исчезает существенное препятствие, не позволявшее применять однодоменные сети на основе Windows NT, в которых диспетчер учетных записей безопасности (Security Accounts Manager, SAM) поддерживал только до 40000 объектов в домене. В отличие от Windows NT в домен Active Directory может входить более миллиона объектов. Для еще большей масштабируемости доменов Active Directory используются два типа элементов: организационные единицы (ОU) и сайты.

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

Как правило, структура OU соответствует функциональной или бизнес-структуре организации. Например, мы могли бы создать по одной OU для каждого территориального участка вашей организации, чтобы местные администраторы получили возможность управлять ресурсами этих участков; при этом все объекты входили бы в один домен. На рис. 3-2 показан один домен, разбитый на OU по географическому принципу.



Рис. 3-2. Применение OU для разделения административных функций между территориальными участками

OU предназначены для логического деления домена, что позволяет делегировать административные полномочия, а сайты используются, чтобы физически разбить домен для управления трафиком репликации между контроллерами домена, связанными WAN - каналами. Сайт - это группа контроллеров домена, находящихся в одной или нескольких IP-подсетях и связанных быстрым и надежным сетевым соединением. Быстрыми считаются соединения со скоростью от 1 Мбит/с. Другими словами, сайт обычно ограничен рамками локальной сети (LAN). Если различные LAN объединены между собой с помощью WAN, мы, скорее всего, создадим по одному сайту для каждой LAN.

3.2 Применение нескольких доменов

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

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

Рис. 3-3. Домены, структурированные по территориальному принципу

Рис. 3-4. Домены, структурированные по функциональному принципу

3.2.1 Планирование текущей модели доменов

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

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

2. Требуется поместить хозяина схемы (schema master) в отдельный домен, не содержащий объектов пользователей или другие ресурсы. Для защиты схемы от несанкционированного доступа годятся обычные средства, но схема чрезвычайно важный ресурс сети с Active Directory. Чтобы обеспечить более надежную защиту, можно поместить компьютер, которому отведена роль хозяина схемы, в свой домен.

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

3.2.2 Проектирование структуры организационных единиц

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

3.2.3 Организационные единицы (OU)

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

OU могут содержать любые объекты следующих типов:

· пользователи;

· компьютеры;

· группы;

· принтеры;

· приложения;

· политики безопасности;

· общие папки;

· другие OU;

3.2.4 Архитектура, основанная на объектах

В структуре OU, основанной на объектах (см. Приложение 4.1, 4.2 и 4.3), делегирование полномочий выполняется в зависимости от типа объектов, которые хранятся в OU. Мы можем выбрать структуру OU, в которой объекты группируются по принадлежности к одному из следующих типов:

· пользователям;

· компьютерам;

· сайтам;

· доменам;

· OU.

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

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

2. Поместить в OU набор объектов, которыми нужно управлять.

3. Делегируем административные задачи для этой OU группы безопасности, в которую мы добавляли пользователя или группу на 1 этапе.



Глава 4. Планирование стратегии репликации

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

В Windows Server используется модель репликации с несколькими хозяевами, при которой на всех контроллерах домена хранятся равноправные копии БД Active Directory. Когда мы создаем, удаляем или переносим объект либо изменяем его атрибуты на любом контроллере домена, эти изменения реплицируются на остальные контроллеры домена.

Поскольку в Active Directory могут храниться множество объектов, репликация изменений этих объектов запросто может отобрать значительную часть пропускной способности сети и системных ресурсов контроллеров доменов. Внутрисайтовая (между контроллерами домена одного сайта) и межсайтовая репликация (между контроллерами домена, относящимся к разным сайтам) выполняется по-разному. При внутрисайтовой репликации трафик репликации передается в несжатом формате. Это объясняется тем, что контроллеры домена, принадлежащие одному сайту, как предполагается, связаны каналами с высокой пропускной способностью. Помимо того, что данные не сжимаются, используется механизм репликации, основанный на уведомлении об изменениях. Значит, если в данные домена вносятся изменения, эти изменения быстро реплицируются на все контроллеры домена. При межсайтовой репликации все данные передаются в сжатом виде. Это отражает тот факт, что трафик, вероятно, передается по более медленным WAN-каналам (в сравнении с соединениями локальной сети, используемыми при внутрисайтовой репликации). Однако при этом увеличивается нагрузка на серверы, поскольку, помимо прочих операций по обработке, им приходится упаковывать/распаковывать данные. Кроме того, репликация выполняется по расписанию во время, лучше подходящее данной организации.

4.1 Архитектура основанная на задачах

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

К этим задачам относятся:

а создание, удаление и изменение учетных записей пользователей;

я сброс сроков действия паролей;

н определение групповой политики;

в управление членством в группах и разрешениями.

4.2 Планирование структуры OU

Служба каталогов Active Directory позволяет весьма точно управлять делегированием административных полномочий. Например, можно предоставить одной группе полный доступ ко всем объектам OU, второй -- права на создание, удаление и изменение объектов OU определенного типа, а третьей -- право управлять определенным атрибутом объектов конкретного типа (скажем, возможностью сбрасывать срок действия паролей учетных записей пользователей). Кроме того, можно сделать эти разрешения наследуемыми, чтобы они применялись не только к данному OU, но и ко всем создаваемым OU более низкого уровня. Такое тонкое управление обеспечивает огромную гибкость.

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

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

* Типы административных задач. Структура верхнего уровня, основанная на административных задачах, относительно постоянна. Какие бы реорганизации не происходили в компании, основные типы административных задач вряд ли сильно изменятся.

* Типы объектов. Как и структура, основанная на задачах, структура, в которой OU верхнего уровня соответствуют типам объектов, обеспечивает устойчивость архитектуры к изменениям.

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

...